Jump to content

Krafpy

Members
  • Posts

    14
  • Joined

  • Last visited

Reputation

32 Excellent

Recent Profile Visitors

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

  1. 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.
  2. @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.
  3. 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.
  4. 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 ?
  5. 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)
  6. 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.
  7. 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)
  8. @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.
  9. 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 ?
  10. 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.
  11. 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.
  12. 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: 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. 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. 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 !
×
×
  • Create New...