2022-10-20, 08:46 PM
Hello Sean,
Many thanks, as ever, for you super quick reply.
Crikey, there was a lot to read in those two conversations, and quite a lot to read between the lines!
As far as the Signal K Autopilot plugin is concerned, as you say, this is solely written to handle the bespoke RayMarine / AutoHelm / SeaTalk 1 way of doing things. We've got a Digital Yacht widget on the boat that bridges the SeaTalk 1 & NMEA0183 world. It will automagically translate a handful of the data items between the two 'standards', but there are ton of things for which there aren't direct translations which it ignores in the default mode. You can enable a 'SeaTalk' mode though, which turns off the translation and just pumps out the raw SeaTalk data onto the NMEA side using a talker ID of $STALK. The format of these sentences has been reverse engineered and documented by Thomas Knauf on his site:
http://www.thomasknauf.de/rap/seatalk2.htm
The SeaTalk messages I'm most interested in translating are the ones that turn an AutoHelm autopilot 'on' and 'off':
$STALK 86,21,01,FE = Switch to Auto
$STALK 86,21,02,FD = Switch to Standby
These are the equivalent of pressing the 'AP' button on the PyPilot web interface and are generated in the Autopilot plugin in the autopilotgui_impl.cpp code here:
My initial simplistic idea was to just extend this snippet to also post whatever NMEA / Signal K sentence PyPilot was looking for. But, PyPilot (or any other autopilot for that matter) doesn't work like that.
My next thought is to look at the PyPilot scripts that you supply and cobble something together that will use your client code to connect to PyPilot on port 23322 and also listen to what's coming in on the SeaTalk interface. When it spots one of those messages, it can simulate the 'AP' button having been pressed. If that works, then I don't think I'd actually need the Signal K autopilot plugin as I'm trying to be able to control PyPilot from the AutoHelm controls up in the cockpit.
For what it's worth, having read the discussions in those two Signal K / AutoPilot threads I have to admit that I think that they only way that Signal K is ever going to be able to sustainably manage to integrate this sort of functionality is to start putting implementation specific keys under the steering.autopilot key (i.e. steering.autopilot.pypilot.* and steering.autopilot.autohelm.*). That preserves the current steering.autopilot implementation if anyone is using it and avoids the problem of different pilots having different interpretations of the same key. Sadly, there is too much variation in the real world to ever be able to come up with a coherent, standard, reference autopilot definition and therefore model it through Signal K.
The alternative of prefixing implementation specific keys with the name of the pilot that uses them (i.e. steering.autopilot.pypilotEnabled and steering.autopilot.autohelmEnabled) seems messy, exposes every autopilot to every other autopilots implementation specifics and probably makes it more difficult to subscribe to all the messages you'd need for a particular implementation.
Cheers
Dez
Many thanks, as ever, for you super quick reply.
Crikey, there was a lot to read in those two conversations, and quite a lot to read between the lines!
As far as the Signal K Autopilot plugin is concerned, as you say, this is solely written to handle the bespoke RayMarine / AutoHelm / SeaTalk 1 way of doing things. We've got a Digital Yacht widget on the boat that bridges the SeaTalk 1 & NMEA0183 world. It will automagically translate a handful of the data items between the two 'standards', but there are ton of things for which there aren't direct translations which it ignores in the default mode. You can enable a 'SeaTalk' mode though, which turns off the translation and just pumps out the raw SeaTalk data onto the NMEA side using a talker ID of $STALK. The format of these sentences has been reverse engineered and documented by Thomas Knauf on his site:
http://www.thomasknauf.de/rap/seatalk2.htm
The SeaTalk messages I'm most interested in translating are the ones that turn an AutoHelm autopilot 'on' and 'off':
$STALK 86,21,01,FE = Switch to Auto
$STALK 86,21,02,FD = Switch to Standby
These are the equivalent of pressing the 'AP' button on the PyPilot web interface and are generated in the Autopilot plugin in the autopilotgui_impl.cpp code here:
Code:
void Dlg::OnAuto(wxCommandEvent& event)
{
wxString sentence = "$" + plugin->STALKSendName + ",86,21,01,FE";
plugin->SendNMEASentence(sentence);
if (plugin->WriteMessages) wxLogMessage((" Pushed Auto %s"), sentence);
plugin->NeedCompassCorrection = false;
}My initial simplistic idea was to just extend this snippet to also post whatever NMEA / Signal K sentence PyPilot was looking for. But, PyPilot (or any other autopilot for that matter) doesn't work like that.
My next thought is to look at the PyPilot scripts that you supply and cobble something together that will use your client code to connect to PyPilot on port 23322 and also listen to what's coming in on the SeaTalk interface. When it spots one of those messages, it can simulate the 'AP' button having been pressed. If that works, then I don't think I'd actually need the Signal K autopilot plugin as I'm trying to be able to control PyPilot from the AutoHelm controls up in the cockpit.
For what it's worth, having read the discussions in those two Signal K / AutoPilot threads I have to admit that I think that they only way that Signal K is ever going to be able to sustainably manage to integrate this sort of functionality is to start putting implementation specific keys under the steering.autopilot key (i.e. steering.autopilot.pypilot.* and steering.autopilot.autohelm.*). That preserves the current steering.autopilot implementation if anyone is using it and avoids the problem of different pilots having different interpretations of the same key. Sadly, there is too much variation in the real world to ever be able to come up with a coherent, standard, reference autopilot definition and therefore model it through Signal K.
The alternative of prefixing implementation specific keys with the name of the pilot that uses them (i.e. steering.autopilot.pypilotEnabled and steering.autopilot.autohelmEnabled) seems messy, exposes every autopilot to every other autopilots implementation specifics and probably makes it more difficult to subscribe to all the messages you'd need for a particular implementation.
Cheers
Dez