Hi Keith. > 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.
That's a very sensible comment. Mike's last N5800 MD flight compared to his before flight sim was with 95% accuracy, so there is some reasoning behind the "trust the sim" logic. > 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. That's pretty much in line with other comments I've read regarding accelerometer drift, only much more detailed! Thanks for taking the time to properly explain the issue. > 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. Thanks for the heads up. I put the EasyMega in the mail for Mike on Friday morning so I'll ensure he does a calibration before flight. > 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. Yep, we've got that one squared away! Jim Jarvis has been providing some assistance regarding our config options (and Kip as well) and he was a recommending a channel configuration for this purpose as a responsible backup configuration. In theory I completely agree; in application if something goes "squirrely dan" during boost or coast I'd be impressed if the nose cone *didn't *come off! In more general comments, going through this process has definitely opened my eyes when it comes to attempting to get a apogee event to accurately occur above 100k' MSL. It seems that most flight computers rely on Baro deployment, and that makes sense, most flights sit well below 100k' and therefore don't require anything other than barometric sensing of apogee to provide an accurate deployment event. But for flights above the range of the baro sensor there's no real solution in use to easily determine apogee reliably. As you detailed above, accelerometer errors accumulate and become a pain. GPS is good from an accuracy perspective but relying on GPS lock for apogee deployment is risky and realistically is only valuable from the 31,000 meter to 50,000 meter range anyway (at least in reference to uBlox that appears to be the case). This brings me back to magnetic apogee. I had a look at the ZeptoMag Apogee detector that can be found here. https://zeptobit.com/zeptomag-with-screw-terminals.html That unit sports a MAG3110, details can be found here. https://www.nxp.com/products/sensors/magnetic-sensors/magnetometers/high-accuracy-3d-magnetometer:MAG3110 A few specs 80 Hz maximum sampling rate I²C interface 400 kHz Full-scale range ±1000 µT And on the *Megas, you appear to be using the Honeywell HMC5883L sensor. https://www.adafruit.com/product/1746 A few specs. I2C interface 160Hz max data rate Range of -8 to +8 Gauss (±800 µT) So roughly the MAG3110 has half the sampling rate but a slightly larger range when compared to the Honeywell chip in the *Megas. I can't comment about whether the Honeywell chip would be suitable for a simple magnetic apogee detector but I can't help but think they would given the roughly comparable chip specs. And I can't think of anything more simple or accurate for detecting apogee above 100k' MSL than with magnetic apogee detection. The only possible failure modes that I can envision is interference from transmitters (easily tested) and the rocket tail sliding and never tipping over at apogee ( I consider this a borderline impossibility with flights over 100k'). Just a thought as it might be simpler to implement that when compared to some of the other avenues you've been investigating. Finally, thank you so much for you assistance in all of this work. I can't thank you enough. Regards, Andrew Hamilton On Fri, Aug 31, 2018 at 11:33 AM, Keith Packard <[email protected]> wrote: > 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 >
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
