Increasing the ArduPilot rudder authority for wind

I had a full day of autonomous flight testing in 20 knot winds, and it's clear that the default PID gains in ArduPilot were not high enough to handle any significant wind. So I upped them from 15 to 30 and the Superstar suddenly regained its tracking authority and was able to circle overhead well. I've modified the standard code in the repository with these higher gains so others who saw "flyaway" behavior in wind should now have sufficient rudder authority to stay on track.

If you want to tweak your own PID gains, they're in the first tab of the code. The current gains are as follows:

//PID max and mins
#define heading_max 30
#define heading_min -30

Please note that with this higher rudder gain, it's important to ensure that your FMA Co-Pilot is doing its job with wing-leveling. Once you're in the air, set it to the highest gain it can take without oscillating (if it's a clear day and you've calibrated it right, that should be the maximum rotation of your gain knob on your transmitter).

Another issue with using ArduPilot 1.0 in high wind is that altitude hold is pretty sloppy and it has trouble making progress upwind. That's because ArduPilot 1.0 just uses the throttle for altitude control. When the plane is going into the wind, it tends to rise. ArduPilot will then cut the throttle, but in a good headwind, the plane may not descend. Instead, it will just hover or even move backwards a bit.

That's why we're shifting to elevator+throttle altitude control in the ArduPilot 2.0 software. With that the plane will point its nose down a bit and keep the throttle going to make headway against the wind. It's a much better way to control altitude. Jordi's testing it this weekend and may have the code ready to release this week.

Views: 496

3D Robotics
Comment by Chris Anderson on March 10, 2009 at 11:48am
Tychoc: The 2.0 code will initially just support the standard EM406, which is what most people have. But we'll add LS20031 support over time. There's no technical hitch, we're just trying to minimize the number of code bases and there isn't enough memory in the atmega to support both in the same code.
Comment by Tom in NOVA on May 10, 2009 at 1:53am
I assume there is enough memory now in the 328 Atmega chip to accomodate both binary (EM406 and GS406) and NEMA (LS20021 and others) codes in one program. Is there enough processing power for 4-5 HZ updates? I understand that the new version of the software coming out around early June will have support for both GPS (at 4-5 HZ?).

Not knowing the programming side much, does the LS20031 NEMA code incorporated into 2.2 and higher verisons provide equally good GPS-related performance as the GS406 4 hz (UBox) in binary?

3D Robotics
Comment by Chris Anderson on May 10, 2009 at 7:03am
@Tom: Yes, 5Hz GPS modules will be supported in 2.2, out in a few weeks. The NEMA parser is not specific to any GPS module. We have not benchmarked the LS20031 against the Ublox, but they're both good.
Comment by wardhanster on September 16, 2009 at 9:08am
can some one tell me what is the algorithm behind the waypoint navigation... like how you control the heading of the airplane w.r.t longitude and latitude... i mean to say is how you all control navigation controls such that the airplane navigates to the selected waypoint


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service