Hand tools and fabrication machines
I decided to try model rocketry due to my passion about rockets and space exploration. It is technically challenging and financially affordable, although the latter may depend on where you live.
There was something missing in model rocketry though. One can find tons of information about aerodynamic simulation, design and motor propellants even if there are many rockets and motors commercially available.
What one cannot easily find is an embedded system that can gather information and send it in real time to a base-station such as a real rocket must have. There are of course altimeters and cameras that are specifically designed for model rocketry, but the data is only available if/when the rocket lands intact.
The objective of this project is to fill this gap in model rocketry by implementing a system connecting an Inertial Measurement Unit (AltIMU-10 v5) and a camera (RPi Camera) to a board capable of sending all this data through WiFi (Raspberry Pi Zero W).Hardware Implementation
The first step in implementation is to connect the RPi Zero W to its camera. It is quite easily done, but the flat cable for the RPi Zero is sold separately.
Once the camera is connected, the AltiIMU-10 I2C and power pins have to be connected according to the diagram below. Note that the VDD and SA0 pins of the IMU are open, since there are no other peripherals to power and only one board is connected to the I2C bus
There are two options to power the RPi: micro USB input or the 5V and GND pins. I recommend the latter, since a micro USB cable is quite heavy and will limit the rocket apogee.
The 5V line has to come from a battery. I recommend Li-Ion or LiPo, since they have the highest energy density among commercial batteries. If you have a small rocket, you will probably need a round one to fit inside. However, do not make the mistake of using a 18650 cell as I did, as they are too heavy for a small rocket. You can find lighter round cells in hobby stores.
For regulation, I still think the best option is to use a Li-Ion/LiPo 5V regulator of a DIY power bank. Try to search for "5v 1a boost charger" to find these boards. Mine is based on the HT4921E, but there are similar ones using the TP5410.
All code and scripts used in the project are available in the repository linked in the Code section. Note that there is a lot of open source code in the repository, so make sure to follow their licensing guidelines should you use/modify them.
Data is gathered by two binaries:
- raspivid for video; selected mode was "1640x922 with full FoV" automatically upscaled to 1080p
- altimu10-ahrs for IMU data, slightly modified to also pick altitude and temperature from the LPS25H barometer.
A C++ code called raspivid_tee.cpp (main repo) was kindly developed by Mark Setchell and slightly tuned up for my project. It is similar to the standard Linux tee, but the FIFOs are non-blocking and managed by independent threads. As shown in the diagram below, this prevents the UDP socket from messing up the data written to SD.
Unfortunately, there is still a pending issue of video files being overwritten when RPi reboots in-flight. I have not tackled this problem yet, but there are a couple of possible solutions:
- Segmenting video in multiple files to prevent the whole video of being overwritten
- Flushing file descriptor frequently to prevent huge block surges during power-down and other instabilities
- Signaling mechanism to kill raspivid and raspivid_tee properly without corrupting the files.
Causes of RPi rebooting during flight are not known. They may be related to battery or piezoelectric crystal behavior under acceleration.
altimu10-ahrs opens two file descriptors: one for UDP transmission and the other to transfer the data to RPi SD card. There is no need for a separate process managing FIFOs, since data bandwidth is pretty low.
To connect my Linux machine to the rocket, I used a WiFi router. It seems a good idea though to modify your RPi Zero W to use an external antenna (U.FL mod). The signal intensity of the PCB antenna is not great.
Once the connection has been established, gstreamer listens to the UDP video port and as soon as enough frames are rebuilt, the video is shown as in the diagram below.
I regret not having implemented a backup of the video to my Linux machine disk. That would have mitigated the loss of data on my RPi SD card.
The altimu10-gui python script receives its data from a netcat process connected to the respective UDP datagram port. A GUI shows the orientation, altitude and temperature of the rocket in real time as in the diagram below. The IMU payload is also saved on disk.
Unfortunately, I got only one try where video and IMU data are available. The problem concerns the overwritten video/IMU files as I already explained.
I have overlaid the IMU GUI to the video from RPi Camera: