Back on 28 October I covered the first 3 flights of the “Autonomy” (now “Autonomy 1”) rocket glider.

We flew it six more times, four times on 5 November 2011, and twice more on 19 November. On the last flight I forgot to arm the electronics (sigh)¹, so this winter we’re planning to build “Autonomy 2”.

At the moment, the main problem we’ve been having is that the GPS loses lock on the satellites a few seconds into boost, and never regains it during the glide. Without valid GPS fixes navigation is impossible, so this is a major problem.

By way of background – the glider is meant as a way to prove out the navigation and control software for autonomous steered-parachute recovery of rockets; see this post for more details. Fellow CMASS member Boris K. built the glider airframe; I did the electronics.

(This post is adapted from the thread on TRF [more details there].)

Review of first flights

From the logged data in flash, on flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.

Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.

Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I don’t know what it is – I haven’t seen this on prior flights (under a parachute).

Also the altimeter data was really noisy – it makes it very difficult to figure out the sink rate while gliding. (See graphs at the end of this post.)

After fiddling on the bench a lot, I concluded that the source of the noise (most of it anyway) is small variations in the power supply voltage (3.3v) caused by load from the servos and radio (which draw on the same battery, but prior to the 3.3v regulator). I could see the altitude readings jump around each time a servo draws current.

Prep for 2011-11-05 flights

In preparation for the 11/5 flights, I made the following adjustments to the glider:

• Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
• Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
• Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
• Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
• Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike was correct in his suggestion on TRF – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
• Lengthened the flare period from 3.0 to 4.0 seconds.

Most of these parameters can be tweaked on the pad with telemetry commands.

Second set of flights

On 11/5 we flew four more times. All four flights resulted in nice glides; the software tweaks seemed to help a lot. Ascent was nice and vertical, the yaw over-control problem got solved.

Unfortunately, the logged data shows that the GPS signal dropped out – again – after a few seconds on each and every flight.

On flight 1, Boris steered in the “yaw” mode, where he directly controls the yaw input to the servos. We used a “YawFactor” value of 10 (out of 100), so it was 1/10th as sensitive as on the previous flights.

Here is the video (first from the ground, then from the onboard camera):

 

On flight 2 we enabled autonomous navigation. As you’ll see, it overcontrolled a little bit (and because of the GPS dropout, navigation was impossible).

Flight 2:

 

After flight 2, we reduced YawFactor from 10 to 5, making it half as sensitive in yaw. This reduced the overcontrolling in yaw.

One flight 3, Boris steered it in the “forced navigation” mode. Here his knob inputs were used to force the navigation system to choose a steering command – this results in steering updates that are coarser and less frequent than in the “yaw” mode, but it allows the navigation system to learn from the response of the glider. Again, since the GPS didn’t work, the nav system had nothing to work from.

Flight 3:

 

For the last flight of the day we tried a larger motor, hoping for more glide time and more data. We got lots more glide time (a great flight), but again the GPS failure meant no useful data. This altitude (1300+ feet AGL) is about as high as I’d want to go with manual steering – any higher and it becomes hard to see which way the glider is pointed.

Flight 4:

 

The loss of GPS sync was again frustrating.

One possibility was a bad GPS unit – this was a new unit that had only flown on the glider. But it performed fine on the ground.

Another possibility was something about the glider flight dynamics that the GPS firmware can’t handle. The glider flies much faster than a parachute glides, while descending at a faster rate than an automobile normally would. Maybe this confuses GPS firmware that’s tweaked for use in cars.

The last idea I thought of was possible RFI from the camera, despite the foil shielding.

Prep for 11/19 flights

I corresponded with the GlobalTop (GPS maker) people – they said there is a dynamics setting in the GPS chipset I didn’t know about:

Regarding the dynamic conditions, you can execute PMTK command for setting. Our output speed is horizontal speed not vertical speed. Also, we don’t have higher accelerations.
PMTK command:
$PMTK302, MODE
Mode: Dynamics mode.
0 : Default ( fixed status)
3 : Slow Ground Vehicle (tractor, boat etc)
4 : Fast Ground Vehicle (car, train etc)
5 : Airbourne Low dynamics (<1g)
$PMTK302,3*2C<CR><LF>
//
Query Dynamics type
$PMTK402*34<CR><LF>：API_Query_Dynamics

Sure enough, the GPS was set to $PTMK302,0 (default) when I checked, so I changed it to $PTMK302,5 (Airbourne Low dynamics). I also ordered some of their new “PA6C” GPS units (successor to the PA6B I’m using now) – they said it has some features that make it (a bit) more immune to noise (a lot lower power, too).

Separately – I finally found the source of the altimeter noise. I was using the internal AVdd as the ADC reference voltage instead of the external pin. You wouldn’t think it would matter, since they’re both supposed be at Vdd – but it makes a huge difference.

Here are the results from my testing – the numbers are the standard deviation of the altimeter noise, in meters AGL:

The radio draws lots of current (> 100 mA) each time it sends a packet; so I used that as a way to test what happens when something draws lots of current.

AVdd reference, DCDC supply: 0.4 meters idle, 4.0 meters w/radio running
AVdd reference, battery supply: 0.8 meters idle, 5.5 meters w/radio

VRef+ reference, DCDC supply: 0.2 meters idle, 0.36 meters w/radio
VRef+ reference, battery supply: 0.12 meters idle, 0.15 meters w/radio
VRef+ reference, LDO supply: 0.11 meters idle, 0.25 meters w/radio

(I used the battery – 2 alkaline ‘C’ cells in series – as a reference “clean” power source.)

So, as Adrian A. (of http://www.featherweightaltimeters.com/) said on the TRF forum, the LDO supply is cleaner, but only by a little – almost all of the difference comes from using the external VRef+ pin. I think the DCDC supply is clean “enough” once I use the VRef+ pin.

I also swapped out the GPS for another one, that I flew in rockets before (under a parachute) and had worked well there.

Final two flights – 2011-11-19

On the first flight I was optimistic that navigation would work. We flew it first on a ProX G125 because the day was extremely windy and we didn’t really know how that would affect things (we only flew it on calm days previously).

Here’s the flight as seen from the ground:

You can see the parachute ejected but didn’t inflate – it remained stuck in the nose cone. Luckily there wasn’t any damage on landing, but we’ll try to avoid this problem on the next glider.

It did about 400 feet AGL (as expected with that motor), but after apogee it just spun around, because the GPS lost satellite lock about 1.6 seconds into the boost (as expected) but never regained it after apogee (not as expected).

This is extremely frustrating. I don’t know why the GPS loses lock in the glider, but works fine under the parachute. I set the high-dynamics mode (as mentioned earlier) but it seems this didn’t make any difference.

I suppose it’s possible there is some interference from the camera electronics. We didn’t unplug the camera for this flight because I thought it would likely work OK with the dynamics setting. However the GPS works fine with the camera running on the ground.

I just got 5 new “PA6C” GPS units from GlobalTop. I won’t have a chance to fly them before spring, but they say they’re less sensitive to interference than the PA6B I’ve been flying. I hope that fixes it.

We have no video from the on-board camera because we haven’t recovered the glider (and camera) yet – the video is still in there.

This flight did serve as a test of the modified altimeter. The results are mixed. The altimeter readings seem to have much less noise on the ground and during boost, but just as bad as ever during glide.

The graph below shows time (seconds, X-axis) vs altitude (feet AGL, Y-axis) for 3 flights – dark blue is this flight, magenta is the very first flight of the glider (in October, similar motor) and yellow is the 2nd flight of the glider (also in October, obviously on a larger motor):

The rocket collects an altitude reading 25 times/second (every 40 milliseconds); that’s what’s plotted here.

You can see that post-modification (dark blue) there’s a lot less noise in the altimeter up until apogee. But after that there’s still very strong noise – the altitude jumps up/down by as much as 40 feet.

I think that perhaps what I’m seeing here is a ‘whistle’ effect of air blowing and vibrating across the vent hole on the bottom of the glider. If so, it only happens in the glide configuration (which is imaginable). There’s just the single vent hole, but the electronics bay hatch (opposite from the hole) is not airtight. Suggestions for how to rearrange things to avoid this (if indeed this is the cause) will be greatly appreciated.

At the top of the graph is the battery voltage (2 x LiIon) * 100 (in cyan). There are 4 distinct dips – these correspond to current drain from (1) servos driving the elevons to boost position upon launch detect, (2) servos going to glide position at apogee detect, (3) servos going to flare position at 150′ AGL, and (4) parachute ejection current.

For the second (and it turned out, last) flight, we went to a bigger Cesaroni 296H110 motor for more altitude. Here’s the video:

I realized about 5 seconds after the crash that I’d forgotten to arm the electronics before launch. That’s a bad feeling.

With the electronics disarmed, the elevons stayed in the boost position (streamlined) for the whole flight, and the parachute didn’t deploy. It crashed across the Pow Wow river in the swamp. I didn’t see where it ended up, but I know where it is within 30 feet or so. It didn’t seem worth risking pneumonia to wade across the near-freezing river to recover the wreckage, so it’s still there. (Boris thinks it might have landed in the river itself and gotten washed downstream.) Maybe once the river freezes solid this winter I’ll try to recover it.

Here is Curtis Heisey’s photo of Autonomy 1 on it’s last flight:

It looks like I have a busy winter ahead.

Saturday 2011-10-22 saw the first three flights of the rocket glider.

(Most of this post is adapted from this thread where there are more details.)

Only one of the flights was really good, but we learned a lot from all 3; and the glider is in good shape.

Boris and I decided to name it the “Autonomy”. Our goal for the day was to get some flight information about the proper pitch setting for a nice stable glide.

There is still a lot of data analysis to be done, but you can look at the videos below. The whistling noise on the audio track is a good indication of relative airspeed, I think.

Flight 1 – Roadrunner G80 (115 N·s)

Video from the ground:

Video from the on-board camera (looking out the bottom of the glider):

Immediately after apogee the glider went into a sharp roll to the left. This was because I forgot to turn off the navigation system, which hasn’t yet been calibrated for the roll sensitivity of the glider. It commanded left yaw and put it into the roll. While spinning it lost lift and dived toward the ground.

The parachute deployed at 200 feet AGL as planned. No damage other than a very tiny zipper (similar to the one on Friday).

Flight 2 – CTI/AMW H54 White Longburn (168 N·s)

This was our best flight of the day. I remembered to turn off the navigation system.

Video from the ground:

And from the on-board camera:

The glider arcs over a little prematurely. Looking at the video, I think this is because the “straight” boost position for the elevons actually is slightly pitch-up, so the glider tends to arc up (toward the rudder) during boost.

I think we can reduce this in future flights by (a) adjusting the boost position a little bit pitch-down, and (b) adding a little bit of yaw command to the boost position to induce a slow roll during boost to even out any pitch-up/pitch-down tendency.

By chance the glider was right-side-up at apogee, and the transition of the elevon position from straight (for boost) to the glide position is very clear in the video. When the elevons go to glide position the glider does an Immelmann turn (due to the high airspeed at apogee – this was a pure accident) and then settles into a steady glide.

The really good news here is the glider does seem to be self-stabilizing due to the dihedral; regardless of what attitude it was in at apogee, if left alone it seems to settle into a stable glide.

During the glide, Boris was manually adjusting the pitch setting via the telemetry system. The effects of this aren’t too obvious in the video, but I’m hoping to learn more when I look at the logged data (servo position vs. climb rate, airspeed, etc.).

Three seconds prior to parachute ejection, as planned the elevons go full-up to induce a flare for airspeed reduction. This is hard to see from the ground video, but the pitch change is pretty clear from the on-board video.

I plan to look carefully at the GPS data from this flight (also correlating that with the two video streams). I hope to get a sense of the forward airspeed of the glider (at various pitch settings), whether or not we have enough control authority to do a full-stall flare (and how long it takes to do that), sink rate, etc.

Flight 3 – CTI/AMW H100 Imax (286 N·s)

On the last flight of the day we tried a somewhat larger motor, aiming to get more glide time and a chance to try manual yaw control.

This time I worked the radio controls (probably a mistake) and Boris ran the camera.

Ground video:

On-board video:

Again you can see the glider pitching up during boost, causing a premature arc-over and too high an airspeed at apogee. It’s more pronounced here than in the prior 2 flights.

It’s hard to tell from the ground video (Boris, you need to zoom in more!), but you can see that at about 0:13 on the on-board video, as soon as I switched on the manual yaw control, I massively over-controlled it and the glider went into a sharp left roll, and dived that way toward the ground, much like in flight 1.

Clearly the glider is VERY sensitive in roll (as predicted by some posters here).

On flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.

Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.

Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I’m not sure what it is – I haven’t seen this on prior flights (under a parachute).

For our next flights (November 5 is the schedule), I’ve made the following changes:

• Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
• Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
• Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
• Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
• Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike is correct – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
• Lengthened the flare period from 3.0 to 4.0 seconds.

Maybe other things once I’ve looked more carefully at the logged data. We’ll see.

Over the last few weeks I’ve posted a bunch of updates to catch up this blog on the status of my GPS-guided rocket recovery project.

At this moment (September 2011), it seems that the main problem I’ve been having with getting the parachute to steer properly is twisting of the control lines (see previous posts). I probably should have figured it out earlier, but the problem didn’t become totally clear until I could see it happening with the on-board 808 keychain camera. I’d been misled by the results of flight #28 way back in July 2010, which seemed to work OK with a tiny 2.5″ baseline – but it seems that was just luck.

Before my next flight, I plan to redesign and rebuild the steering system so that it has a much larger baseline. The comment by Tom Hannan posted July 29 on the project page hits the nail on the head, I think – the GPS and steering mechanism needs to be mounted right at the pivot point of the parachute, not any further down. This should cut way down on the swinging. I’ll try to make the parachute lines much harder to tangle while I’m at it. I also need to implement a apogee-detect lockout for a few seconds after launch (to avoid the problems in my last flight, on July 24). I’m not sure when that will be ready – probably October/November.

At the same time, I’ve been working with fellow CMASS rocketeer Boris Katan on a closely-related project – a rocket glider with GPS-steered recovery, based on the same electronics and software. We started back in June or so. At that time I thought the main problem with the system was swinging of the GPS under the long parachute lines – the GPS could conceivably be swinging in one direction while the parachute flew in another, which would certainly confuse my navigation algorithm. Also, I knew then that I had lots of problems with line tangling preventing reliable parachute deployment. Boris suggested that a rocket glider might be a way to test the navigation system without the complexities of the parachute – no long lines and swinging, and no tangling.

I thought it was a great idea, and we agreed to work on it together – Boris is building the airframe of the rocket glider, and I’ll be installing my electronics and servos into it to steer it.  Boris started a thread on The Rocketry Forum about the project – there’s lots of info there.

Boris first built a 1/3 scale model of the final glider – here it is before flight:

This flew twice on August 11 – both times fine, proving the stability of the design (see the TRF thread for more details). Now he is building the full-scale glider – here’s a recent picture from Boris – you can see the hole in the 3″ body tube for the electronics bay:

The delta-wing glider will steer with two elevons, using two servos to drive it. This will give us both yaw and pitch control, so we can flare the glider as well as steer it left/right. The elevons will be set flat (minimum drag) for the rocket boost. Then after apogee the nav system will try to steer it back to the pad. When the glider gets close to the ground (100 feet AGL or so), it will flare (to minimize airspeed) and deploy a parachute for a soft landing. I’ll be building up a new set of electronics to go in the glider, and working on some minor changes to the way the servos are driven in software, to allow both pitch and yaw control. We’re aiming for a first test flight on October 22 – but no promises.

The other day I got an email from Mike Passaretti way down in Western Australia, who saw my project here, and is working on a similar one of his own. His very first test flight was last weekend. Mike seems like a very experienced engineer, and I think has a good approach. There’s a very interesting thread on his project on the Australian Rocketry Forum. Maybe we’ll have a chance to collaborate – that would be fun.

Now that I’ve caught up the blog, I can go back to work. Watch this space.

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:

Apogee detection was a little late, but not as much so as before. Looking at the logged data afterward, I suspect the algorithm is working fine, but the vent holes for the altimeter are too small.

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 think this is a really cool video because you can see the packed parachute and hear the wind whistling just before ejection.

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:

I had some ability to steer the parachute manually at the very start of the descent, but then lost it as the descent continued. And here is why:

My careful packing paid off – the parachute deployed untangled. Mostly, anyway – the line going to the nose cone can be seen draped over the two parachute control lines. This isn’t good, but it wasn’t so bad that it prevented steering altogether.

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 lost sight of the rocket on ascent, and never found it again. But the telemetry worked. As you can hear on the video, the telemetry reported the rocket coming down very, very fast. And some observers on the ground thought they saw pieces coming off it near apogee.

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.

Over May and June 2011 I had a chance to think about what was going wrong in previous flights.

Since I suspected the GPS was getting confused by the swinging under the parachute (see my previous post), I decided the best way to debug the navigation system was to manually steer the parachute from the ground, while letting the navigation system run and try to figure out the correlation between servo position and turn rate, and the system lag.

So I built my “universal controller” gadget I described earlier – this has a knob that lets me manually control the servo from the ground.

I also used the time to install an “808” video camera into the electronics bay, looking upward at the parachute.  I hoped that a view of the parachute in flight might be useful in understanding what was going on with the navigation system.

Last, it seemed that my recent flights had all deployed the parachute a bit past apogee (late).  That’s not good because it means the parachute is coming out at a higher-than-necessary airspeed, which leads to much larger deployment forces and possible zippers.  So I modified the apogee detect algorithm to be more sensitive and trigger earlier.

On July 16 I got a chance to try these improvements.  The first flight was my 4″ SuperHorizion on a Skyripper H124 hybrid motor:

Parachute deployment was a bit on the early side.

Again, the parachute did not fully inflate, so I didn’t get a chance to try manual steering, or get any useful navigation experience.  I was lucky – there was no damage at all after the hard landing.

Here is the view from the onboard video camera – I think it’s kind of dramatic:

It’s pretty obvious from the video that the parachute lines are all tangled up, which is why the chute didn’t inflate.  This just verified that I still didn’t have a packing method that resulted in reliable deployment.

I tried again the same day with my 3″ Thrud rocket, again on a Skyripper H124 motor:

This was much worse.  The new apogee detection algorithm was much too sensitive, deploying the parachute too early, while still ascending.  The deployment forces broke the Kevlar cord attaching the tailcone to the rest of the rocket and resulted in a very severe zipper (the body tube was totaled).

The parachute did deploy OK, but again it just spun around in one direction for the whole descent.  I took over with the “universal controller” and seemed to be able to control the rate of turn, but I couldn’t get the parachute to fly straight.

The video from the onboard camera didn’t capture a view of the parachute (it’s just out of the field of view), but the audio track was unexpectedly interesting:

The “cycling” sound on the onboard video is the servo attempting but failing to move to the commanded position.  So part of my problem was that the servo wasn’t even moving when it was supposed to! (This affected only the servo on the Thrud rocket, not the one on SuperHorizion. But still.)

It turned out that I was sending pulses to the servo that were outside the range of what it could properly handle – if I sent a command for a large movement the servo would work, but commands for small gradual movements were ignored.

This wasn’t a good day.

Before the next flight I needed to fix the servo pulse problem, the apogee dection algorithm, and repair the broken Thrud rocket after the zipper and crash of the tailcone.