OpenCPN to Autopilot

[Douwe Fokkema]

Originally Posted by stevead

It's just software, we can make it do whatever we want !

On a serious note, what PGN's do you need ?

My fear would be that on a typical NMEA 2000 network, with GPS, Depth, Speed, Wind transducers, Rudder feedback, AIS plus the usual overhead of NMEA 2000 (address claims, heartbeats, product info), we may be overloading the OpenCPN plugin messaging framework.

Alternatively, if it is possible to understand all of the PGNS that different brands of autopilots transmit, then TwoCan could parse these and it could either generate an appropriate response or forward an "Autopilot Response" message to be handled by your (or any other plugin) which would generate an "Autopilot Request" to then be encoded and transmitted by TwoCan onto the network.

The AutotrackRaymarine plugin needs some raw proprietary Raymarine PGN's as input. Below the PGN's that are used now, input only, but this could change in later versions, one never knows, should be selectable as you do now with the ones that are converted. The PGN's that are transmitted towards the pilot can be handled by your latest version of twocan. I did not test this as I have no device that is supported by twocan. I use the NGT-1.

Input from EV-1 pilot to AutotrackRaymarine

65360: // Autopilot heading. From pilot. Transmitted only when pilot is auto.
126208: // if length is 28: command to set to standby or auto
// if length is 25: command to set to heading
126720: // message from EV1 (204) indicating auto or standby state
65359: // heading all the time

Douwe

[Douwe Fokkema]

Originally Posted by rgleason

Douwe, what can we do to get this plugin working on multiple OS? If I were to try building it for multiple OS to get the specific errors, would you be able to help fix those?

The problem with other platforms is only in the handling of the serial port, very different on other platforms. This code (Windows) was largely cloned from OpenCPN itself. It should be possible to add the code for the other platforms here. But then I lack testing facilities on board.

It would be better if another party, preferably O itself, but more realistic twocan plugin, would redistribute selected raw PGNs (as O does with nmea083 messages). One should be able to flexibly list the PGNs wanted, a tick box list will never be complete.

Currently the basic purpose of twocan is to translate PGNs into their nmea083 equivalent. That is not integration but translation, nmea083 is integrated in O. What we need is integration of N2k (used everywhere) as was done with SignalK (used nowhere).

Douwe

[bdbcat]

Douwe...


"What we need is integration of N2k (used everywhere)"
Let us start a specific conversation about his. Perhaps on github as an "Issue"?


Dave

[wholybee]

I do not believe the EV autopilot is capable of steering to a waypoint, rather it steers by XTE.

If it were to steer to a waypoint, then while it would get to the waypoint, current would cause it to not stay on course, which would be hazardous if the route steered around obstructions.

[seandepagnier]

Originally Posted by Douwe Fokkema

n of N2k (used everywhere) as was done with SignalK (used nowhere).

Douwe

I have never used n2k for anything (used nowhere) I use signalk everywhere. Why dont you just convert n2k into signalk and just use that?

better than complicating opencpn to support a protocol most people dont even use.

[bdbcat]

Sean...
n2k is used by very many cruisers with modern electronic suites.

Unfortunately, n2k is closed source, and the sentences (PGN's) are sadly very vendor specific. Most of what we know has come from reverse engineering.

Having said all that, it is worth some effort to create some extensible "framework" for integrated n2k in OpenCPN, or at least think and talk about it.


Dave

[stevead]

I have never used n2k for anything (used nowhere) I use signalk everywhere. Why dont you just convert n2k into signalk and just use that?

Rhetorical question, what commercially available equipment (depth, speed, wind, gps, vhf, ais) that most recreational sailors install, natively support SignalK ?

If OpenCPN had an API similar to PushNMEABuffer, such as PushSKBuffer and converting to the SignalK JSON format instead of NMEA 183, it could be an alternative. It's just text. But why ? Many OpenCPN users still possess NMEA 183 devices so OpenCPN will still have to parse NMEA 183 for many years to come.

From a performance perspective it seems ludicrous for a plugin to decode some incoming data encode it as NMEA 183 (or SignalK), only for OpenCPN to decode it.

The best example of this wastage is AIS. TwoCan decodes NMEA 2000 AIS messages, does the 6 bit AIS encoding, generates a NMEA 183 VDM message, only for OpenCPN to perform the reverse. What a waste of CPU cycles!


Douwe,

Lengthy private e-mail sent regarding controlling Raymarine autopilots. I think a solution could be closer than we think.

[Douwe Fokkema]

Originally Posted by bdbcat

Douwe...


"What we need is integration of N2k (used everywhere)"
Let us start a specific conversation about his. Perhaps on github as an "Issue"?

Dave

See Integrated NMEA2000 support for OpenCPN #2729

https://github.com/OpenCPN/OpenCPN/issues/2729

Douwe

[RaymondR]

Since there are only a few parameters we need to correctly instruct an autopilot it appears (to a non coder) to not be that extensive a project create software to parse out the relevant items and convert them to sentences the autopilot could use.

[seandepagnier]

Originally Posted by stevead

Rhetorical question, what commercially available equipment (depth, speed, wind, gps, vhf, ais) that most recreational sailors install, natively support SignalK ?

I have depth (nmea0183) no advantage to signalk n2k there.
I have speed (land leeway) and wind also nmea0183 and there is no advantage to n2k.
vhf/ais is also nmea0183

signalk is slightly problematic on serial ports as there is no checksum or a standard way of ensuring data integrity.

Where the newer protocol would have an advantage is in things not defined in nmea0183 which are none of what you mentioned.

Consider 3D wind, autopilot control, route/waypoint sharing, and of course multiple redundant sensors.

So I simply suggest converting n2k into signalk as there is already a program to do that, and implement signalk in opencpn to support any missing features which will benefit users of both n2k and signalk.

If OpenCPN had an API similar to PushNMEABuffer, such as PushSKBuffer and converting to the SignalK JSON format instead of NMEA 183, it could be an alternative. It's just text. But why ? Many OpenCPN users still possess NMEA 183 devices so OpenCPN will still have to parse NMEA 183 for many years to come.

nmea183 is already still preferable to signalk in certain cases. You will need something similar for n2k or any protocols supported.

For signalk it would be preferable for the main process to parse the incoming message and put it into a data object for use by the plugins to avoid redundant processing by each plugin, but either way. Allow functions to get data based on absolute path, or just the first available wind sensor are needed and more api functions to get reasonable support.

From a performance perspective it seems ludicrous for a plugin to decode some incoming data encode it as NMEA 183 (or SignalK), only for OpenCPN to decode it.

But the cpu cycles for this work are irrelevant so it makes sense from a maintenance perspective as there is less code paths.

The best example of this wastage is AIS. TwoCan decodes NMEA 2000 AIS messages, does the 6 bit AIS encoding, generates a NMEA 183 VDM message, only for OpenCPN to perform the reverse. What a waste of CPU cycles!

What % of cpu does it take to do this? I can find other places that waste more cpu.

[seandepagnier]

Originally Posted by bdbcat

Sean...
n2k is used by very many cruisers with modern electronic suites.

I dont doubt that based on this thread! Maybe its use is increasing?

Just wanted to point out there are plenty of people with no n2k, and there is no real advantage to using it. Everything it can do I have alternatives (actual 3d printed sensors etc) that are actually also better and cheaper. It just seems problematic overall to have a closed protocol like n2k which is why I suggest the minimum effort path of signalk conversion which helps signalk integration at the same time.

[sailorxyz]

Originally Posted by seandepagnier

I dont doubt that based on this thread! Maybe its use is increasing?

Just wanted to point out there are plenty of people with no n2k, and there is no real advantage to using it. Everything it can do I have alternatives (actual 3d printed sensors etc) that are actually also better and cheaper. It just seems problematic overall to have a closed protocol like n2k which is why I suggest the minimum effort path of Signalk conversion which helps Signalk integration at the same time.

Fact is however that modern instrument systems and autopilots all use N2K no commercial gear that I know of, uses SignalK. SignalK is a great idea but in the real world, there is no support for it. On my own boat, apart from ancient AIS which uses 0183, everything is N2K.


Personally I think OpenCPN needs to support N2K and 0183 and I see little need for it to support anything else at this point in time.

[seandepagnier]

Originally Posted by sailorxyz

Fact is however that modern instrument systems and autopilots all use N2K no commercial gear that I know of, uses SignalK. SignalK is a great idea but in the real world, there is no support for it. On my own boat, apart from ancient AIS which uses 0183, everything is N2K.

This is on your boat and your choice. We are both in the same world and there is support for signalk for everything you have and more. On my boat I have all the instruments and better with autopilot all using signalk. I think for n2k devices you probably pay about 10 times more and the result is an inferior product.

Personally I think OpenCPN needs to support N2K and 0183 and I see little need for it to support anything else at this point in time.

So add support for n2k.

I personally think OpenCPN should not support n2k. Even if it were easy to do, since it is a proprietary standard it is better not to support it. This will also discourage people from using n2k and help encourage them to use better sensors and equipment where they have more freedom and are able to repair/replace more modular components at a small cost. I also would not support windows or macos operating systems, so obviously other developers implement support for things they want, and you could do this with n2k.

For example, a bird breaking a wind sensor you can order 3d printed vane for $3 or print one. With n2k you have no freedoms like this, to inspect modify improve the source code and so forth: it isn't really worth consideration.

As it is, you can convert n2k into nmea0183 or signalk and just use that, so already opencpn supports it, just requiring the signalk server to perform a conversion. For this reason it doesnt make much sense to support it directly in opencpn.

[RaymondR]

Originally Posted by seandepagnier

This is on your boat and your choice. We are both in the same world and there is support for signalk for everything you have and more. On my boat I have all the instruments and better with autopilot all using signalk. I think for n2k devices you probably pay about 10 times more and the result is an inferior product.

So add support for n2k.

I personally think OpenCPN should not support n2k. Even if it were easy to do, since it is a proprietary standard it is better not to support it. This will also discourage people from using n2k and help encourage them to use better sensors and equipment where they have more freedom and are able to repair/replace more modular components at a small cost. I also would not support windows or macos operating systems, so obviously other developers implement support for things they want, and you could do this with n2k.

OpenCPN is one of the finest software products ever developed and is readily available at an unbeatable price. It does not rely upon any market capture ploys to attract an extensive and loyal user base and any attempt to pollute it with crass commercial, monopolistic software and devices should be vigorously resisted.

[wholybee]

Originally Posted by seandepagnier

<snip>

I personally think OpenCPN should not support n2k. Even if it were easy to do, since it is a proprietary standard it is better not to support it. This will also discourage people from using n2k and help encourage them to use better sensors and equipment where they have more freedom and are able to repair/replace more modular components at a small cost. I also would not support windows or macos operating systems, so obviously other developers implement support for things they want, and you could do this with n2k.

NMEA2000 is NOT proprietary, and is an official standard IEC 61162-3. It is supported by every marine equipment manufacture. Whatever you would suggest instead of NMEA standards would make OpenCPN incompatible with basically the entire industry.

OpenCPN doesn't need NMEA2000 only because other products convert NMEA2000 to NMEA0183. But it really would be advantageous if it did.

The future is Onenet, based on NMEA2000, except over Ethernet. Opencpn developers should be looking forward to that, as it will soon be needed.