My primary concern over the low static testing levels is that teaches
the wrong engineering practices. I've been to MTA and seen dangerous
results directly attributable to the attitude that it is better to fly
than to test. I can learn more from a flight :(
Rocketry is not the only place I have seen poor engineering practices.
The software world is rift with the disease. I have seen many a power
supply design burn up in the lab. I have seen other disastrous hardware
failures in the field and lab.
In the rush to get the design out the door only the lucky succeed.
The lucky have:
1) Survived past failures and learned from them.
2) Paper tested/simulated before finishing design.
3) More experience (from more failures)
4) Learned to believe Murphy was an optimist and plan for
failure modes learned in 1, 2 and 3
5) Test designs in safe environments
6) The best defense against failure is to use your brain.
I rant... but I hate failure modes that endanger spectators. I really
dislike individuals and groups that are not paranoid about safety. I
have seen results from farm, fire, chemical and explosive accidents. I
like to keep what eye sight and digits I do have.
I am an advocate for incremental development and small steps. I like to
fly rockets, but I really value safe flights. I like hydrotesting and
static testing.
I am definitely conservative in my approach to engineering practices. My
mil-aero and communication backgrounds reflect/amplify that approach.
This is not intended to slam anyone in particular.
On Fri, 2003-09-26 at 22:29, David J. McCue wrote:
> Since there has been discussion on both lists about this flight attempt, I
> thought I would share a few observations as a member of the group that
> made the attempt.
>
> We chose to fly, rather than static-test again, because we could reuse a
> vehicle that had flown before, and we would learn just as much about the
> operation of the engine on the back of the rocket as on a test stand. Our
> one (yes, that's 1 only) successful static test had shown that the design
> performed as predicted, so the next step was to run a few engines to find
> out what materials/manufacturing/assembly issues there were in this
> design.
>
> As it turns out, the engine failed because of just such problem: a failure
> to properly seat the graphite-ring throat-insert resulted in hot gases
> from the chamber sneaking between the insert and the ablative liner,
> eroding the steel support and causing asymmetrical thrust. we didn't know
> that this was a critical item, but firing the engine taught us it was.
>
> In considering the merits of our decision to fly this engine, please
> remember that this is *not* an engine development program. We are trying
> to give undergraduate students who have just learned new skills a chance
> to design something, then build it and see it in action. With only three
> or four chances to go out and test each year, we do not have them long
> enough to put them through an extended test program. It would have little
> value in any case; we aren't in the business of perfecting a design.
>
> This engine's design had to be simple enough for the students to master
> the engineering theory and skills to design it, then make it. This engine
> has no future with us as a developed, fully characterized product. We will
> refine this design a bit more and fly it again a few more times. It will
> have served its purpose.
>
> As to the recovery system failure, it is a particular disappointment to me
> because I am the guy responsible for the electronic portion of the
> recovery system. I take little comfort in the fact that my bits and pieces
> did their job, yet the mechanical portion failed to perform.
>
> The actuator for the recovery system was a new design, prompted by
> concerns over the Safe(!) Explosives Act. We had replaced the pyro parts
> of the system with electrically-controlled pneumatics which worked great
> in ground testing. Our current belief is that an assembly error on launch
> day was the culprit. In any case, we are going back to our pyro system
> until some future students take on the task of refining the pneumatic
> system.
>
> The one group I feel sorry for in our decision to fly was the pair of
> high school kids with the payload. I don't think they fully appreciated
> the risks involved. But, I also hope to see them return and fly again,
> with great success.
>
> Other post-flight observations:
>
> Nearly all of the propulsion and plumbing components from the rocket will
> be reused on the next vehicle. The tubular carbon fiber skin really helped
> save much of the rocket. Our usual cardboard tube skin would've allowed
> the thing to crumple much more. We will reuse the carbon tube as well.
> (We'll likely never get another one!) The next flight will be the third
> for these parts.
>
> The chamber and injector plate will be recycled as well. This chamber and
> plate were the ones used on the successful static fire in June.
> Refurbished with a new carbon plug (spike) and carbon/ablative liner, they
> will be used for the third time.
>
> All of these parts will be bolted onto a new airframe, the latest in a
> series of rocket airframes of simple, proven, stable design. They are
> fairly easy to teach people to build, and are amenable to modification and
> servicing.
>
> Fun fact:
>
> An earlier vehicle in this series of rockets was the first known amateur
> liquid bi-prop to come back under parachute. Perhaps surprising to the HPR
> crowd, shovel recovery is standard practice in the RRS. That's why we put
> observers in the concrete-covered observation bunker.
>
> I hope the foregoing helps clarify the circumtances surrounding our flight
> and the program behind it. Our objectives are different than yours might
> be, so the path we take will also differ. Comments welcomed.
>
> -Dave McCue
>
> On Fri, 26 Sep 2003, Andrew Case wrote:
>
> > On Friday, September 26, 2003, at 04:02 PM, Henry Spencer wrote:
> > >
> > > No argument there; my point is that one of the things it should educate
> > > them about is "we need to do more static testing".
> > >
> > I'd be interested to see a discussion of how to make the most of static
> > testing. I think one of the disincentives to doing lots of static tests
> > is a sense that doing the same thing over and over doesn't seem
> > especially informative. From my perspective it seems like one of the
> > things to try is varying feed pressure a bit, preferably in sudden
> > jumps while running. If there's any danger of combustion instability
> > this ought to trigger it.
> >
> > The CSULB experience seems to have been a problem with the ablative,
> > which is hard to test for since you really need to make sure that every
> > batch is prepared in exactly the same way. Using volunteer labor
> > working in spare time at borrowed facilities makes that kind of hard to
> > do. If the accident was due to variation in ablative properties from
> > batch to batch it might have taken a very large number of tests to turn
> > up the problem. More testing is better than less, but for problems of
> > this sort it's hard to see how to ferret out the problem with a cunning
> > static test strategy - this seems like only a huge number of firings
> > would turn it up. OTOH, there's probably some relatively simple tests
> > that could be done which do not involve firing the engine but which
> > would turn up potential problems with the ablative just as well.
> >
> > ......Andrew
> >
>
>
>
> _______________________________________________
> ERPS-list mailing list
> [EMAIL PROTECTED]
> http://lists.erps.org/mailman/listinfo/erps-list
--
Rick Eversole <[EMAIL PROTECTED]>
_______________________________________________
ERPS-list mailing list
[EMAIL PROTECTED]
http://lists.erps.org/mailman/listinfo/erps-list
