I’ll write more later (maybe tomorrow), but I hit 17,900ft with an I216 today. I hit a rock on landing and broke a fin, so it doesn’t could as a record flight. Still, I’m super happy with it.
The pressure data look better than yesterday, but I used my backup rocket (very close to the same, but the static port holes are slightly different). The pressure trace looks much better, with only a spike as I transition Mach 1 each way. I did use an apogee lockout, but my guess is that it wouldn’t have been required. I’m grabbing a quick lunch, the starting to prep my other rocket for another record attempt tomorrow. I’ll share more when I can, including the data. Thanks everybody! Bryan Sent from my iPhone > On May 29, 2022, at 11:21 AM, Keith Packard <kei...@keithp.com> wrote: > > "David W. Schultz" <david.schu...@earthlink.net> writes: > >> There are some things in that data that don't make sense to me. >> >> At 9.4s there are spikes in the pressure and acceleration, similar to >> what you see in ejection events. >> >> At 9.47s the state machine switches to the flight_drogue state. (This >> should be the triggering event for the drogue output.) You can also see >> the change in sample rate (100SPS to 10SPS) just after that. The >> velocity at that time is ~240m/s. > > Note that flight state changes are recorded in data records that occur > at a lower rate than the acceleration records, so the spikes in pressure > and acceleration are most probably the drogue charge firing. > >> On the following sample (the last at 100SPS) at 9.48s, the velocity >> drops to ~90ms. There is nothing in the acceleration or pressure data >> that would do that. > > The ground software plotting the data switches from accelerometer > integration to altitude derivatives to compute vertical speed after apogee. > >> The code to change from the coast state to drogue state requires that >> velocity by negative. Nothing else in ao_flight.c changes to that state. >> (That is a global variable so could be changed anywhere.) The recorded >> data doesn't come close to a negative velocity at that time. > > There is no recording of vertical speed, the ground software computes it > by integrating acceleration (during ascent) or differentiating altitude > (during descent). > > In flight, the software uses a Kalman filter that fuses both barometric > and acceleration data to model height, speed and acceleration. Because > the barometric data was so erroneous, that model was far from correct, > and mis-estimated vertical speed badly. > >> Questions: >> >> 1) Why did the state machine change to the drogue state? > > The Kalman estimate of speed went negative. > >> 2) Why is there a discontinuity in velocity at 9.48s? > > The ground software changes its method of computing vertical speed after > apogee. > >> 3) What happened at 9.4s? > > The drogue charge fired at 9.4s, but that wasn't recorded until later. > > I need to fix up the test code which can take the recorded data and run > the Kalman filter on my laptop; that was broken when we made a few > changes to how time is stored recently. With that, we can verify that > the Kalman filter is working as expected. > > Any flight software is full of assumptions and compromises; this > firmware makes assumptions about the quality of the barometric data, and > in this case, those assumptions were not correct. In previous firmware > versions, we ignored barometric data above mach 1, but that caused > problems when the accelerometer had an offset error and the flight was > above mach 1 for a sustained period of time. > > As the accelerometer almost always has a small offset error because of > it's wide range, we decided to re-introduce barometric data above mach > 1, but assign a larger error margin so that more noise didn't end up in > the model. However, it still assumes gaussian error, centered around the > true value (as is required for a Kalman model to function). > > It's the large amount of offset error in the barometric data from this > flight which caused the fault here; that offset slowly slewed the model > to an inaccurate vertical speed estimate. Mix that into the deceleration > measured by the accelerometer and you get an early apogee estimate. > > -- > -keith > _______________________________________________ > altusmetrum mailing list -- altusmetrum@lists.gag.com > To unsubscribe send an email to altusmetrum-le...@lists.gag.com
signature.asc
Description: Binary data
_______________________________________________ altusmetrum mailing list -- altusmetrum@lists.gag.com To unsubscribe send an email to altusmetrum-le...@lists.gag.com
