[old thread] Trajectories : atmospheric predictions

[Starman4308]

I've been having problems with inaccurate trajectory predictions. It's mostly a problem with long/shallow reentries; it pretty consistently overestimates the length of my flightpath (i.e. my craft lands well short of the initially-predicted impact site). This is with FAR, using MechJeb to keep my craft pointed dead-on to my surface velocity vector and without moving any of the Trajectory AoA sliders off of zero. Am I doing something wrong? Is this a bug? Just an unavoidable limitation of the mod?

Great mod overall, though! Even inaccurate predictions are better than none, and it's generally pretty good when my reentry is on the steep side.

A, it will inevitably be inaccurate for long reentries, because reentry is inherently chaotic (highly sensitive to minor things, and error grows exponentially with time), so more error is to be expected with long reentry.

B, are you using wings with stock aerodynamics? Trajectories will not account for stock wings.

C, just to check: are you going in nose-first or tail-first? 0 degrees means a nose-first reentry, generally valid for spaceplanes but invalid for capsules.

D, are you using Deadly Reentry? Trajectories won't account for loss of ablative heatshield material.

E, are you using any RCS stabilization? Trajectories won't account for use of RCS fuel.

[Supraluminal]

A, it will inevitably be inaccurate for long reentries, because reentry is inherently chaotic (highly sensitive to minor things, and error grows exponentially with time), so more error is to be expected with long reentry.

B, are you using wings with stock aerodynamics? Trajectories will not account for stock wings.

C, just to check: are you going in nose-first or tail-first? 0 degrees means a nose-first reentry, generally valid for spaceplanes but invalid for capsules.

D, are you using Deadly Reentry? Trajectories won't account for loss of ablative heatshield material.

E, are you using any RCS stabilization? Trajectories won't account for use of RCS fuel.

For reference, by "long" I mean the reentry phase lasting something around 1/8th of an orbit or even less. I'm not trying to predict a landing a full orbit ahead or anything.

What do you mean by "wings with stock aerodynamics?" All the wing parts that come with stock KSP...? Like I said, I'm using FAR. The OP says "It works with FAR, NEAR and stock drag at this time ; stock wings are not simulated (but FAR/NEAR ones are)," which I took to mean that all wings are simulated when FAR is enabled. I'm also using procedural fairings, if that has any effect.

I'm going in nose-first. I'm aware of how the AoA settings should be used.

I'm not using Deadly Reentry or any RCS.

Specifically, most recently I've noticed this issue while trying to drop-pod rovers onto Fine Print survey sites. Here's what the pods look like:

Payload fairing at the front, 48-7S on the back and four of the delta-deluxe winglets to stabilize.

[Youen]

1/8 of orbit is not too long, that's what I usually do for my tests, or even 1/4.

No problem with wings if you use FAR (well, at least no known issue ; it should work).

How much short do you land ? With FAR, a few kilometers are to be expected I'm afraid (usually less than 10km in my tests). Don't know if the prediction can be made more precise or if it's just because of "noise" in the parameters (controls, entry conditions, even very small changes could make a "big" difference, but I have not measured that yet).

Also, I haven't tested with procedural fairings. Maybe there is something special in this case.

I guess you are aware of that, but just in case, do you use the prediction before or after detaching your lander ? The prediction for the complete vessel could be very different from the prediction for the lander alone (staging is not implemented at this time, you have to stage/undock first and see what prediction that gives after).

Finally, the orientation used during prediction depends on the part used to control the vessel. For example if you use the "control from here" option on a different part (control module or docking port), it could change the prediction. I'm just telling this because the control module of your rovers is not visible on your screenshot, but if it's not aligned so that the "front" is the front of the fairing, it could cause issues. Same thing for the "top" when it comes to lift prediction.

Edited November 14, 2014 by Youen

[pauldbk99]

I want to report a bug:

I know that this happens when you turn the trajectories caculator on when you are on an escape orbit and when you have body fixed mode on, but for the rest, I found nothing in the debug menu that could explain this.

Edited November 14, 2014 by pauldbk99

[Youen]

The spiral is normal behavior. When body-fixed mode is enabled, the trajectory is displayed in the rotating frame of the body. Since you are getting away almost linearly, and the body rotates, this makes a spiral. Unless I don't understand what you want to show here, I don't see anything wrong.

Just turn off body-fixed mode when you don't need it. You'd need it mostly for two purposes: fine tuning a geostationary orbit (the trajectory would reduce to a dot as you wouldn't move relatively to the rotating frame), or when flying in atmosphere (it would show the actual trajectory relatively to the ground). But in most cases, it just doesn't make sense and should be turned off.

[pauldbk99]

The spiral is normal behavior. When body-fixed mode is enabled, the trajectory is displayed in the rotating frame of the body. Since you are getting away almost linearly, and the body rotates, this makes a spiral. Unless I don't understand what you want to show here, I don't see anything wrong.

Just turn off body-fixed mode when you don't need it. You'd need it mostly for two purposes: fine tuning a geostationary orbit (the trajectory would reduce to a dot as you wouldn't move relatively to the rotating frame), or when flying in atmosphere (it would show the actual trajectory relatively to the ground). But in most cases, it just doesn't make sense and should be turned off.

Yes, but this is just one of the many shapes I saw, are all those normal too? If that is the case, I do apologise for missing something.

[Kerbas_ad_astra]

Orbits in rotating reference frames just look weird to us.

Here are some funky orbits in the barycentric corotating reference frame of the Kerbin-Mun system (i.e. the frame of reference centered on the center of mass of the Kerbin-Mun system, rotating so that Kerbin and the Mun appear to stay still), computed using a prototype N-body gravity simulator: http://forum.kerbalspaceprogram.com/threads/68502-WIP-Principia-N-Body-Gravitation-and-Better-Integrators-for-Kerbal-Space-Program?p=1527888&viewfull=1#post1527888

A free return trajectory around the Earth and Moon in our barycentric corotating reference frame looks like a figure-8: https://en.wikipedia.org/wiki/Free_return_trajectory

A geosynchronous satellite will appear to describe an analemma when seen from the Earth (geostationary orbits look like single points), such as QZSS: https://en.wikipedia.org/wiki/Quasi-Zenith_Satellite_System

[pauldbk99]

Orbits in rotating reference frames just look weird to us.

Here are some funky orbits in the barycentric corotating reference frame of the Kerbin-Mun system (i.e. the frame of reference centered on the center of mass of the Kerbin-Mun system, rotating so that Kerbin and the Mun appear to stay still), computed using a prototype N-body gravity simulator: http://forum.kerbalspaceprogram.com/threads/68502-WIP-Principia-N-Body-Gravitation-and-Better-Integrators-for-Kerbal-Space-Program?p=1527888&viewfull=1#post1527888

A free return trajectory around the Earth and Moon in our barycentric corotating reference frame looks like a figure-8: https://en.wikipedia.org/wiki/Free_return_trajectory

A geosynchronous satellite will appear to describe an analemma when seen from the Earth (geostationary orbits look like single points), such as QZSS: https://en.wikipedia.org/wiki/Quasi-Zenith_Satellite_System

Oh, now I see, thanks for the explanation.

[Supraluminal]

How much short do you land ? With FAR, a few kilometers are to be expected I'm afraid (usually less than 10km in my tests). Don't know if the prediction can be made more precise or if it's just because of "noise" in the parameters (controls, entry conditions, even very small changes could make a "big" difference, but I have not measured that yet).

Also, I haven't tested with procedural fairings. Maybe there is something special in this case.

I guess you are aware of that, but just in case, do you use the prediction before or after detaching your lander ? The prediction for the complete vessel could be very different from the prediction for the lander alone (staging is not implemented at this time, you have to stage/undock first and see what prediction that gives after).

Finally, the orientation used during prediction depends on the part used to control the vessel. For example if you use the "control from here" option on a different part (control module or docking port), it could change the prediction. I'm just telling this because the control module of your rovers is not visible on your screenshot, but if it's not aligned so that the "front" is the front of the fairing, it could cause issues. Same thing for the "top" when it comes to lift prediction.

I'm not sure how to measure the shortfall. It seems like multiple tens of kilometers or so? In any case, 10km is kind of a large margin of error for rover deployment - that's around 15 minutes of drive time at 10m/s just to get to the survey area. I fully understand that it may not be possible to make it much more accurate, however.

I do all of the reentry phase using the lander only, so the prediction is not looking at any other stages. Generally they're deployed from a carrier that sits in a polar orbit; the drop pods each have ~1300m/s dV to change planes and deorbit.

I'm fairly certain I have the orientation right. Like I said, I use MechJeb to keep the pod oriented along its prograde surface vector during reentry, and everything (navball, pod) lines up as expected. The rover's probe core is oriented 90 degrees off the main axis of the pod (the bottoms of the wheels face the point of the fairing), so if it were controlling from there nothing should work right. Nonetheless, I'll take a second look to make sure on this point.

Edited November 14, 2014 by Supraluminal

[Youen]

If you can target another object that is at the correct location, you'll see the distance displayed in the main view. But maybe you don't have this possibility if there is nothing yet where you want to go.

I'll let you know when I find some time to make tests with procedural fairings if I find something weird or not.

About the error margin, the worst case I have in my tests is 6km, but I only have simple tests at this time (a pod entering forward and backward with few additionnal pieces), so I can't give numbers for more general cases (I did make more complicated tests of course, but did not measure error). As stated somewhere previously in this thread, 6km is highly precise as compared to the real world, but in a game we could expect much more precise of course, especially if we consider Kerbin is much smaller than earth. But there are approximations for performances, and maybe bugs in the way I reproduce the FAR behavior (predictions are more accurate with stock aerodynamics), or maybe the KSP behavior (gravity, update time steps, maybe there is some kind of dampening in the physics engine to avoid creating energy due to numerical errors, etc.). However, the less obvious the bug, the most difficult it is to find, and 10km of final error means the error at each simulation step is really small, so it's hard to find out which part is wrong (if there is one).

Edited November 15, 2014 by Youen

[Gryphon]

nevermind!

Edited November 16, 2014 by Gryphon
whoops

[Youen]

I just released version 1.0.0

• incremental trajectory update (the game won't slow down while trajectories are computed)
  
• more precise ground impact detection (for mountains etc.)
  
• left click on Blizzy's toolbar shows/hide trajectories, right click toggles the GUI window
  
• possibility to use stock toolbar instead of Blizzy's
  
• reorganized GUI with groups that can be shown/hidden
  
• debug display (performances and error count)
  

I think it's now ready to deserve a "1.0" version number, but as usual, let me know if you find bugs.

[TMS]

Thanks for this, Youen. This mod is already a 'must have' (alongside KER and PreciseNode) for me.

[wcoenen]

Thanks for making this. I love doing interplanetary transfers with a single aerocapture pass.

Edited November 17, 2014 by wcoenen
Misspelled "aerobraking", and I actually meant "aerocapture".

[Gfurst]

• left click on Blizzy's toolbar shows/hide trajectories, right click toggles the GUI window
  
• possibility to use stock toolbar instead of Blizzy's
  
• reorganized GUI with groups that can be shown/hidden
  

I think it's now ready to deserve a "1.0" version number, but as usual, let me know if you find bugs.

You took my advice, awesome . Very happy to see that, will report back if I notice anything wrong. And of course, thanks for the awesome addon.

[rdwulfe]

Trajectories now responds *very* slowly for me. Incredibly slowly. It updates maybe once every 15 seconds or worse. Not sure why. I've 15 or so mods installed, including:

AlternateResourcePanel

Chatterer

DMagic

Firespitter

Kerbal Alarm Clock

kOS

MechJeb

MissionController

PreciseNode

RemoteTech

SCANsat

TAC LS

Toolbar

Those are the major ones. kOS is one of my newest. Is it somehow interfering? I didn't have problems before Trajectories 1.0, so I'm wondering if it's the new version... or kOS which I installed at the same time.

Will investigate further.

EDIT:

Also Precise NODE, which I'd forgotten I had installed. That might be doing it.

Edited November 18, 2014 by rdwulfe

[Youen]

One of the big changes of latest release is that trajectories are computed incrementally. Each frame, it will compute a bit of trajectory, and then suspend until the next frame, where it will resume computing, and so on until the whole trajectory is computed. Then it will display the result, which will remain visible until the next trajectory is fully computed, etc.

So the rest of the game shouldn't lag (this is the point), but depending on your computer, the trajectory might update at a low rate. 15s seems a lot though, especially if you didn't have performance issues before (the previous behavior was that the whole game was frozen until the trajectroy was computed, each frame).

Maybe it's just a matter of tweaking how much time is dedicated to Trajectories each frame, I'll add an option for that.

In the mean time, can you confirm that

- the game does not lag? (only trajectories do)

- no errors are reported? (counter displayed in the settings group)

- what time is indicated in the "Perf" section? (this is the average time spent for computing trajectories per frame)

- if you know that, what is your CPU?

Edited November 18, 2014 by Youen

[rdwulfe]

Perf: 2.8ms 0 error(s)

Aerodynamic model: stock

No game lag at all. Perf gets higher the 'deeper' my descent trajectory... But even with this small number, it only updates on my screen infrequently.

The ship I just launched is quicker, once every 2-3 seconds, so the complexity of the ship seems to be a huge factor. The ship I launched before has approximately 120 or so parts.

My CPU is a Pentium 4 CPU running at 3.00 GHz. 2 Gigs ram. Not beefy by any means, but she gets the job done normally.

EDIT: I also admit I miss the old "Body-fixed mode" radio button at the top. It made life easy to switch between the modes, as I toggle them constantly. I also switched back to the 0.4.1 version to confirm its behavior was the same. No lag, instant response to my changes in orbit.

Edited November 18, 2014 by rdwulfe

[Youen]

ok, thanks for the feedback, I'll take a look at the stock aerodynaic code and bring the body-fixed mode back on top.

[rdwulfe]

Thank you, Youen! You're amazing!

[arkie87]

Wow, this mod is amazing-- i hope squad absorbs it (and compensates you accordingly).

What do you think about making the functionality slightly different to increase its number of features:

(1) When nothing is targeted, everything functions as described except when targeting the landing location, the navball uses the blue maneuver node indicator to show where you should be pointing (rather than new indicators) i.e. always point towards blue indicator (not sure why two indicators are needed)... on second thought, you mentioned the second indicator was for direction only, rather than magnitude so perhaps, a better idea is to use the blue arrow (like the new navball in 0.25 uses to show where your maneuver node is on navball when its off screen) to show which direction corrections should be made. The magnitude of the correction could also make this arrow bigger or smaller (or darker/lighter).

(2) When a target is set (on the surface only), the plugin backward calculates the orientation/AoA necessary to arrive there, and if no atmosphere is present, calculates the maneuver node necessary to arrive there (to me, it seems the backward calculation functionality is already there, since for option 1, the indicators on the navball will tell you how far from ideal you are).

Also, out of curiosity, what integration scheme and order do you use in your calculations (4th Order Runge-Kutta?), and do you use the known variation of density with height to allow for very accurate results with large timesteps and few calculations (thus faster updates)?

[Semmel]

Using this mod, I have some difficulties I dont know how to solve. Its probably my inability to use it properly, so please give me a hint.

I use FAR and Deadly reentry. I have a maned space probe, using the small stock Command Pod Mk1 with a heat shield underneath. I set up the descend trajectory to get down at my desired location. Than I separate from the lander from the service module and prepare for reentry. However, the drag of the heat shield with the MK1 seems to line up very badly with the estimated landing location. If the initial trajectory is very flat and I aim for KSC, the actual touch down point is at the west coast of the KSC continent, at the other side of the mountain range. That is a significant difference. What do I need to do in order to correct for that? Due to the nature of the problem, I cant control the descend after the separation with the service module. Any suggestion?

Edit: Thanks for this great mod btw! It makes life much much easier. I also should add that my experience is with the second to last version, the one before 1.0.0.

[Youen]

Wow, this mod is amazing-- i hope squad absorbs it (and compensates you accordingly).

What do you think about making the functionality slightly different to increase its number of features:

(1) When nothing is targeted, everything functions as described except when targeting the landing location, the navball uses the blue maneuver node indicator to show where you should be pointing (rather than new indicators) i.e. always point towards blue indicator (not sure why two indicators are needed)... on second thought, you mentioned the second indicator was for direction only, rather than magnitude so perhaps, a better idea is to use the blue arrow (like the new navball in 0.25 uses to show where your maneuver node is on navball when its off screen) to show which direction corrections should be made. The magnitude of the correction could also make this arrow bigger or smaller (or darker/lighter).

I don't think using the stock indicators is a good idea (assuming that would be possible), because they already have a meaning, that is different from the meaning of the new ones. But I do agree that the new indicators are ugly, and also they are displayed even when on the hidden side of the navball, which is wrong and misleading.

As you stated, the correction indicator is just a hint : it is only relative to the distance of the impact point relatively to the target. So it doesn't account for any aerodynamic feature of the craft, it just assumes that pulling up will make you go farther (I'm sure it's plain wrong for some craft designs, but it should help with most planes). It should be replaced by some kind of arrow though. The other indicator just represents how the descent profile is configured, so if you follow it, you should follow the displayed trajectory (but chances are you will slowly drift over time, which is why the correction indicator is there).

(2) When a target is set (on the surface only), the plugin backward calculates the orientation/AoA necessary to arrive there, and if no atmosphere is present, calculates the maneuver node necessary to arrive there (to me, it seems the backward calculation functionality is already there, since for option 1, the indicators on the navball will tell you how far from ideal you are).

About calculating maneuver nodes, I wanted to follow the original game philosophy instead, which is to show you what will happen after the maneuver, but not tell you how you should modify it, which is quite efficient at making you learn orbital mechanics. The mod is not an autopilot either. These are interesting features though, but maybe for another mod.

Also, out of curiosity, what integration scheme and order do you use in your calculations (4th Order Runge-Kutta?), and do you use the known variation of density with height to allow for very accurate results with large timesteps and few calculations (thus faster updates)?

I use Verlet integration. It can probably be improved, but concerning accuracy I'm more concerned about the correctness of aerodynamic forces computations. It's hard to tell though.

[Youen]

Using this mod, I have some difficulties I dont know how to solve. Its probably my inability to use it properly, so please give me a hint.

I use FAR and Deadly reentry. I have a maned space probe, using the small stock Command Pod Mk1 with a heat shield underneath. I set up the descend trajectory to get down at my desired location. Than I separate from the lander from the service module and prepare for reentry. However, the drag of the heat shield with the MK1 seems to line up very badly with the estimated landing location. If the initial trajectory is very flat and I aim for KSC, the actual touch down point is at the west coast of the KSC continent, at the other side of the mountain range. That is a significant difference. What do I need to do in order to correct for that? Due to the nature of the problem, I cant control the descend after the separation with the service module. Any suggestion?

Edit: Thanks for this great mod btw! It makes life much much easier. I also should add that my experience is with the second to last version, the one before 1.0.0.

Staging is not implemented, so when you separate the command pod, it's completely normal that the prediction changes a lot. The prediction for the whole ship probably has similar drag forces, but as the ship is heavier, it will go farther. The command pod alone will fall short of the initial prediction. Ideally, the mod should be improved to allow select the stage that will enter atmospher, but I haven't tried yet, and I don't know if it's possible with FAR.

[arkie87]

I don't think using the stock indicators is a good idea (assuming that would be possible), because they already have a meaning, that is different from the meaning of the new ones. But I do agree that the new indicators are ugly, and also they are displayed even when on the hidden side of the navball, which is wrong and misleading.

As you stated, the correction indicator is just a hint : it is only relative to the distance of the impact point relatively to the target. So it doesn't account for any aerodynamic feature of the craft, it just assumes that pulling up will make you go farther (I'm sure it's plain wrong for some craft designs, but it should help with most planes). It should be replaced by some kind of arrow though. The other indicator just represents how the descent profile is configured, so if you follow it, you should follow the displayed trajectory (but chances are you will slowly drift over time, which is why the correction indicator is there).

About calculating maneuver nodes, I wanted to follow the original game philosophy instead, which is to show you what will happen after the maneuver, but not tell you how you should modify it, which is quite efficient at making you learn orbital mechanics. The mod is not an autopilot either. These are interesting features though, but maybe for another mod.

I use Verlet integration. It can probably be improved, but concerning accuracy I'm more concerned about the correctness of aerodynamic forces computations. It's hard to tell though.

Thanks for prompt reply.

Verlet algorithm is second order, so there is room for improvement, which could theoretically result in faster prediction updates for the same level of accuracy (though 4th Order Runge-Kutta is a pain to implement).

What do you mean you are more concerned about correctness of aerodynamic force computations-- you think you are using these forces incorrectly (unsure if you implemented it right) or that accuracy of prediction is much better than ability of user/pilot to maintain required AoA anyway (so why bother improving accuracy/speed of prediction)?

Edited November 19, 2014 by arkie87