Apr 24 and 25, 2001 Meeting Notes
Neil Milburn (24th)
New AirPort base station to leave at Long Range.
Quite a few new fittings.
50 serial extension cable
16 channel PC104 A/D board
Mil-spec aircraft electrical supplies
Pilot headsets for piloted VTVL
Extra burst discs
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 24th, we finally got our drum of peroxide
in at Rinchem, and brought four gallons of it back to LRS. We wont 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 Lozanos 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
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 didnt 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 didnt 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 couldnt be adapted with any of our hardware.
I drove over to Bobs shop, and he liberated a new blow off
valve from another NOS bottle for us, so we planned to try Spider again the
On the 25th, we were all extra cautious after the
previous days 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
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
didnt 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:
The interesting bit is at 50 seconds to 70 seconds in the
mpeg, which is cut out at:
The graphs of the two controlled axis are at:
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
The engines worked great, noticeably better than our
previous runs. We dont 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 didnt get G data. From our last test, we were somewhat
concerned about having enough thrust to lift off, but we definitely had plenty of
Even the crash landing was pretty good this is the first
time we didnt 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
The data logs show plenty of control authority with the
current engine positions, so we can move them in enough to give them full
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 doesnt
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 isnt movement, so the flight computer doesnt think it lost the
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.
Bobs busy getting ready for a car show, so we probably
wont get the lander put back together next week, so we will probably do engine
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 Juans 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.
research problems at the moment:
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 shouldnt 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 isnt 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
doesnt necessarily peg the rate value to a maximum during that time, so you
arent even sure it has happened.
It is possible that airborne hovering is going to be a nice environment for
the gyros, because there shouldnt 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
We struck out with the custom billet solenoids, they dont 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.
Thats 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 Juans engine, Russs 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
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
Longer term, we are definitely going to have to investigate higher flow
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 isnt high enough. It might be possible to mount the control
system on a different valve.
If we dont 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 shouldnt be too hard to try with peroxide, and altitude compensation
would be a bonus. You probably couldnt do real deep throttling like
that, but it would be interesting to see how it worked out.