Apr 24 and 25, 2001 Meeting Notes

 

In Attendance:

 

John Carmack

Russ Blink

Phil Eaton

Neil Milburn (24^th)

 

New supplies:

 

New AirPort base station to leave at Long Range.

Quite a few new fittings.

50’ serial extension cable

16 channel PC104 A/D board

 

On order:

 

Mil-spec aircraft electrical supplies

Pilot headsets for piloted VTVL

Extra burst discs

 

To get:

 

Spill container for peroxide at LRS

All stainless fittings for fill cart

Replace all our non-stainless fittings

Larger size hazmat suits for Phil

Energy absorbing foam

Stainless steel quick disconnects

90 degree male/female 1/8” NPT to offset the pressure gauge

 

 

Very interesting update this time.

 

On the 24^th, we finally got our drum of peroxide in at Rinchem, and brought four gallons of it back to LRS. We won’t have to worry about that again until we move to the high performance vehicle designs.

 

Rus and Phil got around to welded some brackets on the fill cart so we can finally tie things down a little better.

 

We planned on running Spider, but first we were going to test Juan Lozano’s 100lb thrust engine.

 

We still had the highest flowing plumbing from our last water test of two weeks ago on the test stand, which we expected to flow something around 65 pounds of thrust into the engine. The design point was 100 pounds, but out solenoids limit the flow too much right now.

 

As it turned out, we were fortunate that we decided to move the test stand completely on the other side of the wall for running the bigger engine.

 

As I was counting down to start the test run, a cloud of peroxide burst out of the test stand.

 

The 500 ml of peroxide had cooked off in the tank and blown the burst disk on the tank manifold.

 

We pulled everything apart, and found that some of our fittings on the fill cart had corroded internally, and some of that had probably been swept into the tank.

 

We had gotten out of the habit of flushing the fill cart plumbing with water after each session, so there had probably been a bit of peroxide chewing away in it for the last few weeks. Russ/Phil: we didn’t flush the fill cart tonight either, so you should probably flush it out tomorrow, and we need to make sure we do that every time now.

 

Another thing we found on closer examination was that some of the fittings that I thought were stainless steel turned out to be zinc-plated steel, which is not a good thing to have peroxide sit in.

 

We cleaned everything up and replaced some fittings, but it turned out that we didn’t have a compatible replacement blow off valve. I had ordered a few extras, but NOS changed the bottle plumbing recently, and the replacements I got were all “old style” and couldn’t be adapted with any of our hardware.

 

I drove over to Bob’s shop, and he liberated a new blow off valve from another NOS bottle for us, so we planned to try Spider again the next day.

 

On the 25^th, we were all extra cautious after the previous day’s incident. We ran the entire system twice with water, tightening up all the new plumbing. We used distilled water, to avoid any possible catalyst poisoning. Previously we had just used tap water for water tests, which may have contributed to the slow degradation in catalyst pack performance.

 

Russ and Phil were both in the hazmat suits, and we pressurized in stages, keeping an eye on the pressure gauge for signs of decompression.

 

We got it all loaded up, and prepared to test.

 

Flight Computer Code Changes

 

All the flight control parms are now tunable at the command line, so we can try out several different things if we don't bend the vehicle.

 

The flight control has "quit levels" in it, so if things are just not working, it should kill all the engines automatically.  I have them set right now at 15 degrees and 100 degrees / second, which will hopefully have it land upright.  I'm not setting the quit rate too low, because I am worried about transients during liftoff.

 

I spent some time experimenting with different control algorithms on the simulator.

 

I clamp the desired rate, instead of leaving it purely proportional to the delta angle.

 

I added a dead band around the desired rate, so it won't oscillate back and forth every other frame.  This does let it stay a degree or so off of the exact angle sometimes, but our integration drift probably swamps that anyway.

 

A significant change is that I now only do any active control on some fraction of the PWM frames, leaving the others as purely throttle based.  This has a few benefits:

 

It accounts for latency in the sensor path, because you are actuating, then waiting, then checking, rather than checking before your last actuation has been sensed.  This removes the increasing oscillations that I could get under certain degraded sensor arrangements on the simulator.

 

It will let us see in the log files a lot more clearly exactly how much rate we get with each adjustment.

 

If the adjustment kick is set higher than the PWM cycle, this has the effect of making the flight control effectively time division multiplex a binary attitude control on top of the lifting throttle.  This has the benefit that the rate change for an attitude adjustment should be much more deterministic.  When we just add and subtract duty cycle for attitude adjustment, we get noticeably different results based on the throttle level, because the thrust from PWM isn't linear.

 

The current settings are for a 30 hz PWM cycle with binary attitude adjustment once every three cycles, which matches the rated 10 hz bandwidth of the gyros.

 

 

Flight Test Results

 

As I feared, the initial liftoff often messed up the gyros. The first three attempts to smoothly lift off with light throttle caused the flight computer to abort just as it was rocking on the legs. All things considered, this is a Good Thing. Much better to stop on the ground, than lift off with gyros 45 degrees out of whack.

 

I decided to give it more throttle at liftoff, rather than trying to sneak up on it.

 

A very brief pulse gave a nice clean hop straight up and down. If it came off cleanly, the gyros didn’t get jostled too much.

 

I went for a longer flight next. It took off perfectly, and made a couple visible active attitude corrections, but it was rising fast, and it hit the chains as I was dropping throttle trying to bring it back down.

 

When it hit the chains, the rate passed the quit threshold and the flight computer killed all the engines. It dropped straight down from about twenty feet up. It landed completely square, and broke all four legs off at the mounting points. Two of the engines snapped off at the check valve.

 

The full long video is at:

 

media.armadilloaerospace.com/2001_04_27/FirstStraight.mpg

 

The interesting bit is at 50 seconds to 70 seconds in the mpeg, which is cut out at:

 

media.armadilloaerospace.com/2001_04_27/FirstStraightEditedShorter.mpg

 

 

The graphs of the two controlled axis are at:

 

media.armadilloaerospace.com/2001_04_27/FirstStraight.xls

 

I need to get some better graphing software than Excel, but I tried to arrange things to be legible.

 

Series 1 is the integrated angle, scaled by five to fit the other values. It stays within five degrees of zero until the tether is hit.

Series 2 is the angular rate, which responds as expected to the engines, then goes to hell when the tether is hit.

Series 3 is the positive engine (left / near) duty cycle. When the flight software wants to make the rate more positive, it will max this and kill series 4.

Series 4 is the negative engine (right / far) duty cycle (negated to put on the other side from 3).

 

You can see me throttling back the engines starting around sample 30, and the flight computer killing all the engines on sample 49 when the yanked tether took the second axis position past the 15 degree quit marker.

 

From the data, it looks like the tether was probably yanked on frame 45, because the rates both jumped, but not high enough to trigger the rate quit level. At this point the gyros have probably lost their mind, as seen by the second axis integration going way off into la-la land, even though the lander came straight down.

 

 

 

We broke some things, but we still consider this to be a big success!

 

The engines worked great, noticeably better than our previous runs. We don’t know yet if that is the effect of using distilled water for the water flushes, or due to the addition of the unplated foam discs at the top of the pack spreading things more evenly before reactions begin.

 

We got great data, and everything performed as designed.

 

The full loop of sensors, control logic, and actuation did exactly what it was supposed to do. Only for 1.5 seconds, true, but a big change from aggressively tipping over in some of our earlier tests.

 

The predicted issue with bad rates on initial liftoff was correct. We are going to add extra mounting isolation to the gyros, and our new landing design should avoid some of the snap inherent in the spring steel legs sitting on concrete.

 

Unfortunately, while we were debugging the gyro board, we left the accelerometer testing off, so we didn’t get G data. From our last test, we were somewhat concerned about having enough thrust to lift off, but we definitely had plenty of acceleration today.

 

Even the crash landing was pretty good – this is the first time we didn’t drop it on the side.

 

The computer had locked during the crash, so I expected something to be broken inside the electronics box, but it just turned out that the parallel port connector had popped off of the driver board, and probably momentarily bridged something on the motherboard. Power cycling it brought it right back up. Phil is going to be making a new solid state relay driver board that will have a full eight outputs, so we will make sure that we can securely screw the connection down without any adapters (Phil: put a MALE DB25 on the new driver board, on the edge opposite the PC104 connector).

 

Rather than rebuilding the legs on the current design, we are going to change over to the design we had been discussing for the manned vehicle.

 

The data logs show plenty of control authority with the current engine positions, so we can move them in enough to give them full protection.

 

The legs are going to be removed, and the platform is going to be flipped upside down. Instead of legs, there will be a thick block of foam underneath a plate covering most of the base. That will avoid the stuck-leg-spring effect on liftoff, making life easier on the gyros.

 

We are still debating whether the electronics box goes on top of, or underneath the tank, and the details of the engine mounting.

 

The engines nozzles are going to be less than a foot off the ground, so there will be more peroxide backspray, but we should protect the engines and plumbing a lot better, and have smoother liftoffs and landings.

 

 

I am going to make some software changes to give faster reaction to throttle changes in the future.

 

The most significant issue is that the AirPort base station seems to have some 10hz scheduling issue when relaying packets from one wireless card to another. It doesn’t happen when going from wireless to wired, or wired to wireless, but if one wireless node sends thirty packets a second to another wireless node, the packets will arrive in bursts of three every 100 msec, rather than evenly spaced. That will go away if I move to AdHoc network mode, but I had avoided that because it complicates moving the computers in and out of my normal development network.

 

I can allow the arrival of a pilot packet to modify the in-progress pulse width modulation, instead of waiting for the next one to start. That is good for up to 33 msec in the worst case.

 

On the laptop side, I can go to driving the packets based on joystick change events, rather than a fixed rate. That is up to 50 msec better than a fixed 20 hz update rate. I will need timers to force extra packets when there isn’t movement, so the flight computer doesn’t think it lost the connection.

 

The real answer is to move towards computer controlled hovering based on the accelerometers. We will probably do the next test without that major change, but if everything else is worked out, I will give that a try.

 

The simulator shows that we should be able to fly it reasonably well with a manual throttle and low latency, but we need to be able to lift off slower, or have much longer tethers. I might modify the simulator to add tethers, some latency, and sticky liftoff to practice a bit.

 

 

Bob’s busy getting ready for a car show, so we probably won’t get the lander put back together next week, so we will probably do engine testing.

 

Russ: you might want to make a bigger nozzle or two for the test motor, and you should tap a 1/8” NPT port in Juan’s chamber.

Phil: we should get another nitrogen tank, and pick up all the rest of our silver plated foam

Neil: get us a 1000psi nitrogen regulator, and the hard line for isolating the pressure transducer.

 

 

 

Primary research problems at the moment:

Attitude Sensing

 

I corrected the cross-axis coupling in software.  The roll axis caused quite large coupling (about 1 degree in 8) to the others, but the other directions were only about a quarter of that.

The gyros have enough G sensitivity that if you turn it sideways, it will drift at a noticeable rate.  That shouldn’t be a problem for us, because if we are rotated 90 degrees to gravity, things are already over.  It does seem that constant upward acceleration will cause a fair amount of drift, but we should be able to characterize it.

The integration accuracy is still not great.  Tilting the board 90 degrees and back will usually result in five degrees of error or so, and if you just wiggle the board around in your hands for a ten seconds or so, you can get the numbers arbitrarily screwed up.

Slower tilting causes less error, so it might be due to a non-linearity in the rate mapping.  If I had a slow turntable with an accurate tachometer, I could characterize the entire range, which might help somewhat.

The gyros are only rated as having 10hz bandwidth, so rapid wiggling may include significant transients just not measured by the gyros.

We are currently sampling at 60hz, which should be sufficiently above the Nyquist limit of the sensor that linearly integrating  isn’t a problem, but I could try doing better sample reconstruction on the data before integration.  Even better would be to have the microcontroller perform the integration at the 240hz max sample rate of the ASIC.

The worst aspect of the gyros right now is that when they hit their G limit, they just go nuts.  Lifting one side of the gyro board a half inch off the table and letting it drop will cause the rate values to just go all over the place for a second or so, and wind up off in space.  Unfortunately, it doesn’t necessarily peg the rate value to a maximum during that time, so you aren’t even sure it has happened.

It is possible that airborne hovering is going to be a “nice” environment for the gyros, because there shouldn’t be high frequency, large amplitude rate changes.  Still, I am quite concerned about attitude sensing.
 
I would really prefer an absolute, rather than rate based, attitude sensing solution, like some form of radio direction finding, but Crossbow does sell a three axis fiber optic rate gyro sensor with 100hz bandwidth (IMU-600) for $8500. 


Engine Valves

We struck out with the custom billet solenoids, they don’t go any larger than the standard NOS valves.

There are two NOS solenoids that are larger than the ones we have.  The next step up is still ¼ in and 1/8 out, but has a bottom discharge and is rated at 12% more flow.  The final step is the “super big shot”, which has a ¼ out and is rated for 50% more flow, but draws 30 amps (!!!) of power.  That’s beyond the rated level of our solid state relays.

Omega has some high flow ¼ NPT solenoids, but they require 24 VDC to operate.

Before we rush into anything else, we should do fully instrumented tests with our current “high flow” plumbing arrangement on one of the big engines and see just how much thrust we can make with it.

My current understanding of the situation is that we can continue to open up the nozzle throat, which will lower the chamber pressure, allowing more delta-P through the valves, and getting more flow into the engine.  This reduces Isp because of the lower expansion ratio, but increases thrust.

Do we want to put a pressure tap in Juan’s engine, Russ’s big engine, or just make a new one from scratch?

If we get a better nitrogen regulator, we can increase the tank pressure quite a bit with our current equipment.  All of our current plumbing is good for > 1000 psi.  However, that would change the tank requirements for the manned vehicle a lot.  There are a lot of good commercial composite tanks that would work fine at 400psi, but 1000psi cuts down the field.

We need at least 75 pounds of thrust out of each engine at final blowdown for the manned vehicle, which is probably 150 pounds of thrust at initial tank pressurization.

I think we can get that by ganging two of the current valves together and reducing the chamber pressure a bit, but it will be right at the edge.

Pulse width modulation will work quite a bit better with two valves on each engine, because the valves can be run with complementary states so there will be constant flow above 50% throttle.  That should allow us to use a lower frequency, which will be easier on the valves and probably make the gyros happier as well.

We will need to get the new SSR board built with the full eight outputs to independently control four double-valved engines.  We might be able to run them simultaneously with our current setup, but it would be over the rated current limit.

Longer term, we are definitely going to have to investigate higher flow proportioning valves.

Omega has some controllable proportioning valves with very high flow rates, but they are all >$1000, look heavy, and require pneumatic air control.  They also have a stepper motor controlled proportioning valve, but the pressure rating isn’t high enough.  It might be possible to mount the control system on a different valve.

If we don’t need powered vertical landing, we could move to a single big, non-throttled central engine, and just use four engines with our current solenoid plumbing as binary attitude control thrusters.

Another possibility would be to investigate proportioning the catalyzed steam and oxygen, instead of the peroxide.  Having a single central catalyst pack would be a nice benefit.  A stepper motor controlled moving plug nozzle shouldn’t be too hard to try with peroxide, and altitude compensation would be a bonus.  You probably couldn’t do real deep throttling like that, but it would be interesting to see how it worked out.