[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Drew Kerman]

Just now, Arrowstar said:

Hey, you still need/want that atmospheric orbital decay model, right, @Drew Kerman?

Need? No. Want? Yes. I really do think it'll add some interesting dynamics to my gameplay but I'm willing to do without. I'm also not going to need it for a few months since I have had to currently suspend KSA ops due to IRL issues (none bad, thankfully, just busy) so won't be orbiting until the end of this year or early next year anyways

[Arrowstar]

2 minutes ago, Drew Kerman said:

Need? No. Want? Yes. I really do think it'll add some interesting dynamics to my gameplay but I'm willing to do without. I'm also not going to need it for a few months since I have had to currently suspend KSA ops due to IRL issues (none bad, thankfully, just busy) so won't be orbiting until the end of this year or early next year anyways

It shouldn't be that hard to add, just wanted to make sure it was still a desired feature.

[Drew Kerman]

On 8/9/2018 at 11:33 PM, Arrowstar said:

Oh, also, for those interested, I finally figured out how to actually use git and updated the repo tonight for the first time in 3 years lol.  New source code is here:

Oh yea, noticed my old issue of adding space craft names to the Other Spacecraft when loading from SFS or in-game was closed with no response. Is that a thing that will be added or not something easy/possible to do?

[Arrowstar]

2 minutes ago, Drew Kerman said:

Oh yea, noticed my old issue of adding space craft names to the Other Spacecraft when loading from SFS or in-game was closed with no response. Is that a thing that will be added or not something easy/possible to do?

I closed it because it was old and I suppose I forgot about it lol... pretty sure it's do-able, I should be able to get it in in the next few days.

[Arrowstar]

23 hours ago, Drew Kerman said:

Oh yea, noticed my old issue of adding space craft names to the Other Spacecraft when loading from SFS or in-game was closed with no response. Is that a thing that will be added or not something easy/possible to do?

Done, will be next pre-release.

[Arrowstar]

On 8/11/2018 at 5:04 PM, Drew Kerman said:

Need? No. Want? Yes. I really do think it'll add some interesting dynamics to my gameplay but I'm willing to do without. I'm also not going to need it for a few months since I have had to currently suspend KSA ops due to IRL issues (none bad, thankfully, just busy) so won't be orbiting until the end of this year or early next year anyways

Hey, so I had a look at the OrbitalDecay mod code today and took a shot at writing my own implementation of the atmospheric decay algorithm.  The good news is that I get numbers.  The bad news is that I'm pretty skeptical that what WhiteCat implemented is even remotely realistic.  I found the paper he used and it basically looks like he pulled some equations, put them in C#, and called it a day.  Everything in the paper he used was Earth relative and it doesn't seem to make a lot of sense when I think about making things generic across any body.  I'm going to keep thinking about it, but it may result in me having to implement the code in a different way then he did to keep things planet-agnostic.

If you're interested, here's the paper he used: http://www.sws.bom.gov.au/Category/Educational/Space Weather/Space Weather Effects/SatelliteOrbitalDecayCalculations.pdf

[Drew Kerman]

Thx for the update. Looked at the paper but I'm afraid I'm going to be of no help other than to stand here and go "Frickam frackem firecrackem shish boom ba! Arrowstar! Arrowstar! Ra ra ra!"

If you find it an interesting challenge I know you'll stick with it, so that's what I'm hoping for. I'm sure anyone else using the mod would appreciate a more accurate modeling as well. I wonder if @Papa_Joe has had any free time to look at it more closely himself. Pretty sure also I remember @Whitecat106 saying before he got busy he wanted to rewrite the mod since his original pass was more of a proof of concept

[Papa_Joe]

2 hours ago, Drew Kerman said:

Thx for the update. Looked at the paper but I'm afraid I'm going to be of no help other than to stand here and go "Frickam frackem firecrackem shish boom ba! Arrowstar! Arrowstar! Ra ra ra!"

If you find it an interesting challenge I know you'll stick with it, so that's what I'm hoping for. I'm sure anyone else using the mod would appreciate a more accurate modeling as well. I wonder if @Papa_Joe has had any free time to look at it more closely himself. Pretty sure also I remember @Whitecat106 saying before he got busy he wanted to rewrite the mod since his original pass was more of a proof of concept

Been pretty consumed with BDAc updates and work, but I'm willing to work with folks on it.  Whitecat is not gone, so he may be available for consultation.  It was mainly the support I took over, and @Whitecat106 is certainly welcome in the mix

 

Edited August 13, 2018 by Papa_Joe

[Arrowstar]

On 8/12/2018 at 8:10 PM, Drew Kerman said:

Thx for the update. Looked at the paper but I'm afraid I'm going to be of no help other than to stand here and go "Frickam frackem firecrackem shish boom ba! Arrowstar! Arrowstar! Ra ra ra!"

If you find it an interesting challenge I know you'll stick with it, so that's what I'm hoping for. I'm sure anyone else using the mod would appreciate a more accurate modeling as well. I wonder if @Papa_Joe has had any free time to look at it more closely himself. Pretty sure also I remember @Whitecat106 saying before he got busy he wanted to rewrite the mod since his original pass was more of a proof of concept

You know me too well, lol.

Anyway, I have an initial implementation of an atmospheric orbit decay model more or less done.  To use it, you just create a new coast, check the "Use" box in the Orbit Decay panel, and then put in the correct spacecraft and environments parameters.

Some caveats:

• Like OrbitDecay mod, I'm not messing with the eccentricity of the orbit (yet).  I gave it a go, and I know the general trend, but boy it's hard to come up with an analytical model for eccentricity change that can be vectorized to run fast.  Well, a simple one anyway.  There are lots of models out there but they're all stupid complicated.  What this means is that, while the orbits should circularize over time, right now they don't.  The unperturbed eccentricity is also the decayed eccentricity.
• I'm not using the same SMA change formulation that OrbitDecay is.  I'm not super happy with how it was implemented there, mostly because (as I stated before), I think it's mostly bunk.  Therefore, what I have implemented may not match what is in the mod... and therefore results may be different.  Hard to say without really studying the problem.
• The density assumptions in Orbit Decay mod don't really make sense, so I implemented my own exponential decay model for atmo density above the stock atmosphere altitude.  Yet again another thing that won't perfectly match the model in the mod.
• I've tested it as well as I can but right now things are liable to break in all sorts of unforseen ways.  Would definitely appreciate some testing by others.

And now, some results:

Finally, here's the pre-release with the new build that includes all of this (as well as auto population of Other Spacecraft names): KSPTOT v1.5.11 pre-release 3.  Please test and let me know how it all works!

[Drew Kerman]

Whoop whoop. I should be able to do some testing later today

[Drew Kerman]

20 hours ago, Arrowstar said:

Please test and let me know how it all works! 

Ok it's only giving me a single tooltip saying "area of the spacecraft that is normal to the velocity vector" I get that, but not sure how I would best calculate that in KSP. Any ideas? I get the second two parameters come from the Solar Cycle mod, I see it gives that information.

The best idea I have for the m^2 value is to do this:

So what we have here is a screenshot via Kronal Vessel Viewer which lets me create an orthographic projection of the spacecraft, seen here head-on. That's a 1m truss section on the right. I've approximated the sizes of the various rocket sections with boxes - although using the selection tool in Paint.NET even for non-geometric shapes it gives me an accurate pixel area so I could go even more detailed, but for this simple example I just kept things simple. Anyways so with the areas of the boxes in pixels added up and divided by the area of 1m^2 in pixels I get 7.5m^2. If I use the simple Engineer Report in the VAB it tells me the vessel is 4.1m x 4.1m (measuring the tips of the fins) which would be 16.8m^2 so I know at least I didn't screw up my measurements and got a larger number.

Alright so I used HyperEdit to throw the ship up into a 75km circular orbit and used RCS to point the nose prograde so what is shown above was what was relative to the velocity vector (right?). Orbital Decay told me I had 16.4hrs until decay.

I imported the orbital data and told MA to coast for 16.5 hours. Here's what I got:

So with MA's modeling it will take just over 10 hours to begin scraping through the atmosphere. Interestingly tho if I warp ahead at 1,000x the game will drop me to normal speed with a warning the spacecraft is hitting the atmosphere at ~7hrs and if I reload the save and warp ahead 10,000x I get dropped out at ~9hrs.

There are also some recent posts on the Orbital Decay thread that say the mod isn't working, but with this low orbit at least I am seeing decay happening. I can't really test the two together really until Papa_Joe takes a look at your implementation Arrowstar and considers if it can be used similarly in the mod. There is also this implementation offered by FreeThinker that could factor in as well.

Yea I don't have as much time for testing today as I hoped, this will be all I can do but also I think it's all I'm really able to do right now I can't see any apparent usability issues with either MA or the OD mod at this time so I think the next step would just be to get them using the same basic decay calculations - we may have to wait until Papa_Joe has more time after working on BDAc

Edited August 14, 2018 by Drew Kerman

[Arrowstar]

21 minutes ago, Drew Kerman said:

Ok it's only giving me a single tooltip saying "area of the spacecraft that is normal to the velocity vector" I get that, but not sure how I would best calculate that in KSP. Any ideas? I get the second two parameters come from the Solar Cycle mod, I see it gives that information.

The best idea I have for the m^2 value is to do this:

So what we have here is a screenshot via Kronal Vessel Viewer which lets me create an orthographic projection of the spacecraft, seen here head-on. That's a 1m truss section on the right. I've approximated the sizes of the various rocket sections with boxes - although using the selection tool in Paint.NET even for non-geometric shapes it gives me an accurate pixel area so I could go even more detailed, but for this simple example I just kept things simple. Anyways so with the areas of the boxes in pixels added up and divided by the area of 1m^2 in pixels I get 7.5m^2. If I use the simple Engineer Report in the VAB it tells me the vessel is 4.1m x 4.1m (measuring the tips of the fins) which would be 16.8m^2 so I know at least I didn't screw up my measurements and got a larger number.

Alright so I used HyperEdit to throw the ship up into a 75km circular orbit and used RCS to point the nose prograde so what is shown above was what was relative to the velocity vector (right?). Orbital Decay told me I had 16.4hrs until decay.

I imported the orbital data and told MA to coast for 16.5 hours. Here's what I got:

So with MA's modeling it will take just over 10 hours to begin scraping through the atmosphere. Interestingly tho if I warp ahead at 1,000x the game will drop me to normal speed with a warning the spacecraft is hitting the atmosphere at ~7hrs and if I reload the save and warp ahead 10,000x I get dropped out at ~9hrs.

There are also some recent posts on the Orbital Decay thread that say the mod isn't working, but with this low orbit at least I am seeing decay happening. I can't really test the two together really until Papa_Joe takes a look at your implementation Arrowstar and considers if it can be used similarly in the mod. There is also this implementation offered by FreeThinker that could factor in as well.

Yea I don't have as much time for testing today as I hoped, this will be all I can do but also I think it's all I'm really able to do right now I can't see any apparent usability issues with either MA or the OD mod at this time so I think the next step would just be to get them using the same basic decay calculations - we may have to wait until Papa_Joe has more time after working on BDAc

Thanks for the testing!  It looks like it's close anyway.

However: After I posted that build you tested on, I actually found a better algorithm for analytical atmospheric drag.  This one models the change in semi-major axis, the change in eccentricity, and the change in argument of periapsis.  I have it implemented in a test script so that I could compare against ISS real world performance and it does reasonably well there given the assumptions I'm making.  What this means is that I'm going to be completely removing the code that I just put in (lol) and calling this new algorithm instead.  The only other change will be that this new algorithm can't be called in a vectorized fashion, so there will be a slight decrease in coast time calculation performance.  Testing shows that it's on the order of a few milliseconds per 1000 state log entries, so I'm not too worried.

Stand by until Wednesday or (more likely) Thursday and I'll have that implemented for more testing by you.  Your area calculations sound like they're in the ballpark of reasonable, so I'd just stay with what you have there for now.

Oh, a note about how the time warp stuff works in the mod (and in MA for smaller number of points per state log): the algorithm computes a change in SMA (and eccentricity and argument of perigee) per unit time.  Both the mod and I then compute the total change of the quantity by multiplying by the simulation time step.  The smaller the time step, the more actually the model.  You'll see things get wonky at high warps in game and low number of state log entries per coast in MA. 

@Papa_Joe: Take a look at this paper (http://farside.ph.utexas.edu/teaching/celestial/Celestialhtml/node94.html) for how I'm doing the drag effects, particularly equations 10.148, 10.150, and 10.151 (I still need to figure out how 10.149 works and if I need it).  These looks like they're a better model than what WhiteCat was doing originally.  If you have the time, I'd suggest giving this implementation a go in the mod.  I'll have my MATLAB code updated on Github in a few days with my implementation and you could use that as a template/pseudo-code.  It's very straight forward.

[Drew Kerman]

Nice! Okay, good deal and thank you for the explanation of the time warp, I was just about to post over in the orbital decay thread about it. The only problem with that of course is there's just no way I can run the game in real time all the time! So if things will not be accurate over time warp, then perhaps we can figure out a proper time warp to coast step ratio so that if I have to time warp the game at say 1,000x just to enable me to get through days faster, I should reduce the log step accordingly and still get good approximate results. Am I thinking of that right?

Also, I hate to kill the momentum here but I'll be overseas for work 8/18 - 9/2 and then leaving the following weekend for a 4wk cross-country road trip (whoo hoo!). So I won't be around much for testing, but will still at least be checking in when I can to offer thoughts in response to whatever anyone else is posting

[Arrowstar]

47 minutes ago, Drew Kerman said:

Nice! Okay, good deal and thank you for the explanation of the time warp, I was just about to post over in the orbital decay thread about it. The only problem with that of course is there's just no way I can run the game in real time all the time! So if things will not be accurate over time warp, then perhaps we can figure out a proper time warp to coast step ratio so that if I have to time warp the game at say 1,000x just to enable me to get through days faster, I should reduce the log step accordingly and still get good approximate results. Am I thinking of that right?

Also, I hate to kill the momentum here but I'll be overseas for work 8/18 - 9/2 and then leaving the following weekend for a 4wk cross-country road trip (whoo hoo!). So I won't be around much for testing, but will still at least be checking in when I can to offer thoughts in response to whatever anyone else is posting

The equivalent MA setting is going to be based on the length of the coast.  The KSP timewarp is in unites of seconds per second, so if you're running at 30 fps at 1x, you'll get a step (and call to the Orbit Decay mod) every 1/30 seconds.  The equivalent setting in MA would be to take the duration of the coast and divide by the number of state log entries.  Match the times by varying the number of state log entries and plug in that number into the setting in MA.

That all said, I would check to see if you really see any sort of difference between MA (under the new, to be implemented algorithm) and KSP first before you go through the effort.  If it's small, I might not bother, since the effort involved in getting the two in sync may be non-trivial.

Anyway, no worries about your trip and whatnot, all this will still be waiting for you when you return.

[Kobymaru]

Hey there!

I'm having some trouble using the KSPTOT porkchop transfer planner with RSS and Principia.

I started out in 1972 (KSP year 22) and I wanted to go from Earth to Venus with as low dV as possible.

Here's what I did:

1. Installed the KSPTOTConnect plugin
2. Started KSPTOT
3. Edit -> Time System -> Use Earth Time
4. Edit -> Gravitational Parameters -> Use RSS-like
5. Create New Bodies File from KSP
6. Load created bodies file
7. Departure Body: Earth
8. Arrival Body: Venus
9. Earliest Departure time: Right-Click, Enter UT as Date/Time, year 22
10. Earliest Arrival Time: Right-Click, Enter UT as Date/Time, year 24
11. Compute Porkchop plot
12. Get result: Y23 d221, which translates to August 3, 1973

This, however is way too late. I am pretty certain that there was a launch window in March 29, 1972: first of all, there was a real launch by the UDSSR, namely Venera 8. Second, I used @Arrowstar 's old TrajectoryOptimizationTool (v 2.1.1) for Orbiter to find the window, and that calculated optimal departure on March 30, 1972.

I double-checked the bodies.ini file that was created, and the orbital parameters for Earth and Venus seem to match RL almost exactly (compared to this: https://nssdc.gsfc.nasa.gov/planetary/factsheet/venusfact.html).

While writing this post, I figured out what could be the culprit: the inclination of all bodies seems to be very high, around 23°. I'm pretty sure that this is done in principia because rotating the whole solar system is the only way to implement earths axial tilt.

Is there a way I can generate a proper bodies.ini file that works for porkchop plots?

[Drew Kerman]

ooof @Arrowstar you seeing this too?

All I do is load up MA in the default state, set a UT coast for 180 days, and this is what the Graphical Analysis tool tells me when I open it up and click to output the default settings. Decay box is not checked in the UT coast and confirmed the 1000 log events per event is set

Also no matter what vessel I select from the list loaded via SFS it always sets the name from the first vessel in the list

Edited August 16, 2018 by Drew Kerman

[Arrowstar]

@Kobymaru: The inclination is most likely the problem, yes.  I know why they add it, but I wish they wouldn't... it causes issues like what you discovered.

The only solution is to create the RSS bodies file like normal and then manually edit the inclinations to be more reasonable in the file.  There's nothing much KSPTOT can do for it.  I know it's a pain, I'm sorry.

On 8/15/2018 at 2:39 PM, Drew Kerman said:

ooof @Arrowstar you seeing this too?

All I do is load up MA in the default state, set a UT coast for 180 days, and this is what the Graphical Analysis tool tells me when I open it up and click to output the default settings. Decay box is not checked in the UT coast and confirmed the 1000 log events per event is set

Also no matter what vessel I select from the list loaded via SFS it always sets the name from the first vessel in the list

1) Yes, that is expected behavior.  When KSPTOT detects that a long Go To UT/DT coast is executing, and the orbit is eccentric, the code automatically splits out each orbit period into its own sub-coast.  This is mostly done for graphical purposes (for example, if you go around 100 revs and use 100 states per coast, you would only get one point per rev, so the spacecraft would not appear to be moving).

2) Thanks for the report!  I fixed it.  Silly typos.

In other news, I have an update on the new atmospheric model.  I implemented the paper I noted above from U of Texas and it works quite nicely.  Here's a someone eccentric orbit running with the orbit decay option on in Mission Architect:

Green lines are perigee passes and blue lines are apogee passes.  As expected, the spacecraft loses most of its apogee altitude at perigee, when the atmosphere is densest.  Also note that perigee doesn't drop much at all, which I would expect too.

Fun story, by the way: I was looking at this a few days ago and got stuck on a case where a very high eccentricity broke the algorithm.  I ended up grabbing a fellow engineer at work over a break and we deconstructed what the UT author did, figured out they made a "nearly circular orbit" assumption in their math that they didn't mention in the paper, and re-worked the differential equations to eliminate the problem and to be more general.  I really do like my job lol.

(I did some testing on the raw algorithm yesterday on some cubesat data I found online and it compares reasonably well, so I'm much more confident in this model than the other one that's currently in the Orbit Decay mod.)

Anyway, this new algorithm, correction and all, is in the next pre-release, here: KSPTOT v1.5.11 pre-release 4.  This build also includes the fix mentioned above. Please give it a spin, all, and let me know if you find any bugs.

Edited August 17, 2018 by Arrowstar

[Drew Kerman]

Noice! I hope @Papa_Joe gets a chance to look at the new model soon, tho as I said, can’t test myself till I’m home after the 2nd

[eggrobin]

On 8/17/2018 at 2:31 AM, Arrowstar said:

The inclination is most likely the problem, yes.  I know why they add it, but I wish they wouldn't... it causes issues like what you discovered.

Note that the inclinations are not Principia-specific: RSS also uses equatorial coordinates (so as to have Earth's tilt). What Principia changes with respect to tilt is that the coordinate system changes when the main body does, always being equatorial for the current main body.

Quote

 The only solution is to create the RSS bodies file like normal and then manually edit the inclinations to be more reasonable in the file.  There's nothing much KSPTOT can do for it.  I know it's a pain, I'm sorry.

It will likely not have escaped your attention that merely changing the inclinations is not a correct change of coordinate system, and that the resulting orbits will be highly inaccurate (although with Principia you only get osculating orbits anyway, so accuracy is likely a lost cause).

What prevents your trajectory optimization tool from working with equatorial coordinates? These are just ICRS axes after all, nothing outrageously exotic.

[Drew Kerman]

No time for testing squat before I leave this weekend. Will be back after the first weekend of October

[Arrowstar]

On 9/5/2018 at 9:33 AM, Drew Kerman said:

No time for testing squat before I leave this weekend. Will be back after the first weekend of October

No worries!  I'll probably do the release of the current development code before then, but you can tell me if you find any bugs when you get back.

[jmburbach]

Would this tool allow me to plan arrival and entry (without orbital capture first) directly into another atmosphere such that the entry phase begins over a predetermined geographic position? Basically I'm looking for a way to help reliably plan an arrival and entry precisely enough that I can land reasonably near a target area.

[dbandy13]

apologies if this has already been posted but i didn't particularly want to look through 120 pages of posts-

Does this work with rescales? Im currently playing 2.5x and would love to be able to create some delta-v charts and plan missions ahead instead of having to guess delta-v.

Also if it does what level of compatibility-do i need to change the planet database manually or will it auto detect?

Kinds regards

[AVaughan]

If I recall correctly dV scales with the square root of the rescale factor, so 2.5x need about 1.6 times the dV of stock.  (That isn't quite perfect, since atmospheric losses don't scale quite that way, but it is a good enough approximation to allow you to use stock scale dV charts for mission planning in rescaled systems). 

[Arrowstar]

On 8/29/2018 at 3:28 PM, eggrobin said:

Note that the inclinations are not Principia-specific: RSS also uses equatorial coordinates (so as to have Earth's tilt). What Principia changes with respect to tilt is that the coordinate system changes when the main body does, always being equatorial for the current main body.

It will likely not have escaped your attention that merely changing the inclinations is not a correct change of coordinate system, and that the resulting orbits will be highly inaccurate (although with Principia you only get osculating orbits anyway, so accuracy is likely a lost cause).

What prevents your trajectory optimization tool from working with equatorial coordinates? These are just ICRS axes after all, nothing outrageously exotic.

Hey, sorry, just seeing this now.  The answer is that stock KSP assumes that the planets have no tilt, and so I made the same assumption with KSPTOT.  In other words, every planet's coordinate system is assumed to be parallel to the solar system coordinate system.  It wouldn't be too hard to add in support for that, I assume.  I would just need the z and (maybe) x axis directions in the solar system coordinate system for each body coordinate system.

16 hours ago, jmburbach said:

Would this tool allow me to plan arrival and entry (without orbital capture first) directly into another atmosphere such that the entry phase begins over a predetermined geographic position? Basically I'm looking for a way to help reliably plan an arrival and entry precisely enough that I can land reasonably near a target area.

The answer, at the moment, is sort of.   You have to use Mission Architect (MA) for it.  You can definitely do "vacuum" impact point calculations, that's easy.  (See the Mission Architect example included called "Mission to Minmus" or something to that effect.)  A vacuum impact point is the point at which a trajectory intersects the ground without accounting for atmospheric drag.  However, atmospheric modeling is somewhat primitive at the moment.  You could try using the aerobraking event type in MA, though I think that event doesn't like it when you never show up out of the atmosphere again.

I would start by just modeling your reentry using the two body assumption (so just a basic coast, and coast down to an altitude of 0), and then come up with a way to adjust your pre-entry orbit to account for the fact that drag will pull that impact point a bit closer to the point where you hit the atmosphere.  Honestly, depending on your flight path angle at entry interface, the vacuum impact point may not even be a terrible assumption.  Give it a go and let me know how it goes.  I'm happy to help you come up with a good solution if I can. :)

8 hours ago, dbandy13 said:

apologies if this has already been posted but i didn't particularly want to look through 120 pages of posts-

Does this work with rescales? Im currently playing 2.5x and would love to be able to create some delta-v charts and plan missions ahead instead of having to guess delta-v.

Also if it does what level of compatibility-do i need to change the planet database manually or will it auto detect?

Kinds regards

Yes, it will work with re-scaling mods.  Follow the instructions in the OP to create a custom bodies.ini file for your re-scaled solar system and then import that custom bodies.ini file into KSPTOT. Let me know if you need help, I'm happy to help!.