Show HN: I Put a Raspberry Pi in a Rocket(johnjonesfour.com)
johnjonesfour.com
Show HN: I Put a Raspberry Pi in a Rocket
https://johnjonesfour.com/2020/10/04/model-rocket-telemetry-part-2/
42 comments
Good idea! I'd want to do some research and simulations to figure out how much of an altitude hit I'd take with the added weight of an additional controller.
This[0] is the ESP32 module that I keep on hand. The seller doesn't list any information that would help with your simulations, but the photos can give you a rough idea of the physical size. Other than a bare ESP32 module[1] I don't think I've seen a physically smaller ESP32 board.
You can program these with the Arduino IDE, so they're quite easy to use and there are tons of libraries available for interfacing with sensors, etc.
[0] https://www.aliexpress.com/item/32834982479.html
[1] https://www.aliexpress.com/item/1005001271041790.html
You can program these with the Arduino IDE, so they're quite easy to use and there are tons of libraries available for interfacing with sensors, etc.
[0] https://www.aliexpress.com/item/32834982479.html
[1] https://www.aliexpress.com/item/1005001271041790.html
I've used TinyPICO Esp32 modules. They're even smaller than D1 Minis! They lack the metal cover, though I don't quite know what that's for (mumble EMI?).
Thank you!
I'm rather a fan of IZOKEE Development Board for ESP8266 because you get Wifi / WLAN built-in but yeah, ESP is cheap!
Looks like the pocketbeagle has two 'programmable real-time units' PRUs @200MHz which could be used to run the sensors while the main CPU handles video+I/O. Could be a good option for 'multithreading' without having to insert another module. (caution: I've kept to the rpi for weird little side projects, so haven't actually tried this. Double super big caution: Never add hardware before profiling your current system to figure out where the bottleneck is... it might just be a matter of changing your 'main loop' a bit.)
http://beagleboard.org/pru
http://beagleboard.org/pru
Curious what other boards you considered?
You mention using Adafruit libraries & working in Python. The Adafruit feather boards focus on low power situations & some include battery slots. https://www.adafruit.com/feather
You mention using Adafruit libraries & working in Python. The Adafruit feather boards focus on low power situations & some include battery slots. https://www.adafruit.com/feather
I looked into the Feather for a bit, but my experience with the Pi is much stronger, so I felt more comfortable working with that after I determined the battery I'd need to power it wouldn't be too heavy to lift.
BeagleBoard is similar to RaspberryPi, but focused on embedded robotics vs desktop PC alternative. The PocketBeagle is similar to a Pi Zero. Fully open source hardware. Smaller community though, so harder to find examples/capes.
http://beagleboard.org/boards
Artemis seems to be Sparkfun’s new line of Feather-compatible boards. They target a pro-level audience vs Feather’s edu audience. The OpenLog Artemis looks interesting for logging telemetry. https://www.sparkfun.com/news/tags/artemis
Artemis seems to be Sparkfun’s new line of Feather-compatible boards. They target a pro-level audience vs Feather’s edu audience. The OpenLog Artemis looks interesting for logging telemetry. https://www.sparkfun.com/news/tags/artemis
Thanks!
> The software performed well, but I'd still like to increase the data capture rate. There are Adafruit libraries for the components I'm using in C++, so I'm considering rewriting air.py in C++, but I'd really love it if someone talked me out of that.
Would that really improve data capture ? How much throughput is it captured that python can't keep up (is that even the right kind of questions) ?
Would that really improve data capture ? How much throughput is it captured that python can't keep up (is that even the right kind of questions) ?
I'm not totally certain. I could do a quick C++ POC to see if that improves throughput a bit, but I've got doubts. My other thought is that the SPI interface only can go up to a certain speed. If anyone has deeper knowledge of that protocol I'd love to hear their thoughts.
You should try doing some profiling on each part of your system and find where the bottlenecks are.
anecdotally, I built a telemetry system for an electric boat with very similar architecture (RPi, python script for telemetry collection, 433Mhz telemetry radio) and were pretty easily able to push on the scale of ~100 data points at 100hz. Part of that was efficiently (and manually) packing each data point into the minimum space required, pretty much just the raw data and a checksum. But from what you’re describing I definitely think you can push your system further without rewriting significantly.
anecdotally, I built a telemetry system for an electric boat with very similar architecture (RPi, python script for telemetry collection, 433Mhz telemetry radio) and were pretty easily able to push on the scale of ~100 data points at 100hz. Part of that was efficiently (and manually) packing each data point into the minimum space required, pretty much just the raw data and a checksum. But from what you’re describing I definitely think you can push your system further without rewriting significantly.
Really helpful! Thank you! Would you happen to have your source code available anywhere for me to take a look?
Yeah, this is the source code: https://github.com/URSolarSplash/Telemetry-Server. The version uploaded there is transmitting at ~4hz but we cranked it up to a much faster transmit loop when necessary. A few interesting files:
The main server loop: https://github.com/URSolarSplash/Telemetry-Server/blob/maste... The device implementation for our hand-rolled serial protocol: https://github.com/URSolarSplash/Telemetry-Server/blob/maste...
In classic "college engineering project" fashion, the project is rather disorganized and very specialized to the technology we used on our boat at the time. Our telemetry server had an in-memory cache of latest data points which were relayed over serial with all the telemetry nodes. We used the telemetry system to carry throttle and all other control signals for the boat. We replicated all the data points to a secondary server running on a shore computer, so we had two separate sources of data logs.
I will note that since building that system, my philosophy has changed several times -- Today, I would likely not roll our own telemetry protocol, instead using something like https://msgpack.org/index.html or going all-in and using ROS on a larger project.
If you're interested in chatting more, feel free to send me an email (my username @ gmail). It's always great to see others go through the same experimental process with telemetry and data collection systems! (Also, check out bps.space on youtube, who has done a lot with telemetry on model rockets.)
The main server loop: https://github.com/URSolarSplash/Telemetry-Server/blob/maste... The device implementation for our hand-rolled serial protocol: https://github.com/URSolarSplash/Telemetry-Server/blob/maste...
In classic "college engineering project" fashion, the project is rather disorganized and very specialized to the technology we used on our boat at the time. Our telemetry server had an in-memory cache of latest data points which were relayed over serial with all the telemetry nodes. We used the telemetry system to carry throttle and all other control signals for the boat. We replicated all the data points to a secondary server running on a shore computer, so we had two separate sources of data logs.
I will note that since building that system, my philosophy has changed several times -- Today, I would likely not roll our own telemetry protocol, instead using something like https://msgpack.org/index.html or going all-in and using ROS on a larger project.
If you're interested in chatting more, feel free to send me an email (my username @ gmail). It's always great to see others go through the same experimental process with telemetry and data collection systems! (Also, check out bps.space on youtube, who has done a lot with telemetry on model rockets.)
I would have thought that the max SPI speed on the Pi is probably faster than your peripherals can deal with. Your bigger problem is system interrupts which might cause discontinuous capture. The speed is derived from the core clock which can go to well over 100MHz.
Control of the bus is probably handled by kernel drivers anyway, so you're not doing much overhead with Python.
Also make sure you use hardware video encoding. I don't know if the picamera library does, but worth checking. I normally use OpenCV with the omxh264 encoder. You could also run a gstreamer pipeline in parallel with your air code.
Edit: looking at you pipeline you use the lsm303 which is I2C not SPI? So that's 400khz max. And the Bosch BMP something which isn't designed for rapid measurements - even if it's over SPI they output of the chip will be your limit there.
Control of the bus is probably handled by kernel drivers anyway, so you're not doing much overhead with Python.
Also make sure you use hardware video encoding. I don't know if the picamera library does, but worth checking. I normally use OpenCV with the omxh264 encoder. You could also run a gstreamer pipeline in parallel with your air code.
Edit: looking at you pipeline you use the lsm303 which is I2C not SPI? So that's 400khz max. And the Bosch BMP something which isn't designed for rapid measurements - even if it's over SPI they output of the chip will be your limit there.
Donkeycar might give you some ideas... it logs still images with a RaspberryPi camera module. The frames can be stitched into video afterward (though maybe lower frame rate/resolution than what you want). If it crashes, logged frames are on disk.
Thanks!
400 feet doesnt seem very high (to a bystander like me). I made a 19mm diameter sugar rocket with my kids, tied it to a bamboo stick for stability and electrically started it. The thing went so high that we visually lost sight of it.
Is this because my power to weight ratio is so much lower?
Is this because my power to weight ratio is so much lower?
If you enjoy fetching your rocket from a tree you can go higher.
Back when I was involved with some of the higher power aspect of the hobby(J/K/L/M class) we'd go our to the desert where retrieval was a lot easier. Even out M class stuff rarely topped 1500ft.
Minimum diameter can go much, much higher but usually your flight waiver has a fixed ceiling that you don't want to exceed.
Back when I was involved with some of the higher power aspect of the hobby(J/K/L/M class) we'd go our to the desert where retrieval was a lot easier. Even out M class stuff rarely topped 1500ft.
Minimum diameter can go much, much higher but usually your flight waiver has a fixed ceiling that you don't want to exceed.
High Power = H Impulse and above. Also, if your M class flights rarely went over 1500ft those rockets must have been HUGE. I did my L3 on a baby M (M2250 - 9.4% M) and went nearly 20k ft AGL and Mach 1.9.
I'd like to eventually start working with those more high-powered motors, but for a first flight I wanted to keep things manageable.
... and I also had a 400 ft limit with my permit.
... and I also had a 400 ft limit with my permit.
Honestly a little surprised you need a permit for the standard engine power stuff. It's been ages since I've been involved with the hobby but we used to not need one until we stepped above E class.
Bigger stuff is fun but also hits the pocketbook a little bit more.
Bigger stuff is fun but also hits the pocketbook a little bit more.
I'm in the DC area where anything that goes up in the air is taken very seriously.
Different aerodynamics probably had a little impact but it's mostly just a much better power to weight ratio. It helps that you didn't launch a raspberry pi and battery :)
That's exactly it. This thing was pretty heavy with a battery, Pi, sensors, mounting components, etc. I used an Estes D12-5 engine, which is fairly powerful but there are wayyy more powerful model rocket motors out there that I'd like to try in the future with this.
If you’d like inspiration for something larger, check out a rocket[0] a friend and I designed/built/launched earlier this year. Basically a combination of a drone and a rocket, rocket part takes it up, drone part handles the landing. I can share a lot more photos, videos, and design characteristics if interested (contact info on my profile page).
[0] https://www.instagram.com/p/B87uohIJcik/
[0] https://www.instagram.com/p/B87uohIJcik/
Thanks for clarifying.
As a total noob I was staggered by those little sugar rockets, as soon as the thing left the ground I thought "uh oh, what have I done?"
Haha that's awesome. Do you have a link for a good tutorial on them?
Hypothetically -- if you just drive a boat out to international waters, can you launch a mini-rocket into space without any legal issues?
The FCC doesn't tend to agree: https://www.theverge.com/2018/12/20/18150684/swarm-technolog...
I'm still somewhat annoyed that didn't lead to a complete blackballing of Swarm. A <$1M fine for a VC-funded space start-up actually doesn't seem that large, and I bet they probably saved a bunch of money by not following the proper procedures anyway, which lowers the actual impact of that fine anyway. It sets a bad precedent for other New Space companies that might be looking for a shortcut.
Yeah taking the Uber route on regulation compliance does not work for space travel.
On what grounds do they punish you? Why do FCC laws apply to international waters?
We're using a ESP32 as the "brains" of a Rocket tracker. Having Wifi to confirm GPS lock is pretty nice.
I flew it yesterday with a Quectel L-80/MediaTek 3339 chipset, seems to have performed fairly well. https://forum.ausrocketry.com/viewtopic.php?f=32&t=6547
I flew it yesterday with a Quectel L-80/MediaTek 3339 chipset, seems to have performed fairly well. https://forum.ausrocketry.com/viewtopic.php?f=32&t=6547
The company that sold the first generally available "Personal Computer" started as a club that got into telemetry rigs for model rockets.
Hey I know this guy! Nice work, John.
YITBOS
YITBOS
Hey man! I hope you're doing well! Maybe I'll paint the next one green and white!
(For the rest of the world who's confused by this: college fraternity colors.)
(For the rest of the world who's confused by this: college fraternity colors.)
Hi, do you have technical details for that? I don't really see any.
>There must be a buffer that holds a certain amount of camera footage before saving it to disk. Because the battery disconnected in-flight, no flight video saved. I'd like to figure out how to write video data more frequently in case the battery issue happens again.
Disk or SD card?
I'm seeing RSSI. What signal are you measuring the strength of? Given that you talked about problems losing footage and buffering, I suppose you are not transmitting in near real-time but instead save to disk and get the data afterwards? Given that you have a link, why not send the video stream to your ground station directly?
I worked with Raspberry PI to acquire data from fitness trackers with Bluetooth Low Energy (BLE), then transmit using 4G dongles. We serialized the data into protobufs and used Kafka in the backend. We also used the setup for other things.
>The software performed well, but I'd still like to increase the data capture rate. There are Adafruit libraries for the components I'm using in C++, so I'm considering rewriting air.py in C++, but I'd really love it if someone talked me out of that.
I don't think you have to re-write anything in C++. I'm pretty sure the bottleneck is not the language.
>There must be a buffer that holds a certain amount of camera footage before saving it to disk. Because the battery disconnected in-flight, no flight video saved. I'd like to figure out how to write video data more frequently in case the battery issue happens again.
Disk or SD card?
I'm seeing RSSI. What signal are you measuring the strength of? Given that you talked about problems losing footage and buffering, I suppose you are not transmitting in near real-time but instead save to disk and get the data afterwards? Given that you have a link, why not send the video stream to your ground station directly?
I worked with Raspberry PI to acquire data from fitness trackers with Bluetooth Low Energy (BLE), then transmit using 4G dongles. We serialized the data into protobufs and used Kafka in the backend. We also used the setup for other things.
>The software performed well, but I'd still like to increase the data capture rate. There are Adafruit libraries for the components I'm using in C++, so I'm considering rewriting air.py in C++, but I'd really love it if someone talked me out of that.
I don't think you have to re-write anything in C++. I'm pretty sure the bottleneck is not the language.
Hi! Here's the post where I document my build process: https://johnjonesfour.com/2020/10/03/model-rocket-telemetry-... Happy to answer any questions about that!
For the video issue, I need to do some homework and figure out what the issue is. It's just speculation at this point. Yes, I am saving the Pi's microSD card.
Telemetry transmission and reception is done by an Adafruit RFM95W, and I'm using this library to interface with it: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x. It handles data just as Python byte arrays, and I only transmit data from the senors (in real time) but not video. I use that library to determine RSSI as well.
Thanks for the note on the language idea. Like I said in the post, I want to be talked out of that :-)
For the video issue, I need to do some homework and figure out what the issue is. It's just speculation at this point. Yes, I am saving the Pi's microSD card.
Telemetry transmission and reception is done by an Adafruit RFM95W, and I'm using this library to interface with it: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x. It handles data just as Python byte arrays, and I only transmit data from the senors (in real time) but not video. I use that library to determine RSSI as well.
Thanks for the note on the language idea. Like I said in the post, I want to be talked out of that :-)
At first, I had some questions about why you'd use a Raspberry Pi for this, but once I realized that video was being recorded as well it made more sense. I'm quite impressed.
For increasing sample rate, it really depends on where the problem is. The Pi is recording video and managing the sensors - are these two tasks competing with each other?
Perhaps using another controller to deal with the sensors and telemetry transmission could help (if contention is actually the problem). Something like the ESP32 in the D1 Mini form factor would easily fit in the rocket. If I was doing this, I'd ignore the ESP32's onboard radios and use the LoRa module since it seems to work quite well in this application.
[0] https://johnjonesfour.com/2020/10/03/model-rocket-telemetry-...