March 15, 2001 meeting notes:

 

In attendance:

 

John Carmack

Phil Eaton

Russ Blink

Neil Milburn

Bob Norwood

 

New supplies

 

Precision hydrometer for measuring peroxide density

Polyethelene hand pump for peroxide drum

50’ more water hose and coupler

100’ extension cord

Power strips

Large NOS solenoid for 150 lb motor tests.

30’ of -6 SpeedFlex Teflon hose

 

The electronics box is now in full working order:

 

media.armadilloaerospace.com/misc/ElectronicsBox.htm

 

Although we have many improvements to make, this basic design for power, sensing, actuation, and telemetry should serve us for the next couple vehicles.

 

The lander was slightly modified to add pins for the legs again. They had been removed in the last upgrade that tied the legs together, but it turned out that when landing on one leg, it could bend it enough to let them fall off. Legs falling off is Bad, so they are pinned again.

 

media.armadilloaerospace.com/2001_03_15/LanderWithBox.jpg

media.armadilloaerospace.com/2001_03_15/MountedBox.jpg

 

We were testing active guidance on the full platform today. All components that are needed to perform 30 second, untethered, remote piloted flights are now present. We just need to make them work right. In theory, we were hoping for a two second hover with a small load of peroxide tonight. We didn’t get it.

 

 

Flight test plan

 

This is the sequence we laid out for the testing:

 

Power up the wireless access point, and run the laptop off of AC power.

 

Set up the chains and cinder blocks the same way as the last test: each chain should reach to about a foot away from the adjacent corner block. The diagonals will prevent the lander from ever hitting one of the blocks.

 

Prepare the water hose and buckets.

 

Mount the electronics box to the lander.

 

Install and plumb bob align the engines.

 

Boot the flight computer. Some of the driver lights will be on during the boot process, but will shut off when rc.boot begins executing. When a triple beep is heard, the computer is booted. Booting takes about 30 seconds.

 

Telnet to the flight computer from the laptop.

 

Connect the engines to the electronics box. The connectors on the box are in left to right order, and the solenoids on the lander are arranged like this overhead view:

 

3

0 -- BOX – 1

2

front (where the pilot is)

 

Over telnet, launch “flightcom –tiltTest” on the flight computer. If the lander is level, the solenoids should all be clicking intermittently. Someone can then tip the lander in each direction and verify that the appropriate opposite engine stops clicking. If one of the engines isn’t firing when at rest, the platform isn’t level. Adjust either the electronics box or the platform / engines. Finish this quickly to avoid draining too much battery power. Hit enter in telnet to exit.

 

Over telnet, launch “flightcom” with no options.

 

Start RemotePilot.exe on the laptop.

 

Hold joystick button 2 (passive log) to get a telemetry stream from the flight computer. Have someone tilt the lander to verify that both the rate gyros and accelerometers are functioning.

 

Safety glasses on.

 

Load the lander tank with a half gallon of water and pressurize.

 

Hold water cups under each engine nozzle.

 

Put the joystick throttle at 100% (all the way up) and center the joystick.

 

Hold joystick button 3 (full manual control) for a second or so, which should open all engine solenoids full on.

 

Compare the amount of water in each cup, investigating any discrepancies.

 

Put the throttle at 0% and center the joystick.

 

Depressing joystick button 3 should not produce any engine action.

 

For each engine, position the joystick all the opposite direction and press button 3. You should be able to get each engine to fire independently.

 

Holding button 1 (active control) should cause all the engines to intermittently fire if the platform is level. If someone tilts the platform, the firing times should adjust.

 

Drain the rest of the water and nitrogen out through the fill cart instead of using lander battery power on the solenoids.

 

Mix the peroxide for the flight test. 500 ml of 98% plus 100 ml of distilled water, which will give 0.7 kg of 87%. Test our new hydrometer.

 

Load the peroxide and pressurize.

 

Disconnect the fill cart and roll it out of the way.

 

Begin video capture.

 

For each engine, position the joystick all the opposite direction and briefly press button 3 (manual control) to give it a warm up pulse.

 

With the joystick centered and the throttle at 0%, hold button 3 and briefly throttle up to about 20% and back down, looking for uneven thrust behavior.

 

Begin active control by holding button 1. The engines should be intermittently pulsing at zero throttle.

 

Slowly bring up the throttle until liftoff, then bring it back slightly, hopefully resulting in a brief hover.

 

If the lander is 14kg, 0.7kg of 100 Isp propellant should theoretically give nearly five seconds of hover time, but with the pulse width modulation, warm up tpulses, and liftoff ramp, the goal will be two seconds of hovering, then set back down.

 

The joystick is scaled to provide a small range of platform tilt, but if the platform is moving much, it will probably be better to set it down than try to nudge it with the joystick.

 

After setting down, fire the rest of the peroxide at low throttle until it is all expended.

 

Reconnect the fill cart to vent the nitrogen pressure.

 

Load up with water and pressurize.

 

Use joystick manual control to flush water through all the plumbing and engines.

 

Vent the rest through the fill cart.

 

Over the laptop telnet connection, shut down the flightcom program and issue a system “halt”. The flight computer speaker should buzz, then it is safe to disconnect the flight computer main power.

 

Wipe down the lander and spray the area.

 

Clean up.

 

Analyze the telemetry logs on the laptop. Every press of a joystick button will have created a separate file, either “manualXXX.txt”, “passiveXXX.txt”, or “activeXXX.txt”.

 

What actually happened

 

The IEEE802.11b wireless link worked great. No frames were dropped, and it was very convenient. Telneting into your rocket is sort of fundamentally cool. There is a full enough environment installed that I can edit and compile code while the rocket is on the pad if need be.

 

The extra table and power cords made setup and piloting a lot easier.

 

The new logging system worked well. Before, there was confusion about which log file was a real hop and which was just testing the engines or venting the tank. Now, we just keep the “active0.txt, active1.txt, etc” files, which are only generated during the guided flight.

 

We skipped the water testing, because the engines and manifold hadn’t been disassembled since last test.

 

The first two tests didn’t even lift off, because I wasn’t giving it throttle fast enough with the new mass of the electronics box (almost 4kg).

 

The remaining three hops all promptly rotated towards the pilot. We caught one manually, caught another on the tether, and the third one fell over.

 

When we did drop it on it’s side, we lost the flight computer telemetry. It turned out that the impact had actually popped the PC104 stack off of the motherboard. This was my fault – I didn’t have enough PC104 standoffs, so I had only been putting them on the side opposite the pin stack, because the pin connectors are quite sturdy by themselves. I was only considering the stack in compression, not in tension. The standoffs were nylon, and they flexed enough under the impact that the stack popped out of the connector on the motherboard, and was left wedged at an angle.

 

It also popped one of the tie wraps on the battery pack loose.

 

With the computer dead, we were left with a pressurized tank that still had some peroxide in it. In connecting the fill cart up to it, Russ got a squirt of peroxide. It was quickly washed off with no harm done (he had gloves and goggles on), but we decided that the quick connect wasn’t going to connect cleanly with liquid in the tank, so we wired up a manual solenoid control and fired the remainder through one of the engines in a few pulses.

 

Somewhat surprisingly, after we plugged the PC104 stack back in (we had to take the entire stack apart), the computer was still fine.

 

We didn’t have to send the frame back with Bob for repairs, so I would say it was a good test session…

 

Each line of the data logs look like this:

 

3057 16 ( 1.1 -31.5 0.0 18 28 ) ( -39.7 -901.5 0.0 18 28 ) < 0.4 -27.0> < 1.1 -31.5> < -0.9 -639.7> <-39.7 -901.5><-66.1 -178.7> <-63.8 -625.8> <-20.9 -310.3> < 0.0 -42.0>

 

3057: this is the flight computer’s sensor update count. If we don’t drop any telemetry frames, this will increase by one each time.

16: this is the millisecond time delta, and should always be either 16 or 17 if the sensor is giving 60 updates a second.

 

The two parenthesized segments are axis zero (pitch side to side, engines 0 and 1) and one (yaw front to back, engines 2 and 3). The camera was off to the pilot’s left (in the future we will start taking video from the pilot’s POV). Yaw is the one that kept messing up.

 

1.1: the current rate from the gyro. This number is raw A/D units with the centering bias subtracted off, so at rest it should have a value that is between –1.0 and 1.0 due to least significant bit jitter.

-31.5 the current integrated position of all rates since the run started. These are cleared with every trigger press, but the errors pile up fast with our current sensors. One degree is roughly fifteen units.

0.0: the desired position from the joystick. I left the joystick centered except for the last run where I tried to push it away from the direction that it had been turning.

18 28: the number of milliseconds each engine on that axis will be on, out of a total of 33. The adjustment “kick” was set to 10, so depending on which way it wants to adjust the rate, one side or the other will be ten higher (unless the throttle is below 10 total).

 

The eight angle bracketed values are the raw sensor values and their integrations. The order is: gyro1 roll, gyro 1 pitch, gyro 2 roll, gyro 2 yaw, accelerometer X, accelerometer Y, accelerometer Z, and battery. Battery integration is obviously not a useful value. Gyro 1 pitch is axis zero, and gyro 2 yaw is axis one.

 

 

media.armadilloaerospace.com/2001_03_15/active0and1.MPG

media.armadilloaerospace.com/2001_03_15/active0.txt

media.armadilloaerospace.com/2001_03_15/active1.txt

Two skitters that barely lifted off. The extra mass needs more throttle than our previous tests.

 

media.armadilloaerospace.com/2001_03_15/active2.MPG

media.armadilloaerospace.com/2001_03_15/active2.txt

This lifted off, but promptly pitched over. It caught on the tether and came down ok.

 

media.armadilloaerospace.com/2001_03_15/active3and4.MPG

media.armadilloaerospace.com/2001_03_15/active3.txt

Same behavior twice in a row, promptly pitching over towards the pilot. On the last run, I was pushing the joystick away fairly significantly, and it still did it. It fell over on the last run.

 

 

 

Data analysis

 

The computer is making appropriate engine timing decisions based on the attitude sensors, but the bottom line is that these tests were worse than the completely unguided tests, because the attitude sensor was giving the computer incorrect information, and it was doing it’s best to aim that way.

 

The rate gyros aren’t working worth a damn. Sensor values one and three are redundant gyro axis because we needed two dual axis gyros to get three attitude axis. They should stay reasonably close together, but they active4.txt at the end has one of them over 1500 units away, which is about a 90 degree rotation.

 

At first glance, I was thinking that I might have had the yaw axis reversed in code somewhere, because the computer was basically always kicking up the far engine, which made it tip over. It was always getting negative rates, which is supposed to mean “tipping away from the pilot”, so it was kicking up the rear engine to try and level it out. It seemed like an easy explanation, but when we just tipped the sensor board by hand, negative rates were indeed tipping away from the pilot.

 

My bench tests had left me pretty dubious about the gyro results I was getting, but we were crossing our fingers and hoping they would be good for five seconds at a time.

 

By the specs, the gyros have very good precision. The range is +/-150 degrees a second, and they resolve +/-2000 levels for a full 12 bits of precision.

 

We have two of the Gyration ASICs designed for the MG100 gyros on the board, but we were having difficulty interfacing with them, so we just did the A/D with the same chip being used for the accelerometer.

 

The range was in the ballpark, but it was leaving lots of precision on the ground. Violent rotation could only get a range of less three hundred out of the gyros, so over 90% of the precision was being lost.

 

I don’t think that was the main problem, though. At rest, the values are nice and stable, so the drift due to precision should be under half a unit per update, or 30 units a second. That is around 2 degrees, which is a frightening amount of drift, and is roughly what you see at rest, but if you pick up the box and move it around, then put it back down on a level surface, the inclinations will usually have drifted much more than that.

 

The gyros are designed to output a differential voltage, and the specs say that it isn’t ok to read them single ended, which is what we are doing. At rest, the other voltage is just an offset, but I suspect that it changes under rotation.

 

The gyro docs also list them as sensitive to vibration in the 20 to 30 hz range, which is exactly where we are doing are solenoid modulation, so we might have a fundamental problem with them, but we can’t claim that until we have it working well on the bench with just picking it up and moving it around, then failing on the lander.

 

They also list some potential RF interference issues, which could conceivably be an issue with the 802.11 card.

Russ: which gyro is the one close to the Ethernet antenna?

 

We aren’t going to do any more flight tests until we are getting much better gyro data. I want us to find out what the deal is, but worst case, I will buy a 3 axis rate gyro from Crossbow (around $3,000).

 

Other things

 

We made a –6 teflon hose for the 150 lb thrust engine, but I need to get some additional fittings before we can flow test it.

 

We measured the battery voltage with all four solenoids on: it drops the battery voltage from 14v to 10v, but that should still be fine for all the regulated power needs

 

Russ and Phil made a firing earlier in the week with a catalyst made out of a roll of silver screen wire. They wanted to see first hand what happened when you ran 98% peroxide over pure silver. As expected, it melted. The nozzle side of the roll was just gone, and there was silver slag all over the place. We will probably do some more tests at 85%, side by side with the foam packs later.

 

 

Todo

 

Get a manual valve and vent line to plumb into the manifold. We still have free ports, so I think it should just be connected to it’s own port, rather than extending the fill connector. If we vent the system that way, there will still be some residual peroxide in the plumbing, but it won’t be a pressure hazard if it decomposes.

 

Get a big digital clock to put in the video fields of view for correlating video with telemetry logs.

 

Add global timestamps synced to the digital clock to telemetry log lines.

 

Get better precision out of the sensor board.

 

Get more PC104 standoffs.

 

Electronics box todos.

 

Need some female-female 1/4" NPT couplers for the larger engine tests. (just ordered)

 

Get appropriate amplifiers so we can read the load cell directly into the dataq along with chamber pressure.

 

Modify the test stand program to use dataq instead of the 12hz load cell meter so we can get high sampling rates.

 

Run each engine on the test stand while still plumbed onto the lander.

 

Neil is checking on local chemical storage facilities for our peroxide drum, because I don’t think I am going to have land ready for storage soon enough.

 

GPS interfacing to flight computer

 

Weld brackets on the fill cart

 

I should get an mpeg editing program installed so I can cut and trim our flight videos.

 

Make tooling for precisely creating identical compressed catalyst packs.

 

Experiment with putting the cat pack disk cutter on a drill press for faster cutting (try multiple sheets of foam at once?)

 

Try again to get samples of the pure silver foam blocks.