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

Reply via email to