Glider with GPS guided recovery

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Beautiful to watch being built, and to see fly. Great job.

:wave:
 
I've made the following adjustments to the glider for the next flight:

  • 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.
Most of these parameters can be tweaked on the pad with telemetry commands.

I had a very quick look at the logged data from the 3 flights on 10/22.

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).

Also the altimeter data is really noisy; much worse than I'd like - it makes it very difficult to figure out the sink rate while gliding. (I may post some graphs later if I have time.)

Any analog electronics experts out there who might help? I'm using a Freescale MP3H6115A pressure sensor, fed into an ADC channel on the PIC32.

After fiddling on the bench a lot, I've 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 can see the altitude readings jump around each time a servo draws current. To get rid of the noise, I think I need some way to make the 3.3v supplied to the sensor (and to the ADC reference) extremely smooth and noise-free; but I'm not sure how to do that.

If someone thinks they can help, let me know and I'll post schematics of what's there now.
 
Last edited:
After fiddling on the bench a lot, I've 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 can see the altitude readings jump around each time a servo draws current. To get rid of the noise, I think I need some way to make the 3.3v supplied to the sensor (and to the ADC reference) extremely smooth and noise-free; but I'm not sure how to do that.

If someone thinks they can help, let me know and I'll post schematics of what's there now.

Either get a linear regulator with better specs, put a pi filter in front of your regulator, or just use a separate battery for the sensor's regulator. A 2 gram Lipo would work well for that.
 
Either get a linear regulator with better specs, put a pi filter in front of your regulator, or just use a separate battery for the sensor's regulator. A 2 gram Lipo would work well for that.

Thanks for the suggestions.

I'm using a DC-DC converter (Microchip TC105) to get 3.3v from the 7.4v battery (2 x LiIon); I'm sure that contributes some of the noise, but the noise isn't bad when the servos and radios are idle. I don't want to go back to a linear regulator because it wastes half the battery power.

I never heard of a pi filter (I'm definitely not an analog guy); I just looked it up on Google. You'd put that in _front_ of the regulator, not on the output (3.3v) side? How would I calculate the component values?

I thought of a separate battery, but it complicates things a lot (one more thing to break, keep charged, etc.).

I'd like to pursue the filtering idea if you can help with that.

I'm attaching the whole schematic of what I've got now. The pressure sensor is on the left side; the 3.3v DC-DC step-down is on the bottom right.

View attachment Rev422.pdf
 
Ah, I didn't realize you didn't already have a linear regulator on Vdd. I was only suggesting the pi filter in case the linear regulator was somehow getting overwhelmed by noise on its inputs The electronics should consume a tiny amount of power compared to your servos, so I wouldn't worry about the 1/2 power loss for that part. But if you still want to convert it down, I'd still recommend adding a linear regulator for your A/D and sensor. Linear regulators are great at rejecting noise, so I think that would be your most effective solution.
 
The electronics should consume a tiny amount of power compared to your servos, so I wouldn't worry about the 1/2 power loss for that part.

Hi Adrian,

Thanks again for your suggestions - you are much more knowledgeable about this than me!

It's true the electronics hardly draw anything compared to the servos (and radio), but the servos only need to run during flight (and then in bursts), while the electronics run the whole time the rocket is on the pad (~100 mA). For a HPR that might fly several times in a day, that can be hours. So I'm trying to be efficient with the power to the electronics.

On the other hand, the pressure sensor only draws 4 mA (and the ADC part of the PIC much less than that). So running just that off a LDO would be fine.

Since you've been so helpful so far, I was wondering if you'd comment on a few different methods I've been considering to get "clean" 3.3v to the pressure sensor and ADC. These are shown in the schematic I put here. (For some reason I'm no longer allowed to post attachments on TRF; did I post too many?)

On the right are the PIC and pressure sensor. The PIC is powered from the "noisy" DC-DC converter (bottom right), "VDD".

On the left are several different ways I thought of to get clean 3.3v power ("VCC") to the pressure sensor, ADC peripheral (AVDD, pin 19), and ADC reference (VR+, pin 16).

Method 1 is a LDO circuit I've used before - straight from the datasheet.

Method 2 is probably a naive idea - put a resistor in series with VDD (from the DC-DC) to limit the current, and a great big capacitor.

Method 3 is the same idea except with a diode too, to prevent "backflow" of charge from the cap to the VDD line.

Methods 4 and 5 (not shown) are the same idea as 2 and 3, except adding some kind of coil in series with the resistor, to "resist" changes in current flow (and therefore, I hope, voltage).

I suppose I'm revealing my utter cluelessness re analog stuff here.

Can you help? Do any of these seem like something that should work?

Best,

--Dave
 
Methods 2 through 5, as described, won't do as well as #1 when the load changes, for example when your A/D converter changes digital state. The series resistor will make the voltage a strong function of the load, both for steady-state and load transients. #4 and #5, if the resistor is deleted, would still allow load transients to affect the voltage, but at the voltage wouldn't be affected by the steady-state load. I would expect #1 to provide the best performance by far. Linear regulators are designed just for this sort of application.
 
I would expect #1 to provide the best performance by far. Linear regulators are designed just for this sort of application.

Thanks! I'll try to prototype it over the weekend and see if it works better.

Cheers,

--Dave
 
"Autonomy" flew four more times yesterday, 11/5/11, at the CMASS Amesbury, MA launch.

For these flights we increased the level of autonomous flight control to include all flight control activities except yaw control during glide phase. This was done to successfully dial in yaw control sensitivity.

Many things went well with all four flights:
> fairly straight liftoffs
> smooth transitions to glide
> extended glides which stayed right side up and under control at all times
> clean chute deployments at 150ft
> base station stayed in contact with rocket throughout
> rocket is in great shape for more flights

First three flights went up on ProX 29mm 3grain 168H87 Imax motors.

Fourth flight went up on ProX 38mm 2grain 269H110 White motor, reaching an altitude of 1322ft.

We may have had some more occurrences of losing GPS lock during flight, will know more after Dave has had time to analyze the data.
 
Here are the videos from the 4 flights on Saturday.

All 4 flights resulted in nice glides; the software tweaks seemed to help a lot. Ascent was nice and vertical, the yaw over-control problem seems in hand now.

Unfortunately, a first look at the logged data shows that the GPS signal dropped out after a few seconds on each and every flight. This is pretty disappointing - without valid GPS fixes, automated navigation is impossible.

I'm not sure why this is happening; it never occurred on any of the flights with a parachute.

One possibility is that it's a bad GPS unit - this is a new unit that has only flown on the glider. But it performs fine on the ground.

Another possibility is that there is 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. I'm going to email the GPS manufacturer and see what they say.

The last idea I can think of is possible RFI from the camera, despite the foil shielding. I'll try disconnecting the camera for the next flights.

I'll also try swapping out the GPS for another one, and if that doesn't work either, we'll have to look at another model of GPS.

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):

[YOUTUBE]t5FogD9FIRc[/YOUTUBE]
[YOUTUBE]47qpbC_ux7k[/YOUTUBE]

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:
[YOUTUBE]FW4Z168hhoc[/YOUTUBE]
[YOUTUBE]x6LEdKhh8pk[/YOUTUBE]

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

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:
[YOUTUBE]zeZuoSE76Yo[/YOUTUBE]
[YOUTUBE]Yrf4UzetW1k[/YOUTUBE]

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:
[YOUTUBE]k_7ICI06a4s[/YOUTUBE]
[YOUTUBE]xORjPSc_nwM[/YOUTUBE]
 
Last edited:
Another possibility is that there is something about the glider flight dynamics that the GPS firmware can't handle.
What GPS are you using? SIRFstar-based units go crazy in rockets in my experience.
 
What GPS are you using? SIRFstar-based units go crazy in rockets in my experience.

It's the GlobalTop PA6B, based on the MediaTek MT3329 chipset.

I buy them directly from GlobalTop in Taipei. They've been pretty responsive about questions in the past, so I'm optimistic about getting an answer.
 
Maybe this the answer to question about the GPS malfunction is here.

I don't think that's it. The ITAR limits (what that thread is talking about) are 1000 knots and 60,000 feet altitude. The glider gets nowhere near either limit.
 
It's the GlobalTop PA6B, based on the MediaTek MT3329 chipset.
That's the one that DIYdrones sells, though they use custom firmware for it.

I'll be curious to hear what if anything the vendor says. I assume there's no dynamics configuration for it (the Lassen IQ has an air mode that's better than car or pedestrian mode.)
 
Nicely done! It looks like you are getting some good experience. The gain loop is always a difficult one in autonomous guidance but you'll get it.

You should consider getting an airplane to take it up. Its super cheap and quick. We are always dropping stuff off of airplanes. Here is a link to my latest project, the X-37/X-40. I'll get some video of it flying this weekend. Once you work out the GPS and gain issues, you could go back to rocket flights.

The airplane flying chase was the drop plane.

https://www.spacecraftreplicas.com/x-37-x-40

Scott

IMG_1089.jpg
 
I corresponded with the GlobalTop (GPS maker) people today.

It turns out there is a dynamics setting in the GPS chipset I didn't know about - I'm going to check how this was set (didn't have a chance to do that yet). That might be the cause of the GPS dropouts in flight.

I also ordered some of their new "PA6C" GPS units (successor to the PA6B I'm using now) - they say 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 think I can get rid of 90+% of of it in the next flight.

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.)

This confirms what Adrian said - 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.

So things are looking better for the next flights in a week and a half.
 
Last edited:
It turns out there is a dynamics setting in the GPS chipset I didn't know about - I'm going to check how this was set...
Any details on this? I reviewed the Mediatek documentation and didn't see anything.
 
Any details on this? I reviewed the Mediatek documentation and didn't see anything.

This is what I was told (pasted from their email):

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>ï¼&#353;API_Query_Dynamics

I couldn't find it in the the manual, either, and asked about it - they said:

We got 302 & 402command data from MTK, but we donâ&#8364;&#8482;t verify them, so we donâ&#8364;&#8482;t list them in the manual.
 
At the 11/19/11 CMASS launch in Amesbury, MA Autonomy flew two more times.

It was a sunny but windy day. The glider proved its ability to cut through the wind well on its first flight of the day.

First flight went up on a ProX G125, nosed over, spiraled in controlled circles and deployed it's chute for a good recovery. Analysis of the telemetry showed that the GPS had lost lock again, the spiral recovery had been a default position setting for the elevons.

The second flight went up on an H110, nosed over, and went into a spinning dive. Autonomy 1 hit the ground very hard in a swamp across a small river from the field.

The rocket has not been recovered and is likely a total loss other than the many lessons learned.

Analysis of the telemetry data confirmed that Dave and I walked away from the pad without arming the electronics.

We did get nine flights from Autonomy 1 and plan to build Autonomy 2 to continue this project in the spring.

While I would have preferred a (much) softer landing for flight 9, I am truly delighted with the many successful steps we completed on the path to this very challenging project and look forward to continuing to work with Dave Lindbergh to achieve mission success.
 
Last edited:
Analysis of the telemetry showed that the GPS had lost lock again...
I'm wondering if there's some kind of EMI problem given that these GPS chipsets appear to work better than this in general.
 
If the "low dynamics < 1g" is a hard constraint, it's possible that condition was never met in the last 2 flights. A rocket with aligned fins can have less than 1G during the coast, long before apogee, but maybe the initial pitch-over for this glider exceeded the G threshold.
 
If the "low dynamics < 1g" is a hard constraint...
I'd have thought that the dynamics settings only affected the filtering, not the lock per se. Also, this GPS chipset has been used in rockets before (both by Dave and others) without these sorts of problems as far as I know. I'm sure Dave has thought harder about this though.

This is a great project. I've ordered the parts for a 2.6" diameter downscale that I plan to fly as a conventional RCRG, thread to follow.
 
As Boris said above, the Autonomy glider is no more.

On the first flight I was optimistic that navigation would work - I'd swapped the GPS unit with another one that I'd flown in rockets before (under a parachute) and which worked fine there.

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:

[YOUTUBE]cgpkNBFB-9g[/YOUTUBE]

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):

2011-11-19%20Altimeter%20noise_800px.png


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:

[YOUTUBE]qgqaQpKZduc[/YOUTUBE]

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.

This is the 2nd rocket I've lost in my rocketry career due to forgetting to arm the electronics. Like everyone, I've seen it happen to others too.

So one of my winter projects is to build a box that will sit next to the launch pad. This will connect to the ignition leads from the LCO, and have a relay inside, with the motor igniter connected to the relay. The relay WILL NOT CLOSE unless the box gets a radio message from the rocket saying that it's armed. I should have done it long ago.

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

2011%2011%2019%20CMASS%20Amesbury%20095_500px.jpg


Sorry, Boris!
 
Last edited:
It is a nice idea to have a safing device in line with ignition, but you should always have a preflight checklist and do a preflight, just like in an airplane, especially with guidance. I would think you could set it to do a left, right, up down sequence on arming that you can see visually.

Even if you have flown previously and armed it, there could be any number of control problems, servo failures, linkage issues that need to be checked each time you fly. Even if you have the onboard system do a check for full deflection of the servos(via the signal) it might not verify that the control surface actually moved.

My suggestion, on arming do a full deflection cycle of all surfaces, visually look at it, and make sure they move and re-center, have it pause at full deflection each time as well. Having one surface deflect and not another could cause the glider to arc into the crowd.

It should be pretty easy to implement with the software.

It's easy to forget things, I've been guilty once of doing a preflight and not catching that one of the control surfaces was deflecting the wrong direction, that was in the FM days before you had binding to a single receiver as an option, and I had it on the wrong model setting, everything was identical except for elevator direction:)


Frank
 
Last edited:
I'd have thought that the dynamics settings only affected the filtering, not the lock per se. Also, this GPS chipset has been used in rockets before (both by Dave and others) without these sorts of problems as far as I know. I'm sure Dave has thought harder about this though.

Looking at the video, it looks like it was pitching over during and after the boost, and there were high Gs throughout the flight. I would be surprised if the GPS could re-aquire lock under those conditions. Maybe for the next iteration you could measure and zero out the pitch acceleration during the coast phase?
 
Looking at the video, it looks like it was pitching over during and after the boost, and there were high Gs throughout the flight.

I'm not sure what you mean by "pitching over". It was a windy day so there was some weathercocking off the pad, which led to a non-vertical ascent. There were high Gs until motor burnout of course, but after that the rocket coasted to apogee at 0 Gs, not counting air resistance. (Or you could say it was decelerating, vertically, at 1 G due to gravity.)

After apogee there's a brief period of high G when the elevons go to glide pitch - it's moving fast so it pulls some G force until the glider slows to an equilibrium gliding speed.

After that the G forces should be low - just whatever is induced by the turn. It's descending at a constant rate, so there is no acceleration there. But my suspicion is that it's not just acceleration that can confuse the GPS - it may also be simple (constant-rate, non-accelerating) vertical motion. If the GPS is designed for use in a car, it may not handle a high rate of descent well, even if the rate isn't changing (and therefore no Gs).
 
Last edited:
Back
Top