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.
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.
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
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.
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?
Comments
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;
delay(5000);
gps_parse_nmea();
}
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.
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
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.
-
1
-
2
of 2 Next