Online Calculator for Trajectories with Multiple Gravity Assists

[Krafpy]

1 hour ago, Eddy119 said:

That sounds pretty good (for me). Can you tell me your input? Thanks

Custom sequence: Ke-Ev-Ke-Ke-Jo
Earliest departure: Year 10
Latest departure: Year 20
Departure and destination altitudes: 100km
No insertion burn

I don't think this input is really useful. You probably just need to run the search several times. It gave me 1350m/s on the third run. A 10 years departure window seems small enough, but I would recommend reducing it down around the dates it gives on the first runs.

Keep in mind that you will still have to fine tune the maneuvers in game. The ones the tool give aren't prefectly accurate.

 

1 hour ago, Eddy119 said:

theAstrogoth's tool gives me 1700m/s. Ugh.

Well no tool is perfect. We both use some approximations and use the same evolutionary algorithm (only the settings are different I think).

[Interplanet Janet]

3 hours ago, Krafpy said:

From what I know, KSPTOT uses a similar search algorithm (a type of evolutionary algorithm), but I think it doesn't compute the details of in-SOI parts to be displayed, so it has less work to do and has probably more chances of finding good trajectories.

I think some of it does, actually; I found this out recently, but there's a horizontal scroll bar on the bottom. If you look, I think it visualizes the planetary flybys.

[Arrowstar]

On 12/16/2022 at 9:24 AM, Krafpy said:

From what I know, KSPTOT uses a similar search algorithm (a type of evolutionary algorithm), but I think it doesn't compute the details of in-SOI parts to be displayed, so it has less work to do and has probably more chances of finding good trajectories.

I do actually!  I developed a semi-analytic way of computing the flyby orbit and the necessary powered flyby maneuver.  It's really quick (because you don't have to solve it numerically), which is why the code runs as quickly as it does.

[Krafpy]

@ArrowstarI remember on the screenshots you sent a while ago I only saw Lambert arcs connecting the different encountered bodies, considering flybys as instantaneous events (calculating powered swingbys analytically if I remember correctly), that's what I meant by "doesn't compute the details of in-SOI parts to be displayed".
Did you add SOI intersection points and in-SOI trajectories when you display the whole trajectory ?

Sorry if my phrasing is bad...

[Arrowstar]

3 hours ago, Krafpy said:

@ArrowstarI remember on the screenshots you sent a while ago I only saw Lambert arcs connecting the different encountered bodies, considering flybys as instantaneous events (calculating powered swingbys analytically if I remember correctly), that's what I meant by "doesn't compute the details of in-SOI parts to be displayed".
Did you add SOI intersection points and in-SOI trajectories when you display the whole trajectory ?

Sorry if my phrasing is bad...

Oh, MFMS has always displayed the flyby trajectories.  It has to compute the flyby trajectories to minimize the burn delta-v, so it was trivial to just display those trajectories.

[Krafpy]

Ah ! Sorry it was a misunderstanding then. My bad !

I would be interested in knowing what's your approach to compute powered swing bys.

[theAstrogoth]

On 12/16/2022 at 8:42 AM, Krafpy said:

There is some randomness involved in the search process. If you enter a smaller departure date range, it should have more chances to find the optimal one.

This is spot on.  There's no way to guarantee that a globally optimal solution, at least that I'm aware of. If you already have some idea of where a good solution lies, you can shrink the search space (i.e. specifying a smaller range of departure dates / transfer leg times) in order to have a better chance of finding a good solution in that region.

On 12/16/2022 at 11:45 AM, Eddy119 said:

theAstrogoth's tool gives me 1700m/s. Ugh.

@Eddy119 You're right, if you use the default 10-year departure time interval, it typically finds a flight plan with ~1700m/s. When I restricted departure times to year 2, it recreated the trajectory in the tutorial, with ~1100m/s .  There's a chance I just got lucky; you might need to re-run the search a few times to find a good solution. 

Side note: I was curious about whether or not the search strategy that @Krafpy and I use holds up to the one used by the KSPTOT, and it seems like the KSPTOT MFMS also struggles to find this particular solution. Using the same range of departure times and using the same mission settings (i.e. ignoring the cost of an arrival burn), the KSPTOT's best solution cost ~3000m/s, even after a few repeated searches. I'm confident that the MFMS can find the desired solution in theory, it's just that global optimization is difficult. You could try increasing the population size for the genetic algorithm in the MFMS (bottom right corner), but this can become computationally expensive.

My guess is that the particular solution you were aiming to recreate is very sensitive to small changes in timing for some reason. This makes it somewhat less likely that the global search techniques we're using are able to find it.

[Arrowstar]

11 hours ago, theAstrogoth said:

Side note: I was curious about whether or not the search strategy that @Krafpy and I use holds up to the one used by the KSPTOT, and it seems like the KSPTOT MFMS also struggles to find this particular solution. Using the same range of departure times and using the same mission settings (i.e. ignoring the cost of an arrival burn), the KSPTOT's best solution cost ~3000m/s, even after a few repeated searches. I'm confident that the MFMS can find the desired solution in theory, it's just that global optimization is difficult. You could try increasing the population size for the genetic algorithm in the MFMS (bottom right corner), but this can become computationally expensive.

A few thoughts here.  First, make sure that the bounds on the flight times are reasonable for each leg of the trip.  If the optimal trajectory is outside the bounds,  it'll never be found.  Second, make sure that you're specifying years correctly. KSPTOT lets users switch between Earth and Kerbal years and it's important to know which you're working with.  Third, if there's no arrival burn, turn off the option to minimize arrival excess velocity since this won't be important anymore. 

I'm sure MFMS can find a good solution to the problem, it's just a matter of setting things up correctly.

[theAstrogoth]

4 hours ago, Arrowstar said:

A few thoughts here.  First, make sure that the bounds on the flight times are reasonable for each leg of the trip.  If the optimal trajectory is outside the bounds,  it'll never be found.  

That's part of the point I was trying to make! As far as I understand it, you can't have 1) a really large space of flight times and departure dates, 2) fast search time, and 3) a guarantee of a good solution.  No matter what, there are going to be some drawbacks to our default options for the things that affect these. No criticism of the MFMS intended 

 

4 hours ago, Arrowstar said:

I'm sure MFMS can find a good solution to the problem, it's just a matter of setting things up correctly.

Since I enjoy digging into the cases where our tools "fail", in case there is an interesting reason or an opportunity for improvement, I spent a little time fiddling this some more. In case anyone wants to replicate any of these tests, here are the "general parameters" (using Kerbal time) for the trajectory as obtained from the video earlier in the thread:

• Kerbin -> Eve -> Kerbin -> Kerbin -> Jool
• Kerbin departure: Y2, D160
• Kerbin->Eve duration: ~199 days
• Eve->Kerbin duration: ~406 days
• Kerbin->Kerbin duration: ~695 days
• Kerbin->Jool duration: ~1661 days
  • Note that this one is outside the default range in the MFMS. Why does Kerbin->Jool have the shortest maximum duration?
• Ignore cost of arrival burn

The video uses unpowered flybys with deep space maneuvers, but they're very small course corrections, so the powered flyby approach could be reasonable as well. Assuming there's not a problem with my initial result, we already have a similar trajectory using powered flybys.

I revisited the MFMS to double check that the parameters I was using were correct, and I kept getting the same results as before. When I tried to provide a very narrow set of search parameters, working backward from a known solution (from either the tutorial video or the result from the KTI), it fails to find valid flyby trajectories and displays a warning. Relaxing the search parameters, it ends up back in the 3+km/s range.

I'll note that after retesting with the KTI a few times, I think that it's likely that my first result was a particularly lucky optimization run. Most of the time I end up with a result around 2km/s, unless I shrink the search space to a relatively small region around the known solution. Enabling DSMs seemed to make the search slightly more reliable.

 

Maybe this particular case might be one that benefits from the use of DSMs? That would explain why Krafpy's MGA Planner tends to do a good job even when the user doesn't narrow the search space very much. 

Edited December 20, 2022 by theAstrogoth

[Arrowstar]

On 12/20/2022 at 1:17 PM, theAstrogoth said:

That's part of the point I was trying to make! As far as I understand it, you can't have 1) a really large space of flight times and departure dates, 2) fast search time, and 3) a guarantee of a good solution.  No matter what, there are going to be some drawbacks to our default options for the things that affect these. No criticism of the MFMS intended 

 

Since I enjoy digging into the cases where our tools "fail", in case there is an interesting reason or an opportunity for improvement, I spent a little time fiddling this some more. In case anyone wants to replicate any of these tests, here are the "general parameters" (using Kerbal time) for the trajectory as obtained from the video earlier in the thread:

• Kerbin -> Eve -> Kerbin -> Kerbin -> Jool
• Kerbin departure: Y2, D160
• Kerbin->Eve duration: ~199 days
• Eve->Kerbin duration: ~406 days
• Kerbin->Kerbin duration: ~695 days
• Kerbin->Jool duration: ~1661 days
  • Note that this one is outside the default range in the MFMS. Why does Kerbin->Jool have the shortest maximum duration?
• Ignore cost of arrival burn

The video uses unpowered flybys with deep space maneuvers, but they're very small course corrections, so the powered flyby approach could be reasonable as well. Assuming there's not a problem with my initial result, we already have a similar trajectory using powered flybys.

I revisited the MFMS to double check that the parameters I was using were correct, and I kept getting the same results as before. When I tried to provide a very narrow set of search parameters, working backward from a known solution (from either the tutorial video or the result from the KTI), it fails to find valid flyby trajectories and displays a warning. Relaxing the search parameters, it ends up back in the 3+km/s range.

I'll note that after retesting with the KTI a few times, I think that it's likely that my first result was a particularly lucky optimization run. Most of the time I end up with a result around 2km/s, unless I shrink the search space to a relatively small region around the known solution. Enabling DSMs seemed to make the search slightly more reliable.

 

Maybe this particular case might be one that benefits from the use of DSMs? That would explain why Krafpy's MGA Planner tends to do a good job even when the user doesn't narrow the search space very much. 

Can I ask, does that 1100 m/s include the Kerbin departure?  Because I can get MFMS to find a solution with about that delta-v if it's just the in-space delta-v after departure. 

Keep in mind that with MFMS because you're specifying the initial orbit completely, you probably have large radial and normal components to your burn unless you get lucky and your departure orbit is in the right orbit plane to begin with.

[theAstrogoth]

2 hours ago, Arrowstar said:

Can I ask, does that 1100 m/s include the Kerbin departure?  Because I can get MFMS to find a solution with about that delta-v if it's just the in-space delta-v after departure. 

Keep in mind that with MFMS because you're specifying the initial orbit completely, you probably have large radial and normal components to your burn unless you get lucky and your departure orbit is in the right orbit plane to begin with.

Here are the details for the solution I’d found. You can see plots of the trajectory here if you scroll down a bit.

It also uses a fully specified, equatorial orbit, and the departure burn is still mostly prograde. The powered flybys are rather inexpensive (<50 m/s)

[Arrowstar]

21 hours ago, theAstrogoth said:

Here are the details for the solution I’d found. You can see plots of the trajectory here if you scroll down a bit.

It also uses a fully specified, equatorial orbit, and the departure burn is still mostly prograde. The powered flybys are rather inexpensive (<50 m/s)

Awesome, that's for the data.  Are the years and days there Kerbin or Earth years and days?  I will see if I can't find this trajectory in MFMS.  

Something I should look into is a quick method for determining the departure delta-v.  Any idea how that tool computes it so quickly?

[theAstrogoth]

36 minutes ago, Arrowstar said:

Are the years and days there Kerbin or Earth years and days?

All the dates are in Kerbin format.

 

37 minutes ago, Arrowstar said:

Something I should look into is a quick method for determining the departure delta-v.  Any idea how that tool computes it so quickly?

It cheats a little bit by avoiding optimizing the departure delta-v. It requires that the periapsis of the departure orbit intersects with the starting orbit (which means there will be no radial component to the burn for a circular parking orbit), which gives you enough information to fully define the shape of the outgoing orbit (from the energy at the SoI exit and the imposed periapsis). Then you just have to perform some rotations to make sure the departure orbit exits in the right direction and you're done!

For non-circular parking orbits, you  can use this approach and iterate the departure periapsis height a few times to make sure that  the parking orbit and departure orbit intersect at the right spot.

The relevant code is here, in case it's helpful for understanding what I'm trying to do. Sorry if it's a little opaque, since helper functions are defined elsewhere.

I was somewhat leery of using this approach, since it does not explicitly optimize for delta-v, but it is fast, which is great for a web app, and it does great for near-circular parking orbits, which are what I imagine users will input most of the time.

 

[ducceeh]

Question/issue: When using the OPM setting the stock planets aren't in the right positions, I checked and this doesn't affect the stock planet setting, although I haven't checked for the other planet packs.

 

Assist Planner:

 

In Game:

[Krafpy]

@ducceeh I don't see the in game picture, so I can't really evaluate how large the difference is.

One possible reason is that there is an issue in OPM's configuration file, which should have been generated from OPM's Kopernicus files. I'll check that.

Can you give the date to which these screenshots correspond to and which planets seem to have the largest difference ? Thanks !

[ducceeh]

The date is Y1 D241, and also at Y1 D1 they line up, so it might be an orbit speed issue? Eve seems to be behind (in game) maybe 20 degrees, Duna is a bit ahead, Kerbin is around 45 degrees behind, and Jool is at least 90 degrees off(all in game).

Dres is also on the opposite side of where the planner says it should be.

Edited February 6, 2023 by ducceeh

[ducceeh]

I will try to imbed the in game image again

Here you go:

[Krafpy]

@ducceeh I still can't see the picture, the link isn't working.

OPM is an extension to the Stock system, so the settings for the stock planets should remain the same. In the Kopernicus files of OPM ( see here: https://github.com/Poodmund/Outer-Planets-Mod/tree/master/GameData/OPM/KopernicusConfigs ) I can't find any file that would modify stock bodies' data. If you compare the positions of the stock planets between the stock setting and the OPM setting on my tool they are the same at any date.
I also checked @theAstrogoth's tool which supports OPM as well ( https://kerbal-transfer-illustrator.netlify.app/ ) and the position of the stock bodies at Y1 D241 seem to be the same as in my tool and as in your first screenshot.

Do you use a custom mod by any chance ? or a combination of mods ?

[Max_Xu]

thanks for your work!!!  this is exactly what I need. i've been looking for it

[akyyy]

Hi!

 

Please, somebody could be making a video tutorial with two planets fly-by, e.g. Mercury-Venus, or Venus-Earth-Mars? Or Eve-Moho?

[Eddy119]

Hi, 

I don't really know where to ask this so I'll ask here. So KEKKJ works when Jool is on the left side of kerbin (across the sun, near conjunction) at launch in general. If it's near opposition (on kerbin's side) then it seems like we need some other way to do it if not waiting years for Jool to be on the right side again...

Anybody have any flybys that take a similar amount of fuel and time to get to Jool in these cases?

Anyway it seems like the calculator can calculate Ke-Eve-Eve-Moho reasonably at about 4000m/s of delta v including circularization... Although some direct transfers also take about that much fuel (depending on if Moho is near periapsis)

[Eddy119]

Maybe one way is to use Eve as the last flyby before Jool... I got 1500m/s for KEEJ or KEEEJ... not sure how to make it <1100m/s for ~6 years though...

[Eddy119]

Just leaving another thing here, self-flybys are called vinf leveraging manuevers. Examples are using Moho flybys to get nearer to Moho's orbital speed or using Kerbin-Kerbin flyby to Jool (Juno style). There are a couple of papers that describe it but not in an informal Kerbal way. I'm not sure how conservation of energy works in this aspect...

https://engineering.purdue.edu/people/james.m.longuski.1/JournalArticles/1997/V_infinityLeveragingforInterplantaryMissions_Multiple-RevolutionOrbitTechniques.pdf

https://dataverse.jpl.nasa.gov/api/access/datafile/36027?gbrecs=true

[Krafpy]

On 3/16/2023 at 1:04 AM, Eddy119 said:

If it's near opposition (on kerbin's side) then it seems like we need some other way to do it if not waiting years for Jool to be on the right side again...

Unless you find a perfect configuration of Kerbin and Eve, it's pretty hard to find a good trajectory that doesn't requires Jool to get in a good position first. I tried with a departure at the beginning of year 6 (Kerbin/Jool opposition) and forced the departure date to be not later than year 10. I get a deltaV of about 2500m/s (without circularization around Jool) with a departure between year 7 and 9.

On 3/16/2023 at 1:04 AM, Eddy119 said:

Anyway it seems like the calculator can calculate Ke-Eve-Eve-Moho reasonably at about 4000m/s of delta v including circularization... Although some direct transfers also take about that much fuel (depending on if Moho is near periapsis)

I get  about 3000m/s deltaV with a simpler Ke-Ev-Mo trajectory.

On 3/20/2023 at 7:02 AM, Eddy119 said:

Just leaving another thing here, self-flybys are called vinf leveraging manuevers. Examples are using Moho flybys to get nearer to Moho's orbital speed or using Kerbin-Kerbin flyby to Jool (Juno style). There are a couple of papers that describe it but not in an informal Kerbal way.

I think this kind of maneuver is not very well handled by my tool, so it's not very surprising that a good KEKKJ trajectory is hard to find.

[Utkucan]

Hello,

I am writing to you as a user of the ksp mga planner,I have been using your tool for a while and I find it very useful and impressive. However, I still have some questions about how it works and how to use it effectively.

I would like to ask you if you could explain how the ksp mga planner works in more detail. How does it calculate the optimal trajectory? What are the parameters and options that you can adjust? How do you interpret the results and export them to the game? I think these are some of the questions that many users have.

I would also like to ask you if you could create a tutorial video for beginners on how to use the ksp mga planner. I think this would be very helpful for people who are new to this tool or to multiple gravity assist maneuvers in general. A tutorial could show some examples of how to plan different types of missions, such as interplanetary transfers, flybys, or rendezvous.

I appreciate your time and effort in developing this amazing tool. I hope you can answer my questions and consider creating a tutorial for beginners. Thank you very much.