Micropilot Gains

[flyzguy]

I've got a flying wing with major navigation problems, though the inner stability loops appear to be fine. We have tried P gains anywhere from -10 to -1500 with essentially the same result: tight, back and forth turns. The customer support has been only slightly helpful. Has anyone had experience setting gains for an elevon flying wing with micropilot?

[flyzguy]

I can share vrs files and datalogs if anyone would be interested!

[corosplat]

Hi flyzguy, I encountered the same problem and can give you a few tips.

- First make sure you have the latest official release firmware (3.2.86)
- enable smooth gain scheduling in your vrs file
- make sure your autopilot reads level when the plane is set up level
- disable mixing limits for elevon control

Make sure you inner control loops are well tuned, especially aileron-from-roll. You should see measured roll follow target roll exactly with maybe a half second delay and little overshoot.

when you are happy with the aileron-roll control loop, you can move on to roll-from-heading. Use only "flyTo" commands (not "fromTo") in you flight script so you don't complicate it with the heading-from-crosstrack control loop. Don't use an "I" term in the roll-heading control, just P and D. Start with a fairly fast flying speed, and adjust P until you oscillations disappear. Move on to lower speeds in your gain schedule which will take smaller values of P.

Part of the problem with roll-heading tuning is that the gains are scheduled by groundspeed (despite what it says at several places in the manual) whereas the dynamics of roll- yaw-rate are a function of airspeed.

There is a (good) chance that you have already come this far and still have problems with oscillations in heading control. I think the source of the problem is GPS latency. The mp2028g (in the absence of a compass module) uses GPS alone to determine heading which can be time-lagged from the actual heading by up to 2 seconds. So when you are turning to achieve a target heading, the plane overshoots the target heading before the measured heading catches up. Then it has to turn back the other direction and overshoots again, etc. setting up the oscillations. I think people get away with it with slow-turning trainers with inherent stability, but with an agile flying wing with near-neutral stability, the measured heading latency becomes a major factor.

The only solution in that case is to keep reducing your turning effect, which isn't very satisfying, or install a compass module (which I haven't tried) or switch to a GPS with lower latency like the UBlox upgrade.

Good Luck,
Splat

[danstrider]

Flyguyz,

For what it's worth, we've used gains that were orders of magnitude different than what you listed as the range you tried. If you're getting results in the right direction, try doubling (or halving) the gains even.

Is this perchance for AUVSI's Student UAV Competition? What school are you from?

Dan

[flyzguy]

Yesterday we worked on tightening up the aileron gains and got performance where the actual roll was matching up with the desired roll within 0.4 seconds with no overshoot, so I am pretty happy with that. I am unfamiliar with mixing limits and will look into that to make sure it is disabled. Since we don't have the compass module (and no time/money to afford one) we should probably tackle the GPS heading latency effect by reducing our turning. Do you think this means reducing the gains or reducing our maximum turning angle? Our mission involves flying in a relatively straight path over miles of distance so I don't see any reason for us to be struggling with this particular loop ; we don't need perfection.

In yesterday's flights we were doing tests where we just told our plane to simply fly south (turn 180; wait 3000; etc..) and we were able to get a fairly straight path out of it. It was only when we aimed to follow a course (a series of points about 300 ft. apart with 40 ft. waypoint diameters at right angles to eachother) that the oscillations returned in an extreme fashion, finally ending with the plane overcorrecting so much (or so late?) that the plane was no longer making forward progress, just kind of strafing back and forth on a line perpindicular to the desired flight path.

As far as the AUVSI competition, I wish this was for it, but it is actually a University of Colorado UAV designed to glide science payloads down from a weather balloon. We are performing our tests with a 3/4 scale glider with a pusher prop to gain intial altitude before turning the throttle off and putting the MP2028g in control. The full scale glider has its second hot-air balloon drop test tomorrow to fly to a waypoint and deploy a parachute for recovery from about 9k ft. The first hot-air test was plagued by interference and our MP2028g was not functioning at all really. However, our missleworks pyro parachute deployement board worked flawlessly and saved our plane!

[flyzguy]

Oh, and danstrider, what type of planform are you flying and what are the gains you are using?

[kd7ost]

What call sign are you guys flying. I'd like to track it from here.

Will it be hitting local I-gates and transmitting on national APRS frequency of 144.39?

Dan

[flyzguy]

Well, more flight testing today and more wandering turns. Micropilot did not answer the phone from 2-3PM Mountain time or respond to my e-mails with datalogs and vrs files so I guess we are pretty much running on luck that the plane will fly anywhere when we do our full test. Pretty lame of them. Is it a Canadian holiday?

As for tracking the launch, I'm not much of a communications/tracking guy but it looks like all the info you might want should be here: http://eoss.org/flight/prediction.htm

[kd7ost]

Well I don't see any call signs to track. I do see with winds out of the South that your deployment area should drift you north to the dirt road in that piece of no mans land away from the agriculture. Good choice. You guys could probably watch it come in.

Good luck.

Dan

[kd7ost]

I went to Ralph Wallio's site to look for data. Did some digging and cross checking and was directed back to the EOSS site to another page. I found out your "Peregrine" call sign for the flight is KC0YA-12. The frequency they put your radio on though is 145.600. If there is an I-gate in the area tuned to that frequency we may be able to watch it here. Looks like launch is scheduled for 7:30 am MST.

http://www.findu.com/cgi-bin/find.cgi?call=KC0YA-12

You'll notice a line like this.

KC0YA-12>APT311,EOSS,qAo,K0ANI:/141723h4004.10N/10510.97WO073/013/A=010379

You can derive the time, lat and lon out of that data string but the last number following the A= is the altitude in feet.

[toxicmouse]

In yesterday's flights we were doing tests where we just told our plane to simply fly south (turn 180; wait 3000; etc..) and we were able to get a fairly straight path out of it. It was only when we aimed to follow a course (a series of points about 300 ft. apart with 40 ft. waypoint diameters at right angles to eachother) that the oscillations returned in an extreme fashion, finally ending with the plane overcorrecting so much (or so late?) that the plane was no longer making forward progress, just kind of strafing back and forth on a line perpindicular to the desired flight path.


my guess is that your navigation software takes the current position and the next waypoint to calculate path and/or bearing? if so, and your turning circle relative to the distance to the next perpendicular waypoint is large, then the oscilations will increase after each waypoint (it can be calculated what the maximum ratio of turning circle radius to dist between waypoints is, but it is rather academic).

a possible solution may be to compare the bearing to the next waypoint and the bearing from the next waypoint to the one after. if there is a large difference in bearings, then get the UAV to sidestep occasionally. by sidestep i mean a left turn/bank followed by a right turn/bank or vice versa. this will reduce the angle the UAV will need to turn through when it reaches a waypoint and calculates its next bearing.

this sidestep is not a good idea if the waypoints are far apart, but for 300ft it may well be worth considering. this does not work at all if the distance between waypoints is less than twice the turning circle radius.

[poynting]

Corosplat did a pretty good job of diagnosing the problem, I think.

What is your maximum commanded roll (bank) angle? It sounds like you may be seeing the effect of GPS latency, given that you can roll to command so fast.

When you hit a waypoint, you see a step change in commanded heading (course, really), which causes a step input to commanded roll angle, probably to max roll angle, based on your heading-to-roll-angle gain. You quickly roll to command (in 0.4 sec), and your ground course begins to change rapidly. I'm guessing that you're using a 1Hz GPS, which probably filters GPS course somewhat, so that a couple of updates later you have significantly overshot commanded course, at which point you command full roll angle the opposite direction and the oscillation continues.

You may have to very significantly decrease your bank angle from course gains. Given how much phase lag you probably have, I would suggest starting with very close to the smallest allowable value and then double until you see oscillations, then back off. Tune the P component first, then try for D. This part of your navigation loop doesn't need to be too aggressive, especially if you're flying a lot of long paths, and not a short, tight waypoint course.

[danstrider]

Flyguyz,

We're using a modified 12ft Senior Telemaster. I don't know the gains exactly, but if you pm me your email address, I'll ask our autopilot guy to send you the vrs.

Dan
http://www.ncsu.edu/stud_orgs/ar

[kd7ost]

I don't see any current data on the EOSS flights. The glider fell off national APRS frequency early this morning just East of Boulder. I figure they changed transmit frequency to keep it off the national system. It looked like where they might be launching from.

But there was 4 other capsules from EOSS scheduled to go and they're all silent. Maybe the flight was scrubbed, or they changed all the frequencies so we can't see them.

Dan

[flyzguy]

Well, you guys were right about seriously limiting the maximum bank angle of our glider. Today I threw our bird out of a hot air balloon at 5,000ft. and controlled it by RC briefly (in the case the control gains were way off, we would have some flight data) before switching over to the autopilot and letting her go off on her own. It was a beautiful morning and the craft just slipped through the air before I leveled her off. Very stable. With the maximum bank angle set to around 10 degrees, the plane tracked a perfectly straight line to its first and only waypoint approximately 3 miles away before doing 1.5 loiter circles over the target and popping the chute. It was beautiful. I just got up from a nap (college kids usually don't do 5 AM roll-outs) and am going to prepare for tomorrow's weather balloon drop. We should have more data, pics, etc.. soon. Only failures of the morning were the on board video system and we lost one winglet upon chute landing, but its already re attached.

I am sorry that it was so hard to locate the callsigns for our data. They may have changed frequencies because we were testing so near lockheed, starysys, and a cell phone company, but I am not sure. You might have good luck tomorrow if you send your tracking questions to Mike Manes: manes@attglobal.net who will probably be happy to make sure you can track tomorrow's flight.

[flyzguy]

EOSS has graciously compiled some data and pictures and has already hosted it on their site:

http://www.eoss.org/ansrecap/ar_130/recap116_117.htm

[poynting]

It looks like the EOSS flight went up this morning, any word on the results?

http://maps.aprsworld.net/map/track.phtml?call=KC0YA-12&skipTable=0&skipBogusCheck=0&showRawPackets=0&start_year=2007&start_month=4&start_day=14&start_hour=23&start_minute=18&end_year=2008&end_month=1&end_day=1&end_hour=0&end_minute=0&end_now=1&date_search=1

[kd7ost]

I dunno,

Last packet I see in the raw data was at 34,000 feet and descending. That was 7 hours ago. Somthing must have shut down before it got down to the ground. It might have kept flying right, and chute opened, so they might find it in the general projected landing area.

If it just went dead and didn't track anymore, it'll be a needle in a haystack.

Dan

[flyzguy]

:mad: Sadly, the nichrome wire cut away device failed to melt the parachute cord and cut our bird away. It just went up and came down tethered to the string like a "normal" payload. It broke my heart. Worst of all, after surviving the landing impact in tact, it was drug through a cactus field for about 500 yards, severly damaging the elevons and parachute tube on the underside of the plane.

It went up past 90,000 ft and never got to fly! :(

[kd7ost]

I use a servo actuated cutaway device. I find it's highly reliable and doesn't take so much power to operate.

Bummer on the flight and results. You'll get it fixed and move on though. ;)

Dan

[kd7ost]

Hey,

Any idea why it didn't send anymore packets below 34K? Or maybe it did but you guys were getting then direct. Maybe it moved out of range of a digipeater and or I-gate.

Dan

[poynting]

Sorry to hear the flight didn't go well. Are you going to have time to give it another go? Keep us up to date.

[joelhaasnoot]

Let's put it this way: atleast you found your payload, eh? Some guys from MAKE magazine, a DIY magazine, had a ballon project, but they lost their ballon and weren't able to recover the payload... with 4 cameras on board and lots of other stuff...