00 Feature Request

This is the project for all Feature Requests except the ones ones that have been "vetted" (see Feature Requests Vetted) and ones concerning plugins. Please add Plugin Feature Requests to the respective plugin project - thanks.

FS#2131 - A/P Splitting large A/P course change commands into smaller segments to minimize oversteer

Attached to Project: 00 Feature Request
Opened by Jan Pettersson (janp391) - Tuesday, 26 July 2016, 14:58 GMT
Last edited by Rick Gleason (rgleason) - Sunday, 07 August 2016, 13:35 GMT
Task Type Feature Request
Category Backend / Core
Status Assigned
Assigned To Dave (bdbcat)
Operating System Windows
Severity High
Priority Normal
Reported Version future version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No


Thanks for the detailed explanation. I see what the RayMarine plotter logic is.
OCPN has no facility currently for splitting large A/P course change commands into smaller segments to minimize oversteer. This could be added as a Feature for OCPN5 if development resources allow.
This task depends upon

Comment by Jan Pettersson (janp391) - Wednesday, 27 July 2016, 16:40 GMT
What Raymarine also do is that the turning speed is much slower than O. I think this is the most important differens between O and Raymarine. In that way the over steering is more under control
Comment by Håkan Svensson (hakan) - Thursday, 26 January 2017, 13:40 GMT
I've the same experience as Jan with over steering for some APs.
I've a patch proposal for this.
Functional description:
The function is activated if new option is set: Tools > Options > Ships "Use stepwise AP course change to next WP"

While following an active route and the WP arrival zone is reached:
If the to course change to the new leg is more than 15 degrees the AP course to steer is changed 5 degrees every second until less than 5 degr difference is reached.

If a new checkbox "Don't send arrival to AP", in the route message box, is checked no arrival signal is sent to the AP thus the course change will be accomplished without a AP acknowledge. To alert the user about the course change a sound is played on WP arrival. The checkbox activation is only active during a present route and is cleared out once the route is no longer active.
See attached menu images.

The function is tested by a rather extensive simulation but before a forum discussion and a pull request I want to perform a good live test. Our winter period is somewhat hindering such a test for the moment.

The patch is available here: https://github.com/Hakansv/OpenCPN/tree/AP_Stepped_Brg

Comment by Håkan Svensson (hakan) - Wednesday, 01 February 2017, 18:05 GMT
My earlier comment about a patch for this no longer valid.
A live test show it was built on a false assumption. My intention was to send the new course to steer, CTS, in steps to slow down the course change at a WP arrival and turn to next WP.
Now it seems the AP is catching only the first CTS after a course change and the acknowledge to adapt the changed course and next WP. After one accepted CTS is XTE value the only message read, whatever NMEA sentence that value is messaged by, XTE or APB.
All other CTS's are ignored so this method is not usable.
I don't know how Raymarine is handling this if it is as Jan says that his plotter is dividing the course change. Playing with XTE??

Sorry - my patch is not a solution.

Comment by Jan Pettersson (janp391) - Wednesday, 24 May 2017, 17:03 GMT
After an update from Raymarine incl. autopilot. I have a new behavior and the problem is more or less solved for me
Comment by Rick Gleason (rgleason) - Wednesday, 19 July 2017, 11:46 GMT
Is it possible that your code is confused or overridden by the arrival calculations?
The arrival calcs are quite detailed.
See See the Manual "Autopilots & Routes, the details"
For some diagrams.
I think this approach might have merit for sharp turns.
Sean may have some ideas about this.
Comment by Håkan Svensson (hakan) - Wednesday, 19 July 2017, 17:02 GMT
Most APs seems to not care about CTS changes while on a track. Every track is ended by either "Arrival" or timed out by lack of new data. Then when starting a new track, that's a new leg, the CTS is again read but only then. That's why a changed course, CTS, is not noticed while on a track. So my theoretical code attempts didn't survived reality.

Comment by Rick Gleason (rgleason) - Thursday, 20 July 2017, 10:12 GMT
I think this task is good information for the future, so perhaps we don't close it.
Would this mean that acute or abrupt turns are just dealt with internally in the autopilot?

I'll have to try putting 3 or more waypoints close together around a mark with an abrupt turn.
What happens if they are all less than the arrival distance apart?
Do you know if all waypoints are recognized?
Comment by Håkan Svensson (hakan) - Thursday, 20 July 2017, 14:25 GMT
Yes, how to make the turn to next WP and stabilize the course is always dealt by the AP only. Different APs are handle this differently. O is only sending the course to steer and XTE. Newer APS seems to have better coding for this than old ones.

Several close WPs in a route will probably solve a turn problem but you've to accept every course change on the AP. What will happen with WPs so close they are within there's arrival circle I don't know. You've to try but it seems rather impractical?