Autopilot Control

[transmitterdan]

Originally Posted by DotDun

Sorry, it wasn't two weeks ago, it was 10 days ago. Does that fix the untrue part?



Or did you miss post #5 in this thread:

I guess you don’t know much about Sean. He is an accomplished world sailor and has impressive technical skills. This isn’t the forum section for belittling people especially when it isn’t deserved. Your interpretation of the comments is in error in my opinion.

[transmitterdan]

Originally Posted by boat_alexandra

DotDun,



I would like to hear about different ways opencpn can improve autopilot route following from how it is currently handled.



Obviously improvements are subjective. I have my own ideas, in addition to a few others discussed, but new ideas are welcome.

Sean,

Do you have a git repo for the open source pilot program? Maybe we can discuss it more over there without so much distraction.

[DotDun]

Originally Posted by boat_alexandra

DotDun,

I would like to hear about different ways opencpn can improve autopilot route following from how it is currently handled.

Obviously improvements are subjective. I have my own ideas, in addition to a few others discussed, but new ideas are welcome.

First, I've only tested OpenCPN talking to my AP. OpenCPN for me is a tertiary backup that I've never had to press into live service. When I did test, it operated as expected, the same as my off the shelf chartplotters.

Before improving it, I think it's good to understand the current architecture and today's functionality. For this discussion purposes, today's components are:

Chartplotter (CP)
Autopilot Control Head (APCH)
Autopilot Computer (APC)

Typically, communication between the APCH and APC is proprietary, i.e., no standard messages defined but they do utilize the standard network underlying layers (most modern ones utilize N2K). If the CP is the same manufacturer as the AP system, they will allow APCH functions on the CP, but again, this utilizes proprietary messages. (I doubt we need to discuss reverse engineering proprietary messages.)

AFAIK, there are no standard messages for telling the APC information about 'Auto' or 'Wind' mode, as these are mostly simple button pushes. And again, these are proprietary between the APCH and APC.

What has been standardized is the messages for telling the APC the information to utilize in 'Track' mode. The standard includes things like:

Orig waypoint ID
Dest waypoint ID
Dest waypoint (lat/long)
Distance to waypoint (DTW)
Bearing to waypoint - true or magnetic (BTW)
Range to waypoint
Velocity made good
Arrival

For the sake of not reading the standard, I think the above covers what's needed for this discussion.

Also, AFAIK, OpenCPN has no access to N2K...?? So, if there are any extensions to the CP > APC 'track' mode dialog (pgns 129283,4,5) inside N2K, OpenCPN wouldn't be able to utilize it.

The current architecture was designed for the CP to send the 'track' information to the APC one segment at a time. Upon arrival at a destination waypoint, the next segment 'track' information is sent.

Most current off-the-shelf AP systems require user acknowledgement when new 'track' segment information is received. As you've gathered from my previous posts, I personally believe this is a good thing. If the system autonomously changed goto waypoints, people would utilize this and fail to maintain watch. I know you believe that's 'not my problem' thing, but I'm sure you don't want your application enabling someone to get hurt.

I do think there could to be a function to maintain course to steer (CTS) type tracks. To me, a CTS track is one where current is forcing the boat to crab in order to maintain a straight track. There was a big discussion about this years ago on CF. Basically when crossing a known current stream (ex: English Channel or Florida Straits), some have the position that riding the current and then correcting course when out of the current is faster than crabbing thru the current. The only way for me to do this now is set up the track (goto waypoint) on the CP and then feed the CTS heading (from the CP) to the APCH manually via 'auto'.

With that said, I'm not sure you can provide any improvement to current APs. And here is why:

From a protocol perspective, you would have to 'overload' the BTW/XTE messages, which I've always found overloading a protocol message bites back sometime in the future. That may not be the case with NMEA 0183 as it's probably 'shelved' by most manufacturers and won't be extended in the future by NMEA. By 'overload' I mean utilize a message for other purposes than it was designed. Of course, if you do this you would have to test all intended different manufacturer receivers of the overloaded messages to see if they behave as you expect.

And then the acknowledgement function on the AP. I know when I'm in 'track' mode and move the destination waypoint, sometimes the APC will notice and request acknowledgement and sometimes it won't. I don't know it's threshold for ack/no ack. And this seems to be a major complaint by some.

[DotDun]

Originally Posted by transmitterdan

I guess you don’t know much about Sean. He is an accomplished world sailor and has impressive technical skills. This isn’t the forum section for belittling people especially when it isn’t deserved. Your interpretation of the comments is in error in my opinion.

No, I don't know Sean.

I come from a communication protocol design/standards background. Hence, when someone talks about application functionality, I am quick to recognize/apply it from a protocol perspective. In post #5, he acknowledged the lack of understanding of the XTE message between a chartplotter and AP. That says a lot to me, for a person who lacks that basic understanding of the protocol and wanting to revolutionize AP functionality, I see a problem and I called it out. In my normal fashion, I was probably to terse, for that I apologize.

The problem is OpenCPN is only 1 of several pieces of the puzzle. It can only do what NMEA 0183 and the receiving AP will allow it to do.

Rolling your own AP, have a ball!

[seandepagnier]

Originally Posted by DotDun

First, I've only tested OpenCPN talking to my AP. OpenCPN for me is a tertiary backup that I've never had to press into live service. When I did test, it operated as expected, the same as my off the shelf chartplotters.

Before improving it, I think it's good to understand the current architecture and today's functionality. For this discussion purposes, today's components are:

Chartplotter (CP)
Autopilot Control Head (APCH)
Autopilot Computer (APC)

Typically, communication between the APCH and APC is proprietary, i.e., no standard messages defined but they do utilize the standard network underlying layers (most modern ones utilize N2K). If the CP is the same manufacturer as the AP system, they will allow APCH functions on the CP, but again, this utilizes proprietary messages. (I doubt we need to discuss reverse engineering proprietary messages.)

AFAIK, there are no standard messages for telling the APC information about 'Auto' or 'Wind' mode, as these are mostly simple button pushes. And again, these are proprietary between the APCH and APC.

What has been standardized is the messages for telling the APC the information to utilize in 'Track' mode. The standard includes things like:

Orig waypoint ID
Dest waypoint ID
Dest waypoint (lat/long)
Distance to waypoint (DTW)
Bearing to waypoint - true or magnetic (BTW)
Range to waypoint
Velocity made good
Arrival

For the sake of not reading the standard, I think the above covers what's needed for this discussion.

Also, AFAIK, OpenCPN has no access to N2K...?? So, if there are any extensions to the CP > APC 'track' mode dialog (pgns 129283,4,5) inside N2K, OpenCPN wouldn't be able to utilize it.

OpenCPN could use n2k, but there is no one interested in it. Does n2k make additional features available related to autopilot route following?

The current architecture was designed for the CP to send the 'track' information to the APC one segment at a time. Upon arrival at a destination waypoint, the next segment 'track' information is sent.

This architecture giving excess information. There are a lot of nmea messages with duplicate and irrelevant data. The only two parameters that appear to be needed are bearing and xte.

Most current off-the-shelf AP systems require user acknowledgement when new 'track' segment information is received. As you've gathered from my previous posts, I personally believe this is a good thing. If the system autonomously changed goto waypoints, people would utilize this and fail to maintain watch. I know you believe that's 'not my problem' thing, but I'm sure you don't want your application enabling someone to get hurt.

I think you mean, the boat might get hurt, not someone. This is an operator error if there is a collision. It is not for software to limit users. This is a major issue in a lot more than chart plotters. Lets just admit the real reasons for it, and the reason many AP, don't allow you to control them from your phone. They want to to buy their expensive remote control.

I absolutely support the user option to require acknowledgement. It is a good option, and could be further refined. It might be more useful or convenient for the chart plotter to handle this function than the autopilot. It is not really useful in open water. As stated above, it is easy to confirm without actually looking out.

If the AP can make bearing changes, it can at least avoid hitting known obstructions automatically. If the sailor has some problem like a seizure (I met several singlehanders with epilepsy) or maybe you just sleep too long or have medical emergency. It can avoid running aground. It can take evasive action if there is a ship on AIS bearing down. It can turn back or heave to, if you fall overboard. Maybe it can even sail boats back to port after they were abandoned at sea.

Finally, it was a lot of fun to sail down the river making winding turns, watching the boat jibe on it's own while I sit on the front hatch doing nothing. I was looking out the whole time.

I do think there could to be a function to maintain course to steer (CTS) type tracks. To me, a CTS track is one where current is forcing the boat to crab in order to maintain a straight track. There was a big discussion about this years ago on CF. Basically when crossing a known current stream (ex: English Channel or Florida Straits), some have the position that riding the current and then correcting course when out of the current is faster than crabbing thru the current.

This is actually true, but it's more complicated than that.

The only way for me to do this now is set up the track (goto waypoint) on the CP and then feed the CTS heading (from the CP) to the APCH manually via 'auto'.

If it is a predictable current, and you have good data, then you can actually plot the optimal route to cross it, which depends on a lot of factors. This might produce many waypoints.

As for dealing with unknown currents, what can we do about this? As you cross the current you can begin to notice how it affects you, so what logic can we use here? The boundary might help, because it defines the area you can safely navigate in.

With that said, I'm not sure you can provide any improvement to current APs. And here is why:

From a protocol perspective, you would have to 'overload' the BTW/XTE messages, which I've always found overloading a protocol message bites back sometime in the future. That may not be the case with NMEA 0183 as it's probably 'shelved' by most manufacturers and won't be extended in the future by NMEA. By 'overload' I mean utilize a message for other purposes than it was designed. Of course, if you do this you would have to test all intended different manufacturer receivers of the overloaded messages to see if they behave as you expect.

Despite the limitations of nmea0183 and AP that don't allow bearing changes, there is still a lot that can be done even with these systems.

Consider adding a boundary around your route. The boundary would initially be generated from the route with various parameters like width and turn radius. You would define the boundary as narrow in channels. It can be modified by the user to avoid certain areas. A wider boundary reduces rudder corrections needed. The idea is to follow the route while staying in the boundary. For autopilots that require XTE, the XTE value computed would be a relative value that is larger when the boundary is narrower for the same absolute distance from the route.

Another possibility is to calculate XTE not from the current distance from the route, but from the distance you will be from the route at a future time. This smooths turns and avoids the problem of making large corrections from XTE near a waypoint when the next waypoint will steer the other way.

As far as steering directly to bearing (full support) the easiest way to hack it would be to spoof nmea apparent wind data, and set the autopilot to steer to wind. From here, we should be able to make bearing changes and gain full control on the existing autopilots.

And then the acknowledgement function on the AP. I know when I'm in 'track' mode and move the destination waypoint, sometimes the APC will notice and request acknowledgement and sometimes it won't. I don't know it's threshold for ack/no ack. And this seems to be a major complaint by some.

Does it depend on how far you move the waypoint?

[seandepagnier]

Originally Posted by DotDun

No, I don't know Sean.

I come from a communication protocol design/standards background. Hence, when someone talks about application functionality, I am quick to recognize/apply it from a protocol perspective. In post #5, he acknowledged the lack of understanding of the XTE message between a chartplotter and AP. That says a lot to me, for a person who lacks that basic understanding of the protocol and wanting to revolutionize AP functionality, I see a problem and I called it out. In my normal fashion, I was probably to terse, for that I apologize.

I assumed the XTE message was for informative purposes only, as it should be.

Actually using it for control is a sub optimal hack designed by aircraft engineers who have limited understanding of how sailing vessels operate. An additional control loop here is a bad idea. You cannot tune it to critical dampening because the tuning parameters constantly change with conditions to achieve this. It would work best only in flat water with steady wind, or probably if you are motoring which I have no knowledge of.

The fact that you cannot easily tune the PID filter used for XTE in many autopilots speaks for itself.

[Paul Elliott]

Originally Posted by boat_alexandra

I assumed the XTE message was for informative purposes only, as it should be.

Actually using it for control is a sub optimal hack designed by aircraft engineers who have limited understanding of how sailing vessels operate. An additional control loop here is a bad idea. You cannot tune it to critical dampening because the tuning parameters constantly change with conditions to achieve this. It would work best only in flat water with steady wind, or probably if you are motoring which I have no knowledge of.

The fact that you cannot easily tune the PID filter used for XTE in many autopilots speaks for itself.

Can you clarify this for me? If the goal is to follow a course over the ground then XTE is the signal that tells you how far you are from the desired track. With SOG and HDG inputs, and possibly rudder position data I see no reason why you can't tune the feedback loop to create a critically damped response.

And yes, a sailboat can't follow a desired course directly into the wind, but has to tack. Depending on the polars, the best downwind course may involve jibing. Are you trying to build that into the AP? If so, that's a rather different problem.

And of course if the AP goal is to maintain a constant wind angle, then XTE is not relevant. In this case, the difference between actual and desired AWA is the error signal used in the feedback loop. But that doesn't make XTE "a sub-optimal hack".

Or do I misunderstand you?

[DotDun]

Originally Posted by boat_alexandra

I assumed the XTE message was for informative purposes only, as it should be.

Actually using it for control is a sub optimal hack designed by aircraft engineers who have limited understanding of how sailing vessels operate. An additional control loop here is a bad idea. You cannot tune it to critical dampening because the tuning parameters constantly change with conditions to achieve this. It would work best only in flat water with steady wind, or probably if you are motoring which I have no knowledge of.

The fact that you cannot easily tune the PID filter used for XTE in many autopilots speaks for itself.

It's called 'track' mode. To follow a track without using XTE would be quite difficult. BTW can't do it, boats drift due wind/waves/current. Track for a sailboat may not be optimal depending on wind direction.

It sounds like you are looking for laylines support. There are APs and CPs that support laylines (B&G and Raymarine).

FWIW, there are far more power boats using APs than sailboats. Commercial APs are sold to both markets.

[seandepagnier]

Originally Posted by Paul Elliott

Can you clarify this for me? If the goal is to follow a course over the ground then XTE is the signal that tells you how far you are from the desired track. With SOG and HDG inputs, and possibly rudder position data I see no reason why you can't tune the feedback loop to create a critically damped response.

As Dave explained, his AP reacts to XTE over a time period of "minutes". Hakan explained that he multiplied the XTE value by a constant to get better results on his AP.

It's pretty obvious that most AP that use XTE have a very under dampened response. This obviously can work, but it is a limitation of a poor design choice in the first place.

And yes, a sailboat can't follow a desired course directly into the wind, but has to tack. Depending on the polars, the best downwind course may involve jibing. Are you trying to build that into the AP? If so, that's a rather different problem.

This could be a feature of the autopilot route plugin. We can generate the "optimal" route in advance along a route keeping withing a boundary or otherwise attempting to avoid obstructions, but this route may very well change with the wind. It's a difficult problem.

And of course if the AP goal is to maintain a constant wind angle, then XTE is not relevant. In this case, the difference between actual and desired AWA is the error signal used in the feedback loop. But that doesn't make XTE "a sub-optimal hack".

Or do I misunderstand you?

It is sub optimal because it introduces an extra control loop that is poorly tuned. Which autopilot (if any) allows you to modify the gains for each component of the PID filter of the XTE control loop? Even if they did, these parameters must be changed for different conditions, and other dynamics, like which sails you have, or how much bottom growth.

These tuning parameters are supposed to exist for the main control loop already. It is rather convoluted to add an extra loop to tune when it can be completely avoided.

A slightly less sub-optimal method would be to steer to where the boat should be at some fixed time in the future. This bearing would be the best position on the route that intersects the circle that defines where the boat will be in the set fixed time, or the closest point on the route to the circle if it does not intersect. This is a lot easier to understand, and eliminates an under dampened control loop.

[Paul Elliott]

Originally Posted by boat_alexandra

As Dave explained, his AP reacts to XTE over a time period of "minutes". Hakan explained that he multiplied the XTE value by a constant to get better results on his AP.

It's pretty obvious that most AP that use XTE have a very under dampened response. This obviously can work, but it is a limitation of a poor design choice in the first place.

Wouldn't you say that "responding in minutes" implies a very overdamped response?

Originally Posted by boat_alexandra

This could be a feature of the autopilot route plugin. We can generate the "optimal" route in advance along a route keeping withing a boundary or otherwise attempting to avoid obstructions, but this route may very well change with the wind. It's a difficult problem.

As DotDun mentioned, there are autopilots that use laylines for this kind of thing.

Originally Posted by boat_alexandra

It is sub optimal because it introduces an extra control loop that is poorly tuned. Which autopilot (if any) allows you to modify the gains for each component of the PID filter of the XTE control loop? Even if they did, these parameters must be changed for different conditions, and other dynamics, like which sails you have, or how much bottom growth.

Many autopilots have a "learning" process, where they automatically adjust their response to the conditions and the boat characteristics. The high-end ones are apparently quite sophisticated, using pitch / yaw/ etc. as inputs to the steering algorithm. The human doesn't adjust the associated parameters, the AP does it.

Me, I've got a simple AP that has user-selectable gain settings used to adjust the response appropriately for point of sail and conditions. I use it to hold magnetic heading or wind angle, and don't have it connected to the chartplotter.

Originally Posted by boat_alexandra

These tuning parameters are supposed to exist for the main control loop already. It is rather convoluted to add an extra loop to tune when it can be completely avoided.

A slightly less sub-optimal method would be to steer to where the boat should be at some fixed time in the future. This bearing would be the best position on the route that intersects the circle that defines where the boat will be in the set fixed time, or the closest point on the route to the circle if it does not intersect. This is a lot easier to understand, and eliminates an under dampened control loop.

I think you are throwing the baby out with the bath-water. There's no reason that using XTE necessarily results in an underdamped control loop. And having multiple loops, or multiple gain parameters for multiple error inputs is commonly done. If my boat is steering to wind angle, it uses compass heading as the fast-response input to the loop, and AWA as a slower response input.

It's certainly fine with me if you want to design your own AP, or add features to an existing AP system. Perhaps OCPN is a good way to do it. But I think that you are rejecting the use of XTE based on bad implementations (?) and not for valid fundamental reasons.

[seandepagnier]

Originally Posted by DotDun

It's called 'track' mode. To follow a track without using XTE would be quite difficult. BTW can't do it, boats drift due wind/waves/current.

At least in protected waters, my AP was very nearly doing it. The boat track was perfectly parallel to the route segments. Obviously with changing currents or other factors this would not be the case, but the problem here was that OpenCPN changed to the next segment at the wrong time, either too early or too late.

This is due to the waypoint arrival radius logic which is tweaked in opencpn by Dave. If I tweaked the logic for my boat and autopilot I might get better results. Obviously waypoint arrival as a "radius" that is shifted "forward" from the waypoint center is a hack in opencpn.

Relying on XTE to make up for sub optimal course change timing means it will always overshoot or undershoot around waypoints which is annoying.

I would rather try logic that more closely resembles how I would actually hand steer if I were looking at the chart plotter and trying to follow a route.

Confirming the course change (if enabled) needs to be asked of the user well in advance before it actually needs to happen to avoid overshoot.

[Stu Jackson]

Originally Posted by boat_alexandra

>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

This is due to the waypoint arrival radius logic which is tweaked in opencpn by Dave. If I tweaked the logic for my boat and autopilot I might get better results. Obviously waypoint arrival as a "radius" that is shifted "forward" from the waypoint center is a hack in opencpn.

Relying on XTE to make up for sub optimal course change timing means it will always overshoot or undershoot around waypoints which is annoying.

I would rather try logic that more closely resembles how I would actually hand steer if I were looking at the chart plotter and trying to follow a route.

Confirming the course change (if enabled) needs to be asked of the user well in advance before it actually needs to happen to avoid overshoot.

Why not two parameters for the acknowledgement and then the actual course change? The beep beep starts at the radius. Even if acknowledged, the boat doesn't turn until the actual waypoint is reached.

Wouldn't this respond (pi) to your issue about bad turns? And wanting to stay right on course? As in your narrow river? Wouldn't this be the way you steer by hand? I do.

I think you're chasing a solution to a problem that doesn't exist.

[DotDun]

Originally Posted by boat_alexandra

At least in protected waters, my AP was very nearly doing it. The boat track was perfectly parallel to the route segments. Obviously with changing currents or other factors this would not be the case, but the problem here was that OpenCPN changed to the next segment at the wrong time, either too early or too late.

This is due to the waypoint arrival radius logic which is tweaked in opencpn by Dave. If I tweaked the logic for my boat and autopilot I might get better results. Obviously waypoint arrival as a "radius" that is shifted "forward" from the waypoint center is a hack in opencpn.

Relying on XTE to make up for sub optimal course change timing means it will always overshoot or undershoot around waypoints which is annoying.

I would rather try logic that more closely resembles how I would actually hand steer if I were looking at the chart plotter and trying to follow a route.

Confirming the course change (if enabled) needs to be asked of the user well in advance before it actually needs to happen to avoid overshoot.

You are taking XTE way out of context, it has nothing to do with waypoint arrival or course change.

XTE is simply the reporting of how far (right or left) of a line is your current position. The line was drawn previously between 2 waypoints. Again, it supports a ‘track’ mode, i.e., follow a single track.

[fgd3]

Originally Posted by boat_alexandra

Relying on XTE to make up for sub optimal course change timing means it will always overshoot or undershoot around waypoints which is annoying.

I would rather try logic that more closely resembles how I would actually hand steer if I were looking at the chart plotter and trying to follow a route.

How would you hand steer while trying to follow a route looking at the chart plotter?

The track feature on my Raymarine autopilot doesn't work very well. It makes several violent course changes while it hunts for the track. It typically sags to the right of the desired track about 60 feet.

My usual practice is to set the autopilot to follow a magnetic bearing which is the bearing to the next waypoint the GPS has given me. I monitor the track displayed by the GPS. If the track is different from the desired bearing I adjust the autopilot bearing to compensate. The difference between the bearing and track tells me how much I need to change the autopilot setting. Monitoring cross track error tells me how successful I have been at steering the right course to stay on track.

Much of my autopilot use is while under power where the demands on the autopilot are simpler. My autopilot does not have a wind vane input so its performance under sail is never optimal. Since it can't respond to wind shifts I can't trust it to sail close hauled. Reaching or running it will hold course fine but wind shifts require me to actively trim the sails if I want to maintain best speed.

Fabbian

[DotDun]

Originally Posted by boat_alexandra

OpenCPN could use n2k, but there is no one interested in it.

It's more difficult than that, you need a gateway. And, per NMEA, their permission!

Originally Posted by boat_alexandra

Does n2k make additional features available related to autopilot route following?

None that I see in a cursory look at N2K. (but I'm not willing to spend $$ to get the spec)

Originally Posted by boat_alexandra

This architecture giving excess information. There are a lot of nmea messages with duplicate and irrelevant data. The only two parameters that appear to be needed are bearing and xte.

You must understand the current NMEA0183 is an evolutionary product. Yeah, it got messy after years of tweaks.

Since AP control heads have displays, those manufacturers decided to display things like waypoint id, DTW, etc. Hence, it's not all irrelevant data for their use.

Originally Posted by boat_alexandra

I think you mean, the boat might get hurt, not someone. This is an operator error if there is a collision. It is not for software to limit users. This is a major issue in a lot more than chart plotters. Lets just admit the real reasons for it, and the reason many AP, don't allow you to control them from your phone. They want to to buy their expensive remote control.

That is the obvious top priority of NMEA. They don't care about what's good for the application or end user, it's about their revenue.

Originally Posted by boat_alexandra

I absolutely support the user option to require acknowledgement. It is a good option, and could be further refined. It might be more useful or convenient for the chart plotter to handle this function than the autopilot. It is not really useful in open water. As stated above, it is easy to confirm without actually looking out.

If the AP can make bearing changes, it can at least avoid hitting known obstructions automatically. If the sailor has some problem like a seizure (I met several singlehanders with epilepsy) or maybe you just sleep too long or have medical emergency. It can avoid running aground. It can take evasive action if there is a ship on AIS bearing down. It can turn back or heave to, if you fall overboard. Maybe it can even sail boats back to port after they were abandoned at sea.

None of what you mention is supported by the communication protocol. Unless you build the whole system, you'll have a lot of work (and $$) to convince NMEA to support your ideas.

Originally Posted by boat_alexandra

Finally, it was a lot of fun to sail down the river making winding turns, watching the boat jibe on it's own while I sit on the front hatch doing nothing. I was looking out the whole time.


This is actually true, but it's more complicated than that.

If it is a predictable current, and you have good data, then you can actually plot the optimal route to cross it, which depends on a lot of factors. This might produce many waypoints.

As for dealing with unknown currents, what can we do about this? As you cross the current you can begin to notice how it affects you, so what logic can we use here? The boundary might help, because it defines the area you can safely navigate in.



Despite the limitations of nmea0183 and AP that don't allow bearing changes, there is still a lot that can be done even with these systems.

Consider adding a boundary around your route. The boundary would initially be generated from the route with various parameters like width and turn radius. You would define the boundary as narrow in channels. It can be modified by the user to avoid certain areas. A wider boundary reduces rudder corrections needed. The idea is to follow the route while staying in the boundary. For autopilots that require XTE, the XTE value computed would be a relative value that is larger when the boundary is narrower for the same absolute distance from the route.

Another possibility is to calculate XTE not from the current distance from the route, but from the distance you will be from the route at a future time. This smooths turns and avoids the problem of making large corrections from XTE near a waypoint when the next waypoint will steer the other way.

As far as steering directly to bearing (full support) the easiest way to hack it would be to spoof nmea apparent wind data, and set the autopilot to steer to wind. From here, we should be able to make bearing changes and gain full control on the existing autopilots.



Does it depend on how far you move the waypoint?

I have to assume so, but I've never found the ambition to investigate.