[old thread] Trajectories : atmospheric predictions

[Youen]

Set up for 0 angle of attack at all ranges and followed the velocity vector in (bottom of capsule first) and landed on the other side of the mountain range. Is this because it was expecting me to go in top first?

Yes, Angle of Attack of 0° means exactly that : you should point toward the prograde direction. But in the latest version (0.2.2) you can set an AoA of 180°, this has been added exactly for the case of capsules entering atmosphere backwards. Now as pointed out by Entropius, you'll get the prediction for your entire ship, and when you'll detach the capsule you'll get a new prediction for the capsule alone... excepted it's too late to arrange your velocity if you don't have engines on the capsule.

It would be nice if it could update your ship's drag, not based on the ship's current stage/state, but rather a future stage. That way you could get your orbiter into a desired trajectory without having to first decouple the capsule from it yet. (But I'm not even sure if this is possible from a technical standpoint, maybe not).

That's indeed complicated to do. At this time, I just throw some air velocity at FAR, and it tells me the aerodynamic forces for the vessel as it currently is. I'm not telling it's impossible, but don't expect that soon.

[Youen]

They do not. Firespitter Airbrakes operate by adjusting the part's maximum_drag and minimum_drag properties. The stock drag system does the rest.

OK, didn't know that was with the stock model. So it's probably because I precompute the average drag for the whole ship and don't update that later. It's not that computationnaly expensive, so maybe I could update this each frame. Adding that to the bug tracker. There will probably be the same issue for the Stock Drag Fix mod.

Edited September 24, 2014 by Youen

[Chimer4]

Yes, Angle of Attack of 0° means exactly that : you should point toward the prograde direction. But in the latest version (0.2.2) you can set an AoA of 180°, this has been added exactly for the case of capsules entering atmosphere backwards.

Thought that was the case

Also just renistalled the new version, but it still wont show a trajectory for the SP+ Explorer or the stock Aeris 4A. Not sure if its something that I'm doing wrong or if its some incompatibility with the mods. Works fine with pods. I'm using NEAR btw in case that is of help, other mods that i have are just visuals.

SP+ Explorer

pod

Edited September 24, 2014 by Chimer4

[Alshain]

Which is why several times I've suggested in the MJ thread for Sarbian is that the correct solution to the FAR problem is to accept the inaccuracies for what they are. IRL, it's impossible to make the kinds of accurate predictions that players expect.

And yet the NASA shuttle landed by computer perfectly on the runway without jet engines or any type of propulsion how many times? Yep, must be impossible IRL.

I'm not disagreeing with you that this addon doesn't need to be perfect, but that statement about being impossible just confused me.

Edited September 24, 2014 by Alshain

[sgt_flyer]

The space shuttle is easy to make pinpoint landings with - heck, if you know how your spaceplane handles reentry in KSP, it's pretty easy to land at KSC without assistance - simply because they can glide and make approach corrections.

Whereas, in real life, capsule style landings generally have a huuge prediction zone, which is reduced the further they are in atmo. (Real life Capsules can use their angle of attack to adjust the position of the landing zone, but it's still an incertity of several kilometers of radius)

You can replicate this in KSP if you are using FAR - tilt the blunt end of your capsule to be above your reentry vector, and you'll fall short. Tilt the blunt end below the vector, and you'll gain additional lift (as the air is deflected more downwards) and you'll be too long.

Keep in mind that those are predictions - any action upon the spacecraft during reentry can alterate the prediction - which will become more precise the further you are during your reentry.

[marce]

If the problem is the number of data points I suppose we could take even one more step towards reality and have it calculated not instantly. If not the following doesn't make sense

What I'm thinking about is to tell MJ (and I think we all hope for an integration) on which coordinates to land. Then i would have no problem if a "calculation phase" starts which takes some time, retrieving so many data points every frame until a proper curve is ready. This should obviously either happen while still in a stable orbit or even pause KSP until done. After calculation finishes MJ does it's usual landing thing using the calculated burn points, angles, corrections, etc.

During the reentry every frame as many data points as possible are updated. While we move along the curve the amount of necessary data points gets smaller every time. Maybe KSP should freeze after certain points again to recalculate the remaining trajectory exactly. MJ reacts on required changes by changing AoA or using RCS or engines.

I don't know how many calculations are done currently, but I would be absolutely ready to wait 30sec or so until enough data is available. If I get a precision landing in return I'll safe much more time I would otherwise hop or rover over the planet to my target.

[sarbian]

The NASA know the aerodynamics properties of the shuttle before it evens flies. When the properties of your ship are fixed it's a bit easier to predict something.

But Starwaster is right. I could have used a less precise approach long ago, but I don't work that way

Edit: marce, MJ is quite precise with stock aero, even with chute (well, .24 added a bug in stock chute I can't do much about).

But MJ thread may be a better place to talk about MJ, or ask on IRC.

Edited September 24, 2014 by sarbian

[Dooz]

Can this also predict Aerobraking?

[Alshain]

Can this also predict Aerobraking?

In stock yes, in FAR sort of but it won't be perfectly accurate.

[Youen]

Also just renistalled the new version, but it still wont show a trajectory for the SP+ Explorer or the stock Aeris 4A. Not sure if its something that I'm doing wrong or if its some incompatibility with the mods. Works fine with pods. I'm using NEAR btw in case that is of help, other mods that i have are just visuals.

OK, I've added it on the bug tracker

[Youen]

In stock yes, in FAR sort of but it won't be perfectly accurate.

If you fly while looking at the map (i.e. open the nav ball at the bottom), it's perfectly possible to adjust your flight during aerobrake to raise or lower your post-aerobrake apoapsis. At least with a spaceplane it works well. Would be easier with the same targeting system as for landing (excepted this time the target is an apoapsis height, not a ground position).

[Bedi]

I tested it in RSS and it dosen't work. I will specify and show screenshots later.

[Chimer4]

OK, I've added it on the bug tracker

I'll go through with a clean install just to make sure that it isn't just something on my end

[Youen]

I'll go through with a clean install just to make sure that it isn't just something on my end

You can also take a look at your KSP_Data/output_log.txt see if there is something related to Trajectories.

[Chimer4]

The plugin works fine with no mods installed, but with SP+ installed pods still work, but spaceplanes of any kind appear to not work :/ each time I tried I had NEAR installed

Going through output_log.txt I found this, is this of any help? The only thing I can think of is that SP+ has its own configs for FAR/NEAR which may interfere in some way, but I don't see why that would effect completely stock space planes

NullReferenceException: Object reference not set to an instance of an object
  at Trajectories.VesselAerodynamicModel.computeForces_FAR (Double rho, Double machNumber, Vector3d airVelocity, Vector3d vup, Double angleOfAttack, Double dt) [0x00000] in <filename unknown>:0 

  at Trajectories.VesselAerodynamicModel.getCachedFARForce (Int32 v, Int32 a) [0x00000] in <filename unknown>:0 

  at Trajectories.VesselAerodynamicModel.getFARForce (Double velocity, Double rho, Double angleOfAttack) [0x00000] in <filename unknown>:0 

  at Trajectories.VesselAerodynamicModel.computeForces_FAR (.CelestialBody body, Vector3d bodySpacePosition, Vector3d airVelocity, Double angleOfAttack, Double dt) [0x00000] in <filename unknown>:0 

  at Trajectories.VesselAerodynamicModel.computeForces (.CelestialBody body, Vector3d bodySpacePosition, Vector3d airVelocity, Double angleOfAttack, Double dt) [0x00000] in <filename unknown>:0 

  at Trajectories.Trajectory.AddPatch (Trajectories.VesselState startingState) [0x00000] in <filename unknown>:0 

  at Trajectories.Trajectory.ComputeTrajectory (.Vessel vessel) [0x00000] in <filename unknown>:0 

  at Trajectories.Trajectory.Update () [0x00000] in <filename unknown>:0 

This continues for the entire output log

Edited September 24, 2014 by Chimer4

[Youen]

Well, actually it might be as stupid as it just doesn't work with NEAR if you have wings. Somehow, it looks like I didn't test that case. If it's really that, I should have a bugfix soon, I keep you posted.

EDIT: here it is, just released 0.2.3 with the bugfix. The problem was because I have a hack to avoid breaking the craft during prediction due to big aerodynamic forces (that would break the actual craft, because it's used in the prediction code), but NEAR does not have this aerodynamic failure feature, so it caused an error on all wing parts.

Edited September 24, 2014 by Youen

[Chimer4]

ill check that out later, thanks for that

UPDATE: can confirm this does now work with NEAR if you have wings. Thank you

Edited September 24, 2014 by Chimer4

[jordanjay29]

Any chance of auto-disabling Trajectories when the orbit does not enter the atmosphere?

[Youen]

Any chance of auto-disabling Trajectories when the orbit does not enter the atmosphere?

Yes, that's already added in the bug tracker by someone else.

[StainX]

OOHHH MYYYYY!!!! Thank you so much! This is the feature i always missed in KSP!

[epicfacecanada]

Does this mod work with rss?

[Youen]

Does this mod work with rss?

Bedi has tested it and said that it doesn't work, but hasn't given details yet.

[Starwaster]

Does this mod work with rss?

Bedi has tested it and said that it doesn't work, but hasn't given details yet.

I find it hard to believe that it wouldn't work. Although I've been following this thread, until now I hadn't actually installed it.

So I decided to do so and test with RSS since I have it installed.

Also, I don't use FAR or NEAR, I use my own creation Stock Drag Fix. I had previously indicated there shouldn't be any compatibility issues between SDF and Trajectories, but I'm not sure there has been an actual testing of it. So I checked that out as well.

Finally, Firespitter airbrakes. Those had been discussed previously so I put those in the mix as well. Oh, and a comparison with Mech Jeb 2's landing predictions.

Below is a series of screenshots. The first one is pretty much just a discarded rocket stage with some fuel left in it. No airbrakes. The blue marker is Mech Jeb's prediction. You will also notice a similar red marker on top of AT's cross. I put that there (MJ's landing site selector) That way I can get a precise indication of how far off the two are. (the landing autopilot window indicates a difference of 57.23 km)

The next few shots are a reentry vehicle with four FS Airbrakes and an inflatable heat shield. The last is significant because it alters drag when it inflates. Each of the 4 airbrakes alters the drag rating by setting it to 40 (maximum_drag = 40)

With the brakes deployed MJ is reporting a difference of 6,314 km but I'm pretty sure it's only about 200 km difference. With the brakes off, the number falls to 12 km.

As it turns out, MJ's prediction was closer. (except for its odd reporting of over 6 THOUSAND kilometers initially so that sounds like a bug report for the MJ forum coming up). As the craft got deeper into the atmosphere, Trajectories' prediction got closer to MJ's as seen in the final shot. I'm not sure why the airbrakes would produce such a discrepancy seeing as all they're doing is increasing the drag rating on the airbrake parts. Strictly going off of stock behavior.

As for the other discrepancies I'm not sure if that's an RSS issue or what. It shouldn't be really. The atmospheric model is legacy so nothing unusual going on there other than the atmosphere being over 100km deep.

Javascript is disabled. View full album

[Youen]

I think the issues with Stock Drag Fix and Firespitter air brakes is that I precompute the whole vessel drag to speed up computations (remember I'm simulating the whole trajectory each frame, so don't want to iterate over each part for each point of the simulation, on each frame). But I will modify that to re-run precomputation once per frame, so that changes in drag coefficient will be accounted for.

Also, I did notice the prediction is usually a bit short of the actual impact point. Don't know why yet. For very long trajectories (shallow entry angle), this can lead to a big error in landing zone prediction.

Edited September 25, 2014 by Youen

[Starwaster]

I don't think any discrepancies there are due to SDF. Any calculation made is going to be valid even after resources change. Drag forces won't change.