Armadillo Aerospace - New Video Update

[hyper_snyper]

July 14 update now up.

http://www.armadilloaerospace.com/n.x/Armadillo/Home/News?news_id=347

[JesseD]

Looks like they've gotten their modular system up and running!  apparently the third time was the charm; the first two tests had RCS goof-ups.  The big thing will be the integration of multiple engines.  As Masten is apparently finding out, it's not too trivial.

- J

[savuporo]

JesseD - 15/7/2007  9:40 AM
The big thing will be the integration of multiple engines.  As Masten is apparently finding out, it's not too trivial.

Yes, but Armadillo has already done that with their earlier differentially throttled vehicles, so they have that experience.

[jimvela]

This month's update is up, at the following location:

http://armadilloaerospace.com/n.x/Armadillo/Home/News?news_id=348

[braddock]

jimvela - 13/8/2007  3:34 PM
This month's update is up, at the following location:
http://armadilloaerospace.com/n.x/Armadillo/Home/News?news_id=348

Looks like they may have some serious problems.

Armadillo's graphite manufacturer is unable to get them the "good stuff" graphite used in their nozzels for four months, and the second-rate graphite is failing.  Also having injector plate issues.  They are beefing both up.

It will be tragic if they get this close only to be shot down by supply problems.

Here is a pic of one of the new modules.  They hope to have a four module unit built for display at the XPrize Cup.
http://media.armadilloaerospace.com/2007_08_13/quakecon.jpg">

[jimvela]

braddock - 13/8/2007  3:38 PM
Looks like they may have some serious problems.

Armadillo's graphite manufacturer is unable to get them the "good stuff" graphite used in their nozzels for four months, and the second-rate graphite is failing.  Also having injector plate issues.  They are beefing both up.

It will be tragic if they get this close only to be shot down by supply problems.

That's the nature of this business.  

Dealing with these supply issues will mature them and force refinement and adaptability in their designs.  Short term, it sucks.  Long term, they'll have a better system as a result...

[meiza]

Haha, they put the old fairing there on top!

Too bad about the supply problems. I wonder if they could hack together a metal regenerative engine in a few months?

edit: read the update, seems they can do with the new graphite too, just being more conservative with the design.

[rosbif73]

New Scientist are reporting that Texel crashed during a test run on Saturday following problems with touchdown sensors.

Armadillo still intend to enter Pixel for the level 1 contest, but have apparently decided to fall back on the older Module 1 vehicle for the level 2 contest.

Incidentally, I'm surprised not to have seen this reported elsewhere nor mentioned here; there's nothing on Armadillo's site either.

[meiza]

Nono, the Module is a new vehicle (a few months old, has two tanks on top of each other.) They will still fly Pixel (four tanks in a grid, flew last year too) for L2, and Module for L1.
Texel was Pixel's twin. They will construct one Module more to be a backup for the current Module, for L1.

[kevin-rf]

Hobby Space is also running an article on the vehicle loss http://hobbyspace.com/nucleus/index.php?itemid=4394

Pretty much says the same thing as the New Scientist article.

[meiza]

Yeah since both have the same email from John Carmack as their source...

[GF3]

It sucks to hear about their crash... I was really hoping to see them perform well at the Xprize. Hopefully they can pull something together in time.

[jimvela]

GF3 - 23/8/2007  2:00 PM

It sucks to hear about their crash... I was really hoping to see them perform well at the Xprize. Hopefully they can pull something together in time.

Pixel still exists, and I'll bet that they fly out whatever testing they plan between now and then on some sort of improvised larger tether... Which should ensure that Pixel makes it to Xprize.

Also they're trying to expedite permitting of the first of their modular family of vehicles, which may well mean they bring and fly two generations of vehicle.  That's a good show, IMHO.

It does suck that they killed Texel, but now they're off in the portion of the learning curve where they start finding out all of the devil-is-in-the-details stuff that will mature them.  The vehicles that come after this will be far better.  Heritage and lessons learned, and such things.

For example, my understanding is that they switched accelerometers for the touchdown sensor from one that could read high Gs to one that couldn't, but then left the engine cutoff landing shock value to a higher G than the new accel could read.  Oops!   Further, if they'd actually drop tested the accel they might have figured that out before it cost them a vehicle.

Similar is the lesson about bad GPS data.

These guys are doing great work on a shoestring and my hat is off to them.   If only they had a budget to work with like the COTS I RpK milestone payments...

[Martin.cz]

Repost of Carmacks post:

It was a bad weekend for Armadillo. We set out to put some flights on Texel, the backup Quad vehicle, and it didn't go so well. We have video that we will be releasing, but Matt had to leave for Germany the next day, so it won't be digitized for a week and a half.

We started out with a normal 90 second elevated / tethered hover test, but we ran into a problem with the actuator power. We initially thought it was a bad main power switch, but it turned out to be the lithium-polymer battery pack cutoff circuit incorrectly shutting down at 16 amps of load instead of 40. This was a new battery pack ( www.batteryspace.com HPL-8059156-4S-WR), and it had passed all the individual actuator checks, but when the igniter started firing with both high amp NOS solenoids, the battery shut down (went to 0.3 volts indicated) after one second and stayed there until it was physically disconnected. Russ made a fairly heroic field repair, cutting open the battery pack and wiring around the protection circuit while sitting on top of the rocket. The total time spent on this after three attempts was 90 minutes, and enough lox had boiled off that the vehicle hit lox depletion at 60 seconds of flight. We got a few good data points from this: the batteries need to be checked at full current load, with vents open we boil off about two pounds of lox a minute, and lox-depletion runs are benign, if a little flamey.

For the second flight we were going to do a ground liftoff (still tethered for runaway protection) to test the automatic ground contact engine shutoff code. We have had several reasons to want to automate this: We get a fair bit of bounce on touchdown, because the engine is essentially keeping the vehicle weightless during the terminal descent. A computer controlled shutdown would be at least a half second faster than my manual punching of the shutdown when I visually see ground contact. The quads will just safely bounce around on the ground a bit if the engine just goes to idle and doesn't shut down, but the module, with the gimbal below the CG, will try to tip itself over when a landing leg becomes a pivot point, so there is extra incentive to get it shut off fast. You can see that in our XPC '05 vehicle flight. We also need to handle the case of the vehicle landing in a situation where I can't shut the engine off promptly, either because there was a telemetry problem, or when we are doing high altitude flights, it lands out of direct sight. There is a separate shutdownTime parameter that will keep it from sitting there at idle for ten minutes, but a telemetry abort could still have it on the ground and cooking for the better part of 220 seconds. We could still shut the flight safety fuel valve, which would result in just idle level lox pouring out of the engine, but that has its own problems.

I have been very hesitant to put in ground contact shutoff code, because shutting the engine down for some incorrect reason would be catastrophic, and I would feel awful if that ever happened. We had some switch based ground contact sensors on the old VDR, but they never got tested. We have concluded that the landing jolt, as seen by the IMU accelerometers, is a good enough ground contact signal. There is always the worry that combustion instability, or a nozzle ejection event, might trigger the signal level, so there are additional guards about it only functioning when you are within three meters of the ground (we must leave some slop for uneven terrain or GPS innacuracy) and trying to descend.

We loaded up again, being very thankful that we now pack three six-packs of helium for each test trip after we were forced to cancel the second flight on a previous test session due to insufficient helium after troubleshooting a problem forced a repressurization on the first flight. Liftoff and hover was fine, and at the 45 second mark (no sense pushing it on a ground liftoff), I had it come in for a landing. It hit the ground, and I saw it bounce back up. My first thought was "That didn't seem to help at all". My second thought was "Uh, that looks like it is accelerating upwards, not bouncing." My third thought was "How the heck did the ground contact code cause that?" My fourth thought was "Crap, its going to fly into the crane, I need to kill it".

After I terminated thrust, the vehicle coasted to an apogee of about 20 feet, and fell to the concrete. It made a fireball that would make any Hollywood movie proud, but the vehicle didn't launch itself back off the ground, make an earth-shattering kaboom, or throw any shrapnel. The fire truck moved into range of the crash and hosed down the vehicle until the fire was extinguished. Surprisingly, the flight computer was continuing to operate and transmit through all of this, but the sensor and wiring harnesses were shorted out in the fire, so we didn't have any sense of the state of the tanks. With trepidation, someone approached the vehicle and found that the lox tanks were still full and pressurized at the same pressure as when the vehicle was shut down. The Aspen Aerogel insulation on the tanks had prevented them from even warming up. We vented the lox, and started assessing everything.

It didn't take long to find out exactly what had happened.

On touchdown, the ground contact logic failed to activate at all. The IMU in Pixel is an older model Crossbow that was rated for +/-10 Gs, but reads to +/-14 Gs. That particular model was discontinued, and the newer IMU in Texel was only rated for +/-4 Gs. I had set the ground contact trigger value to 6 Gs, which I had some recollection that the IMU read to, but it turns out that it was maxed out at 4.5Gs.

What caused the upwards flight was a GPS issue. On ground contact, the GPS PDOP value went from our normal 200 or so up to a value of 1200. The very next frame, it went to 0. We ignore GPS updates when the PDOP is 0, and also some other cases where we know the data is bad, but after flight starts the rule has been that any valid GPS update is taken as authoritative for velocity. Between GPS updates, and if the GPS goes invalid, the IMU will use dead-reckoning to coast for a while, but the accelerometers in particular aren't accurate enough to do this for very long. The at-impact 1200 PDOP update contained velocity values that were significantly off, including a 5 m/s down velocity, which caused the vehicle to throttle up to try to regain the desired 1.5 m/s terminal landing velocity.

I briefly wondered if the GPS antenna mast might have actually fallen off on landing, giving a correct velocity before losing sat view, but reviewing the video showed that it clearly stayed in place through the bounce.

We have known these GPS receivers are vibration sensitive for a while, and we take several measures to protect them from the rocket environment, but this was the first time we had a shock related failure. I went back to the telemetry from the Oklahoma free flights to look for similar signs on touchdown, and found a corroborating point. On the second free-flight, the GPS PDOP jumped from 200 to 359 at the time of touchdown, as seen by the accelerometers. This effect has evidently always been there, and some combination of the still heavy propellant tanks from the shortened flight and just bad luck caused a jump all the way to 1200 PDOP and an unusable value.

The question of interpreting GPS PDOP values has always been an issue for us. The exact meaning has to do with uncertainties in the calculated GPS position value due to the angles between the currently tracked sats. Flights typically have a PDOP between 150 and 250. We have a no-go set at PDOP 300, and an in-flight abort set at PDOP 400. While the calculated GPS position can vary widely with higher PDOPs, the velocity value always seemed to stay fairly reasonable at high PDOP values, so I had intentionally elected to continue using velocity updates even if the PDOP was past the abort point. The situation I was worried about was having the vehicle at 60 meters altitude, and having the PDOP change to 450, forcing both an abort, and, if I couldn't use that velocity data any more, a reversion to coasting on the IMU updates all the way to the ground, which I wasn't very confident of. I'm not beating myself up about this original decision.

The change I am going to make as a result of this is to define an unacceptable PDOP value, initially set at 500, beyond which a GPS update will simply be ignored as if the PDOP were 0. If we are in a situation of degrading PDOP somehow, that should allow it to abort at 400 and still hopefully make it to the ground with GPS based velocity updates.

In hindsight, there are a couple other, more reasonable-to-expect, things that would have saved the day:

If we had tested the ground contact logic by actually dropping Texel at the shop, we would have found that it didn't trigger, and I would have adjusted the value until it did work. If that had been done, we might not have even noticed the GPS problem, because it would have shut down before any action based on the bad velocities was taken.

If I had planned on just shutting down the flight like I normally do, instead of just watching what the vehicle did with just the ground contact logic, it would have just looked like a higher-than-normal bounce, and we would have seen both the ground contact failure and the GPS issue when I looked at that part of the telemetry. If the ground contact logic had functioned, my pressing the button shortly after would have had no effect.

There were a number of data points learned from the experience:

The vehicle fell straight down after the failure, as it was supposed to do. In fact, three separate shutdown systems were activated. I commanded the shutdown first, followed shortly thereafter by the computer thinking it had flown outside the shutdown box due to the abnormal velocity and triggering another shutdown code, followed a second later by Russ hitting the remote flight termination button and causing the independent flight cutoff valve to close. The reaction times on all of this were quite good, especially considering the completely unexpected nature of the failure. It is one thing to be watching a specific line and hit a button when something crosses the line, and another thing to analyze a completely unexpected situation and make a high-cost decision under pressure. Everyone else reported that their first thought was "Why is John doing a touch-and-go?", and it took a little while to register that this was not intentional.

The vehicle had over 200 psi in the tanks when it went down. There were two pressure vessel failures, both on the fuel side: one of the stubby "feet" on the bottom of one of the fuel tanks hit hard enough to tear at the weld, and the fuel pipe that supports the cutoff valve broke under the force of the impact. All of the fuel was pushed out in very short order, and ignited by residual flames from the engine shutdown. No lox was vented, although there were high heat signs of a small oxygen leak around our lox dump valve during the fire, probably due to the fire cooking the valve packing. It would have been more dangerous if the lox tanks had also broken, but it is hard to say exactly how much. It might have been just an extremely hot fire that melted the vehicle to slag, or it might have been a significant explosion.

All three remaining tanks were bent in somewhat at the bottom where the "feet" were, but they still hold pressure. We will probably do some fatigue cycle tests on them now that the vehicle is scrap. If this had been over dirt, or the tank bottoms had just been simple hemispheres with rubber bumpers without the threaded mounts protruding, the tankage would have most likely been completely undamaged after a 20' fall. The top fuel pipe would still have broken, but that could be designed around if desired. It is possible to make a pressure fed vehicle that can survive a 20' drop.

The fireball and blaze were very spectacular, but the parts of the wiring harness that were wrapped in leather actually came through the blaze ok. With some more care, it would not be unreasonable to engineer a wiring harness that could actually live long enough inside a blazing wreck to allow you to do something useful, like vent pressure.

Everything inside the electronics box appears to be unscathed and still functional, although we know from a previous crash years ago that hidden faults may still lurk, so we aren't going to use them again. We can give an extremely strong endorsement to McMaster-Carr " 85925K423 Fire-Retardant Silicone Foam Rubber Sheet Adhesive Back, 1/4" Thick". We started covering our electronics boxes in foam years ago to give them a milder acoustic environment for the GPS units, but we managed to set the electronics box on fire a couple times when test stand engines misbehaved. We eventually moved to this material, and it not only didn't burn inside this fireball, but it protected everything inside the box quite well. The foam on the bottom of the box was hit by a high-pressure burning fuel jet from the plumbing rupture, but it didn't burn through.

We still have Pixel and Module 1 in flyable shape at the shop, so this doesn't have a critical impact on us, but it does change our testing plans for the next two months before the X-Prize Cup. We are cancelling the untethered 180 second flights for Pixel at OKSP. We will plan on doing two sets of back-to-back 180 flights under tether, but if we are going to risk a crash, it might as well be for the money at XPC now that we don't have a backup. We are going to finish up Module 2 in the next couple weeks so we have a backup for level 1. Modules 3 through 5 should also be at least frame constructed by XPC, but whether we get them wired and tested will depend on how our flight testing goes. If we manage to destroy a module in the next two months, we can crunch hard and get an extra one put together if necessary.

We will be flying again this weekend, and I hope to get at least the following tests in before XPC:

tethered back-to-back 180s with Pixel
tethered ground liftoff / touchdown tests with Pixel (using the double-shudown testing protocol)
tethered back-to-back 90s with Module 1
tethered ground liftoff / touchdown tests with Module 1
free-flight back-to-back 90s with Module 1 at OKSP
tethered back-to-back 90s with Module 2

John Carmack

[GF3]

Well that is good news. I only heard that their was a crash and they might not be able to do the XPrize this year. Good luck to them i can wait to see it fly in October.

[meiza]

People have blown this particular crash far out of proportion, comments from people who know nothing fly around the internet, of course, mostly on other sites than this...

Armadillo probably has a crash every three months or so. That's why their vehicles are cheap, and they have also prepared multiple vehicles for the X-Prize Cup Lunar Lander Challenge, for both levels. This was one of those spare vehicles that they were flying.

Just recently an Atlas V launch failed, there's not so much time from the catastrophic Sea Launch failure and not much more from the Delta IV heavy. SpaceX has had problems so far, Ariane had problems at start. So it's not as if the "big boys" have a very good record either. (Yeah I know they are in a totally different performance class.)

I have been following Armadillo's progress for about four years now and they have made remarkable progress. There have been only a few rockets in the whole history of the world that take off vertically and land vertically as well, and those have been multimillion dollar efforts by big governments. And Armadillo has advanced the state of the art too, with numerous different design approaches, and has reached a pretty well operational system by the standards of their VTVL rocket class, with numerous flights and quick turnarounds.

[halkey]

meiza - 23/8/2007  7:46 PM

People have blown this particular crash far out of proportion, comments from people who know nothing fly around the internet, of course, mostly on other sites than this...

You can definitely write that again after I read the inane comments of the clueless at a certain general science/tech site about the crash which ranged from ragging on Carmack for not being a professional engineer (as though people can't be self-educated or that physics somehow refuses to work for people who haven't achieved a piece of paper) to people thinking that the crash forever proves that Carmack can never succeed and achieve safety for manned flights.  I see the same sort of idiotic comments about Bigelow's project as well, that because his modules are inflatable, they must be far easier to pierce with micrometeorites to accusing him of ripping off investors because atmospheric balloons already exist.  And they always state these types of ridiculous and ignorant comments as though their opinion is absolute truth.   I never know whether to laugh or cry.  I just always fear that these types of people with grossly misinformed opinions will be listened to somewhere up on the food chain and that their ignorance will kill future advancement.   Yes, I'm paranoid.

[meiza]

And it's pretty sad that they actually are listened to, just look at the modding system at slashdot or what gets into many editorials or columns in newspapers. I guess it's the stupidity of the masses who can't judge and criticize these ignorant opinions.

[braddock]

Just as long as the FAA doesn't get too nervous...

[meiza]

Why would the FAA get nervous? They expect crashes during development, and stuff worked as expected, all three shutdown methods worked precisely.

Armadillo has some problems as a small customer to get constant similar hardware from suppliers though, this has been the case in the past too.