PID tuning for high winds...

After a grossly failed attempt at fully automatic landing due to mild winds (luckily no damage), I decided to go back to the simulator and see what PID tuning is required to handle the harshest flyable wind conditions that I could throw at Ardupilot. Because I fly in the mountains and I'm interested in fully automatic take-off and landings, path following needs to be as accurate as possible.


Xplane settings:

Plane: Radio controlled PT60

Weather: Wind: 25kts at 145degrees (from waypoint #3 to #5, never a direct head or tail wind). Shear Speed/Direction 0, Turbulence 0.




Result #1: 


As you can see the air speed (and cruise speed) is around 19m/s and Ardupilot is calculating the wind speed at 12m/s, which should be much higher than you would ever normally fly in.

3689429973?profile=originalResult #1 PIDs:





Result #2:


Much higher Nav/Servo P settings, but only marginally better path following, by simply reducing the "bulge" at each waypoint. However as I discuss below, these higher P settings can start to cause major problems.

3689430046?profile=original Result #2 PIDs:





Result #1 PIDs with no wind whatsoever:


I wanted to find values that still worked relatively well when there is no wind, as you can see they are not too bad but there definitely is some snaking caused by the high Xtrack gain. Lowering this to around 100 reduces the snaking, but virtually kills and high wind path tracking at the same time.




What I've learned:


When dealing with wind, Xtrack Gain and Entry Angle seem to make the biggest difference, increasing P or I values above a no wind situation while can offer minor improvements also introduce a level of risk (at least in the simulator) where in some cases the plane would start rocking and eventually lose control and go into a dive. However increasing the Xtrack gain too much (ie: 1000) often results in high frequency "snaking", because the wind blows the plane slightly off track, Ardupilot over corrects to bring it back onto the track, straightens out, then the wind blows it off track again... Rinse and repeat.

Based on the different forum/blog posts regarding PIDs, they still don't make much sense to me and I haven't been able to get I or D settings to actually help matters, despite hours of tests. :(

The biggest problem with accurate track following appears to be with the fact that Ardupilot doesn't have any turn prediction, so it doesn't start its turn until its right on top of the way point, at which time the wind has already started to blow the plane off track and the PIDs need to be set sufficiently high enough to get it back on track before the next way point. This results in the path "bulges" near each way point where the approach has a tail wind, and "snaking" after way points turning into a headwind, as you saw in the screenshots above.


Does anyone have any suggestions on improving things further? Unless I'm missing something, I would be surprised if anything better than the above paths can be achieved until additional smarts are added to Ardupilot, along the lines of this Turn Prediction.


If anyone wants to give it a try, below are the flight plan and parameter settings that I used:




E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Doug: I just ran a no wind test with the bank angle increased to 85degrees and while it reduced the initial "bulge" immediately at the waypoint, it still over compensated for the turn almost exactly how a 45degree bank did. So the "bulge" is now inside the waypoint square entirely, rather than roughly half outside and inside.


    The net result appears to be pretty much the same, so I don't see any advantage in increasing the bank angle anwhere near that amount.


    Isn't the "I" or "D" values in the PIDs supposed to help reduce the overshoot? Seeing as a bank angle of 45 and 85 both overshoot the turn almost exactly the same amounts, it seems like there should be a setting somewhere that helps reduce this?

  • Developer

    Also (and this may be stating the obvious) if you want to minimize the bulge at turn points, increase the allowable bank angle.  If you are limiting to 20 degrees bank you will get huge bulges at the turns.  If you allow 80 degrees you will get very little (but incur other issues).


    As a further improvement (with the current code) you can plan your mission with intermediate waypoints along course lines so that you slow down before a turn and then speed back up after.


    Finally, the type of path planning that is really needed to best deal with wind is fairly sophisticated, as it requires a wind estimate and a forward looking capability to see how the wind will impact an upcoming turn.  EG you may want to start turning earlier if you have a tailwind and later if you have a headwind.

  • Developer

    Just a side note if you want to get the "minimum time" approach described above you can tweak the "way point radius" in APM Planner for your given aircraft and that might emulate something to what I'm using.  


    Always clean up the bottom control loops first! ;) But thought you might like to play around with what you got in the mean time.


  • Developer

    The oscillation is due to the fact that the heading control is under-damped (not path planning).  Path planning helps but is not the problem. There are two things that I do that helps this issue.  

    1: Estimate your course over ground better by having a separate part of the DCM track heading in a different way.  It is very similar to the algorithm that the DCM in APM uses now, except I track another one that I call "smoothed course over ground".  This is nothing more than the GPS course over ground smoothed by the gyros using a much faster time constant on the heading estimation gains.  This will help reduce some of the lag in the gps which is the main culprit in pushing the heading controller into the right half plane.


    2: I control the heading change rate instead of heading as I described in my paper.  If you use this method, your gain margin significantly increases beings you are no longer depending upon the ground speed being close to your trim PID ground speed.  It is all Ground speed dependent.  Using my method eliminates that factor and your PID takes that into account. All the while this keeps the PID tuned in the same envelope so you can guarantee the damping ratio will stay constant.  As it is written now in APM (last I checked), the damping ratio will change sinusoidaly with wind direction and heading.  

     About your tracking following idea.  Being on track isn't going make the UAV not oscillate.  It is like saying your homemade cruise control in your car is perfect without ever testing it up and down hills.  Well of course it works great if you set up the command points to never get the error to be outside of steady state (no oscillation).  It would also not oscillate if you only make track changes of 5 deg to every waypoint.  So hopefully you see that instead of trying to improve the setup for the controller by handicapping it, you should really just improve the controller.  And that is why I developed that method.  Finer control always stems from the bottom controllers up not the other way around ;)


    Another note on your track following and way point switching Idea.  I also do that!  You calculate your radius of turn based on your ground speed and the trigger the way point switch at that radius.  Or at least something to that nature.  But really the best way to go about doing it is to set up small orbits close to the waypoints that define your optimal trajectory around the transition.  Your 45deg out approach is one of three ways I like to look at this possible turn transition.  Another one would be guaranteed crossing over the way point.  And the last is equal straight line distance across all waypoint transitions reguardless of the turn angle.  So basically the small orbit or loiter circle you use to transition slides in and out.  In your 90/45deg case the orbit circle is tangent to the two track lines.  In the "fly over the waypoint" case the orbit's outer radius crosses over the waypoint, and the last case the transition orbit is somewhere in between based on some geometry and the turn angle.


    This is a very complicated answer for the trajectory following but like I said it doesn't solve the heading controller issue, it only gives it a handicap so to speak.  


    Picture is worth a thousand words!

    3692293105?profile=original -Hope I've helped and not muddied the water!


  • Hi Mike, good to hear it :P

    In my opinion it is a matter of attacking the problem in a right way. If you want a smooth trajectory plus stability (because the cross wind), I believe that the better solution is to control in wind axes or stability axes (angles of attack, sideslip, bankangle, etc). But for Ardupilot maybe this is now a little bit far.

    Anyway, it is interesting, and always welcome, to see another ways for attacking this problem. Keep us posted!

  • 3D Robotics

    Mike: Turn prediction has been on our to-do list for some time, but there have been higher priorities. If you'd like to submit a patch that adds this, that would be great and we'll have the team consider it ASAP. Otherwise, it's just a matter of waiting until the dev team gets to it.


    As an open source autopilot, we look to the community to contribute the features they want added, while the core dev team works on basic architecture, stability and platform evolution to new hardware. This is a great example of the sort of thing we'd look to the community to create. The upside being that you not only get the feature sooner, but such contributions often lead to an invitation to join the dev team and all the goodies that come with that ;-)

  • Hector, that will be one of my next projects, seeing if I can create a flight plan with a significant number of additional waypoints that forces the plane to actually follow the path that I want. Obviously this is far from ideal and Ardupilot should be able to get the same result with just a single waypoint at each corner, but it should be an interesting exercise nonetheless. It may also help prove my original blog post theory about the path bulges. 

  • Ryan, if I read your blog post correctly the primary goal of your work here is to eliminate the oscillation in the track following when there are high winds, which would definitely be welcome.


    My only concern is that eliminating the oscillation doesn't solve the root cause of the oscillation, which in my opinion has more to do with the lack of turn prediction than anything. If you notice my screenshot for "Result #1 with no winds", even when there is no wind whatsoever in the simulator the plane still oscillates and the path still bulges at every waypoint. If there is no bulge at each waypoint, there will be less room for the plane to start oscillating in the first place.


    Ideally (in a perfect world) at each waypoint the plane would make a smooth "sweeping 90degree" turn hitting the exact waypoint at the 45degree mark, starting the turn exactly on the path and ending the turn exactly on the path. If it does that, then oscillations shouldn't occur to begin with, at least for straight track following. In each of my above tests, by the time the plane had completed 50% of each leg, any oscillations originating from the waypoint turn had been smoothed out. 



  • Developer

    It has been so long that I forgot that I had already written something on this idea.  If I remeber correctly I hadn't cross checked a couple things before I got side tracked and it  wasn't 100% validated by my sim.  Now that we have the HIL I'll push some code around and see what we can come up with. Here is the old post

    And here is the link to the write up.


    Standy by for some more validation and updated notes on this!

    Thanks for the reminder!


  • Developer

    I did some work on this a while back.  I'll have to do a write up on it and see if it is worth the dev team including it in the code.  It might help bring some linearity to the heading/ground track controller.  I'm busy with work here at the moment but I'll revisit this and post soon.  Improved Heading Controller



This reply was deleted.