Ok, I got data this weekend from a launch, but it just reinforced how bad my apogee detecting skills are using velocity.
Here is the background on the launch and the setup. I launched a 3” rocket on a 5 grain KNSB motor to 12,100’ AGL. Overall, a good flight and good recovery. The top speed was 1415 fps (994mph). Apogee was about 750 meters (2460’) from launch and landing was about 1.2km from launch. On board we have our own DIY flight computer with GPS (Ublox-M8), an EM7180/MPU9250 16G accelerometer, an ADXL375 200G accelerometer, BME280 baro, SD Card, 435Mhz TTY radio, and and ESP32 running the show. During the launch phase of flight data is logged at 20Hz to the SD card, but both accelerometers are sampling and integrating at 500Hz. The EM7180 is a “black box” co-processor that is filtering and integrating data off of the MPU9250 and outputs raw, linear (filtered w/gravity removed), and filtered quaternions. I am only pulling the accelerometer and quat data, as pulling the gyro and mag data requires more cycles. I also have two commercial altimeters (a Stratalogger and an RRC3) on board for deployment events.
For this flight, my launch detection was perfect and declared launch within 150ms and I pre-captured accelerometer data into integrated velocity during the confirm period. Apogee on this flight happened at 29.416 seconds, as confirmed by the barometer data and the commercial altimeter deployment (I record aft separation with hall sensors). On the other hand, my normal barometer apogee detection was woefully off at 25.164 seconds (4 seconds early and 230’ low), due to tilt indicators showing 180 degrees and baro seeing a single read <20’ from max (more on that below).
The objective of this flight was to capture accelerometer data and see how integrated velocity using the accelerometer z axis (less gravity) tracked to apogee. Here are a few major observations and questions:
1. Did we really flip over at 10,000 feet? In the first 15 seconds of flight our tilt indicator, coming from the EM7138 board (pitch/roll quat data), indicated we were drifting from 10 degrees to 40 degrees, but when we hit 10,000 feet the indicator says we went full 180 degrees upside down while climbing the last ten seconds and 2000 feet. This rocket is overstable, so it is plausible to me that it might have flipped over in high winds, but I’m also doubting the data from the EM7180 after feedback from John. The rocket on the pad is 3.5 caliber stable and when all the fuel is burned it is 5.75 stable, so a big gust at 10K feet (actually 13K ASL), might flip it over (?). That said, the raw Z data from both accelerometers did not seem to flip, only the “linear Z” data from the EM7180, which uses their kalman filters and feeds the quaternion output. Also, no camera on this flight, but previous flights with cameras correlate to the values I get from the tilt sensor.
2. Significantly Different Readings: We got significantly different readings between the two accelerometers. The EM7180 is mounted with Z up, so all the samples and processing logic are standard. The ADXL375 is mounted with the -Y up, so to get “Z” we multiply Y * -1, and to get “linear Z” (crude version G removed) we just subtract 1g (1000mg) from that. We are sampling/integrating and logging at different rates (500Hz vs 20Hz), so we also capture max, min, and average during the logging cycles. For this launch, we can see that the EM7180 with an MTU9250 maxed out at launch (16g), but the ADXL375 only reported a max of 11g. Also, the ADXL accel data looks like a big “W” during the initial motor burn. I figured it was just anomalous readings, but the average readings also exhibit the “W” shape (see photos). The max peak and the drop to negative look normal and consistent with the EM7180, but how to explain the W shape during burn?
3. Velocity Integration was way off: On this flight we were integrating velocity by using the “linear Z” (gravity removed Z value) for both accelerometers, using the formula v += (z accel) x (rate), where rate = (current microseconds - last microseconds) / 1000000. We also start integrating once z > .2g, before launch and we zero out any false starts. The pre-capture worked well. Velocity is being integrated at 500hz and values logged to SD at 20hz. For this launch, velocity started off looking good for both accelerometers. Velocity between the two peaked within the same milliseconds and started to decline, as expected. But, the ADXL declined rapidly and crossed zero at 9.4 seconds (almost 20 seconds before apogee), while the EM7180 was on a nice slope down when it turned back up to positive around 14 seconds (correlating with the reported 180 degree flip in #1 above). The EM7180 never reached negative. I recognize that the EM7180 data was already compromised when the launch maxed out the Z axis, but then it was compromised again with the rotation (or presumed rotation). Also of interest, the trend lines for the raw z of the EM7180 and the “linear Z” of the ADXL both look directionally correct, as they drop negative and come back to near zero at apogee.
So, I’m not sure if I actually flipped over the last 2000 feet or if I can trust the EM7180 for tilt (pitch/roll) data, but this is a better (sorry, longer) explanation of why I’ve had challenges in the past integrating velocity to get apogee. I’m not flying anything to 100K feet for now, but I’d like to develop a solution that doesn’t completely depend on the barometer now, so when we do it is in the bag. If the accelerometer alone won’t cut it, we can integrate early barometer data with time calculations, and/or GPS data at the top. My GPS has been reliably coming back before or at apogee, so that is encouraging.
Below are a few graphs and here is a link to a spreadsheet with raw data. One last note on the data, after we (think) we detect apogee, we switch to logging every second (1hz), so on this flight the resolution drops considerably in the last three seconds, due to the early apogee call from our tilt logic.
Thanks for any advice.
-Mike
Data export in Excel format:
https://www.dropbox.com/s/zu1ddcx1g9nr3iz/21Nov Export.xlsx?dl=0