Feeds:
Posts

## Hovering Vehicle Tilt Control, Part Zero

Someone was asking on ARocket about where to start with building a differentially throttled hovering vehicle. Lots of advice were given by various people. I’ll show some stuff I quickly sketched back in 2007 with Simulink. It’s such an easy to use and awesome software (especially compared to a recent short battling with LabView), that whipping up any control system or any process or system models are really quick jobs.

This is just some really trivial basics, it doesn’t take into account nearly enough things to produce a real hovering vehicle. I guess it’s just a way to show how things could be started.

So, here’s a pic of a simple one-dimensional rotational feedback system. Just tested some feedback coefficient values for the PD controller.

1) You can see the placeholder “guidance algorithm” output at the top left “scope” graph. This is the reference or target value of the angle where we want the vehicle to be. At the start it’s giving a desired angle of zero radians, then from 4 seconds onwards it suddenly wants 0.5 radians, then again zero after 6 seconds. This could be holding a tilt for a while for getting up some lateral velocity for a transverse move.

2)  Below that, you see Theta, the angle that the vehicle actually had during the simulation. It follows the desired angle quite nicely. Below Theta, there’s omega, the angular velocity.

3) The tilting is done by throttling the two thrusters. At top center and top right you can see the values of the throttles. Since this thing only concerns tilt and not stationary hovering, the throttles are at zero when the vehicle is at the right attitude (reference=Theta) and there’s no angular velocity. When the refence is moved, at 4 seconds, throttle 1 shoots up for a while and the vehicle starts tilting. At around 4.8 seconds the other thruster, throttle 2 shoots up to stop the rotation, since the vehicle is nearing the desired angle.

You can see from the block diagram how the error value, E = theta – reference is calculated. And also omega is used. From these the throttle values are calculated, simply by Throttle1 = E*Kp1 + omega*Kd1 and so on. By fiddling with the Kp and Kd values, called gains, one can tune the system. The values currently are just some I quickly tried back then.  This Simulink model actually has a bug, a sign error. The error signal’s difference calculation is backwards, hence Kp1 and Kd1 are negative. It should be the other way around.

You can tune the model. Basically, raising the proportional values makes the system faster (reach desired values quicker) but gives overshooting and can make the system oscillate unstably. Higher derivative gains remove the tendency to oscillate, but the system becomes more sensitive to noise (noise can after all have large derivatives). If the vehicle had problems of always staying some amount off from the final required attitude value, an error integrator could be added that would fine tune the vehicle a little (making it a PID controller). This is probably not needed here though – the guidance system could notice if the vehicle travels somewhere it doesn’t want it to go.

The MDL file for the above is available here.

This is just a very quick first brush analysis, there are much much more things to take into account. The other tilt axis, roll, the need  to actually stay airborne (altitude or vertical velocity feedback loop) that ties into the throttle values too. One could abstract this tilt in one axis to a single control block, and produce another similar block for altitude holding, then couple these blocks into a whole system of altitude and tilt holding (by mixing the throttle values). This should avoid clutter and enable one to isolate problems.

Also, one should add some noise to the sensed angle vs real angle as gyro noise seems to be a real issue for VTVL vehicles. One wouldn’t want to tune a PD controller’s values in a noiseless simulator and then find out it gets wildly out of control in the real world. Even when not simulating noise, one can be quite conservative with the tuning values, and that helps too. The throttles probably would be another source of errors as well, if one used ball valves like here. One could also use pulse width modulated solenoids (John Carmack is fond of those for quick work) and those should be modeled. Digital valves (for liquids) have also improved lately, and hydraulics uses are emerging.

I’ve only done real world PID stuff on lab experiments. But it’s still very cool to see it work. It can balance a ball on an unsteady position on a moving cart, which humans have trouble with using a joystick, and the math in the controller is not complex since linear approximations can be used for that problem.

## Xombie NOW

Live stream just went up at http://qik.com/video/312581

they should be flying at 45 past whatever hour it is now in your time zone. Now on the pad loading propellants and helium.

EDIT:

And they did it! Congratulations! Also great accuracy.

The live cellphone video of the second flight was shot from quite close: http://qik.com/video/3126566

## Masten

Made huge strides in the last few days. A half-L1 done. They might be able to compete with Armadillo on L2, though I’m somewhat skeptical since they’re only going to assemble the new L2 vehicle soon.

Suddenly looks like there are two viable big VTVL sounding rocket companies!

## X-Prize cup 2007, a test for reusable rocketry

Well, as has been noted in the newspace circles, Armadillo Aerospace failed to win the lunar lander challenge even after coming very close in 2006 already, and being even closer this time. Their report text is here and videos and pictures here (highly recommended). Other teams failed even to participate.

Everybody was cheering for Armadillo. The dream carries on. More testing, more steady state solutions. One part of Armadillo’s problems has been that they have to drive quite a distance to their test site, which limits testing a lot. Teams like Masten Space Systems have it easier in Mojave, but they had some tank supplier problems as well as some things with the control algorithms, and haven’t done any info updates for over a month since they started trying to do hover tests. (Wink, wink. 🙂 )

Acuity and Paragon were teams that didn’t give much info, so it was hard to judge where they were, the same applied to BonNova. Speedup gave some info as well as Micro-Space. Unreasonable Rocket‘s Paul Breed was very informative in his blog and I laud his efforts.

One thing which some parallels can be drawn to is the DARPA Grand Challenge, which promised prizes to teams constructing an autonomous vehicle that can drive from Los Angeles to Las Vegas via a marked desert route. The first year was a failure, with most of the teams failing to even qualify for start. (There was a short obstacle course test.) But the next year, the prize was won and many vehicles finished. It seems that either the Lunar Lander Challenge is harder or then people are not willing to put similar broad resources behind it. It may be both. In 2007 the DARPA Grand Challenge has moved to a new urban setting.

There also exists a different comparison. The X-Prize, which was won by Scaled Composites in 2004. Other teams didn’t come even close or even make that much progress and almost all disappeared quickly after the victory. Scaled had a big money backer, Paul Allen, and worked long and hard to do it. A very different picture from the Grand Challenge contest, as well as a different style of doing it. One worked with yearly races with increasing prize money, the other was an absolute deadline. And of course the former was probably much easier than the latter.

There are many ways Armadillo’s failures can be analyzed. You can look at subsystems: this year their problem was the engine (you can read the details in their report mentioned above). Last year it was the landing gear as well as a badly surveyed track.

But the engine problems had some story behind them: either the air was more humid or the altitude was higher than on their own test site. Or the ethanol composition was different which caused clogging of the injector, which caused grief later. Or they hadn’t run back to back flights so close after each other with the engine before. This all speaks of how the small details are important. Jon Goff (who inhabits my blogroll) has said how they at Masten Space had the first engine hard start problems only on the 30th 300th test run. You need lots of testing to make designs reliable (or then somebody invents a foolproof way to do a start). Some people have also proposed that since the development of new reliable rocket hardware takes significant time and effort, it would be easier to buy ready made engines from subcontractors. But it seems this has not caught on, the lunar lander challenge outfits are so poor that they can’t afford this and have to develop their own stuff. Also you lose intellectual capital and technological lead distance by selling your engine design. And lastly, people saw what happened to Masten when they subcontracted their control algorithm (or at least assume until they do a development update). It’s a bit harder to troubleshoot when you didn’t make it yourself. Although the decision still might have sped up development considerably.

It’s an interesting juncture. If there is no more than one LLC competitor next year or even if there are but the prize still isn’t won, would a rethought approach to the problem be better? On the other hand, with a tiny bit more luck, Armadillo could have taken the money home already in 2006, and people would have made other far reaching conclusions about these things. It’s not wise to try to make up your mind from too little data and proclaim somethind far reaching. So I’ll make a prediction, like last year: next year Armadillo will finish the challenge and there will be other competitors too.

Of course, if someone wanted to enter the suborbital business, they could hire me as a consultant and I’d say which parts to buy from where to combine into a perfect vehicle. 😉

Edit 2007/11/5 : Corrected Masten’s 30 test runs before the hard start to 300, per Jon Goff’s comments. 🙂  He also says my guesses about their control system are not entirely right.

## 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 $t_{delay} v_{ter}=y_m$ 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 $y_m=0.5 a t_m^2$. (We used the trick of counting backwards in time from the underground target.) We can solve the imaginary underground time duration, $t_m=sqrt(2 y_m/a)$. And the speed at ground level thus is $v_m = t_m a = sqrt(2 y_m a) = sqrt (2 a v_{ter} t_{delay})$

### 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.

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. $t_d = v_{touch} / sqrt (2 a v_{ter})$. 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.

### (more…)

Deceleration from terminal velocity to hover usually requires about 5-10% of total landed mass as propellants. The amount is directly proportional to the vehicle’s terminal velocity. Also, the higher acceleration, the better. The powered landing penalty fraction is $N_{penalty}=\frac{2g}{3a}$, so landing at 2 gee acceleration (3 gee felt) gives a penalty of 0.3. The required delta vee is $\Delta v = v_{ter} (1+N_{penalty} )$ where v_ter is terminal velocity. And the required impulse $I=m \Delta v$ and propellant mass $m_{prop}=I/v_{ex}$.