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.