AutoTrackRaymarine_pi: Remote control and route following for Evolution Pilots

[mikedefieslife]

Presumably any CAN adapter will work, like the Sailoog Can-USB, and it doesn't specifically need to be an Actisense does it?

I think many are based on the NGT-1 anyway.

[mikedefieslife]

Anyone got a compiled mac version of this? Available.

[mikedefieslife]

Also how is it compiled on the Pi? I'm not really getting anywhere with it.

pi@openplotter:~/Downloads/AutoTrackRaymarine_pi-master $ cmake src
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:27 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginConfigure.cmake


CMake Error at CMakeLists.txt:50 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginNMEA.cmake


CMake Error at CMakeLists.txt:51 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginJSON.cmake


CMake Error at CMakeLists.txt:54 (INCLUDE):
INCLUDE could not find load file:

cmake/FindTinyXML.cmake


-- Building with embedded tinyxml
CMake Error at CMakeLists.txt:75 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginInstall.cmake


CMake Error at CMakeLists.txt:76 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginLocalization.cmake


CMake Error at CMakeLists.txt:77 (INCLUDE):
INCLUDE could not find load file:

cmake/PluginPackage.cmake


-- Configuring incomplete, errors occurred!
See also "/home/pi/Downloads/AutoTrackRaymarine_pi-master/CMakeFiles/CMakeOutput.log".

[Hakan]

mike...
Please read the "README part here: https://github.com/opencpn-radar-pi/radar_pi
But.. the link to opencpn developers manual for the general preconditions is not correct: https://opencpn.org/wiki/dokuwik/dok...ompiling_linux

[mikedefieslife]

I'm getting the same errors no matter what directory or how I try cmake

pi@openplotter:~/Downloads $ cmake AutoTrackRaymarine_pi-master/src
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:27 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginConfigure.cmake


CMake Error at CMakeLists.txt:50 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginNMEA.cmake


CMake Error at CMakeLists.txt:51 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginJSON.cmake


CMake Error at CMakeLists.txt:54 (INCLUDE):
  INCLUDE could not find load file:

    cmake/FindTinyXML.cmake


-- Building with embedded tinyxml
CMake Error at CMakeLists.txt:75 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginInstall.cmake


CMake Error at CMakeLists.txt:76 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginLocalization.cmake


CMake Error at CMakeLists.txt:77 (INCLUDE):
  INCLUDE could not find load file:

    cmake/PluginPackage.cmake


-- Configuring incomplete, errors occurred!
See also "/home/pi/Downloads/CMakeFiles/CMakeOutput.log".
pi@openplotter:~/Downloads $

[Tehani]

I apologize for writing when so much time has passed. I've finally had time to take a look at your code.

I see what you do:

gamma = atan (XTE_for_correction * 1852. / dist) / (2. * 3.1416) * 360 .;
(XTE_for_correction is obtained with a PID from NMEA XTE).
And later:

new_bearing = m_BTW + gamma;

To calculate what I think "bearing to the waypoint" would be, and then you set differences to the current heading to calculate the heading correction to send to the pilot.
My question is: If the BRG to Waypoint is already given in the RMB and APB sentences, wouldn't it be more practical to apply a PID to the difference between this BRG and the COG to calculate the heading correction? I think that this way the mentioned zero_XTE would occur automatically when activating trace mode. The BRG data is the angle to the waypoint from the ship's position at all times.

This way you could add a "NO DRIFT" mode in the style of Simrad. This consists of replacing that reference BRG with the initial COG when activating that NO DRIFT mode. This system automatically corrects for drift, and it is not necessary to set a waypoint.

José Luis.

[Douwe Fokkema]

Originally Posted by Tehani

I apologize for writing when so much time has passed. I've finally had time to take a look at your code.

I see what you do:

gamma = atan (XTE_for_correction * 1852. / dist) / (2. * 3.1416) * 360 .;
(XTE_for_correction is obtained with a PID from NMEA XTE).
And later:

new_bearing = m_BTW + gamma;

To calculate what I think "bearing to the waypoint" would be, and then you set differences to the current heading to calculate the heading correction to send to the pilot.
My question is: If the BRG to Waypoint is already given in the RMB and APB sentences, wouldn't it be more practical to apply a PID to the difference between this BRG and the COG to calculate the heading correction? I think that this way the mentioned zero_XTE would occur automatically when activating trace mode. The BRG data is the angle to the waypoint from the ship's position at all times.

This way you could add a "NO DRIFT" mode in the style of Simrad. This consists of replacing that reference BRG with the initial COG when activating that NO DRIFT mode. This system automatically corrects for drift, and it is not necessary to set a waypoint.

José Luis.

The Zero_XTE is only done at the first activation. It gives the user the feeling it really steers to the first waypoint. Later on Zero_XTE (a call to OpenCPN) is not used, it has no role in the course keeping. I considered using COG for the course keeping. But the problem is that you then do a continuous Zero_XTE, once off track you don't get back. And the idea is that you want to follow the route precisely, within meters. The COG may also be inaccurate and one does not know how quickly it adapts in case of a change of heading. The XTE is very accurate, depending on the GPS. In practice the PID operating on the XTE gives satisfying results. Following complex routes with many short legs and currents the XTE seldom gets above 5 meters. Only on sharp turns at waypoints there may be a larger overshoot. I should introduce a turning radius here.

Douwe Fokkema

[rgleason]

I have been trying to update Douwe's plugin for PIM "Plugin Manager" and have been running into some difficulties related to API117 I think. I had it working for Windows for a brief moment, but that was elusive. The plugin has been moved into frontend template Testplugin 1.0.183.1 and expanded considerably with folders to assist with multiple OS builds. This has been pushed to the "back2working" branch here

https://github.com/rgleason/AutoTrac...e/back2working

The only build that should work at this time is Windows as all circleci builds have been turned off. I understand the plugin was not written with Linux or other builds in mind. It would be great if someone could push this forward to work in Windows first, solving the one or two "undefined" and then modify the code to be compatible with linux.


PS: This thread is about the process so far, and it may help, as you can see, the problem appears to need someone with more than my meager skills. https://github.com/OpenCPN/plugins/issues/511

[rgleason]

The last windows working version is in the master branch commit "0.3.1.18 small chngs" done Nov 29,2021

https://github.com/rgleason/AutoTrac...967fcd1e2f4055

Appveyor completed and that did get deployed too cloudsmith.

[rgleason]

I've found the working version tarball in recycle_bin and have uploaded it to OpenCPN Cloudsmith You can download it and install it using PIM "Import Plugin.


However, we still need to get the source code working and expanded to Linux.

[rgleason]

This is a new plugin added to PIM autotrackraymarine 0.3.4.13 it is by Douwe Fokkema. It is just configured for windows, but we would like find someone willing to modify it to work in Linux and MacOS. The current code is in my repository, but I am going to make a PR back to Douwe shortly.


https://github.com/rgleason/AutoTrackRaymarine_pi

[Tehani]

Originally Posted by Douwe Fokkema

... 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...

I think this is an interesting aspect to consider:

The radius of the earth ranges from 6357 kilometers (3432.876121 Nm) at the pole to 6378 kilometers (3444.216438 Nm) at the equator, for the XTE calculation the mean radius of 6371 kilometers (3440.436332 Nm) is taken.
That is, at the poles we have an error of 0.219745723% by excess, and at the equator of 0.1098729% by default. (+2,197 .. and -1,098 .. per thousand are the extreme values ​​of the error).

Using 3 decimal digits for XTE in the RMB sentence we have an error that ranges from +0.002 Nm to -0.001 Nm depending on the ship's coordinates.
The fact of using 5 decimal digits to represent XTE does not add precision to this calculation, since the indicated error is already appreciable using 3 digits (2 per thousand). In this case, the error extends to the digits 4 and 5: +0.00219 and -0.00110.

The errors added for the calculation of the position (3 coordinates: Origin, destination and present position) have not been taken here, nor the errors in the trigonometric calculation for the calculation of the XTE.

[rgleason]

I believe a change was made in OpenCPN for the more accurate 5 decimal points.
Perhaps the circumference of the earth should be made to vary linearly dependent on position? Or maybe adjust the number of decimals used?

[rgleason]

If you have a large rudder and a strong fast autopilot, can the sharp turns cause a crack in the rudder? I was just reading about an owner of a Bristol 32 who installed a new under deck rudder actuator and autopilot and the next year he noticed a crack in the front of the rudder at the top, so is now rebuilding the glass on the front of the rudder. He thinks it may be due to strength of the new autopilot.


Perhaps a radius at turning would help?

[Douwe Fokkema]

Originally Posted by Tehani

I think this is an interesting aspect to consider:

The radius of the earth ranges from 6357 kilometers (3432.876121 Nm) at the pole to 6378 kilometers (3444.216438 Nm) at the equator, for the XTE calculation the mean radius of 6371 kilometers (3440.436332 Nm) is taken.
That is, at the poles we have an error of 0.219745723% by excess, and at the equator of 0.1098729% by default. (+2,197 .. and -1,098 .. per thousand are the extreme values ​​of the error).

Using 3 decimal digits for XTE in the RMB sentence we have an error that ranges from +0.002 Nm to -0.001 Nm depending on the ship's coordinates.
The fact of using 5 decimal digits to represent XTE does not add precision to this calculation, since the indicated error is already appreciable using 3 digits (2 per thousand). In this case, the error extends to the digits 4 and 5: +0.00219 and -0.00110.

The errors added for the calculation of the position (3 coordinates: Origin, destination and present position) have not been taken here, nor the errors in the trigonometric calculation for the calculation of the XTE.

I don not see the problem. In practice a GPS location is reproducible within a few meters. So we keep the XTE limited as much as we can, normally a few meters. No special version op OpenCPN is needed, the XTE is passed with a API in full precision, already since some releases back.
Douwe