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

Comment by William on March 9, 2009 at 9:50am
Chris, Could you take a moment for us non programers, and explain how these PID values work? How do these values differ from the servo settings under the first tab. and what is the max, and min usable range? Also. are these PID values doing the same job as the 2 adjustable pots on the PDC10, amd RCAP?

3D Robotics
Comment by Chris Anderson on March 9, 2009 at 10:08am
Think of the PID Max and Min numbers as volume controls. The navigation algorithm will move the rudder proportionally (within the Max and Min range) to the direction the plane should fly. The wider the Min Max range, the "louder" the signal and the greater the rudder throw. Those constants that you can change in the first tab are used in the PID&Control tab in lines like this:

heading_output = constrain(heading_output,heading_min,heading_max);//limiting the output....

I would suggest that the values should be between 15 and 30, depending on the aircraft and conditions. The lower the number the more gentle the steering, which is good if you don't have FMA stabalization or if you stabilization isn't working very well. But if it's too gentle, it will be overcome by the wind, as was the case with the setting of 15 on our Superstar. However 45 would be too much and could lead to spins and other cases of stabilization failure.

And to answer your last question, this setting is indeed analogous to the adjustable gain pots on other autopilots.
Comment by jalves on March 9, 2009 at 4:39pm

With the last code posted (Ardupilot1.0 ) my Ap doesn't fix the home position correctly. it fix 0 0 100 for lat(0) lon(0) and alt(0)

but afterwards, it assume correctly the variables lat and lon in line with gps stream, but since home is (0,0) then distance is about 63000.

Can you give me some advice?

I only have one Ap code working correctly, I compare both the gps_navigation tabs and they are equal, thus I am lost regarding where the problem is. TIA
Comment by smguest on March 9, 2009 at 6:37pm
I noted some initialization problems and wasn't sure if it was because I was using the GPS from my OSD (and the OSD needed an extra sentence that the ArduPilot did not), but it appears that I was overwriting the parser's "buffer" variable until I declared it to be 128 characters (char buffer[128]).

I'm not sure that it was necessary but I wound up adding the following code after the yaw_control() statement in the init_startup_parameters() method to make sure I was getting consistent readings before I set the startup position variables.

float temp_lat, temp_lon;

temp_lat = -9999.0;
temp_lon = -9999.0;

while((abs(temp_lat-lat)>0.000001) || (abs(temp_lon-lon)>0.000001))
Serial.println("Improving lock...");
temp_lat = lat;
temp_lon = lon;

This now seems to give me a good lock as I've flown the airplane successfully with the ArduPilot in both RTL mode and waypoint mode.

3D Robotics
Comment by Chris Anderson on March 9, 2009 at 6:52pm
jalves: we're not seeing that problem with the EM406. What GPS module are you using?

Comment by Brian on March 9, 2009 at 8:47pm
Chris - Like always I just have a ton going on so it makes it hard to keep up with with ArduPilot. I'm working on testing w/Ardupilot 1.0 code but am wondering if there is a reason not to move forward to the ArduPilot 2.0 code? I'm also wondering if this 2.0 code is the same code that can replace FMA Co-Pilot? Thanks -Brian

3D Robotics
Comment by Chris Anderson on March 9, 2009 at 8:48pm
Yes, the 2.0 code will replace the FMA Co-Pilot. I'll post it tomorrow.

Comment by Brian on March 9, 2009 at 8:55pm
So no reason not to move onto the 2.0 code?
Comment by jalves on March 10, 2009 at 10:38am
I am using the small locosys LS20033.
But simulating a em406 via software at 4800bps give the same results
Tinkering with the code, I found that If I put some serial.print(lat) to see how lat is being calculated, this does the trick and the AP fixes home.
This behaviour is puzzling me, it doesn't follow a trend.
Comment by tychoc on March 10, 2009 at 11:02am
Did I read somewhere that we who bought the locosys + daughterboard will not be able to use the 2.0 code?



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