Interoperability between OpenCPN(s) & Devices

[flightlead404]

Originally Posted by sv_pelagia

I am not entirely clear as to what is being asked here... but I will give it a shot.


I create waypoints and routes using OpenCPN. I use them in OpenCPN but also "send" them to my Furuno chartplotter


I usually save them as a GPX, then use another program (GPSUtility) to (i) change the symbols and (ii) save file as a Furuno rat/rou file.


It is too bad that OpenCPN cannot save waypoint/route files in formats other than just gpx. Also, OpenCPN symbols do not translate easily to those on other chartplotters.

I do something similar

Create routes in Open CPN and also using Predict Wind weather routing. I will export these in GPX and import to Aqua Map which supplements my help (open cpn at the nav station only at the moment,).

I would like to take weather route output, bring in to open cpn to edit, then make available to aqua map.

I can do it all now, but it takes multiple steps and imports exports etc. I wonder if there’s a way to share automatically.

[Antipole]

Thinking ahead here... several users run two separate OpenCPN installations, say one at the chart table and another on deck. One issue is keeping the two in sync.

I am minded to see if I can add socket comms to a future version of the JavaScript plugin. Given it would be super easy to transfer JavaScript objects such as waypoints or routes between scripts as JSON strings, this would open a convenient way of keeping waypoints and routes in sync between two OCPN systems without struggling with NMEA. Any interest in this? [This would be a project for me next winter after the 2022 season.]

Taking it a step further, if the slave system is to shadow the master system, it would need extra APIs so that a script running on the slave system could cause it to shadow the master system. I am thinking of:

• Navigate to <position>
• Move boat to <position>
• Navigate to <waypoint>
• Activate <route>
• Activate next waypoint
• Deactivate route

It takes a while for new APIs to be agreed and implemented in a future release of OCPN, so this is a sounding out of interest.

These APIs might also open the way for OCPN to follow a non-OCPN system doing the navigating and sending out NMEA RMB sentences.

[rgleason]

Antipole I've not kept up with your PI, but this sounds very good!

[teppokurki]

Originally Posted by Antipole

Thinking ahead here... several users run two separate OpenCPN installations, say one at the chart table and another on deck. One issue is keeping the two in sync.

I am minded to see if I can add socket comms to a future version of the JavaScript plugin. Given it would be super easy to transfer JavaScript objects such as waypoints or routes between scripts as JSON strings, this would open a convenient way of keeping waypoints and routes in sync between two OCPN systems without struggling with NMEA. Any interest in this? [This would be a project for me next winter after the 2022 season.]

Lol, JSON over (web)socket is one core aspect of Signal K. In addition to navigation data like speeds and depths SK has also provisions for what we refer to as resources: waypoints: waypoints, routes, notes, regions and tracks. The actual content leverages https://geojson.org/, so it's not like we reinvented the whole wheel, just the "bearings": the APIs to handle the resources.

Originally Posted by Antipole

Taking it a step further, if the slave system is to shadow the master system, it would need extra APIs so that a script running on the slave system could cause it to shadow the master system. I am thinking of:

• Navigate to <position>
• Move boat to <position>
• Navigate to <waypoint>
• Activate <route>
• Activate next waypoint
• Deactivate route

It takes a while for new APIs to be agreed and implemented in a future release of OCPN, so this is a sounding out of interest.

These APIs might also open the way for OCPN to follow a non-OCPN system doing the navigating and sending out NMEA RMB sentences.

Yay, interoperability, as in the title!

It just so happens that we have been experimenting with https://en.wikipedia.org/wiki/OpenAPI_Specification for taking Signal K to the next level. Using OpenAPI/Swagger one can create an API specification that specifies the API endpoints, their parameters and responses. This allows much more systematic API usage and implementation and less ambiguous semantics.

In Signal K v1 we were very focused on "one data model to rule them all". Imho that is not enough and does not allow use case specific, richer APIs.

The APIs that we have been applying OpenAPI to are resources and course APIs. Resources API allows one to read & write resources as well as search them, for example by bounding box to plot on a map. Course API is all about the operations you already mentioned: how to set and manipulate the target/course/route that the vessel should navigate.

We have a publicly accessible demo of the aforementioned APIs as well as a web based plotter Freeboard that uses them. In Freeboard you can manage waypoints and routes and activate navigation.
The standardized OpenAPI description format allows us to use a generic UI called Swagger. Swagger renders the machine-oriented API descriptions in a human friendly format and allows testing the APIs for reading and writing the data.

• - APIs
  • - Swagger: https://signalk-course-resources-api...admin/openapi/
  • - Course API: https://signalk-course-resources-api...openapi/course
  • - Resources API: https://signalk-course-resources-api...napi/resources
• - Freeboard: https://signalk-course-resources-api.../freeboard-sk/

The APIs and details are work in progress. It would be absolutely wonderful if somebody with intimate knowledge of O's logic related to route, waypoint and course APIs could have a look at the APIs. As OpenApi JSON they are available at
- https://github.com/SignalK/signalk-s...e/openApi.json
- https://github.com/SignalK/signalk-s...s/openApi.json
and the PR for these changes is at https://github.com/SignalK/signalk-server/pull/1381 where comments are welcome.

[Antipole]

@teppokurki ... thanks for that.

If the JavaScript plugin gains the ability to read and write over sockets, it opens the way for scripts to bridge between OCPN and SignalK in a flexible way.

This would be much more realistic than trying to build SignalK compatibility into OCPN core at this time. If certain bridges became widely used, implementing them in OCPN core later could be considered.

So I think the first step is to add sockets to the JavaScript plugin and to add the necessary OCPN-style APIs to allow control of OCPN or for it to be controlled.

[Antipole]

Originally Posted by Antipole

Taking it a step further, if the slave system is to shadow the master system, it would need extra APIs so that a script running on the slave system could cause it to shadow the master system. I am thinking of:

• Navigate to <position>
• Move boat to <position>
• Navigate to <waypoint>
• Activate <route>
• Activate next waypoint
• Deactivate route

The above seem to meet what a 'slave' instance of OCPN needs but a 'master' OCPN needs to learn when to update a slave. For example, if a user creates or moves a waypoint, it needs to update the slave.

At present, for a plugin/script to know e.g. a waypoint has been modified elsewhere, it would have to keep a copy of them all and then read the current versions every few seconds and compare them to see if anything had changed. No thank you

So we need APIs alerting plugins to such things as:

• Waypoint has been added, updated or deleted
• Waypoint has been arrived at
• Route has been added, updated or deleted
• Route has been activated, deactivated or the active point advanced

What else is needed? Start/stop track recording?
Ideas please.

I will start developing a FlySpray ticket for what is needed. But it is going to need significant support for it to carry the necessary weight to get implemented.

[stevead]

Re:

• Waypoint has been added, updated or deleted - Refer to Flyspray FS#2805 for one suggestion.

• Waypoint has been arrived at - Isn't that the purpose of the the OCPN plugin message OCPN_WPT_ARRIVED ?

• Route has been activated, deactivated or the active point advanced - Similarly isn't that the purpose of the OCPN messages OCPN_RTE_ACTIVATED, OCPN_RTE_ENDED etc. ?

Earlier on in this thread I made a suggestion that perhaps the underlying route/waypoint/tracks storage mechanism should be replaced with a proper database. I'm not suggesting DB2, Oracle or SQL Server but I had a quick play with Litesync, which is based on SQLite and supports replication. I thought it has some promise however, the problem would be untangling the current spaghetti code to cleanly separate what one used to call the business logic & data access layers.

BTW, Instead of web sockets & JSON, how about going retro with DCE RPC and ASN.1 ? Just joking....

[Antipole]

Originally Posted by stevead

Re:

1. Waypoint has been added, updated or deleted - Refer to Flyspray FS#2805 for one suggestion.
2. Waypoint has been arrived at - Isn't that the purpose of the the OCPN plugin message OCPN_WPT_ARRIVED ?
3. Route has been activated, deactivated or the active point advanced - Similarly isn't that the purpose of the OCPN messages OCPN_RTE_ACTIVATED, OCPN_RTE_ENDED etc. ?

Thanks for the input.
1. Yes FS#2805 is headed in the right direction. We need a message when a waypoint is added, updated or deleted, whether via the GUI or through the APIs.
The message reply only needs to give the GUID as a plugin can retrieve other details using the GUID - except when a waypoint is deleted because it will be gone by the time the plugin requests the details.
2. OCPN_WPT_ARRIVED - yes that does the trick. There is a OCPN_WPT_ACTIVATED message but when a route advances, no new message is sent so a plugin may not realise the active waypoint has changed.
3. Yes - almost there. Still need OCPN_RTE_ADVANCED

I have raised a FlySpray requests FS#2888 & FS#2889 for these. Please support these with your vote.

[stevead]

I haven't had time to play with any of this, busy battling my own demons, however

OCPN_WPT_ARRIVED - yes that does the trick. There is a OCPN_WPT_ACTIVATED message but when a route advances, no new message is sent so a plugin may not realise the active waypoint has changed.

It would be nice if there was an appropriate OCPN message, but if the plugin supports the SetActiveLegInfo function, I would expect that when you have arrived at the waypoint the Plugin_Active_Leg_Info member arrival would change to true, and then the Plugin_Active_Leg_Info would advance to the next leg.

Nothing like well spec'd, consistent spaghetti code !

[Antipole]

At present, it seems that any character is allowable in the name of a waypoint, route or track - even !@£$%^&*()_+ is valid.

However, this is not the case when such names are sent out over NMEA. I have recently traced an issue I was having to my use of a comma in waypoint and route names, as in "Church Bay, Rathlin". A comma is the field separator in NMEA 0183 - you can imagine the chaos this caused.

Each sender of NMEA data could arrange suitable substations, but in the interests of interoperability I think there is a case for OpenCPN restricting the acceptable character set that can be used in these fields in the GUI. Plugins creating or editing these objects through the APIs would have to look after this themselves unless an API to filter a name was created.

What say others?

[rgleason]

How is current boat position, speed, etc handled? ....via nmea0183 data stream?
Is there any need for this information to be relayed through the API?

Re Extended character set, this is a problem best solved as a filter somehow, but does OpenCPN just automatically remove those characters or is there some GUI warning when entering the waypoint name when it is an illegal character?

What happens to existing waypoints that are using these problematical characters? A big purge with messages?

I think the characters / and \ in should also be excluded from the waypoint name accepted characters.

[Antipole]

Originally Posted by rgleason

Re Extended character set, this is a problem best solved as a filter somehow, but does OpenCPN just automatically remove those characters or is there some GUI warning when entering the waypoint name when it is an illegal character?

I seem to remember that with wxWidgets it is possible to set a character set on a field by field basis. It is also possible to declare a validation function which is called character by character such that non-acceptable characters simply do not type or beep.
[I am afloat at the mo and not in a position to check the facts here.]

[Be Free]

It is always best practice to sanitize any user input.

[rooiedirk]

I don't think we should limit possibility's in O just because some outside (stupid)devices can't . However checking if a waypoint name is (nmea)valid before sending it over nmea is a good idea.

[skkeith]

I would like to see a gRPC interface on the OCPN API. OCPN would be a gRPC server. Keep the API the same and focus on hardening it. Force all the customization outside OCPN. You don't even need a plugin, you can do gRPC remote from anywhere. Please please please don't use xml or omg sql for this kind of thing. Do an RPC API. If you really need a database do REDIS please avoid xml if we are talking ease of device interoperability.


If you are not familiar, gRPC can be single or streaming single or bi-directional and is super easy to use in any language. The protobuf binary format can be used for efficiency or json if you want a pure asci human readable serialized form.


I guess I could make the gRPC server for OCPN API a OCPN plugin? I have never done OCPN dev before but I might just try this...