Quoting Doug Ausmus <daus...@gmail.com>:
What has been the root-cause of each of the three failed ARM flights?
I'm pretty sure that two of the failures were attributed to a failed
IO pin on the micro. My understanding was that the pin failed in such
a way that it looked like it was fine, but actually was not. I think
it was a data ready pin on one of the sensors. The first drop test
failed to deploy the 'chutes, and the second simply failed to log data
from the test (chutes were deployed by a pic based timer). We
originally wanted to deploy the chutes based on a timer that starts
when the zip line got pulled. As with many projects, we added the
additional complexity of the altimeter, and it could have cost us the
nosecone. The thing we were testing (NSR and parachute) didn't get
proven because of our added complexity. On the third run (last May)
the launch was not detected by the board.
robust controller solution would seem to be a primary factor for the
roll-control project, with either a single- or a multi- servo approach.
So how do we measure robustness? There are a number of methods that
will organize failure severity and probability (FMEA, some six-sigma
stuff, etc.) but we still have to make the choice ourselves. My choice
is to chose a mechanism that is not capable of changing the rocket
direction regardless of a failed control. The single servo approach
makes the controller "robustness" much less of a factor, and possibly
not even a "primary" factor since the rocket won't spin any faster
than it did on the last launch.
Four servos is really what I wanted from the beginning, but in
retrospect, I feel that the present design is the way to go.
psas-airframe mailing list