Finally got a chance to fly the ArduRocket on a reasonably powerful motor, this time on a CTI J285. ArduRocket flew at NCR's Mile High Mayhem event in a modified 4" Binder Excel+ kit I call Hayley's Comet. The goals this time were to see how well it recovered from high-ish (~10 g) acceleration, and to test the range of the 900 MHz radios with existing antennas.

Flight prep didn't get off to a great start. I left the eye nuts for mounting the recovery harness at home, so had to improvise with an eye bolt and some threaded rod. That worked fine, but required modifying the nose cone. During that process I shook hands with the xacto knife...

A couple stitches and a good amount of rain later, I managed to get the flight in on Sunday. (KMZ file)

According to GPS, the flight reached 3618 ft. AGL. I also had an RRC2 Mini altimeter on board to trigger the ejection charges for the parachute. That device also provides a second set of data to help analyze the flight. The RRC2 Mini reported that it took 15s to reach an altitude of 3489 ft. AGL, and achieved a maximum velocity of 650 fps during flight. The rocket was successfully recovered just under 1 mi. away.

The ascent portion of the flight was nice and straight. As expected, GPS lock was lost shortly after take-off. The GPS receiver appears to have regained lock right right around motor burn-out. While lock was lost, it was regained automatically, which was my hope. Good radio signal was maintained throughout the flight.

The rocket landed over a hill about 4600 ft. away. Radio signal was maintained at that distance without requiring line of sight. The antennas used had a gain of 3.1 dBi and were tuned for frequencies of 868MHz-928MHz. Since I didn't collect signal data from the xBees, I don't know how strong the signal was. However, judging from the number of samples received, very few, if any, samples were lost. Certainly, 1 mi is a safe range outside the city. I'll narrow that down with further testing.

GPS acceleration limits

The reason I wanted to see how the unit recovered from high-ish acceleration conditions is that the uBlox 5 chip has a 4 g acceleration limit. My initial understanding was that this was due to the crystal becoming temporarily deformed enough to affect timing in a meaningful way during high acceleration conditions. Since GPS is a very timing sensitive application, lock is lost if this is not compensated for.

While this is certainly a possibility, after some research it appears that there are multiple potential causes including lack of correction for Doppler shift of the GPS signal and limitations relating to the update frequency of the chip. What does seem likely is that this limit is not due to a government regulation, as the rules defining altitude and speed maximums don't mention acceleration. There's a good discussion of this at http://www.gps-forums.net/acceleration-limit-t41060.html.

Next steps

As one prone to possibly over-analyzing things, of course I found more room for improvement.

First, it would be really helpful to have a time stamp on each record. This will help determine how much data might be getting lost. Thankfully this is something that GPS can provide an initial basis for. Due to the potential for losing lock, the Arduino will need to maintain that through the flight. The ATMega328 isn't great at keeping time, but it'll do fine for this application.

Second, an accelerometer would be really helpful. In addition to helping determine the g force at which the GPS loses lock, it will also allow for capturing fairly high resolution velocity and altitude data.

Third, gathering signal data from the receiving xBee would be good. Not sure that it's totally necessary, although it will provide the best indication of any communications difficulty.

Finally, given that no directional control is possible, the navigation and way-point functionality is unnecessary for amateur rocketry applications. Removal of this code will allow for adding functionality more appropriate for rocketry, and possibly permit an increase in the update frequency of telemetry data.

Here's my current to-do list for transforming the ArduPilot into something that can truly be called ArduRocket:

1. Adjust velocity calculation to calculate 3D velocity, and preferably break out X, Y, and Z vector values separately
2. Set time from GPS, and time-stamp each record when transmitted
3. Add accelerometer, calculate and transmit velocity, acceleration, and altitude
4. Remove or disable navigation and waypoint code
5. Collect signal strength information from receiving xBee
6. Add configurable flight events for triggering ejection charges