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.

This is another catch-up post on my GPS rocket navigation project.

As mentioned in my last post, over the winter of 2010/2011 I got the code working to drive the telemetry radio. I also built a new version of the PCB, “Rev 4.2.1”, the same one I’m flying now and discussed in this post.

April 30 was my first chance to test the new telemetry system in flight I got in 3 flights that day – here is the first, my 4″ “SuperHorizon” rocket on a Skyripper H155PP:

The parachute deployed OK (eliciting some surprise), but there was no obvious steering of the parachute – it just spun around slowly counterclockwise (as seen from the ground).

Other than that, everything including the telemetry system worked fine until a few seconds before landing, when the telemetry stopped abruptly. On recovery, the electronics were completely powered down, and one of the two LiIon cellphone batteries had 4.1 volts on it (a full charge), but the other appeared short – so only 4.1 v was reaching the electronics, not enough to run it.

I didn’t know why the parachute didn’t steer, but I was happy enough that the parachute was deploying and the new hardware and telemetry stuff seemed to be working.

I tried to extract the log data from the PIC32 flash memory via the telemetry system, but there was nothing there. I wasn’t sure why (then) – it might have had something to do with the power system problem.

Since my goal for the day was to acquire navigation experience that I could analyze afterward, I went ahead and flew my 3″ “Thrud” on a Cesaroni H100. Here it is:

It got to 1577 feet AGL. This was just the second flight for the “Rev 4.2.1” hardware, and again it worked fine – this time with no power system problems. It seemed to steer somewhat back toward the launch pad, but the wind was also blowing that way, so it wasn’t so clear at the time if this was just good luck.

Again I had problems extracting the log data via the telemetry system. I was ultimately able to do it by connecting to the physical serial port on the PCB.

I still had time for one more flight. I decided to fly the SuperHorizon again after stealing the batteries from Thrud (since I didn’t trust the batteries that had failed on the first flight).

This time I shortened the forward parachute lines by about 1 inch, hoping to decrease the angle of attack and get a faster forward airspeed for the parachute. The wind was really low so I went with a bigger motor – a Skyripper J144:

As you see, shortening the forward lines resulted in a parachute that didn’t fully inflate. So I won’t do that again.

Again I lost all the logged navigation data from this flight. I did have some info from the telemetry, which showed a very confused navigation algorithm, with no consistent mapping of servo position to turn rate, and no consistent system lag values. Some of this might have been from the poorly-inflated parachute, but it wasn’t a good sign. I was concerned that the swinging of the whole electronics bay (including the GPS) under the parachute was confusing my navigation algorithm – the swings were so large that I imagined the GPS could think it’s heading in the direction of the swing, while the parachute itself was going in a completely different direction. At the time, that was my theory as to why the navigation wasn’t working.

Post-flight analysis

It turned out that cellphone LiIon batteries have an over-current protection circuit, which is supposed to reduce the chance of the battery catching fire in case of too much current draw. On the first flight, the servo loads triggered this circuit in the “short” battery. Once I ripped that circuit board out of the battery, that cell was fine. Lesson learned – I now take the over-current protection circuit board out of all my batteries before flight.

The logging data turned out to have been lost because of a minor bug in the way I was handling buffer overruns in the telemetry software – this was easy to fix once I’d discovered it.

Last winter (2010/2011) I finally got around to writing code that drives the Microchip MRF24J40MB transceiver module on the PCB for my GPS-guided rocket recovery project.

The transceiver module is a very nice little part – it’s an IEEE 802.15.4 (ZigBee) radio that uses the 2.4 GHz ISM band – the same band that WiFi and microwave ovens use. The “-MB” is Microchip’s long-range module – it has the radio, antenna, power amplifier (PA), and low noise amplifier (LNA) all on a surface-mountable board a bit bigger than a postage stamp. It comes pre-approved by the FCC for unlicensed use. And the price is reasonable.

Here’s a pic showing the size:

It outputs 100 mW (20 dBm) and has a receive sensitivity of -102 dBm, so the range is quite good; well over 2500 meters outdoors (line of sight).

Microchip also offers a “-MA” module that’s both smaller and cheaper, but it only outputs 1 mW and doesn’t have the LNA, so it has less range.

It talks to the MCU with a simple 4-wire serial SPI interface; internally it has a lot of registers – you send it SPI commands to read and write the registers.

I’d already included an interface to the module on my PCB layout (posted elsewhere on this site – see here), so now I had to write some code that would talk to the module.

My goal was to get real-time telemetry from the rocket in flight, as well as to be able to send the rocket commands from the ground. I was already logging flight data to the flash memory in the PIC32, but if the rocket isn’t found I can’t get that data out of the PIC. So at a minimum, I wanted to get GPS fixes in flight, so if the rocket is lost I know where to go looking for it.

As well, the ability to send commands to the rocket is useful. With the telemetry system I can arm/disarm the ejection charges from a safe distance, as well as manually force ejection, switch modes, and power down the PCB (to save battery power after a scrub).

Software

IEEE 802.15.4 is the basis of ZigBee, a rather complicated protocol for smart gadgets and appliances to talk to each other wirelessly. Microchip offers source code for the entire ZigBee stack, but I didn’t need anything like that kind of complexity for this application.

Microchip also offers source code for something they call “MiWi P2P”, which is a vastly simplified protocol that implements a small subset of the ZigBee functions (it’s not compatible with ZigBee).

I had a look at the datasheet for the MRF24J40 transceiver chip – it’s 156 intimidating pages long. So I decided to use Microchip’s MiWi P2P source code, thinking that would be an easier solution than figuring out the datasheet and writing my own code.

That was a big mistake, at least for me. The MiWi P2P code has lots of functionality that I didn’t need – it will route messages around a network of peer devices, do store-and-forward for sleeping radios, etc. All I needed was simple point-to-point transmit and receive. So I started to modify the code to simplify things – all that functionality was making the interface to the rest of the system needlessly complicated. In the process of doing that, I found lots and lots of problems and bugs in the MiWi code. I ended up spending several weeks porting and debugging it; by the end I’d rewritten 98% of it (and thrown away a good 85% as useless overhead for my application). I used version 3.1.3, which is no longer the latest, but I don’t think the newer versions are much better.

The MiWi P2P code does work if you treat it as a “black box” and don’t attempt to do anything other than the few example things documented by Microchip. The bugs either aren’t exercised or are worked around for those cases. But if you want to customize or optimize anything at all you quickly run into trouble. It’s a bloated, buggy, poorly written and poorly documented piece of code. (It is well-architected. And it is free.)

In the process of rewriting the MiWi code, I learned how the MRF24J40 hardware works, and how to code to it myself. It turns out that “intimidating” 156 page datasheet isn’t nearly as bad as it first seems – from a software point of view, you only need to read sections 3.2 (Initialization), 3.11 (Reception), and 3.12 (Transmission) – that tells you everything you need to know in less than 10 pages! (It helps to skim over the IEEE 802.15.4 document first to know what to expect – but you don’t have to implement all of it to get simple data transfer working.)

If you’re going to do this yourself my advice is to ignore Microchip’s source code and write directly to the MRF24J40 hardware per the datasheet, unless you really need the whole ZigBee stack. Follow the datasheet’s initialization instructions exactly. Do not even look at Microchip’s application notes – they’ll only add confusion.

If you do that, you can have it running with 2 or 3 days of work (instead of the 2 or 3 weeks I spent). The hardware is excellent and it works like the datasheet says.

[Update January 2012: I’ve posted the source code; see: https://nerdfever.com/?p=1797]

Once I had basic radio I/O working, I implemented a set of commands the rocket would respond to – they’re all simple ASCII strings (think a command-line interface). Here is the list as of this writing:

STATE NAMES (forces rocket software into commanded state)

NONe
SAFe
ARMed
TLAunch (timed launch – used for ground testing)
ASCent
DEScent
GROund
TESt

NOUN ALONE

DUMp (dumps log as hex)

RESET-LOG *
RESET-NAV *
RESET-ALL *
POWER-DOWN *

* must type whole command for these

PARAMETER COMMANDS (noun verb)

(no parameter = report current status)

CHAnnel n (set radio channel)
BUZzer on/off
BEEp on/off
LOWbuz on/off
GPS_enable on/off (GPS power)
DROgue on/off (drogue output)
MAIn on/off (main parachute deployment output)
ST2 on/off (“stage 2” output)
ST3 on/off (“stage 3″output)
RED on/off (LED)
YELLow on/off (LED)
GREen on/off (LED)
VSWbatt_pwr on/off (switched battery power circuit)
VSErvo_pwr on/off (servo power)
STEer / S 0 to 255 (both servos same)
S1 0 to 255 (servo #1)
S2 0 to 255 (servo #2)
UPDates on/off (transmit updates every 40 mS)
LTHreshold  meters (launch detect threshold)

PARAMETERS

<integer> value
ON 1
OFF  0
TOGgle  !<oldValue>

I only have to send the capitalized characters (usually the first 3); the rest are ‘syntactic sugar’ to make it easier for me to remember them.

In addition to responding to the commands, the rocket will also send status information each time the software changes state (for example, when launch is detected and the rocket goes from ARMED to ASCENT) and on each GPS fix and each cycle of the navigation algorithm (for diagnostics/debugging).

Ground station

Now that I had telemetry software in the rocket, I needed a ground station to talk with the rocket.

The ground station consists of a 802.15.4 radio that talks to the rocket, plugged into a netbook computer that acts as a terminal. Here’s a pic of the ground station radio:

Look familiar? It’s pretty much the same PCB that goes in the rocket – this was an earlier spin of the PCB that didn’t work out too well – I’d used a ADP3335 LDO as a voltage regulator, but forgot to put in any heatsink for it. The LDO got too hot for comfort when running of the 7.4v flight battery, but it wasn’t bad when running off the 5v USB from the netbook, so I used the board as the ground station radio. (As you can see, I was experimenting with making the radio module a separate board at the time.)

There are two USB connectors that go to the netbook – one powers the board, the other has a USB-to-serial converter on it, because I still haven’t gotten around to writing a driver for the USB port on the microcontroller side. On the netbook side I’m just running a terminal emulator (PuTTY if you must know) for now – in the future I’m planning to write something that will process the data in real-time to produce plots, etc.

Here’s the netbook, with the radio attached by velcro to the back:

It’s a Samsung N130 running Ubuntu. There’s no particular reason to run Ubuntu instead of Windows (my usual OS) for now, except that Ubuntu seems to be a better-supported Python development environment, and eventually I plan to write some Python code to talk to the rocket in real-time. And it was a good excuse to play around with Ubuntu a little.

One major change I made to the netbook was to replace the standard LCD screen with a Pixel Qi display. Normal (backlit) LCDs are almost impossible to read in direct sunlight – and rocket launches are very often outdoors. I’ve had terrible problems trying to read laptop screens at launches. So I bought the ridiculously overpriced display from Maker SHED ($275 plus shipping for a display to go in a $300 netbook!).

Although I still grumble about the price, the Pixel Qi display is great. It’s a normal color LCD except that, in addition to the backlit mode where it acts like any other LCD display, it has a reflective layer that makes it readable in full sunlight – the more light the better. Some people call this a separate “mode” from when it’s backlit, but there really isn’t a mode – the display is reflective all the time, but you can’t tell unless there is a lot of light.  If there is so much ambient light that it washes out the backlighting (outdoors), you can just turn off the backlight altogether and save the battery power it consumes.  The reflective mode is black-and-white, but that’s fine with me – it’s readable and I love it.

While I had the netbook apart, I swapped out the HDD for an 80 GB SSD – so it runs a little faster now, with no moving parts except the CPU fan.

Universal controller

Lastly, after a few test flights (which I’ll describe in an upcoming post), I decided that I wanted a way to manually steer the parachute, mainly so I could try to analyse what the navigation system was doing with known steering inputs (which didn’t work for reasons I’ll explain later too).

So I built what I call the “universal controller” to steer the parachute:

It’s nothing but a potentiometer and switch.  But, hey, on/off and less/more – what else could you possibly need?  🙂

The pot is connected to an analog input of the microcontroller on the ground station PCB. When the switch is set to ON (switch is attached to a digital input), the position of the pot is read and transmitted as a steering command to the rocket; the steering servo just tracks the position of the knob. When the switch is OFF, the rocket steers itself with the on-board navigation algorithm.

The telemetry system has worked very well, at ranges of well over a mile.

Continuing with my update on my GPS rocket navigation project, in this post I’ll quickly run thru my progress (or lack thereof) in latter half of 2010.

17 July 2010 – Flight #28 – First navigation attempt

Last year I posted a video of flight #28 of 17 July 2010, which was my very first flight with the GPS navigation software running and the steerable parachute.

As I mentioned in my recent post, that flight used a steering baseline of just 2.5 inches, yet the system appeared (from the ground) to be able to steer the parachute OK with that tiny baseline. Here’s the video (again):

As can be seen in the video, the rocket appeared to be steering purposefully, although not in the right direction. So I came away with the idea that (somewhat to my surprise) a tiny 2.5″ baseline was a workable thing.

Below, the red arrow shows the 2.5″ baseline – the distance from the left steering line (kevlar braid) to the right steering line.

Here’s the plot of the flight path (click for the Google Earth KML file):

The navigation didn’t really work at all, but this was my very first attempt and I didn’t expect much; I knew there were a lot of variables in the navigation software that would need tweaking from flight experience. The winds aloft were much higher than expected and the rocket landed way off the field – 40 feet up in a pine tree. It took me 4 days to find it and get it down, but I’ll spare you that sob story.

One thing that came out of the flight was a determination to get the telemetry radio working – if I’d had that on this flight, I’d have had the GPS coordinates of the landing site, and it wouldn’t have taken days of searching to find the rocket.

18 September 2010 – Flights #29 and 30 – Test of piston ejection

The July 17 flight also had a problem with the ejection charge burning the steering control line to the parachute.

To avoid that happening again, I redesigned the rocket to use piston-type ejection, where the electronics bay is the piston. That way, instead of having the ejection charges on the parachute side of the electronics bay (where they can burn the control lines), the charges are on the opposite end of the electronics bay. The charge fires into the space between the altimeter bay and a fixed bulkhead in the body tube. The whole electronics bay slides out, pushing the parachute ahead of it.

Earlier in the year (April), I’d run some ground tests in my backyard to find out how big a BP charge was needed for piston ejection. I’d been using 3 to 4 grams of BP in conventional (non-piston) ejection in my 3″ and 4″ rockets. Here’s a video of the tests with the piston, in my 3″ rocket “Thrud”:

I started with 2.5 grams – I didn’t mean to build a cannon, but it seems I did. I ended up using just 0.5 grams of BP in the 3″ rocket (“Thrud”), and 750 mg in the 4″ rocket (“SuperHorizion”).

Two flights on 18 September tested the new system (without any attempt at navigation); it worked perfectly (and has continued to work great since). I’m sticking with piston ejection!

2 October 2010 – Flight #31 – Bad chute deployment

By October, I’d made a few software tweaks, had the piston ejection working smoothly, and was ready to try again with navigation. Here’s what happened:

The parachute lines were horribly tangled up, which prevented the parachute from inflating.

6 November 2010 – Flight #32 – Another crash

By the November launch I fixed the damage and was ready to try again:

Oof. Again, the parachute lines tangled in flight, resulting in a crash. This time there was no damage (just lucky).

Here are a couple of stills from video, showing what the parachute lines looked like at recovery – all twisted and tangled:

6 November 2010 – Flight #33 – Some navigation! ?

Undeterred by the tangling/twisting problem, I packed the parachute and lines even more carefully and tried again.

Despite the taunts from my long-suffering fellow club members (they’ve seen a lot of my failures), the applause at landing was encouraging, even though I wasn’t sure at the time if the navigation was real or just good luck with the wind.

It was a low altitude flight – just 650 feet AGL on a Cesaroni H133 motor (a very small H), so the navigation system didn’t have a lot of descent time to learn to fly the parachute.

Here is the flight path as plotted in Googe Earth (again, click to download the KML file):

From the ground the parachute appeared to have deployed OK, but on recovery I found, again, tangled lines, but not as bad as in the previous flight. Have a look:

After the flight I had a careful look at the logged navigation data (including the internal state of the navigation algorithm) and decided that the rocket probably had navigated successfully for part of the flight – at least for a few seconds of the short descent. So this was a real milestone.

More importantly, I’d learned a lot. The tangling issue was clearly an ongoing problem, even with the most careful packing.

Looking at the video, I became concerned that another problem might be the swinging of the whole electronics bay (including the GPS) under the long parachute lines. Since the rocket estimates its flight direction based on sucessive GPS fixes, a significant swing could easily confuse the rocket into thinking it’s heading in the direction of the swing, instead of the direction of the parachute’s flight.

Club member Boris Katan – a much more experienced rocketeer – suggested that my parachute lines were much too long. I’d made them long to reduce the impact of the short baseline on the angle that the steering lines reached the parachute, but Boris convinced me to vastly shorten the lines – both to reduce the swing, and also to reduce the chance of tangling.

21 November 2010 – Flight #34 – Last launch of the 2010 season

The next launch on 21 November was the last of the year (here in Boston we get snow soon after that).

With much shorter lines to the parachute, I launched the 3″ “Thrud” rocket again, on an Aerotech H180:

That was bad.

In my earlier flights, I’d been using one of Robert DeHate’s PICO-AD4 altimeters as a backup to my own electronics for deployment. But I’d made some software changes to save battery power on the pad by powering down the servo until launch was detected. Inadvertently, that had also disabled power to the AD4 altimeter.

So as a quick “fix” to provide backup deployment in case the first flashbulb didn’t go, I’d wired two flashbulbs, with 0.5g of BP each, in parallel onto my own apogee ejection output. This was my half-baked ejection redundancy. It seems that 1g of BP going off at once was too much for the kevlar cord retaining the electronics bay/piston.

A lesson I learned late is to avoid using epoxy on Kevlar cords – I’d plugged the hole where the cord went thru a bulkhead with epoxy, but epoxy is stiff and doesn’t let the other fibers in the cord take up strain. So the Kevlar becomes brittle and weak – it ripped right at the end of the epoxy. (Hot glue is a much better solution; it’s flexible so it still allows the different fibers to take up the strain.)

The whole e-bay was ejected from the main body tube, together with the parachute and nose cone. The bottom plate of the e-bay (with the ejection charge holders and power switch) and the tube around it were ripped off (never found that). The wires running to the flashbulbs and power switch were ripped off at the PCB.

As you saw in the video, without the weight of the back end of the rocket, the parachute drifted a long way, bounced off a power line, and landed in the dreaded CMASS swamp.

The only good thing was that my PCB kept running, as it’s designed to turn off only when the power switch is closed (not open).

So that was it for the 2010 season.

I’d had one good flight of the system. That had worked only a little bit. But I got valuable data from the flight, which I was optimistic would enable me to tweak things so they work properly. The tangling problem was clearly serious, but I hoped that the shorter parachute lines and careful attention to packing of the parachute would address that in the new year.

This post continues my update of progress toward a steerable parachute system that automatically returns rockets to the launch pad.

In early July 2010, coding of the navigation software was done – it worked well in the simulation, but as a reality check I built another truck to at least test it on the ground.

I stripped a $15 toy truck down to the chassis and installed an old hobby servo to steer it:

Here’s the sophisticated steering linkage – a bent paper clip:

Then I stuck the CPU board in there with some batteries to run the truck motor:

There was no R/C radio – the system is autonomous and steers itself.

This one wasn’t as robust as the truck I’d tested back in 2006 or so (see my slides) – that was a $80 toy truck, and big enough to run on grass and drag around a whole laptop and lead-acid battery- but I didn’t need the laptop anymore since the navigation was running on the flight hardware. It was good enough for a quick-and-dirty test in a nearby parking lot.

It was a very useful test – I found lots of bugs, as documented in my notes. But, after a mere 6 or 7 tries over the July 4 weekend, it was successfully navigating its way around the parking lot. The road to flight glory seemed open.

It’s been quite a while since I posted an update on my GPS-steered parachute for recovery of rockets. This is is the first in a series of posts where I’ll try to bring things up to date.

(For those who want way-too-much-dry-detail, my Flight Test Notes updated thru August 2011 are here; by the time you read this, there might be a newer version linked from the main project page.)

The bottom line is that, as of this writing (August 2011), it’s not working yet, but I think I’m very close. I seem to have have been sidetracked for a whole year by using a very small baseline (horizontal distance between the left and right parachute control lines) to steer the parachute. My flight #28 in July 2010 seemed to work OK with a tiny baseline (just 2.5 inches), so for the past year all my flights have used small baselines – and none of them have steered very well (altho some worked a little bit). Only in July 2011 did I realize the small baseline was causing most of my problems – the steering lines simply get twisted together, preventing steering.

I’ll get to how I figured that out, and what I plan to do about it, in future posts.

Current hardware – Rev 4.2.1 PCB

Here’s a picture of the hardware I’m flying now – I call it “Rev 4.2.1”:

It’s a slightly-updated version of the Rev 4.1 board I posted earlier:

• A Microchip PIC32 MCU (PIC32MX440, with the USB interface),
• GlobalTop PA6B GPS (updates at up to 10 Hz),
• Microchip MRF24J40MB IEEE 802.15.4 radio transceiver for telemetry,
• Freescale MP3H6115A pressure sensor for the altimeter,
• Some buttons, LEDs, and a piezo beeper,
• A USB port that right now is only used to power the board on the test bench,
• Some MOSFET switches to drive four pyro outputs (on the back side; not visible)
• Logic power is 3.3v from a Microchip TC105 switching DC-DC converter (also on the back side) – this is much more efficient than my old LDO design – the board can now sit on the pad for hours without me worrying about the battery dying.

I layout the board in Eagle PCB and have them made in China by BatchPCB.com, then populate the boards myself by hand with a soldering iron, heat gun, stereo microscope, and patience.

It runs off 6 to 9 volts; normally I use two LiIon cellphone batteries in series (see next pic) or 6 NiMH cells in series.

At this moment I have a very slightly updated version (Rev 4.2.2) out at BatchPCB being made, but I’m aiming for a new version this winter which will, I hope, run off a single LiIon cell (3.6 v) and have a charging circuit on board, so it’ll charge off the USB port.

Also visible in the picture is the back side of the steering servo, and the 808 keychain camera I’ve written about before. This looks upward at the parachute in flight, and has proved extremely useful in diagnosing what is going on with the parachute and steering (see videos linked in the Flight Test Notes).

Note the little glass-bulb thing at the top between the PCB and the camera. This is a magnetic reed switch, and it’s how I turn on the board inside the rocket without making a hole in the rocket for a switch. Unlike a Hall effect sensor, the reed switch doesn’t draw any power at all. I hold a magnet on the outside of the rocket, opposite the reed switch. The switch closes while the magnet is there, which powers up the CPU. As soon as the CPU boots, it pulls up an output line to keep the power on, even after the magnet is removed.

I can turn the power off with the reed switch too (the CPU monitors the switch as an input), but these days I usually power down with a telemetry command – when the CPU gets the command, it drops the same output line and turns itself off.

Electronics sled

Below is a picture of the back side of the e-sled, with the batteries and servo top visible.

A few lessons I learned the hard way:

• Pot wires with hot glue, not epoxy. Potting is important to keep wires from flexing and eventually breaking, but epoxy is brittle – the wire will flex exactly where the epoxy ends. Hot glue dries rubbery, so it allows some gentle flexing but spreads the load out along the wire. It’s easier to remove if you have to, too.

 

• Modify cellphone LiIon cells before using them in another application. Cellphone LiIon cells have a protection circuit – usually a tiny PCB mounted at the connector – which limits charge and discharge current for the battery. Lithium batteries can catch fire (or theoretically even explode) if improperly charged or damaged – these circuits are supposed to prevent some of that, but the circuit can turn off the battery just at the critical moment when you need maximum current from it (it happened). So rip those boards out and connect directly to the cell. (And take proper precautions in general.)

 

• Note the screw terminal connector at the end of the payload bay. This position lets me connect up the ejection charges without having to remove the whole e-sled and use long wires – my next spin of the PCB will mount the screw terminals on the end of the board directly, so I don’ t have to remotely position them this way.