Online Calculator for Trajectories with Multiple Gravity Assists

[Arrowstar]

22 minutes ago, antipro said:

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?

Hey there, @antipro!  This is probably a question that's better off asked on the KSPTOT thread so we don't clutter up @Krafpy's thread here:

That said, to answer your questions:

Quote

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?

The departure maneuver from Kerbin can be "uploaded" to KSP directly by right clicking the "DV Maneuver Information" text box.  The other maneuvers can't be "uploaded" in that way, though it's something I could pretty easily add.  There's a caveat though: the assumptions used in MFMS that make the calculations fast also simplifies the dynamics model quite a bit and there's going to need to be a fair bit of hand-tuning involved in order to get the maneuvers to work out.

The better process flow is to use your MFMS designed trajectory as a starting point and then model the trajectory in higher fidelity using Launch Vehicle Designer (which, at this point, is less than aptly named since it does everything Mission Architect can do and more lol).  LVD actually models the spheres of influence of the bodies, which MFMS and similar tools cannot do, and you'll get much more precise results.  If you need help with this, check out the LVD example mission file "lvdExample_ToEelooViaJool_BackPropExample.mat" that ships with KSPTOT and ask questions over on the KSPTOT thread I linked to above.  Thanks!

[Interplanet Janet]

Will you ever be able to add patches for popular planet packs like OPM, New Horizons, or MPE?

[Krafpy]

@Interplanet Janet I would like to, and this is totally feasible. I imagined having a selector just above the solar system view where you can choose between several systems/planet packs. This requires to collect the data of each systems in a file first, and refactor some part of the code a bit so it can handle loading and switching between multiple systems. You can see how I store the KSP's system configuration in a yaml file on the github repo of my tool. So if you or other people want to create the files (or fill the existing kspbodies.yml if keeping all in a single well structured yaml file makes more sense) for a particular system and/or implement the multiple systems support, they are totally free to make pull requests on the repo. I'm looking forward to any contribution .

I don't really have the time to work on the project right now unfortunately (studies). But I want to first fix several issues my tool currently has. Mainly refactoring the physics part (which is kind of a mess right now....) and redesign the optimization process so it gives better results (or at least avoids non sense results as much as possible ). Then I'll consider adding other planet packs.

Also some people mentionned making it a mod. In that case the tool can directly adapt to the planet pack the player uses. If I manage to make my online tool work successfully I may start working on a mod version of it, which would make it more useful than having it as an external tool.

[theAstrogoth]

Just wanted to say this looks really cool!

It's given me the motivation to do two things I've been interested for while, but lazy about; learning JavaScript (I like the look of TypeScript) and getting more comfortable with the math behind planning gravity assists. Forking this now, and if I can get a handle on the language, I should be able to provide system configurations for RSS and OPM. Will submit a pull request if I get it figured out!

[Krafpy]

Thanks for your comment @theAstrogoth and good luck with learning TypeScript/JS ! As I precised in a previous answer, my code is a bit messy currently, so I hope it's readable and not too complicated to understand...

I'm open to any question regarding implementation and maths/physics details.

[Krafpy]

Hello ! I've updated the tool and fixed some issues. The fixes focus only on the 2D physics implementation used for the planetary sequence generation. Some sequences were never proposed, like the Ke-Ev-Mo route despite being probably one of the most efficient, and it now always appears in the proposed sequences when looking for a Kerbin to Moho transfer.

I also changed the sprites used for the planets and maneuvers indications. Nothing much but they look cleaner.

I'll try to work on fixing and improving the trajectory solver as soon as can.

[Krafpy]

Hello ! I've finally updated the 3D physics and completely recoded the trajectory calculator and optimizer. Most of the problems in the physics and trajectory calculations are now fixed. There are still some minor errors here and there but they shouldn't be a problem when using the tool.

• There is no longer risks of absurd nonsense trajectories being calculated with incredibly high apoapsis (at least, I didn't see any occuring when testing).
• There is also no more risk of getting a flyby orbit with a periapsis below the surface level.
• The circularization step is temporarily removed from the trajectory calculation, thus some trajectories may be a bit weird simply because they doesn't consider the arrival deltaV. However, it will be back as soon as I get the time to implement it, and this time with the ability to configure the radius of the circular orbit around the destination body.

In general, the tool finds better trajectories with lower deltaVs.

You can now also plan missions in the Jool's system:

The small problem to consider though is that the tool doesn't check if a part of the trajectory crosses the SOI of a body before reaching its end. Therefore some orbits can be impossible because they intersect the SOI of another body on the way, or they enter the targeted body SOI before the calculated point. This problem also arises in interplanteray missions, especially when using Jool for a gravity assist, but is a lot less problematic than in the Jool's system. I have no idea yet on how to fix that.

I precise that the calculated maneuvers are far from being exact. Consider them as indications, you will always have to do some fine tunings, hopefully not too many.

I also commented most of the edited parts of the code and tried to make it more readable. I will continue to comment the rest of the code.

In the following updates I will make it display more information on maneuvers and various step of the trajectory, such as each arc orbit parameters (periapsis, inclination of orbits, SOI enter and exit dates).

I was wondering if the automated sequence generator is really useful considering that we can simply input a custom sequence. If you have been using my tool, is this feature useful or should it be simply removed ?

Please report any problem you may encounter and write any suggestion you may have !

[SpaceFace545]

Wow this is awesome!! Is there anyway that I could convert this to match a scaled up KSRSS system.

[Krafpy]

@SpaceFace545 I haven't implemented the possibility to add custom solar systems yet, but that was asked several times. I'm not sure on whether I'll try to implement it in my online tool or simply move it to a mod so the solar system is handled automatically. For now here is how you can do it :

Fork/download the source code from the github repo. The tool loads the solar system data described in the kspbodies.yml file, in the data folder at the root of the repo. So you simply need fill it with KSRSS data instead of the stock ones. You may also need to edit time related settings in the config.yml file (hoursPerDay and daysPerYear... I don't know if KSRSS uses advanced time representations depending on conventions, if so that may cause problems). I'll immediatly add some additional information in these files about how to edit them. To run the tool you need to start a local http server, or any live server provided with editors like vscode, at the root of the repo, and it will open it in a web browser window.

I never tested it on another system. I can't garantuee that it will work, but it is surely worth trying !

I hope this helps !

[Krafpy]

@SpaceFace545 I added the following notes in the solar system configuration file :

#             Units
# radius:             m
# mass:               kg
# stdGravParam:       m^3/s^2
# soi:                m
# apoapsis:           m
# periapsis:          m
# eccentricity:       None
# inclination:        ° (degrees)
# argOfPeriapsis:     °
# ascNodeLongitude:   °
# meanAnomaly:        rad, at 0s UT
# sideralPeriod:      s


# EDIT NOTES FOR CUSTOM SOLAR SYSTEMS

# - Follow the exact same format (names, indentations) as used in this file
# - Numerical data must follow the units described above
# - Each body has a unique ID, it must be an integer between 0 and N-1, where N is the number of bodies 
# - The sun must have the ID 0
# - The sun does not have an `orbit` attribute
# - The ID given to a body must be representative of its order in the solar system.
#   For planets, it represents its order from the sun; for sattelites, its order
#   from its attractor body.
#   For example :
#    Body :  Sun | Moho | Eve | Gilly | Kerbin | Mun | Minmus ...
#    ID   :  0   | 1    | 2   | 3     | 4      | 5   | 6      ...
# - The blocks of data describing the bodies in this file must be ordered according to their ID.
#   For example, the sun's data are written first, followed by Moho's data... etc.

 

Edited December 24, 2021 by Krafpy
Added a note.

[Krafpy]

Hello ! I finally got the time to make an update ! You can now configure the altitude of the orbit around the destination body. I also improved the trajectory search by tweaking some parameters. The total delta-V is usually lower than previously, especially for trajectories to Eeloo. Let me now if you encounter any problem.

[Krafpy]

New update ! I worked on adding several features in the past few days :

• You can now show or hide the SOI of bodies (see picture below). This can be useful to check for example if the tool didn't miss a possible earlier intersection with the SOI before a flyby, which would cause the calculated trajectory not to be actually feasible in game (or at least not without some other maneuvers).
• You can now see more details about the flybys in the maneuver selector : SOI enter/exit date, altitude of the periapsis and inclination of the orbit (always between 0 and 90°).
• The optimization process got improved a bit and can give really interesting trajectories. Below is for example a Kerbin to Eeloo trajectory with Eve and Jool flybys which theoretically only requires 1612 m/s of deltaV ! (of course more is needed in game to compensate potential approximation errors and inaccuracies with the game, but hopefully not much).
  To help the tool finding good trajectories, avoid looking for wide departure date range. A 10 year range seems about a good compromise. I also recommend to run the trajectory search several times if the trajectory you get seems not so great. Due to the randomness involved in the optimization process, the tool will probably give a different result at each new run.

I also fixed a bug that caused an offset in the position where you need to double click to focus the camera on a body. This bug affected every browser except Chrome.

Note that you may find some weird trajectories where the ends of interplanetary arcs don't actually connect with the SOI at the expected date, especially when you look for far dates (e.g. above year 100). I think that this is due to floating point rounding errors which become greater the bigger the number gets. I don't know how to fix this issue and if it can even be fixed.

 

 

Edited July 12, 2022 by Krafpy
Added some more information

[Krafpy]

Hello ! New important update : the tool can now support several solar systems !
As of today, only the stock solar system and JNSQ are implemented (data collected from this fork: https://github.com/jmking628/KSP-MGA-Planner-JNSQ ).

You can contribute to add more solar systems !
I edited my original thread post and described the steps to follow. Basically, you simply need to add new configuration files through a pull request on the tool's github repository.

Please report any issue you encounter.

[Krafpy]

Hello ! New update !

There is now a "No insertion burn" checkbox for the trajectory settings. If checked, the final orbit around the destination body will be a flyby with the specified altitude at periapsis.

Atmospheres' are now taken in account in flyby calculations (yes, this was not the case until now...). Flybys can't have a periapsis that goes below the atmosphere limit anymore.

But more importantly, in order to help adding new solar systems to the tool, you can now directly convert Kopernicus .cfg files to a `bodies.yml` file on this page : https://krafpy.github.io/KSP-MGA-Planner/tools/cfg-to-yml/
Simply select all configuration files of all bodies (body files only) and convert. If a solar system is an extension to the stock one, you can check the "Combine with stock" checkbox to automatically add the stock bodies if no .cfg file is overriding them.
This should make the use of custom solar systems much easier and straightforward. Instructions are detailed in the original post as well as in the github repo's readme.

Using this feature, I completely replaced the data files for JNSQ which contained some errors.

[Dealthough]

hi, I don't find the ejection angle info in the calculator, it is not needed? am I missing something? also would be cool to show an arrival date (I know is the same as the circularization date). thanks!

[Krafpy]

Hi @Dealthough !

Indeed there is no ejection angle information for the departure, I haven't implemented it.
The arrival date is indeed the cirularization date (or the date at which the spaceship enters the arrival body's SOI if "no insertion burn" is checked).

I agree these could be useful information that I should have thought of ^^'... especially the ejection angle. I'll work on that as soon as I can !

For the time being you can try to guess the ejection angle by zooming on the departure planet and looking at where the ejection maneuver node is placed.

 

One note just to be sure it's clear: the departure date shown represents the date at which the ejection burn from the origin's body is made. The mission elapsed time that is displayed is computed from that ejection burn. Therefore if you try to do a mission from the launch the MET in game and in the tool won't match.
It's not a big problem as long as you plan the duration of the ascent and do the ejection burn roughly at the correct date... The maneuevers always require a manual tuning anyway.

Don't hesitate to ask if you have any other question or issue !

[Krafpy]

Hello ! New small update !

In response to @Dealthough's comment, I added the following:

- The arrival date is now clearly shown along with the departure date of a trajectory.

- The ejection angle is displayed in the details of the first maneuver. It corresponds to the angle between the direction of the departure body's velocity (tangent to the orbit at the departure date, pointing in the body's moving direction), and the position of the ejection maneuver on the parking orbit around the derpature body. The angle is oriented counter clockwise (trigonometric direction).

I hope this is useful.

[Eddy119]

Hi, it seems like Ke-Ev-Ke-Ke-Jo (KEKKJ) doesn't work too well on your website?

[Krafpy]

Hi !
What do you mean exactly by "doesn't work too well" ? @Eddy119
Is it failing at computing a trajectory ? Or is the trajectory incorrect ? delta-V too high ?

I just tried a Ke-Ev-Ke-Ke-Jo with departure between year 1 and year 20. I get a trajectory with an estimated delta-V of 1750m/s (without circularization burn around Jool).

[Eddy119]

I think it's supposed to take less than 1100m/s depending on the time (year 2-3)... I'll elaborate later after my exams

[Krafpy]

@Eddy119It is totally possible that a better trajectory with less delta V exist. My tool does not guarantee to find the optimal trajectory. It tries to... but is likely to miss it if it's a complicated trajectory.

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.

[Eddy119]

Video above shows 1100m/s

I think the Ke-Ev-Ev-Mo works well though? (Similar to KSPTOT) I'm not sure what departure vinf is on KSPTOT is though... Yours is easier to read overall

Edited December 16, 2022 by Eddy119

[Krafpy]

Yeah it is totally possible to find a better trajectory manually.

I just ran my tool again for KEKKJ and I got a 1350m/s delta V this time. Not as good as the 1100m/s of the video, but better than my previous try.

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.

You can also try theAstrogoth's tool : https://kerbal-transfer-illustrator.netlify.app/
It has a flyby calculator similar to mine, but uses a different approach at calculating the trajectories. Maybe it could give better results.

[Eddy119]

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

[Eddy119]

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