GPS position of the flight control board, as received over 433mhz radio by a groundstation up to 2km away. Data collected so far indicates we have the link budget for over 20km of range.
As Avionics lead for AerospaceNU's Project Redshift, I've been involved with a ton of different software projects for our our rockets, including radio and bluetooth driver and communication protocol development, and Kalman filter for detecting rocket events.
helped develop and test the radio driver for the 433mhz and 915mhz radios on our flight control board and groundstation, as well as the groundstation software to decode and forward packets to our GUI, in embedded C and C++ for STM32 microcontrollers. A TI CC1120/CC1200 low-power transceiver was used, and on the 915mhz radios a CC1190 range extender (Power Amplifier + Low-Noise Amplifier) is used. I've been interested in digging further into RF since 9th grade, when I got my Ham technician's license to fly model aircraft with 5.8ghz video transmitters, but haven't gotten to really dig into how packet radios work before this project. I had a ton of fun digging through the radio datasheet to understand what each register did, learning how modulation worked, and how to configure the radios to reliably send data.
When I picked up the project, the radio driver worked only with CC1120s with a relatively low symbol rate of 1.2kbps. I helped debug and test the software driver and radio configuration settings to ensure reliable wireless communication of important information like rocket latitude, longitude and altitude to our groundstation, including a 2km range test across the Charles river, the results of which are shown above. A full test on a high-powered rocket (with an expected apogee of 700m or so) will occur around 2/19/2022.
Flight Control Board (top) and Groundstation (bottom), designed by other team members. Radio transceiver seen on the bottom right.
My other software work on the flight control board includes a driver to allow communication between the Bluetooth chip (blue, middle left of the top board above) and the STM32 MCU. This included defining the communication format, learning about DMA and UART on STM32s, and working with team members to ensure the code on the MCU and Bluetooth chip worked together. Bluetooth will be used to communicate with our line cutters to forward data over the long-range radio and command deployment events, as well as with a phone for viewing at-a-glance information like battery voltage and flight state without a full groundstation.
The driver solution we settled on for now uses DMA to detect the UART line between the two chips going idle, then uses a callback to enqueue that data into a circular buffer for our code to parse. This does involve copying up to 100 bytes inside an interrupt, which is less than ideal. Future driver revisions might investigate buffering incoming data in a circular buffer, to avoid this copy.
Kalman filter run on a flight where the rocket kicked over due to casing burnthrough
One of my first projects for the flight control board was a simple 2-state Kalman filter for estimating rocket vertical position and velocity. On some flights, the barometer pressure readings would have large spikes (which tend to happen with large wind gusts, large angles of attack, or transsonic/supersonic flight), which confused our previous simple velocity checks for deployment. A moving average or other filter would work, but we'd also be introducing a lot of time delay. For this reason a Kalman filter, which can interoperate readings from multiple sensors, was used.
The system we used is a simple double-integrator, with states [position, velocity], inputs [upward accel] and outputs [position]. We use accelerometer measurements to project the state forward (Fancy words for saying velocity += acceleration * dt and position += velocity * dt + 1/2 * acceleration * dt^2), and then the onboard barometer is used to update the position and velocity. This fuses readings from our barometer and accelerometer, making a filter that's robust to erroneous altitude reading that don't physically make sense based on the accelerometer data. We can do this by weighting our trust in each sensor; for our rocket, we chose to trust the state estimate much more than our barometer.
The graph above and video below shows this in action -- the rocket tipped into the wind just before motor burnout, but the position kept increasing and the velocity stayed positive despite the graph of position and (dPosition/dt) going crazy, which is more representative of what our rocket is actually doing.
Video of the flight that generated the data shown in the graph above.
