Another progress report on my GPS-guided rocket recovery project (follow the link for an intro & index of posts).
After the July 16 launch (see previous posts) I only had a couple of days to fix things before it was time to drive out from Boston to metropolitan Brothers, OR for the OROC Desert Heat launch.
I repaired my 3″ “Thrud” rocket, changed the apogee detection algorithm, fixed the servo pulse problem, did some quick testing, and then packed up the motorhome for the trip.
On July 23, I flew my 4″ SuperHorizon rocket with the new software on a Skyripper J144 in the spacious Oregon desert:
As you saw on the video, the parachute deployed but didn’t fully inflate at first – after about 8 seconds it untangles enough to fully inflate. Here is the graph of altitude (feet AGL) vs. time – you can clearly see the high descent rate slow down when the parachute fully inflates:
Once the chute inflated, I had a very nice descent with a good chance to steer manually. Unfortunately, the steering didn’t work at all – the parachute just descended doing another slow counterclockwise turn.
But I got a strong hint as to why – have a look at the onboard camera video:
I should have figured it out before, but it is completely clear from this video that the parachute lines are badly twisted together right from the moment of inflation. With the lines twisted like that, when the servo pulls on one line, the other inevitably gets dragged along, so no real steering happens.
The lines untwist gradually, becoming straight just a few seconds before landing.
I wasn’t able to redesign things out in the field, so the the next day (July 24) I packed the parachute even more-er carefully-er and flew the 4″ rocket again, this time on a Cesaroni I195:
But as the descent continues you can see the lines twisting together. And that’s when I lost steering control.
After looking at this video, it became completely clear that the reason I’ve been having so much problems getting the parachute to steer for the last year is that my steering baseline (distance between the origin of the left and right control lines) is far too small – this allows the control lines to twist together under the parachute. I need to redesign the steering system to provide a much larger baseline.
The afternoon was the end of the launch, so I decided to get as much data as possible from my last flight, taking advantage of the rare chance (for me) to fly in a really big desert field. I put my biggest motor, a Cesaroni J395, into my smallest rocket, the 3″ Thrud.
The result was not good:
I analyzed some of the telemetry data after the flight, and got the following graph:
(For more info about this graph, see http://www.microchip.com/forums/fb.ashx?m=637866)
The maximum climb rate on the way up was reported (by telemetry) as 302 m/s (676 MPH, about Mach 1). The descent rate reached 126.8 m/s (284 MPH) just before loss of signal.
A lawn dart.
Unfortunately, the telemetry didn’t have any valid GPS data, because the high vertical speeds seemed to prevent the GPS from holding lock on the satellites. My son and I searched for the rocket for over an hour, but never found any of it.
After the flight, I tried to analyze what went wrong. The telemetry gave an apogee of 7316 feet AGL (a personal record). But the telemetry also showed that the rocket detected launch at 93 feet AGL, then just 40 milliseconds (one cycle) later, falsely detected apogee and fired the ejection charge at a reported (but highly unlikely) altitude of 8 feet AGL. This immediate (and unreal) dip in measured altitude almost certainly caused the false apogee detection.
It’s clear from both video and telemetry that the parachute didn’t deploy just after launch. Launch mass was about 2.2 kg. Based on the published thrust curve of this motor, the rocket should have left the pad at about 22 Gs of acceleration; my best guess is that the 22 x normal weight of the nosecone just after launch was enough to keep it on the rocket despite the ejection charge.
My theory at this time is that the false apogee detection was caused by the high G forces at launch. Most of my rockets leave the pad at 4 to 6 G; this one left at 22 G. The Freescale MP3H6115A pressure sensor is known to be sensitive to physical flexing – probably the G forces flexed the sensor, leading to the false reading. I’ll have to implement a software “lockout” to prevent this from happening again.
The flight was a useful radio range check; the graph above plots time against AGL altitude, RSSI, and LQI, both scaled to 10,000 as the max reading (all from telemetry); as you can see the radio still worked well at a distance of about 1.5 miles, although the signal strength was starting to get low.
I did have a backup ejection charge setup. And it worked exactly as (poorly) designed. At 200 feet above the pad elevation, the rocket was descending too fast, so the rocket fired the backup charge. You can see the overpressure from the backup charge in the altitude graph (above). Unfortunately, 200 feet at 280 MPH is less than half a second. The backup ejection happened just 200 milliseconds before the last telemetry record was sent (when the rocket either impacted or went behind a hill shortly before impact); nowhere near enough time for the parachute to deploy. In retrospect, I should have made the backup system depend on the time to impact (based on descent rate) instead of simply altitude. Oops.
About a month later, the debris was found by Stan Speegle of OROC, who was nice enough to call and tell me about it. Sure enough, he found the parachute partly deployed, and the rest of the rocket smashed into tiny pieces. He’s promised to mail the wreckage back but I don’t have it yet – maybe I can still extract some data or video from it when I get it.
ever do any more testing?
@thomas: If you mean re the GPS-steered parachute, not since my last update on this website.
It was a hobby project and I eventually got distracted with other things. Maybe someday I’ll get back to it – who knows?
I’m pretty sure the only serious problem was the lines twisting due to a too-short baseline.