AutoTrackRaymarine_pi: Remote control and route following for Evolution Pilots

[Douwe Fokkema]

Beta plugin AutoTrackRaymarine_pi.


Will provide remote control of a Raymarine Evolution autopilot from OpenCPN and route following for complex routes from start to finish.

So you make up your route in OpenCPN. Activate it. Cast off. Put the ship on course. Press Auto on the Raymarine P70 pilot head. Pilot takes over as usual. Press auto again: the plugin takes control of the autopilot and will steer your ship along the activated route to your destination. Following the route with a margin (XTE) normally less than 2 meters, independent of cross currents and compass errors. Only thing to do is keep a lookout for obstacles and traffic. As soon as you press Standby the autopilot returns to standby and you can steer manually again. When you press one of the buttons +/- 1 or 10, pilot will switch to regular auto on the last heading plus the button you pressed. Auto button when pilot is in auto activates the tracking again.

Alternatively this may be handled from the plugin window on the OpenCPN screen, see attached image.

The Auto, Standby and +/- buttons work as usual with your Evolution pilot. On top of this comes the Tracking button which is enabled only when a route is active. It will make you follow the active route as described below. Buttons are large for easy use on touch screens.

Currently this is a beta version. The user interface needs some improvements, I am trying to get used to the wxFormBuilder. To use the plugin you need an Actisense NGT-1 to connect to the Raymarine Raytalk-ng network, which is an nmea 2000 network with lots of proprietary pgn's. Some of these I have decoded to get access to the required functions. The current code (Windows only) can be found at https://github.com/douwefokkema/AutoTrackRaymarine_pi . To my regret, the this plugin requires some updates in OpenCPN to function properly. The present version of O provides the XTE (the source for our steering) in nm with 3 decimals. This accuracy is insufficient, we need at least 5 decimals, though the real accuracy is limited by the GPS. And to avoid unexpected behavior at activation we need to set the XTE to zero, I have added that function to the plugin manager. For these modifications in OpenCPN I have submitted a PR, pending. In the meantime I use my own version, at https://github.com/douwefokkema/OpenCPN-1

If you want to try this plugin, at https://www.dropbox.com/sh/7j3vs6s9l...TMymjgJSa?dl=0
you will find:
- opencpn.exe, the compiled version, replace your opencpn.exe with this one.
- the installer for AutoTrackRaymarine_pi or if you prefer
- AutoTrackRaymarine_pi.dll


In preferences, set the serial port number of your Actisense NGT-1. You may forget about the rest.
For the technically interested, the plugin is using a PID based steering function that calculates corrections on the Bearing to Waypoint (BTW) based on the XTE as received from OpenCPN. It normally sticks to the route within 2 meters, on heading changes at waypoints it may overshoot a little. With large compass errors or strong cross currents, it may take a minute or so to settle down on the track.

This plugin was inspired by and may use code from autopilot_route_pi, Autopilot-Plugin and Canboat (for controlling the Actisense NGT-1).

Warning: this plugin may take full control of your autopilot. In case of system or software errors be ready to switch the autopilot off (never happened).

[rgleason]

Douwe, thank you. I have created a new beta plugin page for you in the wiki.
Aren't you an editor now? If not, let me know please, by PM.

[rgleason]

Originally Posted by rgleason

Douwe, thank you. I have created a new beta plugin page for you in the wiki.
Aren't you an editor now? If not, let me know please, by PM.

AutoTrackRaymarine_pi

[jean_pfoumf]

Hello
Great job. Does it work with Actisense NGW-1 ?

[Douwe Fokkema]

Originally Posted by jean_pfoumf

Hello
Does it work with Actisense NGW-1 ?

To my regret, no.

NGW-1 is a converter for converting between NMEA2000 and NMEA0183. NGT-1 interfaces NMEA2000 directly to the computer. The plugin uses the NGT-1 to send Raymarine proprietary PGN's (NMEA2000 messages) to the Evolution EV1 course computer, and to listen to the network where the plugin detects specific commands. So the plugin notices when the user presses a key on the P70 control head and can act on that.

For difference between NGW-1 and NGT-1 see also https://desk.zoho.eu/portal/actisens...gt-1-and-ngw-1


Douwe Fokkema

[Tehani]

Bravo Douwe!. Nice job.

I think I can help you complete your SerialPort.cpp with more pilot orders. Also how to get more data from this pilot by reading PGN's 65345, 65360 and 65379, and how they are used in combination with what you have written.

But it is quite tedious to work with Actisense NGT-1 in that format. I think that a speed per serial port of 115200 baud in hexadecimal ASCII with separators and synchronisms can jeopardize the synchronization with the N2k bus if, in the future, you want to process more PGN's. It is certain that frames will be lost.

Congratulations.
José Luis

[Tehani]

I found this page where various spherical geometry calculations appear, in particular the Cross-Track distance:
https://www.movable-type.co.uk/scripts/latlong.html
Your plugin can calculate the XTE directly from the coordinates of the starting point and the destination waypoint. That would be autonomous.

José Luis

[rgleason]

Good web page Jose. Thanks.

[Douwe Fokkema]

Originally Posted by Tehani

Also how to get more data from this pilot by reading PGN's 65345, 65360 and 65379, and how they are used in combination with what you have written.

But it is quite tedious to work with Actisense NGT-1 in that format. I think that a speed per serial port of 115200 baud in hexadecimal ASCII with separators and synchronisms can jeopardize the synchronization with the N2k bus if, in the future, you want to process more PGN's. It is certain that frames will be lost.

Congratulations.
José Luis

Hi José,
Thanks for your comments. If you have a suggestion for using for using PGN's 65345, 65360 and 65379, welcome. And I would appreciate to have the spec's for these PGN's.
I agree the hexadecimal ASCII is not the most efficient. I copied this part from Canboat, it just works. May be change to binary formats later.
Douwe Fokkema

[Douwe Fokkema]

Originally Posted by Tehani

I found this page where various spherical geometry calculations appear, in particular the Cross-Track distance:
https://www.movable-type.co.uk/scripts/latlong.html
Your plugin can calculate the XTE directly from the coordinates of the starting point and the destination waypoint. That would be autonomous.

José Luis

In Sean's the autopilotroute_pi the whole route is copied into the plugin, all calculations are done inside the plugin. This did not work with many waypoints, performance issue. And I like the OpenCPN route display, the functions "ZeroXTE" and free choice of the active waypoint. Further I don't like to duplicate calculations that are done in O already. So I choose to stick to the OpenCPN routemanager as a base. Steering is based on the active leg only. It keeps it all very simple.

Therefor I have now made a proposal for an API117 that directly sends the active leg info from the routemanager in O to the plugin. For this I have submitted PR1472 for OpenCPN.

Douwe

[rom]

Thank you Douwe, this is going to be very useful ! I have a verspermarine XB8000 that (from my understanding) is able to transmit XTE and other PGNs from/to OpenCPN/STNG. So there should be no need for any particular conversion ? Any idea how to use that feature ?

[Douwe Fokkema]

Originally Posted by rom

Thank you Douwe, this is going to be very useful ! I have a verspermarine XB8000 that (from my understanding) is able to transmit XTE and other PGNs from/to OpenCPN/STNG. So there should be no need for any particular conversion ? Any idea how to use that feature ?

As far as I understand the XB8000 (AIS responder) will send position information to OpenCPN. Based on the information of the active leg of the active route and the current position OpenCPN will calculate an XTE. Based on this XTE and the bearing to waypoint my plugin will calculate an optimal heading. This heading is send to the autopilot, currently only the Raymarine Evolution pilots are supported. As we can only talk to the Raymarine pilot using NMEA2000 with proprietary sentences we need to connect to the NMEA2000 (=Seatalk ng) network. For this I use the NGT-1. I do not think that the XB8000 can send these Raymarine proprietary messages, at least I would not know how to command it to do so. But it could be (speculation) that it accepts special NMEA like messages that allow you to specify any PGN.

[rom]

Originally Posted by Douwe Fokkema

I do not think that the XB8000 can send these Raymarine proprietary messages, at least I would not know how to command it to do so. But it could be (speculation) that it accepts special NMEA like messages that allow you to specify any PGN.

I am pretty sure it won't work actually, I didn't realize it was a proprietary PGN.

Originally Posted by Douwe Fokkema

As we can only talk to the Raymarine pilot using NMEA2000 with proprietary sentences we need to connect to the NMEA2000 (=Seatalk ng) network.

Are you sure ? I thought I could still use my old ST6002 head (ST/NMEA0183) to control my new EV400, provided I have the raymarine ST/STNG converter. I also believe the P70 can control an older S3 smartpilot. Taht would mean there exists a clear NMEA0183 sentence to control the EVolution AP. But I am talking from memory here, will take some time to check in the next few days.

[Douwe Fokkema]

Originally Posted by rom

I am pretty sure it won't work actually, I didn't realize it was a proprietary PGN.

Are you sure ? I thought I could still use my old ST6002 head (ST/NMEA0183) to control my new EV400, provided I have the raymarine ST/STNG converter. I also believe the P70 can control an older S3 smartpilot. Taht would mean there exists a clear NMEA0183 sentence to control the EVolution AP. But I am talking from memory here, will take some time to check in the next few days.

You could take a NMEA to Seatalk converter (Thomas Knauf, well documented) connect it to this Raymarine ST/STNG converter (undocumented) and try it out. Good luck.

Earlier I used this Raymarine ST/STNG converter. Terrible, auto pilot kept resetting to statue miles instead of nautical miles. I threw the thing out.

With the NGT-1 you will have full control of the NMEA2000 bus, and you can monitor any PNG you like.

[Tehani]

Originally Posted by Douwe Fokkema

Hi José,
Thanks for your comments. If you have a suggestion for using for using PGN's 65345, 65360 and 65379, welcome. And I would appreciate to have the spec's for these PGN's.
I agree the hexadecimal ASCII is not the most efficient. I copied this part from Canboat, it just works. May be change to binary formats later.
Douwe Fokkema

Hello Douwe,
I think this explains better what you ask me:

// Raymarine / Simrad data reading
FlagType getpgn_stk(void) // Single packet non addressed: 0x0ff00 - 0x0ffff
{
FlagType retflags = 0;
uint8_t ii;
CanRxMsg mess = Rx0Msg;
uint16_t value = ((mess.Data[1] & 0x07) << 8) | mess.Data[0];
if ((value == 1851) || (value == 1857)) { // Raymarine / Simrad verification
switch((mess.ExtId >> 8) & 0x00ffff) {
case 65340: // Simrad Pilot Mode, 0xFF3C
value = get16(&mess.Data[2]);
ii = 0; // Default set: STBY (value == 0x00)
if (value == 0x0110) ii = 0x02; // AUTO Mode
else if (value == 0x0310) ii = 0x04; // VANE Mode
else if (value == 0x0610) ii = 0x08; // TRACK Mode
else if (value == 0x0410) ii = 0x01; // No Drift Mode
NAVDAT.autom = ii; // --> Seatalk1 pilot mode (Thomas Knauf doc)
break;
case 65345: // SeatalkNG Pilot Wind Datum, 0xFF41
BOATDATA.WindRef = get_uangle(&mess.Data[2]); // Pilot wind reference
break;
case 65360: // SeatalkNG Pilot Locked heading, PGN 65360, 0xFF50
NAVDAT.autoc = get_uangle(&mess.Data[5]);
retflags = PILOT_COUR;
break;
case 65379: // SeatalkNG Pilot Mode, 0xFF63
value = get16(&mess.Data[2]);
ii = 0; // Default set: STBY
if (value == 0x0040) ii = 0x02; // AUTO Mode
else if (value == 0x0100) ii = 0x04; // VANE Mode
else if (value == 0x0180) ii = 0x08; // TRACK Mode
else if (value == 0x0181) ii = 0x01; // No Drift Mode (?)
NAVDAT.autom = ii; // --> Seatalk1 pilot mode (Thomas Knauf doc)
break;
}
}
return(retflags);
}

I have also done the control for Simrad B&G pilots, although it is not yet complete for heading corrections in wind mode.
The BOATDATA.WindRef variable is used by Ray as a reference to which corrections are added in wind / vane mode. Those corrections, as you know well, go in radians ^ -4
The variable NAVDAT.autoc is the "Pilot Locked Heading". Reference for corrections in AUTO mode. Also in rad^-4
I would like to discuss the PGN 127237 "heading track control" in this thread. I have seen that manufacturers barely complete it. And this aspect is interesting because they supplement it with PGN propietary ones. In addition, it seems to be "round trip": Order and response. Certainly, the operating mode specified here is not accurate because the "commanded heading" mode refers to three possible modes: Wind, Track and NoDrift.

That is why I think that the pilot calculator only manages the course tracking in magnetic angle, and it is the P70 in this case that is giving orders to correct XTE and wind angle, maneuvers and figures for fishing, etc.

I am finishing the software of a new pilot. In it, all course management is performed by the calculator in all modes. Thus there are no dependencies on external elements of other manufacturers. Do you think it's OK?