NMEA *Input* string format to signal next autopilot waypoint?

[neodiogenes]

Hi. I'm putting together a software autopilot. I have no trouble reading the NMEA *output* from OpenCPN and having the software follow a route. I can read the RMB to see the current destination lat/lon value, and when the boat has entered the "arrival circle".

I'd like to know if OpenCPN accepts an *input* NMEA string that tells it to track to the next waypoint in the route. If it does exist, then the exact format of the string? I imagine this is a standard string output from most existing autopilot systems.

Second: I notice that OpenCPN seems to automatically track to the next waypoint, apparently when the boat moves out from the arrival circle. Could someone confirm this behavior, and is there any way to disable it? I couldn't see any option to do this in settings, or to set the radius of the arrival circle.

Thanks!
- Andrew

[bdbcat]

Andrew...

OpenCPN automatically shifts to the next waypoint in the route using an arrival radius of 50 meters, IIRC. Or maybe .05 NM. One of those...

All of this is automatic, not configurable and not signal-able.
Works fine in the general case.

I don't know of any system where the A/P signals the plotter to advance to the next WP. I can't see the logic. Help me out here.....

Good luck with your project.

Dave

[neodiogenes]

The idea is to require some kind of user confirmation before turning the boat, so it doesn't come as a surprise. It seemed that OpenCPN didn't shift to the next waypoint until after it had left the arrival circle ... but now I see I might have to check this more thoroughly.

It's important if OpenCPN makes the shift *before* it gets to the waypoint or *after* it leaves the waypoint. I can assess this by experiment.

The idea is to remove a layer of control and just have OpenCPN "drive" the boat, allowing the user to signal changes from some remote device. But now I think I can have the A/P include its own logic when the RMB "destination" value changes and not actually move the boat until the user confirms the change. Not as clean, but it should work.

[yachtman]

Originally Posted by neodiogenes

The idea is to remove a layer of control and just have OpenCPN "drive" the boat, .

no change of direction should happen without human confirmation.....
In my opinion

from a safety point of view

[bdbcat]

Andrew...

Your latest idea is the way most A/P systems work. The A/P is watching the RMB strings. It sees a new destination lat/lon, and new heading to steer, and then asks the user for confirmation to make the turn. Raytheon/Autohelm work this way. Seems the safe conservative thing to do.

Dave

[neodiogenes]

I agree there should be human input. The problem is OpenCPN doesn't seem to work this way -- it switches waypoints automatically, and not at the right place. 50 meters gives maybe 15 seconds to respond for a sailboat going 5-10 knots, but only about 5 seconds for a powerboat going 20-30 knots. By the time the pilot authorizes the turn, the boat is already past the waypoint.

The distance before which the autopilot signals an upcoming change should be configurable, and the change should be able to be signaled from the autopilot unit after it receives confirmation. I can work around this limitation, but it will be less than ideal behavior.

[bdbcat]

neo....

I agree that there could/should be a programmable arrival circle, based upon ship speed. Maybe a good feature request.

However, I see no case where the A/P should authorize the plotter to shift to the next W/P. In our architecture, the plotter (OpenCPN) owns the route, and the A/P is a slave.

But maybe your architectural split is different.....

Dave

[DotDun]

The AP knows DTW & SOG, why can't the AP put up a waypoint arrival alarm based on TTG?