Precision deployment of parachutes

[Laie]

Situation: lander approaching base. I'd like to time the deployment of my parachutes such that I come down pretty close to the base. Say, dozens of meters. I have kRPC at my disposal to look at relevant data and trigger the chutes with split-second precision. Only, when?

If anyone has solved that problem before? I'd be grateful if you would share how you did it.

[bewing]

You would need an atmospheric drag model that matches KSP's fairly closely. You also need to know the exact timing of the various parachutes to go from closed to partial to full deployment, and the related drag values. You also need the mass and drag of the landing craft, to factor that into the simulation too.

In any case, you pick a theoretical reference point on the ground straight beneath you. You theoretically initiate the parachute sequence as you theoretically cross it. You simply run the simulation until your theoretical landing craft reaches terminal velocity and then measure how far downrange you went from your starting point. Then pick your actual destination point and subtract that number, and begin staging your parachutes there. You can redo the calculation once a second, or something like that, after you are below the altitude/speed limit of your first parachutes, to refine the exact moment.

Edited April 26, 2020 by bewing

[Linkageless]

My only method is iteration while cutting down on as many variables as possible.  I've recently had some success with targeting on Duna with using the trajectories mod, and targeting for 1km overshoot, but both vessels doing that were using a partially propulsive landing (I would have needed ridiculous amounts of parachutes).

As with Bewing's suggestion, a reference point/ landmark was helpful for timing of the thrust, although my primary reference was altitude.  I did this manually so vectoring was needed to get me on target.  I also staged the chutes early in the descent, so they opened as soon as their conditions were met.

It came as a pleasant surprise that I could actually drop the minimum pressure setting on each to 0.1 for Duna (rather than the VAB values of 0.2 for drogues and 0.4 for radial chutes), which was handy for phasing when they initially pop out.

TL;DR - For me, that kind of precision is only possible with persistence and over-engineering!

[Laie]

2 hours ago, bewing said:

You also need to know the exact timing of the various parachutes to go from closed to partial to full deployment,

Yup, one can't possibly work without *that*. For future reference, if the topic ever comes up again:

(fun fact: these plots are where .gif works best, hands down)

That's data from two tests starting with different air speeds. Timer starts when the parachute is staged, it's almost 2 seconds until it becomes first noticeable. The faster vessel brakes harder at first, but after 3-4 seconds they're even.

In terms of actual ground distance covered after deployment (not shown), the difference is a whole 250m, most of which happens before the chute becomes effective.

1 minute ago, Linkageless said:

As with Bewing's suggestion, a reference point/ landmark was helpful for timing of the thrust, although my primary reference was altitude.  I did this manually so vectoring was needed to get me on target.

Just by the way, the highest possible precision amounts to however much ground distance one covers between physics updates. These happen 20 times a second, right? No matter how smart your autopilot is, or how fast your reflexes are, you can only rip the cord at a few distinct points in time: one of these is bound to be a little too early, and the next one is already too late.

So in my example, for a vessel going 300-400m/s, even the most precise timing of the parachute will only get me to within 7-10 meters of my target (assuming I have it lined up perfectly, which probably is not a safe assumption to make).

If the vessel is supposed to land on a post stamp (or a docking port), there will have to be some vectoring in the end.

Personally, I'll be content if I can use parachutes to get within 100m of my landing point. It seems as if that should be doable without a full-on aerodynamics simulation.

[bewing]

41 minutes ago, Laie said:

These happen 20 times a second, right?

Uh, I don't think it's that often? Isn't that the number in your game settings that defaults to about 8?

42 minutes ago, Laie said:

the difference is a whole 250m

Well, if the ground range variation is that small, and is a simple function of initial air speed, then yeah that sounds pretty simple.

 

[AHHans]

10 hours ago, Laie said:

(fun fact: these plots are where .gif works best, hands down)

OT rant: Well, PNG works as well, for papers or posters vector image formats (SVG, PS, PDF if it is vector data) are even better, jpg - and everything that uses a similar compression algorithm - just plain sucks! Especially for posters! Double especially if you send me a powerpoint file that I'm to print for you! So switch off that "automatically compress images on save" option! *arrrggghhhh!*

Sorry for the off-topic, but that needed to get out.

[Linkageless]

10 hours ago, Laie said:

20 times a second

Oh how I wish I could reach that   And yes, 100m accuracy by parachute alone would be marvellous on Kerbin, let alone Duna!

[CBase]

Actually I got pretty descent results on Kerbin on parachute timing, see https://github.com/cbase2/MechJeb2/blob/master/MechJeb2/LandingAutopilot/AtmosphericCorrection.cs.

Parachute.Update() is what you are probably looking for, it is calculating horizontal slow down distance for netwon drag (F = k v²) until terminal velocity with open chutes: x(v) = m / k * (ln v - ln v_t)

However I made some approximations you should be aware of:

• During semi and full deployment drag is linear increased which I ignored. I simply added the time from issueing deploy command until it is fully deployed and multiply with speed at start of deployment. It was good enough, so I never cared to adopt x(v) for a k(t) = k_0 + k_1 * t. This is probably biggest error so far.
• It is pure horizontal slowdown. Actually the slower you get, the more Drag points up and increasing fractions do not slow down horizontally. However you are already quite slow once this gets important. The slower you are, the less error the approximation results.
• If you have drogue and normal parachute however I do calculate that inbetween only the drogue chute will slow down until other is safe to deploy, which is easy by calculating x(v) for each section.
• KSP Drag includes a mach dependent term, which is a parameter curve. Damn ugly to integrate, Approximation k(current_mach) = k(v_deploy_start) makes life easy.
• KSP Drag is dependent on atmosphere density. Damn ugly even to predict the altitude, since altitude affects drag which in turn affects point in time you would deploy.... I am simply using current atmospehere density.

Actually Physics in KSP are calculated 50 times per second or with 0.02s time steps. The last two errors are small since I update them every time step and adjust parachute opening.

The very final precision up to 1m can be gained with control surfaces while floating down on parachutes when you rotate lift from static deployed control surface towards target.

 

[CBase]

Since I just managed to tame the throttle control PID for final touchdown, I can now share a short video, around 2:45 you see the parachute timing in action. I just noticed that I did not push a bugfix on bodies g value, so if you want working code, look again

The following roll is actually just an effect that upside is always orientated towards target during parachute descend, which is mainly to fine tune landing as described above. But it has the nice benefit of getting the rocket vertical very fast using the lift of control surfaces to turn.

 

Edited April 28, 2020 by CBase
added info about fixed code push