Viewing blog entries in category: #Rocket
Nothing like an extra week of competition and some great competitors to provide motivation... Father's day was launch day for flight 2 and with one exception it was a success! A 36" nylon parachute from Apogee Rockets was just the ticket for a safe return to earth.
I started with a slight redesign of the 3D printed base (updated files included with this blog post) to strengthen it and to move the parachute mount to its centerline. Threaded rods replaced screws so that I could secure the entire stack-up of base and Featherwing PCBs. Grommets were added as a shock absorber to the screws holding the parachute mount in place.
New Parachute and Mount
With the rocket back together I spent some time with my code. I'm not entirely sure about the mbed OS pre-emption model, specifically if threads of the same priority can be suspended at points other than an explicit release of control with a wait or yield, so I made a slight change to the StringFifo to protect against pre-emption while checking how many bytes are available. The big find, however, was had by monitoring profiling outputs (P4_0 and P5_6) on a scope and finding that writing to the Micro-SD card is slow and expensive (time-wise) which explained why I lost data during the first flight. [This kind of debugging sound familiar avitron?!? ]. In the scope trace below the red trace is an output that is high while in the fprintf to write data (Micro-SD writer thread). Usually the call takes ~20 uSec but occasionally it requires ~52 mSec as the buffered data is written. The yellow trace is the active time inside the accelerometer thread executing every 10 mSec. Each measurement and associated push of data requires about 450 uSec. The Micro-SD writer thread is executing about every 5 mSec in this capture because it is trying to keep up with the accelerometer and light sensor threads, each executing every 10 mSec. It was immediately clear that my write process can't keep up and eventually the FIFO between it and the sensors overflows. Fortunately it yields the thread during the long write or I would have been back to the drawing board. My quick fix is to a) take advantage of the large amount of RAM in the MAX32630 and allocate 256 kBytes to the FIFO and b) cut the default recording time to 60 seconds as a back-of-the-napkin calculation showed I won't overflow the larger FIFO during that time. A better solution will need to eventually be found but this one worked and I recorded all data. The mbed project from the earlier blog post has been updated.
Threads in action
Finally I took the rocket outside and added a make-shift light box of electrical tape around the light sensor with just a sliver opening to reduce the amount of light hitting it on these sunny launch days. As you can see from the data graph below my hack was successful, the rocket doesn't rotate much - which we verified with video in slo-mo. But the light sensor still needs to be improved. Probably by scaling the output voltage more with an external resistor divider.
Launch is nothing compared with ejection!
I pulled the temperature sensor further outside the nose cone and got slightly more interesting data this flight. It measured a decrease of about 5 degrees F from ground temperature to the apogee of flight.
Unfortunately the GPS failed again so I still don't know how high the rocket flew. This time I was able to correlate loss of fix with the starting of recording. There will have to be further investigation to see if there is some strange code problem or perhaps some additional electrical noise that causes the receiver to lose fix.
The rocket was completely undamaged and will fly again. Just have to figure out what's going on with the GPS. And to find a bigger engine so it will really soar!
My entry for the #makewithmaxim contest is a data acquisition and telemetry payload for a model rocket, a base station and software to control the payload and analyze its data.
The project, although not entirely successful in its first flight was a lot of fun. Perhaps some aspects of it might be useful for other rocketeers.
The MAX32630FTHR board was mounted on a custom 3D printed base along with GPS and RFM95W featherwings from Adafruit, a MAX31865 amplifier/AD board and PT100 temperature sensor, a solid-state light sensor and a small LiPo battery. The RFM95W radio was chosen because it is capable of transmitting for reasonably long distances. My testing showed it was capable of several km range. The payload fits inside the nose cone of an Estes “Executioner” model rocket. Holes were drilled in the nose cone for mounting screws, for the light and temperature sensors and for the USB connector. The rocket body shock cord and parachute attached to the bottom of the 3D printed base. Firmware for the payload is written using the mbed online environment and makes heavy use of existing mbed libraries as well as several ported Arduino libraries from Adafruit and Radiohead. Two custom libraries were also written for a data fifo and software SPI. The payload collects data from five sensors.
- Built-in accelerometer : X, Y and Z acceleration forces at 100 samples/sec
- Battery voltage : Using the MON output on the MAX14690 PMIC. The firmware will also automatically power down on low battery detection. Battery voltage is sampled every 5 seconds.
- GPS : Fix status, latitude, longitude and altitude at 1 sample/sec
- Light level : The output of a Everlight ambient light sensor is recording using an analog input at 100 samples/sec. I added light level monitoring as a nod to very old model rocket telemetry system that used a photocell to control an oscillators frequency. The oscillator output was transmitted to ground using an analog radio and the rocket’s rotation could be determined by listening to the “warble” as the rocket rotated.
- Temperature : A PT100 RTD temperature sensor processed by a MAX31865 provides temperature data at 10 samples/sec.
The payload data interface carries both ASCII commands and data sentences. Data sentences are in a form inspired by NMEA protocol and include a checksum. The same data interface is available over the radio link and MAX32630FTHR DAPLINK debug serial interface. The command set includes:
- status - Returns status including recording state, battery voltage and temperature as well as GPS fix status, coordinates and altitude
- file - Allows setting the recording filename
- dump - Allows dumping a file (either the current recording file or a specified filename) through the interface. This is very slow for large files and lossy without a more sophisticated protocol layered on top of the basic Radiohead broadcast mechanism.
- dur - Allows setting the duration of a recording session (seconds).
- msd - Enables USB mass storage device mode to access the micro-SD card. I made a small change in the mbed USBMS library to prevent it from attempting to connect when the C++ object was instantiated.
- send - Enables telemetry of a selected sensor over the interface at a one sample per second rate. The main use of this feature is to transmit GPS coordinates during flight with the idea that a rocket that went out of sight. It is also useful during testing.
- record - Triggers a recording session. Is used immediately before launch.
- shutdown - Commands the PMIC to shutdown power to the payload. Useful because it was not possible to access the small button on the MAX32630FTHR board and I decided, after some experimentation, that an external switch presented a reliability issue.
- help - Displays the commands and arguments.
- Prepare rocket : Load engine, wadding and parachute.
- Setup base stations : Connect the base station to the computer and start the Rocket application. Connect to the base station radio and verify it identifies itself.
- Power-on payload : Use a USB cable to trigger the PMIC to power-on the system. Verify the base stations receives the “HELLO” message from the payload.
- Achieve GPS fix : Use the “status” command to tell when the GPS has a fix. The coin-cell battery (which is held in place with additional hot glue) makes repeated start-ups in a location much faster.
- Rocket on launchpad : Connect launch controller and verify continuity.
- Start GPS telemetry : Use the “send gps on” command to start transmitting GPS coordinates to the application
- Start recording : Use the “record on” command
- Track : Use the GPS telemetry to track the rocket after landing. The last GPS coordinates can be fed into the
- Shutdown : After the payload has been either located or recovered, use the “shutdown” command to power it off.
- Connect payload using USB
- Establish communication using Rocket application and base station
- Offload data : Enable mass storage mode with the “msd on” command and copy data to the personal computer once the payload appears as a USB storage device.
- Analyze data : Load the file into the Rocket application and press Analyze to process the individual sensor data. Acceleration and rotation sensor data is also graphed.
BOM & Schematics
The Schematics and BOM for the electronics (both payload and base station) are available on the DigiKey schemeit system. Most everything is orderable from DigiKey. I used a 100 uF/16v electrolytic capacitor I had laying around to provide burst energy for the base station transmitter since, according to spec, its power requirements exceed that of the Teensy's 3.3V regulator.
I chose the Estes "Executioner" rocket primarily because it was both available at a local hobby store and had a large enough nosecone. I'm sure there are other rockets that would work as well or better. The primary aspect will be the size of the nose cone and ability to carry a payload. Get the biggest engines you can!!! You'll also need a launch pad for your rocket.
An upgraded parachute is also necessary (as I found out!). I haven't sourced a new part yet but I see there are much sturdier parachutes available from the model rocket companies. I will probably go with something larger than 30 inches.
The design files for the 3D printed payload base are included in the attached CAD file. This should be printable on any type of printer.
Building this project requires several subassemblies. Each build will probably vary depending on the chosen rocket and other parts the builder has laying around.
- Rocket : I followed the Estes instructions
- Payload : The 3D printed base requires drilling several mounting holes. The payload was building using standoffs with direct board-to-board wiring. I like nylon wire because it is flexible and easy to solder. The parachute and rocket shock cord are mounted to a pair of screws on the underside of the base.
- Modified nose cone : The bottom of the base is removed and holes drilled to allow mounting the base. Additional holes are drilled for the light sensor, temperature sensor (which is pulled, using tweezers, just outside of the nose cone envelope prior to flight) and the USB connector.
- Base station : I just attached the two PCBs using think 3M double-sided tape and directly wired them together.
The MAX32630FTHR firmware is available on the mbed website.
The attached code.zip file contains three things.
- Arduino Base Station Code: You'll also need the RadioHead library.
- Rocket Application: I've included the xojo source code, the dataplotclasses library and a pre-built executable for MacOS. The xojo development environment allows you to view and run the source code without requiring a license so you can edit and run this code for free.
- 3D printed payload base: The SCAD design, STL and gcode files I used to print the base. You'll want to create your own gcode file for your printer.
Bill Gates once said, "It's fine to celebrate success but it is more important to heed the lessons of failure". Yesterday's launch wasn't the complete success I had hoped but was fun, we got some great data and learned a thing or two for subsequent launches.
The rocket flew well, up until the point where the added weight of the payload tore the strings from the parachute as it deployed. Amazingly both it and the electronics package survived the fall back to earth. Helped, no doubt, by landing among some weeds. The system worked and transmitted data throughout the entire flight with three interesting anomalies.
- The GPS lost fix or somehow its data acquisition thread malfunctioned and it reported the same coordinates throughout the entire flight and in the excitement of things we didn't notice that the numbers being sent back were the same. Too bad because we can't really estimate how high the rocket flew.
- The light sensor pegged at the upper limit of the ADC input so we got no rotation data. I didn't think to check its output in full sunlight. Next time, a filter, perhaps something like a piece of tape, should fix this problem.
- Two times data was lost while recording to the Micro-SD card. This is a mystery and will take some digging to figure out.
The 3D printed base was also cracked and will have to be slightly redesigned and reprinted.
The most interesting data came from the accelerometer. The different phases of the flight were clearly visible and the launch impulse matched the engine's spec very well.
The temperature sensor worked as well and reported a similar temperature for the entire flight. I suspect the rocket did not fly high enough to see any real temperature gradients.
We will fly again another day but first a little work: larger and stronger parachute, new 3D base and a bit more firmware debug.
Ready to fly. I removed the reed switch and now power is turned on by plugging in USB power briefly and turned off by via a shutdown command. I also added a little more structural support for the boards, re-soldered the GPS receiver to increase the amount of solder holding it in place and hot-glued the GPS coin-cell battery in place. If all goes well, we'll launch the maiden voyage tomorrow at a park west of the foothills - and hopefully the rocket will miss the lake that's close by...
I did some range testing and was able to drive a couple of kilometers from my house while successfully getting real-time GPS data sent to the base station there. Here's the data converted by gpsvisualizer.com and displayed by google earth.
Software is ready although I suspect that there is a hazard or two left in the multi-threaded code. I have seen the firmware hang-up, usually when using the diagnostic serial port, so I'm a little worried but have reviewed the code several times and suspect I'd have to dig into some of the libraries to go further and/or try to debug the system using a desktop development environment. I'm betting I misunderstand how to use some of the mbed functions. Unfortunately there is not enough time for that right now.
I wrote a quick&dirty companion desktop application using the Xojo development environment to communicate with the rocket as well as manage and display data. It can read and parse the data file from the rocket and display map locations, accelerometer and light sensor data in graph form and all data in tabular form (to make it easy to export to a spreadsheet or other processor like gpsvisualizer). The result of shaking the electronics while recording is shown below.
Next up...the moment of truth. Will it fly? Will it collect data?
Just a quick update. I have some software now running. The basic system is operational on the MAX32630FTHR board communicating with all sensors and radio. SD-card logging is not yet implemented, nor is being able to mount the device as a remote USB storage device. It uses a number of mbed-os features including threads and event queues, as well as a bunch of libraries. I also have a very simple sketch on the Teensy-LC base station to communicate with the rocket. Communication appears as a serial channel and can occur either over the LoRa radio or the DAPlink debugger serial port. There is a simple command set to control the system.
In the picture, CoolTerm_0 is connected to the DAPlink debugger serial port and CoolTerm_1 is connected to the Teensy-LC. I typed "help" and "status" commands into CoolTerm_0 and turned on and off various sensor data streams in CoolTerm_1 using the "send" command. I am thinking that I will only "send gps on" during flight and record all other sensor data to the Micro-SD card.
I've run into a couple of issues so far (aside from own cluelessness). The MAX32630 implementation for the hardware SPI seems to require using only the three hardware slave select pins (as opposed to allowing software to control them using GPIO). One is brought out and available but the other two are double-mapped to the I2C bus. Since I need two slave selects (RF95 LoRa radio and MAX31865 temperature chip) and also the built-in I2C bus (BMI160 accel chip and PMIC chip) I had to implement a software (bit-banged) SPI implementation. I can get about 1 Mbps out of it. I also attempted to catch the RX Interrupt for the hardware serial port used by the debugger serial interface using the serial object's built-in attach function. Unfortunately that seems to hang the software whenever there is an incoming character. I haven't tried to debug that but instead put polling the debugger serial interface into its own thread which should be fine since it will be unused during flight (it's really only for debug).
Up next, a simple PC application to control and display data and also distance testing for the LoRa radio. I'm also going to replace the magnetic reed switch with a more robust type of switch because the more I think about it, the more nervous I get that acceleration or the parachute ejection might cause it to close which would reset the system (The power switch input is mapped to both reset and power-control on the PMIC).