Steven Saner <[email protected]> writes: > It would, therefore, be cool if the altimeter could in some way detect > the apogee failure and trigger the main ejection early. Obviously, this > defeats the intention of the dual deployment, but I would much rather > have to hike after the rocket than for it to be destroyed and/or come in > hot and unsafe.
I've thought about this a bunch, and in fact all of the Altus Metrum flight computers have some idea of their descent rate on the way down already; computed as a part of the Kalman filter outputs. The big issue is that with only a barometric sensor in a tumbling airframe, you've got a *lot* of noise in the data, so computing anything like an accurate speed turns out to be a bit tricky. You can see what the output of the Kalman filter looks like by plotting a .telem file -- the telemetry data includes the output of the Kalman filter while the .eeprom file does not. We typically see a range of 50-100 m/s in speed reported this way; that's what AltosUI or AltosDroid report for descent rates, and you may have seen the crazy numbers from that... What we don't have today is a bunch of high-precision descent data. We reduce the data recording rate during descent from 100 samples/sec down to 10 samples/sec to save flash space. This means that most of the data used for the Kalman filter on the rocket during descent is not stored anywhere. This makes doing development pretty hard; without any real data, it's impossible to test a filter on the ground. So, in order to make this work, we'd first need to hack the firmware to capture high-rate descent data from a variety of flights. Then tweak the Kalman filter parameters to generate reasonably smooth speed data. *then* we could adjust the flight software to include a 'hail mary' mode. -keith
pgpMyZXnILNIa.pgp
Description: PGP signature
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
