Online Calculator for Trajectories with Multiple Gravity Assists

[Krafpy]

Hello !

I released an online tool that allows for automatic planning of interplanetary trajectories with multiple gravity assists.

https://krafpy.github.io/KSP-MGA-Planner/

The tool provides an interactive 3D replica of KSP's solar system where you can zoom on planets and moons. It also provides a time selector to see the KSP's system configuration at a specific date.

The trajectory calculator works in two steps:

1. Generation of a planteray sequence : configure the origin and destination body, and constraints on the trajectory (maximum number of swing-bys...). The sequence generation calculates a set of possible sequences that respect the constraints you've specified.
2. Trajectory optimization : once you've selected a sequence, you specify an earliest and latest departure date, and a parking orbit radius around the departure body. The tool will then run an optimization process to calculate a possible optimal trajectory with the given sequence and departure conditions.

The details of the nomenclature and each settings is detailed in the "How to use" section.

The calculated trajectory will be displayed in the solar system view: interplanetary orbit arcs as well as flyby orbits of each planet encountered. The date and ΔV along each axes of each maneuver are displayed. The trajectory can be vizualised step by step, and you can click on the date of each maneuver to set the system view to that date.

 

July 2022 Update: How to add solar systems

The tool can now support different solar systems from mods. Follow these steps if you want to use the tool on a solar system that is not supported:

1. Fork the project from its github repository (https://github.com/Krafpy/KSP-MGA-Planner) and create a new branch for your solar system.
2. Create a new folder in the `data` folder where the solar system data will be stored (e.g. data/some-system).
3. Copy the `config.yml` and `bodies.yml` files from the `data/stock` to the folder you just created and edit them with your solar system data.
   • `config.yml` stores the global configurations of the tool. These parameters must be changed depending on the properties of the solar system (e.g. duration of a day, camera clip distances for large solar systems...).
   • `bodies.yml` stores the description of each bodies in the solar system. Follow rigorously the edit notes.
     If the solar system uses Kopernicus' .cfg files for configuration, you can directly convert them into a `bodie.yml` file on this page :  https://krafpy.github.io/KSP-MGA-Planner/tools/cfg-to-yml/
4. Add an entry to the `data/systems.yml` file, following the template.
5. Test the tool on your computer with your system. You simply need to run a HTTP sever on the repository folder (I use VSCode live server).
6. Create a pull request to the github repository for me to merge it (only for mods, not personal solar systems).

 

Important notes and current issues :

• Despite the precision of the maneuvers details, it is very unlikely that following them will give the exact same trajectory in game. They do however result in a similar trajectory to the one calculated by the tool, and most of the time only some fine tunings are needed at each maneuver.
• There is no guarantee that the calculated trajectory is the best one. Since multiple gravity assists problems can only be solved using iterative optimization algorithm (here it's a differential evolution algorithm which is implemented), the result only approximates the best solution. It is totally possible that a better trajectory than the one calculated exists.
• A calculated trajectory may be unfeasible (more likely because of unfeasible flybys) in game due to the implementation not (yet) considering some parts of KSP's physics.
• A calculated trajectory may be complete non sense and absurd because of constraints implemented in the optimization process (this is very likely to occur when you look for trajectory between moons like in the Jool's system).

These problems may be solved in the future.

 

I hope this tool may be useful and I'm open to any feedback. Thanks !

Edited August 20, 2022 by Krafpy
July 2022 update

[linuxgurugamer]

Would be nice to see this in-game, so that it can work with any installed planet pack.  But looks very nice

[antipro]

it seems pretty cool and it would be nice to have a mod like this, anyway trying with a Ke-Ev-Ev-Mo and Ke-Mo sequences,
I can't get a result better than a direct Ke-Mo MJ adv transfer at year 168 day 96.

Edited August 18, 2021 by antipro

[Krafpy]

The displayed "total ΔV" does not count the circularization around the destination body. Since you cannot define the final orbit you want to get around the destination body, I judged not necessary to count it in the trajectory details. Note that it is however taken in account by the optimization process which tries to minimize the relative velocity at the arrival.

In the case of the Ke-Ev-Ev-Mo trajectory, the resulting ΔV is higher than a direct Ke-Mo transfer (usually up to 3000 m/s for the first one, and less than 2000 for the second one). This is because there are more maneuvers in the Ke-Ev-Ev-Mo trajectory, thus more ΔV is used to get an encounter. But since the gravity assists lowered your orbit, the final encounter velocity will be smaller than if you did a direct Ke-Mo transfer, which should counter the extra ΔV from the various maneuvers.

(The total ΔV with circularization is however displayed in the dev console if you want to see it : F12 -> Console)

I notice now that this may be confusing, so I'll work on it right now to add the circularization maneuver in the trajectory details.

I also point out that searching in a very wide range of departure dates may result in less optimal trajectories than with smaller ranges.

As for making this a mod (as linuxgurugamer already mentioned it), I considered it at the beginning but I wanted to experiment with the physics and maths of orbital mechanics. But if I manage to improve my current tool and have it working well, I will consider adapting it into a mod (if I have the time...).

 

Edit: I updated the tool so now the ΔV for circularization around the destination body is counted in the total ΔV.

Edited August 17, 2021 by Krafpy

[Snark]

Moving to "Tools and Applications", since this isn't really a tutorial per se.

Very cool work, @Krafpy! 

[antipro]

On 8/17/2021 at 12:27 PM, Krafpy said:

I updated the tool so now the ΔV for circularization around the destination body is counted in the total ΔV.

good, but I still can't calculate a better or at least similar dV result:

MJ adv transfer: 2198 + 1967 = 4165 m/s (at 100km)
MGA: Ke-Mo: 5301 m/s
MGA: Ke-Ev-Ev-Mo: 4470 m/s

Edited August 18, 2021 by antipro

[Krafpy]

1 hour ago, antipro said:

I still can't calculate a better or at least similar dV result

Alright I think I know where this can come from.

I can't really see it on your screenshot, but I guess that on MJ's trajectory, the first maneuver (on Kerbin's parking orbit) is not only prograde but also have a normal component. Which directly gives the correct inclination when you exit Kerbin's SOI, so that the deep space orbit immediatly matches Moho's orbit inclination. Whereas in my implementation, the first maneuver can only be prograde.

This though doesn't explain all as this problem can be countered if the DSM happens right after exiting Kerbin's SOI and gives the correct inclination to the transit orbit. I have another idea of what may cause this, but it's a bit complicated to explain here because it is related to how the trajectory is computed and represented in my program.

It can also simply be an error in dV calculation... (maths mistakes can happen )

Thanks for reporting this problem. I'll try to work on it as soon as I can.

 

 

[antipro]

2 hours ago, Krafpy said:

I guess that on MJ's trajectory, the first maneuver (on Kerbin's parking orbit) is not only prograde but also have a normal component.

yes, it has a normal component of -35, and also the parking orbit is inclined by 25°, that saves about 150 dV compared to if I launch into an Eq orbit.
This is why the navball maneuver indicator is so close to the prograde indicator.

 

2 hours ago, Krafpy said:

Thanks for reporting this problem. I'll try to work on it as soon as I can.

Thx to you for this software.

Edited August 18, 2021 by antipro

[Arrowstar]

This is pretty neat, good work.  It's interesting you went down the DSM route instead of the powered flyby route like I do in KSPTOT's MFMS tool.  Was there a reason for that decision?

Btw, did MFMS inspire any of this?  It looks very similar in some ways lol.

[Krafpy]

Thanks for your comment @Arrowstar

I took the DSM route because it looked "simpler" to implement. In the sense that I could directly use a Lambert solver to find arcs with a guaranteed intersection along with the DSM dV. I don't really know how to implement powered flybys. It would be nice to combine both to have even better trajectories I think.

I didn't really look at existing tools before starting mine. I just got that idea during a physics class and I was curious to learn orbital mechanics, so I thought creating this tool would be interesting. So if it's similar to yours, it's pure coincidence .

My main resource was a Ph.D thesis by Matteo Ceriotti about optimization of multiple gravity assists trajectories. The other sources I used are listed on the github repo of my tool.

I would be curious to see how your tool performs compared to mine (yours would probably win lol, as mine has still a lot of room for improvement). I am using a differential evolution algorithm to optimize the trajectory with a vector representation. What method are you using in your tool ?

 

Edited August 19, 2021 by Krafpy

[antipro]

Hi @Krafpy, I understand that advanced math is familiar to you so,
just out of curiosity, could you write a software similar to MGA but which solves the problem of calculating the best route for a certain Grand Tour?
That is, given a series of celestial bodies, find the best low space flyby sequence, or given the exact sequence of celestial bodies, find the best route?

Edited August 20, 2021 by antipro

[Krafpy]

@antipro So if I understand correctly, extending my MGA to have custom planetary sequences ?

If it's that, then I can definitely add a custom flyby sequence input to my MGA solver. The optimization process doesn't need any change and will search an optimal trajectory that follows the sequence it receives... regardless of if it's from the sequence generator or from a custom input. It was something I was already planning on.

As for the altitude of the flybys, I'm currently limiting the maximum altitude to two times the radius of the body, so that may be enough ? I will see if I can add an input to control that too.

Unfortunately school starts soon for me and I have to prepare a lot homeworks. But I'll try at least to get the sequence input done as soon as possible.

[antipro]

42 minutes ago, Krafpy said:

So if I understand correctly, extending my MGA to have custom planetary sequences ?

correct, for example:
- the user chooses the planets included in his Grand Tour contract > MGA-Planner provides the best sequence and the trajectories.
- the user chooses a specific planetary sequence > MGA-Planner provides the best trajectories.

 

1 hour ago, Krafpy said:

It was something I was already planning on.

good to know.

 

1 hour ago, Krafpy said:

As for the altitude of the flybys, I'm currently limiting the maximum altitude to two times the radius of the body, so that may be enough ?

no, it wouldn't be enough but it doesn't matter, it's not that important in order to complete the Grand Tours contracts.
I said "low space" because of I was thinking about how to get as many scientific experiments as possible.

 

1 hour ago, Krafpy said:

But I'll try at least to get the sequence input done as soon as possible.

Thanks.

[Arrowstar]

19 hours ago, Krafpy said:

Thanks for your comment @Arrowstar

I took the DSM route because it looked "simpler" to implement. In the sense that I could directly use a Lambert solver to find arcs with a guaranteed intersection along with the DSM dV. I don't really know how to implement powered flybys. It would be nice to combine both to have even better trajectories I think.

Powered flybys are a bit challenging, I agree.  The idea is basically to figure out what the delta-v vector at flyby periapsis is that connects your inbound and outbound trajectories.  I admit it took me a few weeks of getting the math worked out back in the day, but it works well now.  I've actually considered adding DSMs to my software but powered flybys work pretty well and I just haven't been interested in doing it yet.

Quote

I would be curious to see how your tool performs compared to mine (yours would probably win lol, as mine has still a lot of room for improvement). I am using a differential evolution algorithm to optimize the trajectory with a vector representation. What method are you using in your tool ?

I use a genetic algorithm as well.  I've tried a few global optimization algorithms but GAs (or DE, same thing basically) seem to work the best.  I definitely found that Direct Search methods and MATLAB's "Global Search" methods didn't work nearly as well.

[Krafpy]

Software update ! You can now enter a custom planetary sequence. This is useful if the automated generator omitted interesting sequences or if you want to define your own routes. The trajectory optimizer will automatically calculate the trajectory for the custom sequence if you specified one. If not specified, then it will use the selected sequence from the proposed ones as before.

For example, the automated generator does not propose a Ke-Ev-Mo route (for some reason I don't know yet). However, setting that sequence manually provides very interesting Kerbin to Moho trajectories ! I managed to get one which requires about 2700m/s of total dV.

@antipro You can define the sequence for your Grand Tours. It doesn't generate a sequence for a particular set of planets though. You have to define the sequence manually, i.e. the visited planets as well as intermediate flybys for eventual gravity assists. For example if you want to visit Eve and Duna, you can enter : Ke-Ev-Ke-Du.

 

(if the input bar looks ugly, it's probably because your web browser saved the previous CSS file in cache, in that case: F12 -> Network -> check "Disable cache" and reload the page)

Edited August 20, 2021 by Krafpy

[Arrowstar]

2 hours ago, Krafpy said:

Software update ! You can now enter a custom planetary sequence. This is useful if the automated generator omitted interesting sequences or if you want to define your own routes. The trajectory optimizer will automatically calculate the trajectory for the custom sequence if you specified one. If not specified, then it will use the selected sequence from the proposed ones as before.

For example, the automated generator does not propose a Ke-Ev-Mo route (for some reason I don't know yet). However, setting that sequence manually provides very interesting Kerbin to Moho trajectories ! I managed to get one which requires about 2700m/s of total dV.

@antipro You can define the sequence for your Grand Tours. It doesn't generate a sequence for a particular set of planets though. You have to define the sequence manually, i.e. the visited planets as well as intermediate flybys for eventual gravity assists. For example if you want to visit Eve and Duna, you can enter : Ke-Ev-Ke-Du.

 

(if the input bar looks ugly, it's probably because your web browser saved the previous CSS file in cache, in that case: F12 -> Network -> check "Disable cache" and reload the page)

So I tried a Kerbin - Eve - Jool - Eeloo flyby with your software tonight and compared it to KSPTOT.  I end up with a total mission delta-v of 2.5 km/s.  Yours seems to settle pretty consistently around 5.5 km/s - 6.0 km/s.

A few questions that might help debug a bit:

• How many individuals are in your DE population?
• How are you bounding the optimization variables?
• Does your Lambert solver consider both long way and short way trajectories?

[antipro]

5 hours ago, Krafpy said:

However, setting that sequence manually provides very interesting Kerbin to Moho trajectories ! I managed to get one which requires about 2700m/s of total dV.

Nice, I've just tried the Ke-Ev-Mo sequence for the whole year 168 and I got:
Departure date: Year 168 - Day 219 - 00:29:05 UT
Total ΔV: 2688.0 m/s
Pretty amazing, isn't it?

Then I tried a typical easy Grand Tour seq. such as "Ke-Ev-Mo-Du-Ke" for the first 100 years and I got:
Departure date: Year 53 - Day 240 - 05:11:55 UT
Total ΔV: 8218.7 m/s

Don't know about the dV, anyway the complete Tour lasted 57 years cause after the Eve swing-by something went bad:
the Apoapsids became very high, more than eeloo's SMA, and just before return home it decided I have to
literally pass through the sun...this will hurt.. eheh..





It takes some time of my slow cpu to calculate 5 or more planets, but I will do other tests. It's just funny.

One thing, if I can say: many Grand Tours contracts end with the "return to kerbin" condition,
therefore it would be useful to be able to choose whether or not to add the last circularization maneuver in the Total dV.
cause in these cases, the last maneuver coming from deep space, is aerobraking and not circularize.

Provided that it is mathematically simple enough, the next step would be to add bodies that do not orbit the same body, I mean Gilly, Ike and Jool's moons.


edit: with the "Ke-Ev-Du-Ke" seq. it seems all went good.
Departure date: Year 99 - Day 408 - 04:58:52 UT
Total ΔV: 3743.5 m/s (minus the circularization dV) 3743.5 - 904.1 = 2.839,4 m/s

Edited August 21, 2021 by antipro

[Krafpy]

6 hours ago, antipro said:

the Apoapsids became very high, more than eeloo's SMA, and just before return home it decided I have to
literally pass through the sun...this will hurt.. eheh..

This is a problem I was aware of and it is on the list of things to fix. So yeah, like I mentionned in my very first post, expect to sometimes get non sense trajectories like this one. As for colliding trajectories, it's something, I thought that, with the way I implemented flybys, shouldn't be possible... but turns out my maths were wrong .

Also note that in the Ke-Ev-Mo-Du-Ke sequence, you are doing a direct transfer from Moho to Duna... which is something that requires a lot of dV. So here it would be interesting I think to add an extra Eve flyby and therefore have the following sequence for your tour : Ke-Ev-Mo-Ev-Du-Ke.

 

6 hours ago, antipro said:

it would be useful to be able to choose whether or not to add the last circularization maneuver in the Total dV.

It is something I can easily add. And since you plan on using aerobraking, I can make so that the optimization process still tries to minimize the relative velocity to Kerbin for example, but without considering the circularization.

 

6 hours ago, antipro said:

It takes some time of my slow cpu to calculate 5 or more planets

Indeed the computations get longer as you add more bodies. I made the computation multithreaded, but this is surely not enough for some processors. I'll add more details about the optimzation step in my next post to answer to Arrowstar. Also I recommend you to have the task manager open if you want to experiment with bigger sequences... to avoid asking too much of your CPU and RAM.

 

6 hours ago, antipro said:

the next step would be to add bodies that do not orbit the same body, I mean Gilly, Ike and Jool's moons.

This is a whole other challenge. Combining gravity assists using planets and their moons is something I thought of at the beginning... but that I will consider when what I have now will work well and have all other issues fixed. I have no idea yet how I this can be implemented... but would definitely be a cool feature.

(Though I don't really think a flyby of Gilly would be of any interest lol)

Currently, you can plan trajectories between Jool's moons, which is I think the most interesting. But all bodies visited (including departure and arrival body) must therefore be Jool's moons only. Though for having tested it, it is more probable to get non sense trajectories.

[Krafpy]

13 hours ago, Arrowstar said:

A few questions that might help debug a bit:

• How many individuals are in your DE population?
• How are you bounding the optimization variables?
• Does your Lambert solver consider both long way and short way trajectories?

So here are more details on the optimization process implementation (as of the day I write this post):

Trajectory parameterization and DE settings

Each agent is a vector of dimension d = 4(n-1)+2 representing a trajectory, where n is the number of bodies in the sequence. The size of the population is set to 500 * d. All components are real valued numbers and represent the variables of a trajectory. In order:

• t₀ : The date of departure (in seconds, between the earliest and latest departure date specified)
• k : The scale of the ejection velocity, as a multiple of the velocity required to eject from the gravitational influence of the departure body at the parking orbit radius (between 1.05 and 3)

Then for each interplanetary leg i (definition in the "How to use" section on the website), the 4 following components are added:

• T_i: The duration of the leg (in seconds) joining the exited body and the next body on the sequence.
• α_i : The offset (in time) on the leg at which the DSM happen (between 0 and 1, so if this component has a value of 0.5 this means the DSM will happen after half of the leg duration).
• θ_i: an angle used to compute the entrance point on the SOI of the next body (described later).
• φ_i : same thing as above ^.

The settings for the DE, as define here : https://en.wikipedia.org/wiki/Differential_evolution , are : CR = 0.9 and F = 0.8. The algorithm I implemented is also the one describe on the wikipedia page.

Trajectory calculation

Currently, the bounds are calculated and applied when the trajectory is computed (in the fitness function of the DE). Because depending on the trajectory, the bounds are different. The trajectory computation steps with bounds calculation are the following:

1. Calculate the parking orbit (equatoral circular orbit).
2. Calculate the ejection velocity : v_ejection = k * √2 * v_circular ; and its corresponding dV : dV₀ = v_ejection - v_circular (we suppose a prograde only maneuver).
3.  Calculate the angle (true anomaly) at which this ejection should be done in order to have a velocity at infinity (i.e. when exiting the SOI) tangent to the departure's body orbit.
4. Propagate the ejection orbit until exiting the SOI, calculate the global state vectors when exiting the SOI.
5. For each leg i :
   1. Calculate the deep space orbit from the state vectors calculated before.
   2. Apply the following bounds to T_i and α_i (simple clamping), let P be the period of the resulted deep space orbit :
      • if the leg is not resonant, then 0.5P ≤ T_i ≤ P and 0.01 ≤ α_i ≤ 0.999.
      • if the leg is resonant, then P ≤T_i ≤ 3P and max( (n_revs - 1) / n_revs ; 0.01 ) ≤ α_i ≤ 0.999, where n_revs = T_i / P (this is to try to avoid the post-DSM arc from having a duration that would give multiple revolutions).
   3. Propagate that orbit for duration  α_iT_i , the resulting position is point A and the velocity vector at that position is v_A0.
   4. Calculate the position of the targeted body at the encounter date (T_i + time of flight until last SOI exit + t₀).
   5. Calculate bounds for θ_i and φ_i (described in the next section) and with that the point at which the SOI of the targeted body is entered: point B.
   6. Slove the Lambert problem to find the orbit that links points A and B in a time (1 - α_i)T_i. This gives the velocity vector at point A and B : v_A and v_B.
   7. Record the DSM dV : dV_i = || v_A - v_A0 ||.
   8. Calculate the relative velocity to the body when entered at point B and the flyby orbit.
   9. Depending on the case :
      • if the body is the destination body : propagate the flyby orbit until its periapsis and calculate the circularization maneuver. END THE PROCESS.
      • if the body is not the destination body : calculate the exit point from the SOI after the flyby, and calculate the global state vectors when exiting the SOI to be used by the next leg.

It can happen that step 5.3. ("Propagate that orbit for duration  α_iT_i") fails and returns NaN values (for a reason I don't really understand yet). If that happens, the agent is randomized again and the trajectory is recalculated.

The Lambert solver doesn't consider long and short ways. I am using ESA's Lambert solver script for pykep (https://github.com/esa/pykep/blob/master/src/lambert_problem.cpp) that I adapted for TypeScript, and simplified to not consider multiple revolutions.

Meaning and bounds of θ and φ

These two angles are used to represent an entrance point on a SOI. In order to do the step 5.5. of the algorithm above, we must solve the Lambert problem to link point A and a point B' which is the position of the planet targeted at the encounter date. This allows us to calculate a relative encounter velocity that will approximately be the same as if we targeted a specific point on the SOI. We normalize this encounter velocity vector and reverse its direction : this gives a vector u pointing in the opposite direction of the incoming velocity.

θ and φ then describe a point around the direction of u that lay in a sort of ring on the SOI surface. We can suppose that the velocity vector with which the spaceship will enter the SOI will be parallel to u. With that said, we clamp θ between θ_min and θ_max which are defined as follow (in a 2D projection):

From the geometry of the figure we deduce that :

• θ_min = arcsin( R_body / R_SOI )
• θ_max = arcsin( R_max / R_SOI )

θ therefore defines where on the purple arc the point will be. φ then defines a rotation angle around u between 0 and 2π.

The point on the SOI is then calculated by:

1. Rotating u along w = u × (1, 0, 0)^T of the angle θ (we need a perpendicular vector in space around which we can rotate), this gives a new vector u'.
2. Rotating u' around u of the angle φ.
3. Multiplying u' by R_SOI.

This gives the position of the entrance point on the SOI (in the coordinate system centered on the body), which lay inside a ring cut on the SOI surface.

In the current implementation, I set : R_max = 2 * R_body.

This was done in the hope to ensure that the flyby is possible considering the entrance point and the relative velocity, and to avoid the flyby orbit to cross through the body's surface (which turns out, for that last assumption, doesn't work).

 

 

I know this is not the most efficient nor the cleanest way to do this (I'm solving a Lambert problem twice for each leg for example). That's why there is a lot of room for improvement. I'm open to any suggestion.

What I'm considering for the moment is to have all components of the agent vectors be values between 0 and 1. Then the specific interpolations will be done during the trajectory computation. This would allow to have constant bounds. I'm also considering replacing the way the T_i's are bound because this causes some problems (try Mo-Ee trajectory).

The source code is available here : https://github.com/Krafpy/KSP-MGA-Planner (I'm planning on rewriting some parts to have a cleaner structure)

Edited August 21, 2021 by Krafpy

[Arrowstar]

Okay so I haven't had a chance to go through and really think about what you said earlier but I do have some thoughts.

10 hours ago, Krafpy said:

The Lambert solver doesn't consider long and short ways. I am using ESA's Lambert solver script for pykep (https://github.com/esa/pykep/blob/master/src/lambert_problem.cpp) that I adapted for TypeScript, and simplified to not consider multiple revolutions.

I'm not talking about multiple revolutions, I'm talking about the concept that every Lambert's problem, even the single rev cases, all have two solutions: one where the transfer angle is greater than 180 deg and one where it's less than 180 deg.  If you're only using one of those solutions everywhere then you're going to have an issue because short way and long way can have radically different delta-v.  Looking at the lambert code you're using, I think the input flag is the "const int &cw" input, though I've run into the ESA ACT's Lambert solver before and I've never been a big fan of their "clockwise" / "counterclockwise" notation.  Anyway, what are you using for that parameter and have you tried changing it to verify that it works the way you think it does? 

I guess on top of that, you might consider playing around with the automatic bounding of the time of flight variables as well, if I'm reading your post correctly.  It can be hard to pick generalized bounds that work for all cases.  It might be worthwhile allowing the user to specify the upper and lower bounds for time of flight between bodies.

That's all I've got for now, there's a lot of math to look at lol.

[Krafpy]

10 hours ago, Arrowstar said:

all have two solutions: one where the transfer angle is greater than 180 deg and one where it's less than 180 deg

Ah ok thanks for the precision. So ESA's script does consider long and short way, and you can indeed configure that with the "cw" parameter. In my adaptation, I removed all parts that deal with this variable (basically just an if statement that changed the sign of some values if this variable was set to 1, at line 90 : https://github.com/esa/pykep/blob/master/src/lambert_problem.cpp#L90), as well as the parts that deal with the "multi_revs" one. So with these constraints added, the Lambert solver in my script calculates one only possible orbit, whether the angle between the positions is greater or smaller than 180°.

I of course tested it. For example, I gave the points r₁ = (R, 0, 0) and r₂ = (0, 0, -R) to the solver (y-axis is up), so the transfer angle between these two points is 270° (if we consider the trigonometric convention for rotation). For the TOF, I gave 2/3 of the period of a circular orbit with radius R. What I expected is the solver to give me a circular orbit, with the arc going from r₁ to r₂ being 2/3 of the circular orbit. Which was indeed the case. And looking at the resulting velocity vectors computed by the solver also confirmed that the rotation was the right one (i.e. same as how planets rotate, and perfectly perpendicular to the orbit, which confirms again that it's a circular one). I have tested several configurations, with angles greater and smaller than 180° and various TOF, and all seemed to give the expected result.

You can also notice in the image on my very first post that the last arc, the pink one from Eve to Moho, has a transfer angle greater than 180° (the DSM happens right after exiting Eve's SOI).

(I don't know if you meant that I should check for both long and short way... but that seems useless because in that case, at least one of the two possible orbit is retrograde, which would required an insanely big dV to get to it... right?)

You can see my adapted script here: https://github.com/Krafpy/KSP-MGA-Planner/blob/master/src/dedicated-workers/libs/lambert.ts

 

10 hours ago, Arrowstar said:

It can be hard to pick generalized bounds that work for all cases.  It might be worthwhile allowing the user to specify the upper and lower bounds for time of flight between bodies.

I wanted to have the most easy/straightforward to use tool, that's why I tried to look for automated bounds. I think that it may not be really obvious for all users which lower and upper bounds they must enter. But if it is not possible to find good automated bounds, I guess I'll have no choice than switch to user-defined ones, or at least make this option available.

As I described in my previous post, the bounds change for each agent in the population of the DE. This is probably a problem because this means that the variables of most of the agents are constantly clamped, probably to the upper or lower bound, at each new generation. There are definitely better automated bounds to look for before switching to user defined ones.

For example, instead of clamping the duration of each leg based on the resulting transfer orbit, which can cause good trajectories to not be considered (try a Mo-Ee trajectory with my tool, the result is really ridiculous), I am thinking of defining the upper and lower bound for that variable with the period of an elliptic orbit joining the exited body and the targeted one (like in a Hohmann transfer). So basically replacing the value of P introduced in my algorithm in step 5.2. with what I just descibed. That would at least give fixed bounds for each variables, and allows more trajectories to be considered.

I also thought of removing the θ angle from the variables, and replacing it by the periapsis radius of the flyby. I think that we can compute θ knowing the incoming velocity and the periapsis radius. This would allow for a better control of the minimum and maximum radius of the flybys.

 

I hope this helps. Do not hesitate to ask for more details or rephrasing if needed.

 I noticed one thing about your software, when looking closer at the drawn trajectory. Are you considering the flybys as instantaneous events ? Or that the bodies' SOI as infinitely small points ?

Edited August 22, 2021 by Krafpy

[Arrowstar]

9 hours ago, Krafpy said:

I noticed one thing about your software, when looking closer at the drawn trajectory. Are you considering the flybys as instantaneous events ? Or that the bodies' SOI as infinitely small points ?

Local gravity wells are modeled as zero radius SOI with instantaneous flybys.  It simplifies the problem space down into a bunch of Lambert arcs while still producing reasonable results.  If people want to model more accurate trajectories, that's what KSPTOT's Mission Architect (and really, Launch Vehicle Designer, which has mostly filled the role of MA for some time now) is for.  LVD numerically integrates equations of motion to produce trajectories and can model discrete vehicle stages, tanks, engines, electrical systems, and can propagate forwards and backwards in time to help make it easier to find those multiple gravity assist trajectories.

[Krafpy]

19 hours ago, Arrowstar said:

Local gravity wells are modeled as zero radius SOI with instantaneous flybys.  It simplifies the problem space down into a bunch of Lambert arcs while still producing reasonable results.

So it would be possible to compute a simplified model with zero radius SOI and instantaneous flybys to have better performance, and which would give the date of DSMs and encounters. And then run a more precise model from the best found solution in the DE considering SOI entrance point and non instantaneous flybys, but the parameters that configure the duration of each leg and the DSM date are fixed. That sounds interesting to try, but would that be efficient ?

Shouldn't it be at least considered that a planet moves during the time of flyby ? In all research papers I've read about the subject, they consider instantenous flybys, which is valid in the case of our real solar system. But in KSP which is a lot smaller, bodies' motion on their orbits even during a single day looks non negligible. That's especially the case for Moho or moons.

But if we do consider the duration of the flyby, this at least requires us to calculate some more parameters of the orbit. We can consider that all flyby orbits would be hyperbolic.. which is still not always the case. In the case of Jool's moons for example, I think it is possible to have an elliptical orbit which apoapsis is outisde of the SOI of the moon.

Edited August 23, 2021 by Krafpy

[Arrowstar]

9 hours ago, Krafpy said:

So it would be possible to compute a simplified model with zero radius SOI and instantaneous flybys to have better performance, and which would give the date of DSMs and encounters. And then run a more precise model from the best found solution in the DE considering SOI entrance point and non instantaneous flybys, but the parameters that configure the duration of each leg and the DSM date are fixed. That sounds interesting to try, but would that be efficient ?

Yes, you can do that, but you'll need to be very careful about trajectory continuity.  You'll also need to re-optimize your flyby times, DSM times and delta-vs, and the rest of it, using the lower fidelity model as a starting point, because once you introduce the higher fidelity models, the answer will change.

Quote

Shouldn't it be at least considered that a planet moves during the time of flyby ? In all research papers I've read about the subject, they consider instantenous flybys, which is valid in the case of our real solar system. But in KSP which is a lot smaller, bodies' motion on their orbits even during a single day looks non negligible. That's especially the case for Moho or moons.

But if we do consider the duration of the flyby, this at least requires us to calculate some more parameters of the orbit. We can consider that all flyby orbits would be hyperbolic.. which is still not always the case. In the case of Jool's moons for example, I think it is possible to have an elliptical orbit which apoapsis is outisde of the SOI of the moon.

I think I maybe see a flaw in your thinking about this problem in general.  Why do we use the zero radius SoI assumption, and the instantaneous flyby assumption, and Lambert arcs, and all that?  It's because it lets us quickly explore the problem space, find reasonable trajectory concepts, and then implement them in a higher fidelity tool.  No one in the "real world" uses software like yours or like my MFMS tool to actually plan a real mission: it's all about exploring the problem space.  Once a trajectory engineer has identified a good trajectory, they always move up to tools that can provide higher fidelity dynamics, like my KSPTOT Mission Architect or Launch Vehicle Designer tools, and rework the trajectory there.

Because of all that, while you can certainly add more fidelity to your code, at some point you'll have to break away from the Lambert arc assumption.  By all means, definitely dive into handling finite sized SOIs and celestial body motion and finite duration flybys and the like!  I just don't know how long you'll be able to keep your tool "simple" (and the underlying code simple!) if you do.  It'll be an interesting science experiment to find out.

[antipro]

hi, it's y179 d259 on my career and I'm planning a new mission for a contract that asks for land on eeloo and return.
anyway I have calculated the total dV needed from a 120km LKO to a 100km LEO, using MJ adv transfer(Ke-Ee), is 3508 m/s, starting the burn at y180 d82.

Trying a Ke-Ev-Jo-Ee seq. with the MGA Planner I only get a dV of 4162.3 m/s at Departure date: Year 180 - Day 363 - 00:16:05 UT,
among other things by passing through Eve's mantle.

now, based on the image below, if I've understood it well, with a Ke-Ev-Jo-Ee maneuvers, it's possible to reach the eeloo orbit with only 2500 m/s.
My question is: assuming that I learn to install and use the "Trajectory Optimization Tool" or "Multi-Flyby Maneuver Sequencer" whatever it is called,
then does the tool interact with the game by creating the maneuvers itself?

Edited August 25, 2021 by antipro