Plugger Lockett <[email protected]> writes: > Yea, that's what I'm trying to avoid, hence all the questions. So to > confirm, you're recommending using the primary Apogee channel and then add > to that a 10 second delay in the "Configure Flight Computer" window in the > "Apogee Delay (s)" field? I think what concerns me is that from looking at > the sim the rocket reaches 100k' AGL at ~47 seconds into the flight, but > apogee isn't reached until roughly 83 seconds after ignition. So wouldn't > it make sense to plug in a 36 second delay on the "Apogee Delay" instead of > 10?
No. The flight computer continues to estimate the state of the rocket from the accelerometer, trying to figure out when the rocket reaches zero vertical velocity. That's a matter of integrating acceleration, which if the sensors were perfect, would also be perfect. Because we integrate only the z-axis acceleration, and the airframe is tilting over during flight, that introduces error which makes the computer think the rocket reaches apogee before it actually does. > And given the length of that delay and the fact that we're basically > trying to program around early deploy issues with delays is the main reason > why I thought it might be simpler and more accurate to just configure the > Apogee deployment event as a pure timer event with some logic to ensure the > rocket is well above ground before allowing the channel to fire. I don't know how accurate you've modeled the airframe, but any errors in the motor simulation or CD of the airframe will cause significant errors in apogee estimation. Whether those are worse than the accelerometer integration errors is hard to know. > I was hoping given the superior sensor package in the *Mega boards there > might be some configuration that would mitigate both baro ineffectiveness > above 100k' plus accelerometer only deployment events which seem quite > prone to drift and accumulated errors over time issues. I could easily be > wrong, as my great uncle used to say, "It takes two of me to make one > idiot". Yeah, we don't currently use the 3-axis accel or gyro as a part of the kalman filter, so they don't help with apogee estimation at all. I've started using the tilt angle estimation to look at vertical speed in post-flight analysis to see if that helps at all, but the reality is that we're using a 105g accelerometer for vertical acceleration with 10 bits of resolution, which means about 1/10g per bit. So, a single bit error in the acceleration measurement integrated over 10 seconds yields a 10m/s mis-estimate in speed. Over 100 seconds, you can end up with a 100m/s mis-estimate, which is 10 seconds off in apogee estimation. Oh, one thing that is absolutely critical -- recalibrate your accelerometer before flight; they tend to drift over time. Make sure you're using AltosUI 1.8.6 for all configuration and calibration as 1.8.5 had bugs when dealing with flight computers configured for 'antenna-down' operation. Again, small errors in calibration yield large potential errors in apogee estimation. Which ever nominal apogee detection method you use, I suggest programming a second channel to fire right at estimated apogee if the altitude is below 30km so that a non-nominal flight will deploy the drogue as soon as possible. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
