Introduction: Radio Telemetry for a Model Rocket
Model rocketry telemetry is nothing new. Amateurs have been stuffing electronics in rockets since the beginning of the hobby. A programmable micro-controller coupled with a low-power radio, however, allows us to take the hobby to a whole new level. What makes this project notable is:
- Wireless data transmission allowing in-flight monitoring or post-flight data downloading without the need to physically access the on-board hardware.
- Constructed from easily available open source hardware and software, allowing anyone with modest soldering and programing skills to put together a configuration to acquire and record any data they desire. No custom PCBs, chip programmers, or toolchains to setup as in my last well received, but little followed Instructable (https://www.instructables.com/id/Buggy-A-Crafty-Programmable-LED-Creature/)!
Details, in brief:
A 50 gram, on-board micro-controller collects pressure and acceleration data and then transmits it on 915 mHz using a Hope RM12 module at a rate of about 50 reading per second. A separate micro-controller connected to a laptop via USB receives the data and transfers it to a serial port. A software program running on the same computer graphically displays the data as it is collected, and also saves it to disk for further analysis. Piece of cake, right?
Step 1: Hardware
The heart of this system is an Arduino compatible JeeNode micro-controller designed by Jean-Claude Wippler from the Netherlands (http://jeelabs.org/ ). It contains an Atmel Atmega 328P, which has more memory and runs faster than my first computer (a Sinclair ZX-81). The JeeNode has a significantly smaller footprint than a standard Arduino, similar to Lady Ada’s Boarduino, but also has an integrated Hope RM12B wireless module. Additionally, the JeeNode has the I/O pins grouped in to four “Ports” to facilitate standardizing sensor connections, and runs at 3.3V. JeeLabs has developed a number of sensor/breakout boards, called "Plugs" using the IC2 interface, meaning they can be piggybacked on to the same port, making the JeeNode extremely extendable. In addition to the hardware, JeeLabs provides a software library making the use of ports and assessing sensor data very easy.
I used the following hardware, available in the U.S. from Modern Device (http://shop.moderndevice.com/ ) or elsewhere from JeeLabs (http://jeelabs.com/ ).
*JeeNode Kit ($22.50) (a.k.a. “Transmitter”)
*JeeLink Module ($36.50, assembled) (a.k.a. “Receiver”)
*JeeLabs Pressure Plug ($21.95) Bosch BMP085 barometric pressure and temperature sensor.
*USB BUB Board Kit ($14.00) or FTDI programming cable
*JeeLabs Gravity Plug ($20.00) BMA020 3-axis accelerometer sensor
*JeeLabs Memory Plug ($9.50) (1 x 128KB STMicroelectronics M24M01 EEPROM)
For the full setup, you are in for about $125 + shipping. You could fly with just a Pressure Plug for altitude. You will also need batteries and a holder (I got mine at RadioShack). Consider this a small investment in your continuing Maker education. You only need one JeeLink and USB BUB. You can add or reuse as many JeeNodes as projects you dream up (or just type “Arduino” in the Instructables search box). The sensors and Port library can also be used with a standard Arduino with some effort.
I do not work for or have financial interest in JeeLabs. In fact, I would have a hard time pointing to the Netherlands on a map. I have, however, worked with Jean-Claude’s tech and find it well engineered, documented, and supported. Those are three requirements to get my hard earned money in my pursuit of hobby. I hope this sends more his way.
Makers Solder :
Each of the kits have instructions online and require some soldering. The sensors need headers soldered depending on how you position them. If you are unsure of your soldering skill, check out https://www.instructables.com/id/How-to-solder/ . If you want to see what building the kit involves, check out http://jeelabs.org/2010/09/26/assembling-the-jeenode-v5/ . Once you build this, you can definitely claim you can solder. Hacking is all about mad skills.
In my hardware configuration for the Transmitter, all the IC2 sensors are connected to Port 3, and I have a single LED and resistor hooked to the Port 4 digital & GND lines. Any variation from this layout can be easily accounted for in the Transmitter program by changing the Port numbers. I’m powering the JeeNode using 2 x AA in a plastic RadioShack battery holder. The flight assembly weighs in at about 50g, of which a little less than half is battery. A light-weight lithium ion battery would be ideal for this, but because of the near constant radio operation, it would take a bit more than a CR2032 coin cell (yes, I tried).
Step 2: Software
[Updated October 2015]
Since this Instructable was written (February 2011!), both Arduino and the JeeLabs software have progressed, leaving my code useless for a current installation. There is hope however, and that is installing the earlier versions to make this work. This can be done separately from any current Arduino installation you have.
- Download Arduino Version 22 from https://www.arduino.cc/en/Main/OldSoftwareReleases...
- Download the attached Ports.zip file.
- Extract Ports.zip to a folder, and move it to the .../arduino-0022/libraries folder.
- Run Arduino.exe from the .../arduino-0022 folder.
- The programs for the transmitter and receiver are located under:
- [File] -> [Examples] -> [rocketry_sketches_01]
- If they don't show up, you probably do not have the Ports library installed correctly. Go back and double check (You have to restart Arduino if changes are made)
To graph and save the data on the computer, I’m using Processing. It is based on the same underlying software as Arduino, but is geared to graphical output. The language and syntax is very similar, and if you’ve done either, picking up the other is quick and easy. It also has a lot of interesting example programs installed. Download Processing from (http://processing.org/download/ ). I’m using Processing version 1.0.9.
- The sketch for graphing is located in the Ports library (just for my convenience):
Step 3: Data Acquisition
LAUNCH VEHICLE :
For this project, I’m using a water powered soda-bottle rocket from Make Volume 5 (http://makezine.com/05/rocket/ ). Don’t laugh. As you will see from the data, these have some remarkable thrust and speed while being safe enough to fly in the neighborhood park. And water is still pretty cheap around here at least, especially compared to pack of Estes motors and igniters. The rocket and launcher were easy to build, used commonly available materials, and have been robust in operation, all top Maker traits. This setup has served me well over several years, and I am a regular participant at a scout camp where I use them to sneak in some physics and math while having some fun. This year will add yet another level of interest!
Each of the uploaded Arduino sketches can be tested using the serial monitor for the port they are connected to (connect the Transmit JeeNode via the USB BUB or FTDI when uploading or testing). Use the same key commands for all three points (Transmitter, Receiver, and Processing):
“c” - clears the non-volatile data memory and zeros out the sensors. The rocket should be in the correct orientation for launch. Processing or Receiving should report “0, 0, 0” in the serial screen, where as Transmitter will display the information about the sensors. The Transmitter LED should flash once.
“w” - (as in “write”) starts or stops transmission and recording of data. The LED on the Transmitter will be lit when recording and a message indicating status displayed on the serial. Receiver and Processing will show a stream of data start on the serial and Processing will start to graph the data. Press “w” again to stop the data flow or it will just keep collecting until the memory is full (~2100 readings, or about 42 seconds).
“r” - (as in “replay”) plays back the recorded data from the non-volatile memory (if used). This will be essentially identical to the flight data, but will also contain any data that was lost in transmission if your rocket went out of range or experienced interference.
My launch sequence has been to do a clear, write, and read sequence prior to putting the rocket on the pad to make sure everything is powered and functional (see video). I then set up the rocket on the pad and pressurize it. With Processing running, send the clear signal “c”, followed by the write signal “w”. As soon as data starts coming in, start your count down! Processing is tracking the last 400 readings and will show the minimum and maximum acceleration, altitude, and speed. Once the rocket lands, hit “w” again to stop the data flow. If you think you lost data during the flight, bring the Transmitter near the Receiver and hit “r” to retransmit the data. The reading are saved to a comma separated values (.csv) file in the Processing sketch “Graphing/data ” folder with a time identifier in the file name. Lather, rinse, repeat.
Step 4: Data Analysis
Now we've got some flight data, but is it accurate? From the read outs in the field, we see a quick (off scale) acceleration followed by an arcing altitude graph. The results are a bit higher than I would have guessed, but within reason.
One approach to validating the numbers is theoretical. Dean Wheeler has put a water-rocket simulator on-line that accounts for everything down to air temperature. To put it to use, you need to know some key parameters. My total rocket (minus water) weighed 185 grams. I used 0.7 L of water pressurized to 60 p.s.i. (there I go mixing units again). Using Dean's suggested drag coefficient, which is the primary unknown in all this, the number fall short of measured (268 feet verses 176 feet). The calculated flight time and time to apogee are also shorter. So, what is a good scientist to do? Right, massage the data. Since the drag coeeficent is the primary unknown, and all the other data seem scaled low, I adjusted it until the maximum altitude matched. The time to apogee and the total flight time are pretty close! (see the dotted lines in Figure 1)
There was a lucky accident here. Did you catch it? The theoretical model assumes the rocket has no parachute on its return to earth. My parachute failed to open, allowing us to directly compare the total flight time.
Of the four flights we made, only flights 1 and 4 provided data. The crash from the first flight fractured the battery holder so the micro-controller would loose power during the acceleration, leaving an eerie end to data transmission. The final flight, the parachute, making up for past transgressions, opened to early, leaving a flight in my estimate of half as high as the first.
Alas, nothing in science is as clear cut as you would like it to be. A measurement of the angle at apogee on the final flight put it's altitude at 60 feet, well below the indicated 120 feet.
Some final observations on the data. The calculated maximum Gs are ~60! That would kill a human, and explains why I have a hard time keeping fins attached to the rocket body. Also of interest is that the bottle empties of water in under 0.2 seconds, while the rocket is still just 10 feet off the ground! Some things to think about.
Step 5: Conventional Rocketry
In all, not too bad. I've got plans for a lighter, more powerful rocket so I can fly both the electronics and the video camera at the same time (we were over the recommended limit by a ways). Here are the two instrumented flights. Flight 6 was a bit lighter due to removing the helicopter recovery system, and thus went higher. It also descended slower on the parachute. Look at the "zero G" coasting after the engines shut off!
Step 6: Postmortem
So clearly, the acceleration was more than expected, and a high-G analog sensor is in order. Matching acceleration against theoretical values would give more confidence. According to the simulator, a smaller nozzle significantly reduces initial acceleration while having little effect on overall altitude (thrust time is proportionally longer).
The batteries are a problem. They are too heavy, while having more capacity than needed for a few minutes of flight. Their mass also causes problems during the occasional rapid decelerations experienced during chute malfunctions.
The radio range was far shorted than I expected. I imagine some research on antenna and positioning could improve that. I had to scratch the original title of this Instructable from "Real-time Model Rocket Telemetry ". As it was, it is certainly convenient to be able to query the controller on the pad to ensure it is functioning, and download the data after the flight without having to disassemble or connect anything.
If nothing else, I hope you've seen how easy and fun it is to incorporate an Arduino in to a hobby. If you want to see more of my craziness, check out my model train layout operated by, yes, you guessed it, an Arduino! It uses a Wii Nunchuk for input!
Now, go be a Maker!