Jump to content


  • Posts

  • Joined

  • Last visited


37 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Wooooow ! Just discovered it and it's amazing ! Really cool work, I'm glad my work inspired you . The UIs are also very neat and clean. I tried a Kerbin-Eeloo trajectory and the total delta-V your tool finds is way better than mine : about 1840m/s, instead of about 3000m/s on my side. You managed to solve several problems I'm still facing. I'd be really interested in knowing some of the maths and implementation details . Like, how are you generating flyby sequences ? What trajectory parameterization are you using ? How did you implement your "refining" of trajectory feature ? Looking forward to talk in messages .
  2. @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.
  3. @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 !
  4. 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 !
  5. 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.
  6. 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.
  7. @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.
  8. 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.
  9. 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 r1 = (R, 0, 0) and r2 = (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 r1 to r2 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 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 ?
  10. 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: t0 : 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: Ti: 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: Calculate the parking orbit (equatoral circular orbit). Calculate the ejection velocity : vejection = k * √2 * vcircular ; and its corresponding dV : dV0 = vejection - vcircular (we suppose a prograde only maneuver). 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. Propagate the ejection orbit until exiting the SOI, calculate the global state vectors when exiting the SOI. For each leg i : Calculate the deep space orbit from the state vectors calculated before. Apply the following bounds to Ti and αi (simple clamping), let P be the period of the resulted deep space orbit : if the leg is not resonant, then 0.5P ≤ Ti ≤ P and 0.01 ≤ αi ≤ 0.999. if the leg is resonant, then P ≤Ti ≤ 3P and max( (nrevs - 1) / nrevs ; 0.01 ) ≤ αi ≤ 0.999, where nrevs = Ti / P (this is to try to avoid the post-DSM arc from having a duration that would give multiple revolutions). Propagate that orbit for duration αiTi , the resulting position is point A and the velocity vector at that position is vA0. Calculate the position of the targeted body at the encounter date (Ti + time of flight until last SOI exit + t0). 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. Slove the Lambert problem to find the orbit that links points A and B in a time (1 - αi)Ti. This gives the velocity vector at point A and B : vA and vB. Record the DSM dV : dVi = || vA - vA0 ||. Calculate the relative velocity to the body when entered at point B and the flyby orbit. 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 αiTi") 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( Rbody / RSOI ) θmax = arcsin( Rmax / RSOI ) θ 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: 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'. Rotating u' around u of the angle φ. Multiplying u' by RSOI. 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 : Rmax = 2 * Rbody. 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 Ti'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)
  11. 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. 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. 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. 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.
  12. 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)
  13. @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.
  14. 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 ?
  15. 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.
  • Create New...