September 10, 17, and 21, 2002 Meeting Notes
I attended the Space
Frontier Foundation's strategic retreat on the 15th, so we missed a work
session. Russ finished the internal
chamber for the 1K biprop while I was away, so we are getting close to firing that.
Hypergolic Fuels
We did some drop test experiments with miscible hypergolic
fuels. We werent able to dissolve
enough manganese acetate in isopropal alcohol to make drops hypergolic, but we
found epoxy hardener to be an effective promoter for the process, allowing much
larger quantities to dissolve in the furfual alcohol.
We were holding out some hope that we might be able to make
a hypergolic engine with 70% commercial peroxide, obviating the need to deal
with the hassles of acquiring 90% peroxide, but we couldnt make it work. This video has drop tests with 70%, 80%, and
90% peroxide:
http://media.armadilloaerospace.com/2002_09_21/hypergolic.mpg
There are still some potential advantages to a hypergolic
engine, but I dont think they outweigh the disadvantages, so this line of
development is being closed off.
Advatnages:
Shorter and lighter engines due to no catalyst pack, injector
gap, and injector venturi.
Potentially less engine variability without cat packs.
Cheaper engines without silver screens.
Less things to fabricate for a new engine size.
Mildly higher chamber pressure for a given tank pressure,
due to lack of catalyst pack pressure drop on the peroxide side (biprop chamber
pressures are quite a bit higher than monoprop chamber pressures, so the pack
doesnt hurt as much as monoprop tests would indicate).
Ability to use 98% peroxide for higher performance, which we
cant do with silver based catalysts.
Disadvantages:
It is much easier to explode an engine. This is the
primary one.
A preparation step for the fuel is required, and if it
doesn't go completely right, we can get detonable liquids when we try to fire
an engine. Just imagine a 1000 lb thrust engine that was accidentally
loaded with an alcohol without the catalyst properly dissolved -- we would have
50 pounds of sensitive high explosive splashing all over the place before we
could close the valves. This might even be a bigger deal than the engine
explosions.
No ability to operate in monoprop mode, so the mixture ratio
control to burnout at depletion becomes more critical. I was expecting
all of our big kerosene engines to be loaded such that the kerosene goes away slightly
before the peroxide, so the engine finishes the burn in monoprop mode.
With large engines, even a slight miss on the mixture ratio, which we are
guaranteed to have, would result in a
non-trivial quantity of liquid propellant sloshing out the engine at the end of
the run.
Dissolved metal salts are probably not very good for our
plumbing and valves.
Injector design will be a lot more finicky without the high
speed gas component.
The top engine closure/injector may be more difficult to
cool.
Somewhat more expensive fuel (not much).
Somewhat lower Isp for a given combination, due to the
non-combustible dissolved catalysts.
5 Lander Hops
The lander now has a forward roll cage, extended pegs to
protect the attitude engines in case of a tip-over, and the rear plumbing
manifold has been mounted on a new bracket inside the rear support bar to
protect it. All hops are done with the
computer controlling the throttle based on the laser altimeter. I just click the joystick hat once to have
it lift off and attempt to hold a given altitude, so all I have to do is make
joystick trim adjustments to keep the vehicle in the position I want.
http://media.armadilloaerospace.com/2002_09_21/fiveHops.mpg
Hop 1 (sep 17):
http://media.armadilloaerospace.com/2002_09_21/hop1.gif
The altimeter just stopped outputting samples while the
vehicle was in the air. Fortunately,
the last altimeter derived velocity was positive, so this caused the throttle
to continue falling, rather than continue climbing. We are prepared to handle a runaway throttle condition with the
shock absorbing tether arrangement and the joystick throttle cancel of the
auto-throttle mode, but that would likely result in a fairly hard (but still
straight) landing.
I changed the altimeter code so that it continues to try
resetting the altimeter if samples stop arriving, instead of only resetting it
at startup. This works well, and also bypasses
a minor operational issue we previously had, where the altimeter needed to be
powered on before the flight control software was started.
We added a little more counterweight at the front to keep it
from tipping as much on liftoff.
.
Hop 2:
http://media.armadilloaerospace.com/2002_09_21/hop2.gif
The hover bobbing had enough amplitude to actually hit the
ground in this flight, so for future flights I increased the desired altitude
for the first up-click from 0.5 meters to 0.6 meters.
The altimeter had quite a few malformed serial strings
during flight, which caused glitches in the altitude and derived velocity. Most of them get rejected because they dont
look like the expected numeric values, but sometimes a corrupted bit still
makes a string look reasonable. We had
seen these before, but I had never been able to reproduce them at home. We finally determined that the pistol grip
handle (this laser rangefinder is intended for manual surveying) that the power
and serial lines go through was not a very reliable connection at all. Phil could wiggle the handle and cause bad
serial data and power interrupts. On
Sunday, Russ took the altimeter apart and soldered our cable directly to the
boards, removing the detachable handle completely. This seems to have completely solved the occasional mangled
serial packet, and we also didnt experience any altimeter shutdowns.
I added code to the flight computer to automatically start
an auto-throttle descent after a configurable amount of time, or in the event
of a telemetry failure. This is a
significant safety improvement for us.
You no longer have to try to track the time you have been flying, you
just work the joystick, and it will automatically descend a certain amount of
time after the first climb command.
Looking at the telemetry, the main ball valve motion is a
lot slower than it should be. The valve
is rated at 0.8 seconds to full open, but in the telemetry it is taking almost
a full second to get to 50%. We
attribute much of this to the voltage drop on the battery when two of the
attitude solenoids are open, which draws 17.5 amps of current. We swapped batteries around so we could put
a much larger one on the actuator bus, which did help out a fair amount.
Hop 3: (sep 21)
http://media.armadilloaerospace.com/2002_09_21/hop3.gif
The remaining hops are with ballast to simulate the full
weight of a pilot two sand bags and a punching bag. The total dry vehicle weight is 515 pounds with ballast. We are getting low on peroxide, so we have
decided to stick with five gallon flights for the time being, which only gives
us a six second flight with the ballast.
Once we resolve our supply issue, we can load it up for 15 second piloted
flights, or 20 second empty flights.
We noticed an interesting thing: this flight was taking place in bright sunlight, and the
altimeter signal was noticeably noisier, with an occasional flashing invalid
on the front panel. We had seen the
altimeter signal being rougher on some days than others, and since this
behavior went away after the sun set for Hop 5, I think we understand this
issue now.
Six seconds of hover goes by pretty quickly, but the timed
auto-land worked perfectly. This is a
very, very nice improvement for flight testing. When manually throttling the vehicle you cant track time well,
and you have to plan on setting it down very early, otherwise you may be on the
wrong side of a manual oscillation control when the propellant runs out.
Hop 4:
http://media.armadilloaerospace.com/2002_09_21/hop4.gif
I gave it another click up after it got in the air, so it
gained some more altitude.
Everything worked perfectly, as with hop 3.
Hop 5:
http://media.armadilloaerospace.com/2002_09_21/hop5.gif
We had been balancing with a person before this flight, so
the counterweights werent correct for the ballast again, so there was a bit of
a tip on liftoff.
Everything was nominal until touchdown, at which point we
lost the computer for some reason. It
was an intermittent glitch, because the system did not reset, it just hung. Telemetry cut off before it registered the
impact acceleration, so it was almost certainly an impact event.
The computer powered back on fine, and we could not make it
misbehave again by wiggling anything inside, or dropping the box repeatedly. We are making a few speculative reliability
improvements, which may or may not correct the problem:
The computer PCB is being mounted on a separate plate, which
will be isolation mounted inside the box.
We cant isolate the entire electronics box, because that would wreck
our inertial measurements.
We are running +5v and gnd to the computer over the PC104
bus pins as well as both pins on the main power connector, so if there is an intermittent
glitch on one of them, it shouldnt matter.
The main battery leads are going to go straight to the power
supply board, instead of to the unregulated 12V distribution strip, which then
went to the power supply board.
I am going to investigate three improvements to the flight
control logic:
I will add some code to force a throttle down if the
altimeter samples ever stop arriving, so if the altimeter does completely crap
out and not come back, the vehicle will just drop to the ground, with the
attitude engines still firing. It wont
be a soft landing, but it will be better than gaining any more altitude.
The hovering has a bob of about +/- 0.4 meters, which I
would like to reduce. This is
proportional to total system latency of the sensors and actuators. I have to filter quite a few altimeter
samples to get an accurate climb velocity.
I may wind up buying another unit that has 4x the sampling rate, but now
that we think we have the rougher sampling tracked to direct sunlight, I may be
able to shrink my sampling buffer a bit if we just fly it in the evening. The ball valve still isnt opening as fast
as it should, we should perform some more tests, and possibly swap the ball
valve if another one proves noticeably faster.
I think I can reduce the bounce on set down significantly by
having the computer go into a forced throttle to zero when it detects ground
impact with a desired altitude of zero, which looks like a 3G impact. As it is right now, the rebound makes it
think it is falling too fast, so it throttles back up, which makes the bounce a
lot higher.