Closed TomD53 closed 1 year ago
Thank you. I'm pushing the first draft, will improve based on those papers once I read through.
You mentioned a "state engine" in your code. There is already a design for this in src/main.cpp
🙂
I see what you mean now in having a separate, smaller state engine within the Apogee detector. We can probably include this in the same file so everything is in one place
Moved your code to the lib/EventDetectors
folder in 2df0f77
To be clear, the reason for doing this is stated here in the PIO docs https://docs.platformio.org/en/stable/plus/unit-testing.html#shared-code
We recommend splitting the source code into multiple components and placing them into lib_dir (project’s private libraries and components). Library Dependency Finder (LDF) will find and include these libraries automatically in the build process. You can include any library/component header file in your test or program source code via
#include <MyComponent.h>
The MS5607 pressure sensor has an operating range of 10 to 1200 mbar, and so its minumum pressure value is 1000 pascals.
According to the U.S standard atmosphere, the pressure at 30KM altitude is 1197 pascals. Therefore 30KM is the maximum height at which the barometer would operate.
Another source that proves this is the Traveler IV whitepaper. The team also used the MS5607, and it maxed out at an altitude of 100000 feet which roughly equals 30KM
Therefore we can only use barometric apogee detection up to a height of 30KM. Above this altitude we must use other methods that involve the accelerometer, and would require a lot more testing. Therefore please clarify the apogee @ZefyP @Jacob-Lawson
as discussed with @Phylex on 14/04/2022
Apogee would be considered detected if all three conditions below are met:
After further research and discussion, it is clear that the High-G accelerometer should be sufficient to detect apogee
Apogee detection using the high-G IMU would work as follows: 1) Whilst the rocket is still on the pad, the flight computer measures the force of gravity acting on the rocket by sampling the Z axis of the accelerometer. 2) Following launch, the computer integrates the Z-axis velocity values (longitudinal to the rocket) and applies the gravity offset to each sample. 3) When the integral of acceleration goes below 0, this means that the rocket reached apogee
References: https://ntrs.nasa.gov/citations/19730018164 (page 3)
(we love referencing reddit conversations) https://www.reddit.com/r/rocketry/comments/lu8ua3/how_would_you_detect_apogee_of_a_space_shot/ https://www.reddit.com/r/rocketry/comments/gy8hg9/integrating_accelerometer_for_apogee/
The apogee detector will take the same structure as the launch detector, with a
run()
function that returns true or false.Listed below are three papers which discuss methods of apogee detection https://aws1.discourse-cdn.com/arduino/original/3X/a/3/a37bb6242fc5a9ada7025bd1ef64440a9d1c19f0.pdf https://cnx.org/exports/36fdaf81-f17c-4325-a90b-ffa07e2da5a6@1.1.pdf/digital-detection-of-rocket-apogee-1.1.pdf http://davesrocketworks.com/rockets/rnd/2002/KalmanApogee.pdf
The above examples all use multi-dimensional kalman filters to determine an estimate of vertical position. In my opinion it will be difficult for us to design and test such a filter in the short time frame available.
It is simpler to use just a barometer to detect apogee. However, this comes with some challenges as there are possible pressure fluctuations as the rocket surpasses the speed of sound. Mentioned in this forum post is an interesting approach to solve this issue.
We can integrate the accelerometer values to obtain a rough estimate of when the vehicle is traveling at less than Mach 1. Following this, we can then enable the apogee detector, as it is then less likely to fail.
Before work starts on this part of the system we need to have a group discussion to confirm that this is a sound approach @abayomi185 @Phylex @ZefyP