Autopilot Control

[jongough]

My autopilot, TMQ AP4, does not take wind input, it uses its own remote heading sensor for 'follow heading' and will take APB sentences from OCPN to follow a route. So this plugin works with that to allow sailing to the wind.

The plugin is also 'alpha' as I can only test it on my autopilot, to progress it further I would need to know what other autopilots accept. Currently it handles RMB and APB as outputs to control the autopilot. It can do XTE as well but currently this is disabled.

I am looking for input to make this plugin work easily with other autopilots, as this allows for easy changes between 'follow route' and 'follow wind' by simply (currently) clicking on the WV icon on the OCPN toolbar. It would be easy to add a keyboard shortcut for this if needed.

[DotDun]

Originally Posted by jongough

My autopilot, TMQ AP4, does not take wind input, it uses its own remote heading sensor for 'follow heading' and will take APB sentences from OCPN to follow a route. So this plugin works with that to allow sailing to the wind.

The plugin is also 'alpha' as I can only test it on my autopilot, to progress it further I would need to know what other autopilots accept. Currently it handles RMB and APB as outputs to control the autopilot. It can do XTE as well but currently this is disabled.

I am looking for input to make this plugin work easily with other autopilots, as this allows for easy changes between 'follow route' and 'follow wind' by simply (currently) clicking on the WV icon on the OCPN toolbar. It would be easy to add a keyboard shortcut for this if needed.

The 'big 4' manufacturers targeting the recreational market, i.e. sailing market, (Raymarine, Garmin, Furuno, Navico) all support wind mode natively on the AP.

Not sure the value of enabling the XTE sentence as the same information is available in both RMB and APB.

Are you changing the BTW as the wind direction changes? If yes, your AP doesn't ask for acknowledgement?

[transmitterdan]

Most AP only require acknowledgement when arriving at a waypoint. By acknowledging then the AP can ask for the next waypoint in the route. But I don’t think any AP will care if the BTW, DTW and XTE keep changing. Indeed, it would not work if they did care. These parameters are always changing when following a route.

The AP doesn’t care about the coordinates of the waypoint except maybe to display it on the controller.

[DotDun]

Originally Posted by transmitterdan

Most AP only require acknowledgement when arriving at a waypoint. By acknowledging then the AP can ask for the next waypoint in the route. But I don’t think any AP will care if the BTW, DTW and XTE keep changing. Indeed, it would not work if they did care. These parameters are always changing when following a route.

The AP doesn’t care about the coordinates of the waypoint except maybe to display it on the controller.

Move the goto waypoint on your CP while following a route. My AP will see the BTW change and ask for acknowledgment.

BTW should stay the same if you stay on track....???

[transmitterdan]

Mine won’t unless the BTW exceeds a limit that causes an alarm. This is so the AP can throw up its hands if something isn’t right. But it does not happen every time.

[rgleason]

Would'nt this integrate nicely with ShipDriver raymarine buttons to allow wind mode?

[jongough]

With my autopilot if the waypoint it is trying to get to is more than about 90deg off of current heading it will sound an alarm to let you know, but it will still attempt to change the heading to go to the waypoint. So when following a route and there is a sharp bend the autopilot will beep a few times as it changes course, then it will stop beeping when it starts to get the heading closer to the desired one. I would find it very disconcerting if the autopilot just threw its hands in the air and gave up or required acknowledgement that there was an issue.

As for the current autopilots handling wind, well mine is about 17 years old, still working well, it just only does follow heading or 'goto waypoint' which OCPN provides with the APB sentence. I don't think everyone has a new autopilot that has all the smarts. I could say that a 'modern' autopilot would not need OCPN as it has all the charts, routing, weather, communications and multiple displays, i.e. a full navigation/boat control system, but I don't think I could afford to buy it let alone maintain it. So for me OCPN and the plugins make a very cost effective, usable and customisable navigation system.

[seandepagnier]

I have just been sailing a few days through the ICW following routes. I have a few issues:

I learned the default arrival radius of 0.05 miles is too large for ICW I reduced it to 0.02 and it's working better. Maybe arrival radius really makes no sense? It should be the perpendicular line this distance from the waypoint? I never managed to "miss" a waypoint, but a radius implies it could be possible.

If I create an intermediate route point along the active route segment, it doesn't activate the new waypoint. I have to deactivate and reactivate the route. Wouldn't it be better to activate the newly created point?

Similarly, if I drag the active waypoint in the route too far, sometimes it activates the "next" waypoint. Why would it do that? In all cases I had to deactivate and reactivate the route to correct it.


I am also slowly writing the autopilot route plugin. I have so far, 4 modes:

1) Standard XTE

This does what is built into opencpn with default values, with improved graphics!

The difference is that you can set an XTE multiplier (default 1) to adjust the response. There is also, and optional XTE' multiplier (default 0) which can combine the rate of change of XTE into the XTE sent to the autopilot. This might be interesting, or be removed if it proves useless.

Maybe the factor can also be based on other factors like water speed, or even wind speed? I realize this type of logic can be built into the autopilot as well, but it's worth experimenting to override it.


2) Boundary XTE

This mode will have a simple button to generate a boundary that surrounds the active route. From here, the user can drag the boundary waypoints to modify its width and avoid areas, or allow areas. Typically narrow in canals, but can be wider in places. Eventually generating the boundary can be integrated with vector charts and the boat's draft.

The XTE reported to the autopilot is based on the actual XTE divided by the distance from the route to the edge of the boundary. There is also a multiplier to tune it as well.

The goal here is to reduce autopilot power consumption while keeping the boat away from obstructions when needed.


3) Waypoint Bearing

This is a very simple mode, and it is what I currently use with success in the ICW. The autopilot simply steers to the next waypoint changing the bearing as needed. It may not work on all autopilots if they require a confirmation.

It is probably not as good as XTE mode (assuming it's tuned properly) if dodging obstructions in a narrow channel, but it would be better if dodging obstructions outside a channel (lobster pots in maine for example)

If you create more route points along the route (even if all fall in a straight line) the autopilot will drift off course less, while wider spaced route points allow more drift.

There will be boundary support to keep the boat inside of an optional boundary.


4) Route Position Bearing

This mode takes either a time, or distance. If time, it computes the distance based on current average speed. From here it intersects this distance from the boat to the route. There may be several intersections, it would pick the one that is furthest along the route. If there is no intersection, it finds the closest position on the route to the boat.

It's a little more complicated when it is integrated with optional boundaries, but that is the basic idea.

It steers the bearing of this position which is continuously updated. This mode avoids waypoint arrival logic completely. It avoid discontinuities at waypoints, and avoids making corrections just before reaching a waypoint that will need to be undone.

When integrated with boundaries, it should more closely resemble how a human operator would actually steer a route.



There could be more modes, but this is a start. I intend to add "dodge" buttons as well.

[Hakan]

Originally Posted by boat_alexandra

......
I learned the default arrival radius of 0.05 miles is too large for ICW I reduced it to 0.02 and it's working better.

Agree, but it's easy to change the default radius for a new WP in "options>own ship"

If I create an intermediate route point along the active route segment, it doesn't activate the new waypoint. I have to deactivate and reactivate the route. Wouldn't it be better to activate the newly created point?

For most AP, as said, it's not a good idea. The AP will not change course if you move the WP. You've to reinitialize the AP's NAV mode. It's better to deactivate the route in O, move the WP and then activate it again.


And, again, my comments are made in respect to interaction with a common AP, where the present code in routeman.cpp is rather functional. For to control your own AP in a new plugin all your thoughts may be fair.
Håkan

[transmitterdan]

Sean,

The arrival radius is one part of the calculation. But also, O looks at distance to waypoint. When distance has "increased" for a bit O assumes the radius was missed and then advances the waypoint anyway.

[rgleason]

These diagrams describe how OpenCPN handles waypoints.
Route to Autopilot Measurements used:

• Arrival Radius (declared)
• Waypoint Advance (normal)
• Advance WP on arrival only (when checked)
• RNG (Range)
• NR (Normal Range)
• XTE (Cross Track Error)

Conditions checked:

• RNG>NR and RNG=0
• XTE=0 and XTE>0
• WP on arrival Checked or not.
• RNG>1.1*NR

B&G Autopilot Information


This is from the B&G H5000 Pilot Computer summary which might be some things to consider.

..sailing algorithms and steering modes - Gust Response, Recovery and High-Wind Response. ... ideal for short-handed cruisers or racers.

• Selectable steering modes: The H5000 Pilot CPU lets you elect to steer to Heading, Wind or Waypoint
• AWA and TWA steering: The H5000 Pilot CPU can utilize Apparent, True or Polar wind modes for optimum performance under sail.
• Intuitive and responsive: Provides gust and high-wind response modes for rapid response to changing conditions
• Optimum course keeping
• Features auto response switching and recovery mode for optimum course keeping in varying sea-states.

[Paul Elliott]

Wouldn't it be nice if the autopilots had a "rudder angle only" control mode? That way you could design your own controller without having to reverse-engineer and otherwise work around the existing control algorithms.

[rgleason]

Should have added several other conditions.

Conditions checked:

• RNG > NR and RNG = 0
• XTE = 0 and XTE > 0
• WP on arrival Checked or not.
• RNG > 1.1*NR
• NR < Arrival Radius or
• NR > Arrival Radius
• RNG has increased for > 2 seconds

I like Paul's idea.

[seandepagnier]

Oops!!! I edited transmitterdan's post by mistake (with my moderator tools). I will try to repost it. Sorry!

Originally Posted by transmitterdan

Maybe, but commanding the autopilot in this way introduces lag into the control loop which is bad.

Yes, delay is bad in a control loop. I was assuming that any development would be taking that into account, and minimizing delay as necessary. I doubt that you would want to do this inside of a one-second sample process, but software (and custom hardware) can be as fast as you want.

I was speaking in a science-project frame of mind.

[Paul Elliott]

Originally Posted by transmitterdan

Sean,

This is faulty logic.

Shouldn't it take the line perpendicular to the route, and move it forward by the arrival distance (renamed from radius), then check which side of the line you are on?

Maybe, but commanding the autopilot in this way introduces lag into the control loop which is bad. My autopilot is free software, you could just use that, it runs on raspberry zero, or many other boards that cost <$10. From there, design your own control algorithm which is just a few lines of code without having to rewrite all the other pieces.

I realize this is a limitation of many autopilots that they cannot change bearing without confirmation. Dragging the active waypoint on the chart or making a new point before the active one is a sort of confirmation. My AP can handle it, and I think it's useful. I will correct this behavior within the plugin at least.

it may be functional, but that does not mean it is perfect. Did anyone besides me notice it uses mercator projections for all the vector calculations?! There is no reason it should be using any kind of projections here. It will break down in very long route segments, especially in high latitudes. I will be using spherical trigonometry.

[I may have messed up the quotes -- again, my apologies to transmitterdan!]