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?

Views: 752

Reply to This

Replies to This Discussion

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?)

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. 



That's the thing: crosstrack adjusts for wind. If your plane is significantly more off-track when there's a "stiff wind," crosstrack isn't working properly.

Consider the case of automated landings, something we should strive to do well, how far off the track line is "good enough," and how tight does it need to be before it crosses the line to "just because it would be 'better'"?

If parameters are a problem, we should make some of them compile-time options.

The current proportional-derivative (PD) will compensate for wind, it just won't do it perfectly. You only use an integrator to get that last 1%. Is 99% good enough? Maybe not for landing, but probably everywhere else.

I'd say it's worth more than the last 1%.  Properly tuned, an integrator will reduce the rise time and settling time when acquiring a track.  It will also allow the proportional gain to be reduced, which may improve the steadiness and stability margins. People are likely running higher crosstrack proportional gains than is ideal because they're trying to reduce the steady-state error due to wind.

In a track following controller, the crosstrack integrator is really the lateral plane integrator that is most important to performance.  It struck me as odd that we would have integrators for heading and roll, which don't really help the track-following problem much, but not for crosstrack.

If a crosstrack integrator is not useful for everything, then set the gain to zero in those cases.  If there isn't room for the extra parameters, then maybe there will be with the next hardware upgrade, and perhaps we should be thinking ahead for then.

Jonathan - Compile time options are deemed not user friendly, and we are trying to minimize use of them.  


Alex - I have no argument that having an integrator term would be "better" and not having it is not ideal.  However, I have never felt it necessary in actual practice.  There are lots of things that could be in the code but are not...  Like I said, I'd be happy to add it if people feel performance is inadequate without it, but my experience actually flying to code is that it isn't necessary for 99% of users.  If you think it is a big deal put an issue in the tracker for it as a future feature and it will get added to the "someday" list.


Mike - did you see the picture I posted several weeks back of my Skywalker sitting within 1 meter of the runway centerline after an auto landing?

I feel like if we're facing serious hardware constraints that mean we can't have more parameters, we absolutely should be evaluating whether some of them should be compile time options... And if we're not, then what's the problem? I'd like to code it myself, but I still don't understand how the parameters work well enough to add one...

It's cool that your plane landed on the centerline once, but can it do it repeatedly? Can it do it in wind?

Correct me if I'm wrong, but without an integrator, won't the plane always, always, always be down wind from its track, no matter what?

Doug - I did. I kept the picture in a window for 3 days. I was very impressed, and it had a certain beauty to it.


What I am about to say should not take away from that. I don't want to be impressed. I want to instead be thinking "yea, big deal, of course it can do that. It can do that 999 times out of a thousand, in all conditions, and by this time next year, we'll solve that .001th issue too." I share that with complete respect, admiration, and appreciation for the achievements and progress made in the community to get the point where we are today.


I agree with pretty much everything you said. However, the devil is in the details. I find that the biggest issue with an integrator is preventing wind-up and other problems. You can design a fantastic integrator gain on paper that causes all sorts of problems in the "real world".

That said, it is something necessary for precision flying. I am just not sure how often precision flying is required, outside of landing. Is there any problem with tracking a course with an error of 10 meters? If I am surveying or photo-mapping, maybe. If I am just flying something around for fun, 10 meters is fine. Would 1 meter be better? Sure. Just be careful not to turn that gain up too high.


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.


Reply to Discussion


© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service