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.