Powered landing, practical considerations (1-dim)

There was some excellent commentary in the last post, and that has partly been one inspiration in writing this post.

In the last part, the absolute minimum efforts by the launch vehicle making a vertical landing were determined. On top of these, there are lots of slightly more practical ones. This is still a one-dimensional vertical analysis.

Effects of a Time Delay

Let us see what a delay of t_delay before starting the main deceleration would do to a landing vehicle. The craft would travel extra distance before starting deceleration. That would mean that the actual reaching of zero speed would be y_m behind the original deceleration target. If we assume the original target was on ground level, then the new target would be underground. The difference between the targets is . (We used the trick of counting backwards in time from the underground target.) We can solve the imaginary underground time duration, . And the speed at ground level thus is

Example Vehicle

Our example vehicle, with v_ter=100 m/s and a=20 m/s^2 would stop in 5 seconds and 250 meters normally. If it traveled without any margins and would miss the engine ignition by one second (t_d=1 s) and 100 meters (y_m=100 m), it would impact the ground at over 60 m/s (130 mph, 220 km/h), or roughly two thirds of its original terminal velocity of 100 m/s. That would destroy it completely.

If we used a gentler and more lossy 10 m/s^2 deceleration (and started the engines higher accordingly, but still had the unfortunate one second delay), then the impact speed would be about 40 m/s. Still far too much.

Even a realistic 0.1 s of delay would cause a 20 to 14 m/s impact, depending on planned acceleration. Complete crash, remotely possibly survivable.

Musings about Results

The results might look unintuitive. That’s because in a constant deceleration, the most time is spent on the end, low speed distances, while most distance is covered with high speeds, early on. So if the deceleration is cut short even by a short percentage in distance, the time is cut short by a much bigger percentage, so the vehicle does not have enogugh time to brake much. Running out of a little distance you run out of a lot of time. This in total makes the vertical landing a very time sensitive problem!

It is also the reason why in the classical driving school example, even if you lock-brake and the car overshoots the pedestrian crossing by just a few meters, it was still going quite fast when you crossed it. The car’s speed doesn’t change much per meter when you start braking, but in the end half it changes a lot because it’s going slower and there are many more seconds per meter and thus the force has more time to effect. The drag is not dependent on velocity so in a sense it functions like a rocket engine. Accelerating with the car’s engine is the opposite as it generates constant power, not constant acceleration.

So, if we anyway design the vehicle to survive some vertical touchdown speed v_touch , then we can calculate the margin for the fast deceleration directly to pad in seconds. . With our example vehicle it could be 4 m/s, equal to a drop from 0.8 meters height. Then the acceptable time delay would be 0.063 s or 63 milliseconds. That’s probably too small of a margin.

More Realistic Approaches

So, in reality, one can not have a direct high deceleration to pad. One could have multiple other approaches and ways to think about it. These are the most obvious to me:

1. Put the the deceleration aim target (hover) some distance above the ground. Layne Cook told that was an approach the DC-X used.
2. Stop the high deceleration at some determined velocity and switch to a low deceleration. For example at 10 m/s.
3. Use some more elaborate forecast of the vehicle position and throttle accordingly to always have a plan to reach very slow speed at touchdown. I think Armadillo is using something like this approach.

These are handled below.

Method 1, hover target in air

We can have a time robustness parameter t_delay, and we try to end up in the air hovering at so we don’t crash if the delay happens. Then we descend from there.

Example: Our example vehicle has this distance at terminal velocity 100 m/s times delay robustness 0.1 s, which results to 10 meters. 130 m/s delta vee expended to reach that position, hovering at 10 meters height. But how do we get down from there? We have to throttle down and accelerate again, losing valuable time there and getting gravity losses the longer it takes (10 m/s every second). Why do we have to stop to hover, we could start the low deceleration landing from when we still have some vertical speed. This is the next method.

Method 2, acceleration rate switch

First we get rid of the majority of our terminal velocity efficiently with the high acceleration part, then when at low enough velocity (and high enough height!) we start a more careful “second leg” towards the ground. We can call the switch velocity v_swi. It’s short of the hover target by a time difference of t_short. where hi means the high acceleration part. The distance from switch to ground is now . On the other hand, from the low acceleration part, and combining them, and

The time for the second leg would be and the gravity losses would be

Example vehicle again:

Switch velocity 10 m/s. Then the high 2 gee acceleration is cut short by 0.5 s (save about 15 m/s of delta vee), and the switch distance is thus 10+2.5 meters from the ground. The low acceleration would be 4 m/s^2 and would take 2.5 seconds. Delta vee during the low acceleration phase would be roughly about 35 m/s. When taking the 130 m/s from the previous analysis post, minus 15 and plus 35 would result in 150 m/s in total delta vee. This would be 60 kg of propellants for a 1000 kg vehicle with ISP 250 s. Air drag doesn’t affect the low acceleration part since the velocity is so low, below 10 m/s and drag is one hundreth of the terminal velocity.

One version of this method would settle for a constant touchdown velocity, say, half the maximum touchdown velocity v_touch. When it is reached, don’t decelerate anymore but approach the landing with that. Starting from 12.5 meters at 10 m/s it would take 2 s to reach the 2 m/s at low acceleration, and the vehicle would travel 12 meters. So from 0.5 meters height onwards it could travel at a constant 2 m/s. Seems like a quite nice solution. We also replace the last 0.5 s at 4 m/s^2 resulting in 7 m/s delta vee with 0.25 s at constant velocity meaning 2.5 m/s delta vee, a tiny saving. 🙂

There are probably many reasons for choosing a particular acceleration rate switch target when designing: acceleration, velocity and/or height. Each one of them is a safety critical item. If the calculated resulting acceleration for the rest of the landing is too high, there is no margin for the craft to brake if it finds out it’s coming too fast too late. What if the data is something that was not anticipated? This leads us to the next method.

Method 3, dynamically updated criteria

I think I’ve seen John Carmack write something about this in the past Armadillo Aerospace updates when they were still flying peroxide rockets with jet vanes. When autolanding, you could have your current altitude, vertical velocity and acceleration as inputs and use all kinds of fudge factors (in control theory, gains) to deduce some desired throttle positions from them, and the rest would then handle by positive feedback when the vehicle would move down and the inputs would change. But it didn’t seem to actually work out that well, and he went for actually forecasting the vehicle position some time in the future (I think if the throttle is kept on a constant setting), and doing the desired throttle positions from there. That way you can always do the simple calculation: do you have enough time to null your velocity before you reach the ground?

Let us disregard air drag for now (we did it in the low speed analysis in the previous methods too). Assuming we have T/W > 1, the trajectory is The deepest point in the trajectory is when vertical velocity is zero. That means and the original becomes and we solve . Frighteningly simple. The desired rocket thrust would be .

One note though, this doesn’t minimize gravity losses but uses constant acceleration starting immediately from the calculation point. It is just a simplistic autoland mode, but updates constantly from the sensor input.

The y_0 current altitude could have a coefficient like 0.95 to add a 5% constant safety marginal. With our example vehicle, at the 250 meter height at high speed acceleration start it would be 12.5 meters. But the target would get lower as the vehicle neared ground and also sensor input improved (If we use laser or radar altimeters.). It would be just 5 cm at 10 m. On the other hand, if we fly on just GPS and inertial navigation, the vehicle data quality probably depends somewhat on speed but is generally the same at all altitudes (below tens of kilometers). You could also use a conservative high estimate of the downward speed at the same time, using a 1.05 coefficient or design the filter in some clever way. So we in effect are again linked to the first method! 🙂

All these approaches depend a lot on the hardware: what are the position, velocity and acceleration errors (noise, bias, delay) in the sensors, how accurately is the level of the ground known (if GPS is used) and how precisely and fast can the rocket be throttled or it’s mass be known, are there wind gusts etc… In practice, it’s not possible to find out all this beforehand, but flight tests are needed to tweak it all.

Further note

I’m not done on posting about vertical landing! I’ve got some old Matlab/Simulink code lying around (not here) that I’ll run later and compare to the analytical methods to verify how much it’s needed. You can get pretty far with just analytical methods, it’s been a surprise for me. I also want to do some analysis of the terminal velocity decisions later.

If I made any mistakes in the analysis, please point out in the comments! Thanks.