Crash for Armidillo

http://media.armadilloaerospace.com/...8InchCrash.mpg

Another X-Prize contestant has some bad luck.

Nice flight, though, John! Take on some more fuel next time.

BitBanger wrote:
....Take on some more fuel next time.

Or fly the craft over a lake.

Or fly the craft with a few parachutes
held up by balloons.

Or reconsider a splashdown as the alternative
to vertical power landing.

"BitBanger" wrote:

http://media.armadilloaerospace.com/...8InchCrash.mpg

Another X-Prize contestant has some bad luck.

Nice flight, though, John! Take on some more fuel next time.


The loss of thrust because of the lack of fuel is a symptom, not the
problem. The problem is a significant failure of the engine due to
design problems. The direct cause of the crash was ignoring failure
symptoms during the pre launch phase.

http://spaceshipsummer.blogspot.com/...in-pieces.html

D.
--
Touch-twice life. Eat. Drink. Laugh.

(Derek Lyons) wrote in message ...
"BitBanger" wrote:

http://media.armadilloaerospace.com/...8InchCrash.mpg

Another X-Prize contestant has some bad luck.

Nice flight, though, John! Take on some more fuel next time.


The loss of thrust because of the lack of fuel is a symptom, not the
problem. The problem is a significant failure of the engine due to
design problems. The direct cause of the crash was ignoring failure
symptoms during the pre launch phase.

http://spaceshipsummer.blogspot.com/...in-pieces.html

D.

Obviously we made mistakes there. However, I do not take it as an
indication that our basic aproach is flawed. We will incorporate
lessons learned from this, but you just can't wait until everything is
"provably perfect" before flying something.

Crashing just isn't THAT big of a deal for us, and forcing the
evolutionary cycle has some mitigating postive benefits. The new
vehicle is going to be a lot better in many ways, including the
engine.

When we have a spurious problem, like a loss-of-computer, we make some
theories about what might have caused it and take some corrective
action. It might or might not actually have fixed the problem, but we
can't tell, because the problem was spurious. We go about our
testing, and if it happens again, well, we need to try something else.

The tank pressure transducer had been giving occasional spikes in the
reading. Should we have canceled whatever we were doing and waited
until we resolved it? If it turned out that the spikes were do to an
intermittant short that then caused a computer failure and loss of
vehicle, many smug people would have pointed to our failure to follow
up on the problem, but I think that most people that work with sensor
systems would agree that a slightly misbehaving sensor in a
non-critical application isn't always worth chasing down.

When we saw the catalyst rings escape from the engine on Tuesday, we
continued using the engine, but I went home and designed the
all-drilled support plate that avoids the screens completely and
functions as an integral part of the chamber. This should fix the
problem, but the delivery was 3 - 4 weeks ARO. We could have sat on
the vehicle for that time, but instead we went ahead and flew it and
crashed. We got good data from the flight test, and we will have a
new, greatly improved vehicle built up only a week or two later than
if we had just sat around and waited for the modified engine parts.

John Carmack
www.armadilloaerospace.com

On 11 Aug 2004 15:24:37 -0700, (John Carmack)
(Derek Lyons) wrote in message
http://media.armadilloaerospace.com/...8InchCrash.mpg
Nice flight, though, John! Take on some more fuel next time.
http://spaceshipsummer.blogspot.com/...in-pieces.html

Obviously we made mistakes there. However, I do not take it as an
indication that our basic aproach is flawed. We will incorporate
lessons learned from this, but you just can't wait until everything is
"provably perfect" before flying something.

Crashing just isn't THAT big of a deal for us, and forcing the

John Carmack
www.armadilloaerospace.com

You must be having more fun than anyone else!

Good on ya!

Gunn the Enthusiast.

In article ,
John Carmack wrote:
Crashing just isn't THAT big of a deal for us,

I have to wonder how serious you really are about manned spaceflight
after saying something like this. Is it,

(a) "Crashing a manned flight also isn't that big of a deal
for us, because our people are expendable,"

(b) "Crashing a manned flight is a big deal, but we're going to learn
not to crash very soon,"

or

(c) "Crashing a manned flight is a big deal, but we're going to risk it
because we thrive on grief"?
--
/\ Greg Kuperberg (UC Davis)
/ \
\ / Visit the Math ArXiv Front at http://front.math.ucdavis.edu/
\/ * All the math that's fit to e-print *

(Greg Kuperberg) wrote in message ...
In article ,
John Carmack wrote:
Crashing just isn't THAT big of a deal for us,

I have to wonder how serious you really are about manned spaceflight
after saying something like this. Is it,

(a) "Crashing a manned flight also isn't that big of a deal
for us, because our people are expendable,"

(b) "Crashing a manned flight is a big deal, but we're going to learn
not to crash very soon,"

or

(c) "Crashing a manned flight is a big deal, but we're going to risk it
because we thrive on grief"?

Honestly, that's simply an absurd thing to post. If I'm developing
medical software where lives are at stake, and I get a compile error,
should I wring my hands in despair that I'm not taking it seriously
enough?

No, obviously, because I'm in development. At that stage of the
process, errors are expected. It's the end-product that matters, and
late-stage testing is different from early-stage testing.

Exactly whose life was put at risk here? The rockets are in
development. He knew there was a problem, yet decided to risk
launching, because he wanted to gather more data.

(John Carmack) wrote:
When we have a spurious problem, like a loss-of-computer, we make some
theories about what might have caused it and take some corrective
action. It might or might not actually have fixed the problem, but we
can't tell, because the problem was spurious. We go about our
testing, and if it happens again, well, we need to try something else.

A valid testing philosophy, and one I've used myself on multiple
occasions, on *much* bigger rockets, and with greater possible
consequences than yours. (That's not arrogance, read on please.)

Since you are not a regular reader of all the threads (AFAIK) in the
sci.space.* hierarchy, allow me to enter my background into evidence;
I've followed space topics for around thirty years, including an above
average laymans understanding of the technologies and issues involved.
In addition, I spent ten years in the US Navy as a Strategic Missile
Firecontrolman on the Trident-I (C4) weapons system. I'm no Henry or
George when it comes to the deeper and more technical issues, but I've
got more experience on actual birds and their control systems (if
different from NASA's and others) than most folks here.

But the key issue here is the difference between what you say you are
doing (here) and what you have said you are doing (in the past), more
on that a little later.

The tank pressure transducer had been giving occasional spikes in the
reading. Should we have canceled whatever we were doing and waited
until we resolved it? If it turned out that the spikes were do to an
intermittant short that then caused a computer failure and loss of
vehicle, many smug people would have pointed to our failure to follow
up on the problem, but I think that most people that work with sensor
systems would agree that a slightly misbehaving sensor in a
non-critical application isn't always worth chasing down.

In something as tightly integrated as a rocket, there are very few
non-critical applications. However, as above, the issue of my article
turns on what was and was not said in your weekly update.

Another issue is that you are forming now the habits that will follow
you into operational and manned testing. It's *dammed* hard to change
that mindset when you change modes. (Been there, done that bringing a
SSBN out of the shipyards, through sea trials, inspections, workups,
and on to deterrent patrol.)

Also, please be careful about using words like 'smug'. Being critical
and questioning (like myself or the people on the X-Prize boards) does
not mean that we are not rooting for you, or that we are not all
striving towards the same ultimate goal.

When we saw the catalyst rings escape from the engine on Tuesday, we
continued using the engine, but I went home and designed the
all-drilled support plate that avoids the screens completely and
functions as an integral part of the chamber. This should fix the
problem, but the delivery was 3 - 4 weeks ARO. We could have sat on
the vehicle for that time, but instead we went ahead and flew it and
crashed. We got good data from the flight test, and we will have a
new, greatly improved vehicle built up only a week or two later than
if we had just sat around and waited for the modified engine parts.

A very viable testing philosophy. The problem is, once can only be
interpreted on the material one places into evidence. When you report
"we had this problem and that problem and flew anyhow", only one range
of interpretation is possible. When you report "we had this problem
and that problem, and thought we had a fix, but were wrong", a quite
different interpretation comes to light. It's a matter of only a few
words in your weekly update, but those are important.

D.
--
Touch-twice life. Eat. Drink. Laugh.

John Carmack wrote:
(Derek Lyons) wrote in message ...
"BitBanger" wrote:

http://media.armadilloaerospace.com/...8InchCrash.mpg

Another X-Prize contestant has some bad luck.

Nice flight, though, John! Take on some more fuel next time.


The loss of thrust because of the lack of fuel is a symptom, not the
problem. The problem is a significant failure of the engine due to
design problems. The direct cause of the crash was ignoring failure
symptoms during the pre launch phase.

http://spaceshipsummer.blogspot.com/...in-pieces.html

D.

Obviously we made mistakes there. However, I do not take it as an
indication that our basic aproach is flawed. We will incorporate
lessons learned from this, but you just can't wait until everything is
"provably perfect" before flying something.

Crashing just isn't THAT big of a deal for us, and forcing the
evolutionary cycle has some mitigating postive benefits. The new
vehicle is going to be a lot better in many ways, including the
engine.

Ah I see You basicly hack on the vehicle and resolve the problems
as they come up and replace subsystems when you can. Good approach.

John Carmack
www.armadilloaerospace.com

--
Sander

+++ Out of cheese error +++

"Sander Vesik" wrote in message
...
Ah I see You basicly hack on the vehicle and resolve the problems
as they come up and replace subsystems when you can. Good approach.

If you don't start flying sometime, you can get stuck in "Analysis
Paralysis".

http://c2.com/cgi/wiki?AnalysisParalysis

NASA has been guilty of this behavior in the past, always working towards
the perfect hardware or the perfect mission, but every attempt ends up being
cancelled due to cost and schedule. In my mind, the whole HL-20, X-38, CRV,
CTV, CEV, and etc. path is a good example.

Something simple, like an Apollo derived capsule, wasn't "good enough" for
use as a space station lifeboat, so they started down the path of making
something "better". In the end, it's 2004 and we're still stuck using Soyuz
at ISS because the US has absolutely nothing to fill that role.

Jeff
--
Remove icky phrase from email address to get a valid address.