Feb 27, 2001 meeting notes:

 

Location: Long Range Systems

 

In attendance:

 

John Carmack

Phil Eaton

Russ Blink

Darin Smith

 

New supplies:

 

Small inner tube and aluminum plate for VTVL base bumpstop

Oxidizer hazmat labels for our peroxide

IR temperature probe

PC104 PCMCIA card interface

Silver screens (finally!)

X-L Catalyst sample

3 axis accelerometer from http://www.xbow.com/html/product.htm

Extra table for workshop

 

Still on order:

 

Two wireless Ethernet PCMCIA cards for laptop and flight computer

Drum of 98% peroxide

 

Still to get:

 

Project box for flight computer / batteries / sensors (NMEA?)

Waterproof connectors for solenoids

Waterproof main power switch

Longer water hose

Power strip and longer extension cords

An extra large solenoid for 150lb engine testing

 

My real job had me cramming for a demo and flying off to Tokyo the last two weeks, but things have died down so I can get back to work on the rockets now.

 

I finally got a real web page together with all of our data: www.armadilloaerospace.com

 

I still need to get the rest of our software up there, but I will be keeping it updated after each work session.

 

I finally dug up the raw serial line specs for the dataq-151 serial data acquisition box I got a while ago: http://www2.dataq.com/spec100.htm#t194

 

There are some decent tools and libraries available for logging with it, but I want to integrate it directly with our solenoid control program so we can log one or two pressure channels at up to 240 hz to go along with the 12hz load cell reading, and have it automatically cropped and correlated with our control actions.

 

We have a harsh conditions pressure transducer that will cover our needed range of chamber pressures, but we still need to figure out exactly how we want to plumb it into an engine for testing. We are probably going to fill it with water to protect it during fittings.

 

Related to the topic of correlating multiple data sources, I would like to be able to sync video logs with other data logs. If we had a camera that could overlay time of day with at least second (preferably more) accuracy, I could sync the computer time with that and dump time of day along with all other logged data. The other option would be to use a firewire camera or something that can stream directly to the laptop and have it record the video along with everything else.

 

Something like that would have been particularly useful for today’s tests.

 

Bob strengthened the VTVL frame by using the next thicker tubing for the legs, and tying them together rigidly with tubes (the old legs, in fact) instead of wire at the halfway point. This worked out great – it is much more steady and strong. One mistake that wasn’t obvious until the testing was that the legs were just slipped on, under the assumption that the cross-ties prevented hem from sliding out because they were angled outward. This turned out not to be true when bouncing off of a single leg – we had one fall off during a hop. They will be drilled and pinned again for the next hop.

 

Russ is nearly finished with our six degree of freedom sensor board. It will secure to our PC104 flight computer stack, but it doesn’t use any of the bus signals. It outputs a continuous, raw, one directional serial stream of A/D conversions in ascii hex format for each sensor. It has it’s own power connector. Russ laughed at me when I innocently suggested that he just use the PC-104 regulated 5v. :-) We will give it it’s own connector to our master unregulated 14.4v bus and let it do high precision regulation to 5v on it’s own.

 

We are using two of the gyration micro gyros for attitude rate, and an Analog Devices CXL04M3 for linear acceleration. This combination should see us through this vehicle, but the micro gyros are not well suited to G loads over about 2G.

 

We did one quick engine test with the X-L catalyst in our small test engine. This catalyst is a bunch of porous ceramic tubes about a cm long each, coated with something (potassium permanganate?). The benefit of this catalyst is that it can work with 98% peroxide without melting. We just filled up the engine with it and set it up. There was almost no back pressure through the pack, so we expected the engine to just flood like our uncompressed foam tests.

 

media.armadilloaerospace.com/2001_02_27/xl_catalyst.MPG

media.armadilloaerospace.com/2001_02_27/xl_catalyst.xls

 

That is basically what happened, giving a very cloudy exhaust the entire time. We should have cleared the line with a couple pulses before logging, because the 200msec warm up pulse didn’t seem to even get fluid to the catalyst bed, so the main run was to a cold bed. We will want to revisit this when we get around to buying or making a cavitating venturi to moderate the startup flow properly. We might also be able to work it out with a special sequence of startup pulses to build chamber pressure, which would be the ideal solution, because it wouldn’t mandate the 15% pressure drop across a CV.

 

We also have pure silver screen to test with when we want to now. I need to try pestering the company advertising pure silver foam some more, they never responded to my email inquiry.

 

Our next major engine development work will probably be a 150lb thrust engine for use in the unguided dumb rocket and possibly one corner of the first manned craft.

 

We put everything back together on the VTVL, and incorporated the new electronics board. There were improvements in a number of areas.

 

media.armadilloaerospace.com/2001_02_27/Spider1_1.JPG

This shows the thicker legs with cross ties. The electronics board is a lot thinner now, and is securely bolted to the top plate.

 

media.armadilloaerospace.com/2001_02_27/manifold.JPG

The –4 tap and O-ring worked fine, so now our fill port goes directly into the manifold, instead of needing a chain of NPT to AN fittings. Tapping for AN fittings is a good capability to have for the future.

 

media.armadilloaerospace.com/2001_02_27/DriverBoard.JPG

The driver board now has connectors for each of the solenoids, instead of terminal posts.

 

media.armadilloaerospace.com/2001_02_27/batteries.JPG

The batteries are now in the center of the board, because they were heavy enough to give a noticeable change in CG.

 

media.armadilloaerospace.com/2001_02_27/GyroMouse.JPG

This is my butchered and mounted GyroMouse that we used as an attitude sensor.

 

We used twice the tether length as our previous hops. The tethers were arranged so that the chain from each corner cinder block could nearly reach the next corner block, which meant that the opposite diagonal was quite a bit away. This gave the VTVL some room to move, but guaranteed it couldn’t come down on a block. We drilled holes on the top plate to quick link the chains to, instead of wrapping them around the support braces down low like we were doing before. I think we will be keeping this length and arrangement for the next few tests.

 

We did a water test first to make sure everything was working with the new connectors. We found that we hadn’t tightened some of the port plugs, so we had trouble drawing a vacuum. Then, when we got water in and opened up the engines, we found that one of the engines had the check valve in backwards, and wasn’t firing. Oops. Water testing after ANYTHING changes is a very very good idea.

 

The guts of the GyroMouse served as some form of two degree of freedom attitude sensor, but there are some significant problems with it.

 

To put it into continuous update mode, you need to double click a button. The double click is very finicky, and it was hard to do it fast enough when it was bolted to the platform.

 

The continuous update stops after a few minutes of inactivity to save battery power. We were constantly jostling the lander to try and keep it from going out and needing another double click.

 

The main body of the sensor communicates over an RF link to a base, which is connected to the computer. We had it go into some state that just wouldn’t get any data out, until we took it apart and reset it in the cradle. We never did figure out exactly what the problem was.

 

Because it is a serial mouse, if the laptop boots with it already connected, Win98 grabs that port as a desktop mouse, and my program can’t get at it. I have to unplug it, boot, then plug it in before running my program.

 

This isn’t really a problem with the mouse, but for anything communicated small at low baud rates (1200 baud in this case), it is critical to set the serial port driver properties so the FIFO interrupts on every character, instead of buffering them up. This causes a tiny amount more driver overhead, but without doing that, the arrival times are all over the map.

 

The biggest problem (even bigger than I thought before tonight) is that the mouse protocol doesn’t send ANY bytes when there is no detected movement. When something is constantly moving, you get exactly 30 updates a second, very repeatably. The millisecond count is always 33 or 34. However, if it doesn’t detect movement on either axis, it doesn’t send anything. The cruddy part is that instead of just skipping some multiple of 33 msec and checking again, the clock gets reset at an arbitrary time.

 

Unfortunately, we messed up the video for todays flights, because the camera was still in still shot mode:

 

media.armadilloaerospace.com/2001_02_27/feb27_hop.JPG

 

This was too bad, because we are starting to look pretty good! There was a second or two of credible hovering in the runs before we tip over…

 

Here is a sample log from d5_flight0.txt.

 

The first number is the number of milliseconds since the previous line, which should be 33 or 34 whenever the sensor is feeding a continuous stream of data. The last line shows 50, which means the sensor failed to output a reading for a brief period of time. I expected the rocket to always be more in motion, but it did clearly get nearly stable (1,0) the previous frame, so a (0,0) update is certainly plausible.

 

The second number is the throttle percentage that I was using at that time. This clip is during my throttle up just after liftoff. Liftoff seems to be around 30% throttle. The throttle is very non-linear, with the thrust picking up fast at the beginning of the range. This makes sense, because at low duty cycles the chamber pressure will be mostly blown down, allowing a given amount of msec to flow much more peroxide into the chamber than when the chamber pressure is all the way up.

 

The parenthesized sections are the two axis, which are treated identically.

 

The first number is the rate value read from the sensor. The second value is the integrated position that is the sum of all rates so far. The third number is the desired position, which is always zero when the joystick is centered. The fourth number was supposed to be the desired rate, a value calculated internally during the control logic, but I didn’t log it properly.

 

The last two numbers on each axis are the duty cycles for the engine pair controlling that axis. If the first engine is on longer than the second, the rate should get more negative. If the second is on longer, the rate should get more positive. The program is set up to just have a single fixed size kick, in this case 5 msec. There is no dead band, so in stable hover it should be swapping the kick back and forth between the engines constantly.

 

34 0.30 ( 1 4 0 0 13 8 ) ( 1 1 0 0 13 8 )

33 0.34 ( 2 6 0 0 15 10 ) ( 0 1 0 0 15 10 )

33 0.38 ( 1 7 0 0 16 11 ) ( -4 -3 0 0 11 16 )

33 0.40 ( 1 8 0 0 16 11 ) ( -22 -25 0 0 11 16 )

34 0.41 ( 0 8 0 0 17 12 ) ( -45 -70 0 0 12 17 )

33 0.41 ( 0 8 0 0 17 12 ) ( -40 -110 0 0 12 17 )

33 0.43 ( 0 8 0 0 17 12 ) ( -35 -145 0 0 12 17 )

34 0.43 ( 0 8 0 0 17 12 ) ( -36 -181 0 0 12 17 )

33 0.43 ( -3 5 0 0 17 12 ) ( -39 -220 0 0 12 17 )

33 0.45 ( 1 6 0 0 18 13 ) ( -47 -267 0 0 13 18 )

33 0.45 ( 2 8 0 0 18 13 ) ( -65 -332 0 0 13 18 )

34 0.45 ( 1 9 0 0 18 13 ) ( -77 -409 0 0 13 18 )

33 0.46 ( 0 9 0 0 18 13 ) ( -68 -477 0 0 13 18 )

33 0.48 ( 1 10 0 0 19 14 ) ( -70 -547 0 0 14 19 )

34 0.49 ( 2 12 0 0 19 14 ) ( -75 -622 0 0 14 19 )

33 0.54 ( 2 14 0 0 21 16 ) ( -62 -684 0 0 16 21 )

33 0.56 ( 2 16 0 0 21 16 ) ( -53 -737 0 0 16 21 )

33 0.59 ( 2 18 0 0 22 17 ) ( -29 -766 0 0 17 22 )

34 0.61 ( 0 18 0 0 23 18 ) ( -7 -773 0 0 18 23 )

33 0.65 ( 1 19 0 0 24 19 ) ( -1 -774 0 0 19 24 )

33 0.66 ( 0 19 0 0 24 19 ) ( -8 -782 0 0 19 24 )

33 0.69 ( 1 20 0 0 25 20 ) ( -18 -800 0 0 20 25 )

34 0.73 ( 0 20 0 0 26 21 ) ( -12 -812 0 0 21 26 )

33 0.74 ( 0 20 0 0 27 22 ) ( -4 -816 0 0 22 27 )

33 0.76 ( 0 20 0 0 27 22 ) ( -7 -823 0 0 22 27 )

34 0.77 ( 1 21 0 0 28 23 ) ( -5 -828 0 0 23 28 )

50 0.79 ( 1 22 0 0 28 23 ) ( 0 -828 0 0 23 28 )

 

The program asked for the 5 msec kick in all the appropriate places, but the delta was not enough to effect the rates the way it wanted. I increased the kick to 10 msec for the next run.

 

33 0.34 ( 1 -3 0 0 10 20 ) ( -3 -127 0 0 10 20 )

33 0.34 ( 1 -2 0 0 10 20 ) ( -1 -128 0 0 10 20 )

34 0.34 ( 2 0 0 0 20 10 ) ( -2 -130 0 0 10 20 )

33 0.34 ( 6 6 0 0 20 10 ) ( -4 -134 0 0 10 20 )

33 0.35 ( 10 16 0 0 20 10 ) ( 0 -134 0 0 10 20 )

33 0.38 ( 13 29 0 0 21 11 ) ( -11 -145 0 0 11 21 )

34 0.38 ( 3 32 0 0 21 11 ) ( -5 -150 0 0 11 21 )

33 0.35 ( -3 29 0 0 20 10 ) ( 7 -143 0 0 10 20 )

33 0.27 ( -7 22 0 0 18 8 ) ( 0 -143 0 0 8 18 )

33 0.21 ( -13 9 0 0 16 6 ) ( -1 -144 0 0 6 16 )

34 0.21 ( -21 -12 0 0 6 16 ) ( 12 -132 0 0 6 16 )

40 0.21 ( -33 -45 0 0 6 16 ) ( 9 -123 0 0 6 16 )

26 0.21 ( 0 -45 -3 0 6 16 ) ( 0 -123 0 0 6 16 )

50 0.21 ( -38 -83 -9 0 6 16 ) ( 0 -123 0 0 6 16 )

33 0.21 ( -43 -126 0 0 6 16 ) ( -81 -204 0 0 6 16 )

50 0.21 ( -61 -187 0 0 6 16 ) ( -111 -315 0 0 6 16 )

41 0.21 ( -89 -276 0 0 6 16 ) ( -107 -422 6 0 6 16 )

26 0.23 ( 0 -276 3 0 6 16 ) ( 0 -422 6 0 6 16 )

 

Here we can see the kicks making a difference. The X axis went from negative to positive, and back to negative, exactly as commanded. Once the updates stopped coming in regularly (at 33 or 34 msec rates), things sort of fell apart.

 

The two positive kicks in X at the top resulted in positive increases in the rate for three updates even after the kick changed to negative. There are a number of source of latency in the system that account for this. There is one frame of latency just from the serial transport, and we have no idea what the radio link was doing. Both of those should go away with our custom board.

 

Even though it kept a positive 10 kick on Y the entire time, it never could get a positive rate out of it, although it kept it from going negative as fast as with the 5 kick. There is probably a disparity in the engine outputs that we need to nail down. We should probably static test all four engines, one after the other. If there is variability we can’t solve, we can at least match them in closest pairs.

 

We probably won’t run with the GyroMouse again, because the non-regular updates seem to be poison to the flight control, and it was a general PITA. For the tethered tests, we will be connecting to our custom board over the same cable as the driver control, eliminating the radio link.

 

 

Our peroxide order from X-L should be done within a week, but we don’t yet have a place to store the drum. I am looking at buying 13 acres of land out away from town Real Soon Now. My wife is in a real-estate investing mood, so I don’t need to justify is solely for Armadillo Aerospace :-). Initially, I will just put a Home Fepot shed on it for our drum of peroxide, but we are beginning to plan for a larger test stand and possibly some work facilities. It should be plenty big enough for untethered VTVL testing as well.

 

 

 

Stuff to do:

 

Finish the sensor board.

 

Strip the frame back down and get it back to Bob for a few more modifications.

 

Finish fill cart

 

Phil needs to pick up the extra work table from my office

 

Buy the land

 

Get the damn flight computer working. Darin: grab me a handful of PC104 standoffs if you can.