[old thread] Trajectories : atmospheric predictions

[cybersol]

Just to make sure, are you staging off any parts of your craft during this sequence of events?

No staging for me, as its usually a rocket SSTO coming in for landing at KSC

Does your craft have any wings, control surfaces or fairings? The stock aero prediction system isn't working quite right with those at the moment.

Yeah, the rocket SSTOs usually have 12-20 AV-R8 control fins depending on how awkward the payload is.

I'm still experimenting with other craft, but so far it definitely seems like the overall tendency is to overshoot the prediction, as others are reporting.

[thegreatgonz]

I, too, am experiencing massive overshooting with stock aero. I'm not just getting the wrong landing position, but also getting cases where the mod shows me landing, but in practice I skip back out into space. No aero parts, and no mods that seem relevant. Is this being worked on?

[narf0708]

The new 1.0.3 update reduced drag, which explains the 'pessimistic' predictions seen.

[Bishop149]

Is this mod being maintained at all?

No disrespect meant its just its an awesome mod that is getting less and less useful with each new iteration of KSP, which is a shame.

Even in its inaccurate state its better than nowt, can't imagine KSP without it and am hopeful of an update!

[Jarin]

I hear tell that it's still perfectly functional with FAR, if people are feeling adventurous about trying realistic drag mechanics.

[Murdabenne]

I hear tell that it's still perfectly functional with FAR, if people are feeling adventurous about trying realistic drag mechanics.

No thanks, I have enough realism to deal with outside the game. If I want a sim, there are good ones out there that don't have little green dudes with big heads, but actual mockups of NASA and other craft. Plus I have enough in RAM now without something cluttering it up for minimal gain since I am not a space-plane or aircraft flyer, so the atmosphere is only something between me and space. I prefer rockets, and prefer the stock aerodynamics, which is real enough to make it non-trivial, but abstract enough to be fun instead of work. To each his own (which is what makes this such a good game). Maybe when I get farther along in the career game.

I'm wondering if this will be updated for the reduced drag and changed thermal models in 1.0.3/1.0.4? If not, what all is involved in changing it - perhaps some of the maths in the stock section, but the rest should be no change perhaps?

Edited July 2, 2015 by Murdabenne

[Youen]

I think it wasn't completely accurate in 1.0.2 either. Don't know if it's gotten worst with 1.0.3 or if it's just the same. Something must be wrong somewhere, but I don't know what. I'm not working on the mod at the moment, but maybe I'll get back to it later (no ETA, sorry). Results are much better with FAR for the few ships I've tested (not because it's intrinsicly better or more realistic, but just because it's open source so easier to follow, and also ferram exposed a public API to do exactly what Trajectories needs).

I know it sucks that it isn't accurate for the stock model anymore, but it's quite a pain to keep mods up-to-date with KSP updates (not their fault either of course). Especially 1.0 introduced a really more complicated model.

[thegreatgonz]

FWIW, I'm finding accuracy seems to vary a lot with the ship. I seem to be getting much better results with my 2.5m ships than I did with my 1m ships.

[Vorg]

I de-orbited a booster last night and it came down very close to the predicted spot. Might have been dead on if I hadn't deployed chutes at ~7k. And nearly a 3rd of it's final orbit was in atmo. It was a very shallow entry.

[Youen]

I de-orbited a booster last night and it came down very close to the predicted spot. Might have been dead on if I hadn't deployed chutes at ~7k. And nearly a 3rd of it's final orbit was in atmo. It was a very shallow entry.

Maybe the bug is in drag adaptation for stacked parts then...

[diomedea]

Everything in these latest posts shows to me the lift component is not yet correctly accounted (or not at all).

Since KSP 1.0 every part has a "bodylift" component. And, wings and control surfaces still have a very peculiar lift in KSP. As should be widely known, lift is a force acting perpendicular to the air flow, Lift = 0.5*ÃÂ*v^2*A* Cl (where ÃÂ= air density; v= speed of the airflow; A= area of the surface exposed to the flow; Cl is the lift coefficient that is mainly function of the Angle of Attack (AoA) for a specific airfoil).

Parts where drag remains the dominant force (short cilindrical objects, spheres) will retain a reentry profile defined mainly by drag. But any craft with wings or a longbody (in the air flow direction) will show a marked lift component, that will seriously change the trajectory. Keeping the Angle of Attack =0 along the whole reentry, so to cancel lift, would allow prediction to match what expected (though, keeping AoA =0 is the worst reentry profile for thermal stress).

As lift dramatically changes in intensity with AoA (and, its vector can rotate around the air flow direction at will), its cumulated effect during reentry can bring the craft in any point within an elliptic area, its center being the predicted point when only drag is considered. This ability to use vectored lift to modify the reentry path is widely used however.

Yes, KSP 1.0.3 changed some of the physics constants that affect drag and lift as they were known in 1.0.2. While those changes have certainly reduced drag somehow, the same would make lift a greater influence compared to drag.

To me, that's why "it's gotten worst with 1.0.3", but hope to have made clear where the wrong is. Trajectories can't account for something like AoA during reentry, that is a wild unknown with potential huge effects. If the tool could make a valid guess at the AoA kept during reentry, then lift could be computed.

[Youen]

I'm not sure if that's what you meant, but just in case, AoA is taken in account by Trajectories (the player can choose prograde, retrograde, or a custom angle, or even an AoA that varies depending on the ship altitude, which is meant for spaceplane reentry). Then, of course, the player has to keep its rocket/plane with the correct AoA during the whole entry, and as you said, small errors can accumulate to huge difference for the landing site (especially for spaceplanes).

I've just looked quickly at the code written by atomicfurry for stock aerodynamic predictions, and there is definetely somthing about lift. But maybe not accurate though. Also, if I understand correctly this post from thegreatgonz, there are also issues with ships that have no wings.

The fact is, there could be issues both with lift and drag... I'll make more tests when I find some time.

- - - Updated - - -

Does anyone know what CubeData.exposedArea means? It's not used in the current prediction code, but maybe it should?

Also, if someone with knowledge of stock aero wants to check the prediction code, it's there: https://github.com/neuoy/KSPTrajectories/blob/master/Plugin/StockAeroUtil.cs (function SimAeroForce)

Edited July 3, 2015 by Youen

[Vorg]

I should have been more clear, it was the first stage, not an SRB. It was mad up of 2 of the 1/2 orange tank tanks, a Mainsail, 4 heat sinks near the engine and one of the probe cores and I forget how many chutes.

[Mipe]

Would it be possible to collect aerobraking data and then calculate trajectories based on collected data? More accurate the more you scream through atmosphere.

[Vorg]

Then you end up with a bunch of big data base files to work through.

[Requia]

assuming an AoA of purely pro or retrograde would seem perfectly functional here. (no good if the rocket won't point one of those two ways naturally though) A lot of the normal control systems could be left untouched in favor of getting close to KSC in the first place.

Edited July 9, 2015 by Requia

[A_name]

Is this working on 1.04? If so, any idea when it will be working on CKAN?

[UAL002]

Is this working on 1.04? If so, any idea when it will be working on CKAN?

I think they're re-re thinking the stock drag/lift model. They're talking about a lot of over my head math. Must be a bunch of aero engineers.

[LostOblivion]

Even though the mod is a bit off, it's still invaluable for precision reentries. I use it to plan reentry with my shuttles, and its inaccuracies can be worked around by steering the shuttle (higher AoA, etc.) during reentry. Doing this, I always end up over KSC. So Youen and Kobymaru , thanks for this fab mod! :-)

[ajburges]

For reentry...

As long as you give your craft has no air brakes and maintains pro/retrograde course (to avoid lift) trajectory will easily be accurate to 10 km.

If you are reentering with space plane: the kobra maneuver will subtract around a quarter circumference from the trajectory, but add a little less than an eighth circumference once you enter a glide. Plot your course so that the trajectory is between KSP and the mountains at 50 km. Somewhere near the peninsula in the east.

For aerobrake...

It you overshoot a tad unless you use airbrakes. airbrakes make aerobrake trajectories useless. In 1.04 you are better just sticking to multiple passes at a 50-55 km aerobrake altitude for Kerbin anyway.

[Youen]

I think I've found the bug that caused the biggest prediction issues when using the stock aerodynamic model : the forces cache was not updated if the vessel shape changed.

To reproduce this bug, you have to predict a reentry (aerodynamic forces will be cached during prediction for various altitudes and velocities, this also happens if you go in map view during ascent), and then change the shape of the ship (decoupling stuff for example). Then, while the mass of the ship is correctly updated, which means you'll see the predicted trajectory change and think everything is OK, forces that have already been cached are not updated, which means the new trajectory might be highly inaccurate. Basically, the prediction thinks you still have all the drag from the parts you've decoupled, which means it will predict short of the real landing site (this isn't completely true either, because new situations that are cached after decoupling, such as lower speed for a given altitude, will compute the forces correctly for the relevant portion of the trajectory, so the new prediction is a mix of valid and invalid data). Of course this bug didn't appear in the simple test scenarios that I use during development, which explains why it's been there for so long.

A temporary workaround : in the Trajectories GUI, click the "update now" button in the settings each time you decouple something, or anything else that has an impact on aerodynamics.

I'll publish a new version soon. I'll see if I can make a version that is compatible with KSP 1.0.2 to 1.0.4 versions.

Edited July 10, 2015 by Youen

[atomicfury]

It you overshoot a tad unless you use airbrakes. airbrakes make aerobrake trajectories useless. In 1.04 you are better just sticking to multiple passes at a 50-55 km aerobrake altitude for Kerbin anyway.

Airbrakes are treated as a special case in the stock aero system - they have there own set of curves, or at least they did in 1.0 and 1.02. I gave up working on them since I was just trying to get the base functionality in for stock aero. If someone out there is working on them, the code could check for the special modules/curves if the brakes are on, but see what Youen says about changing parts during flight below.

I'll publish a new version soon. I'll see if I can make a version that is compatible with KSP 1.0.2 to 1.0.4 versions.

I haven't stopped in for a while. Sorry to see folks are having trouble with spaceplanes and wing parts - I never figured out what was going on exactly. Real Life is a bit to busy for me to help now, but here may be some hints in case someone out there is working on this. During testing I found that wing lift was off, and I thought it scaled to angle of attack. I suspect that I missed a rotation or transform for the wing relative to the airstream, but I could never track it down. I know also that unless you forced constant updates, control surfaces might mess things up - when the cache gets built it will use the current state of the control surfaces (angle of deflection and whatnot) to build the cache. If you leave SAS on during re-entry, the control surfaces could move, changing their aero forces. The more control surfaces a craft had, the worse predictions I saw during testing if they kept moving.

[Youen]

I've released a new version here. If I get positive feedbacks (and no regression), I'll upload it to Kerbal Stuff as well.

This version should fix the staging bug (where drag was not updated after detaching a part of the vessel), and also improve accuracy for prograde entries (related to the cache resolution that missed a point for AoA of 0°)

Let me know if you still have prediction errors with stock aerodynamics (a .craft file would help, because everything I've tested on this version seems to be pretty accurate)

[Murdabenne]

I've released a new version here. If I get positive feedbacks (and no regression), I'll upload it to Kerbal Stuff as well.

This version should fix the staging bug (where drag was not updated after detaching a part of the vessel), and also improve accuracy for prograde entries (related to the cache resolution that missed a point for AoA of 0°)

Let me know if you still have prediction errors with stock aerodynamics (a .craft file would help, because everything I've tested on this version seems to be pretty accurate)

Thanks so much for this - the maths for the aero vs dragcubes vs unity vs KSP are not simple items - I am thankful for you folks who do handle this!

[atomicfury]

I've released a new version here. If I get positive feedbacks (and no regression), I'll upload it to Kerbal Stuff as well.

This version should fix the staging bug (where drag was not updated after detaching a part of the vessel), and also improve accuracy for prograde entries (related to the cache resolution that missed a point for AoA of 0°)

Let me know if you still have prediction errors with stock aerodynamics (a .craft file would help, because everything I've tested on this version seems to be pretty accurate)

The debug messages are still on! Otherwise seems to work fine.