I've looked through the code and, unless I've missed it, there is no integral term in the calculation of nav_bearing. Specifically, in navigation.pde:
static void update_crosstrack(void)
{
// Crosstrack Error
// ----------------
if (abs(wrap_180(target_bearing - crosstrack_bearing)) < 4500) { // If we are too far off or too close we don't do track following
crosstrack_error = sin(radians((target_bearing - crosstrack_bearing) / (float)100)) * (float)wp_distance; // Meters we are off track line
nav_bearing += constrain(crosstrack_error * g.crosstrack_gain, -g.crosstrack_entry_angle.get(), g.crosstrack_entry_angle.get());
nav_bearing = wrap_360(nav_bearing);
}
}
The omission of the integrator doesn't make sense to me, so I'm assuming it's been tried before and was removed for some reason. Can someone fill in the details on why this is?
The effect of *not* having an integrator on the crosstrack error will be that the vehicle is carried downwind from the desired track until crosstrack_error * g.crosstrack_gain produces the required crab angle to reach an equilibrium.
Certainly integrators can be fussy to tune and unless proper antiwindup logic is in place integrator windup can cause large overshoots or limit cycling. But the benefit of an integrator to performance is substantial. Additionally, all the other control loops have an integrator, so why not on crosstrack?
Replies
I hit the Stop Following button on my last reply a couple of minutes ago thinking it would toggle but it doesn't and I can't figure out how to undo that action. So this post hopefully will allow me to follow this thread that I commented on. If someone knows how to reset the Stop Following parameter on conversations I would appreciate knowing.
Thanks
Jack Edwards
I am working on an autopilot for a 40 foot sailboat. Last summer it steered my boat 40 miles. It does not have cross track error handling and I am trying to add it. I was looking at ARDUPilot cross track error handling and came to the conclusion cross track error handling needs a PID with the Integral term.
Does this make sense? ARDUPilot (AP) adds a bearing correction proportional to the cross track error in meters. Bearing Correction = Gain * Cross Track Error (in meters) so
Cross Track Error = Bearing Correction/ Gain.
Consider the case where cross wind is 10% - 50% of vehichle speed. So the plane has to crab at an angle to the wind so its course veleocity is equal to cross wind velocity. The angle is arctan(cross wind speed / vehicle speed).
cross wind %, Correction angle, resulting Cross track error
10%, 6 deg, 57 m
20%, 11 deg, 113 m
30%, 17 deg, 167 m
40%, 22 deg, 218 m
50%, 27 deg, 266 m
Ity seems to me that a PID with integrator could reduce this droop.
At this point I have implemented and will soon be testing a PID for track following in the 2.26 code. However, I don't yet have any code that resets the integrator, though I don't think it should be a huge deal for an aggressively tuned PID with a reasonable IMAX. Shouldn't be too hard to reset it when it switches waypoints, though.
Like I said, untested so far, I just got telemetry a couple days ago so I'm in the process of re-tuning everything else on my plane first.
I agree that accurate track following is important. In fact I've made two blog posts detailing my fight with this exact issue:
http://www.diydrones.com/profiles/blogs/pid-tuning-for-high-winds
http://www.diydrones.com/profiles/blogs/quest-for-the-perfect-fligh...
Right now I think there are two things holding back practical auto-landing. High accuracy track following, and turn prediction. I believe Michael Oborne has tackled the turn prediction issue as stated in the comments to the 2nd link above, though I haven't had a chance to test it yet.
Point of order: the 4500 in the first line of code should be a #defined constant.
Sorry, I was raised in the "never, ever, ever, ever code a 'magic number' " school of programming. :^) Carry on.
I have never found an integrator term on the cross track error necessary. How tight are you wanting to follow the track line?
I would estimate that my reasonably well tuned SkyWalker stays within 3-4 meters of the track line unless the wind is quite stiff.
We never had an I term on cross-track. I would be happy to add it if I hear sufficient request from it from people who find the performance of the current scheme lacking. I don't think it is worth adding "just because it would be 'better' ". Parameter space is still a little bit of a commodity.
This is something that I'm concerned about as well. I've never been able to get my plane to follow the track as well as I'd like. I was trying to work towards an autoland on a relatively narrow (10m wide) runway, but I couldn't even get it to fly directly over the runway.
The other issue with tracking that I found is that the track is set from the location of the plane when it "hit" the last waypoint, rather than from the last waypoint to the next waypoint. This can mean that the actual track itself can be inaccurate by up to the radius of the waypoints (30m or 40m by default, I believe?)