Controlling Pypilot

[diverdezzy]

Hello,
Having got Pypilot sorted out running on its own Pi, I've been noodling around with Openplotter running on a separate Pi.  I've sorted out a bridge to our aged SeaTalk 1 network using SignalK and everything is now playing nicely together.  Pypilot has got all the wind and GPS info it needs for all of the modes to work properly.

In reading around, I've stumbled on the AutoPilot SignalK plugin which is now happily talking to our SeaTalk / AutoHelm instruments, and the obvious question is now how would I go about linking things up so that using the AutoHelm instruments I can activate / deactivate Pypilot.  I had thought that there would be an NMEA sentence that covered this, but I think that it's actually handled by the internal Pypilot comms on port 23322.  I don't suppose that something already exists to do this does it?  A handy dandy bit of code that monitors the $STALK sentences whilst connected to port 23322 and translating between the two?

Or have I got it completely wrong, and there's a magic switch or plugin somewhere within Pypilot / OpenPlotter / SignalK that already bridges the very old with the very new?

Cheers
Dez

[seandepagnier]

Does it produce nmea sentences or signalk? I am asking because you mention $STALK.

The autopilot signalk plugin being: https://github.com/SignalK/signalk-autopilot ?

To be clear this is specific to the raymarine autopilot. The author of this plugin essentially ignored my inquiries about how to make it universal (support pypilot) and from what I recall basically told me the raymarine way is the right way. Further, the signalk autopilot definitions are all written for raymarine without consideration for pypilot, and my attempts to make the signalk standard un-biased are rejected.

https://github.com/SignalK/signalk-autopilot/issues/1
https://github.com/SignalK/specification/pull/624

Please come back after reading these discussion with your opinions. I have all but given up hope for using signalk to control pypilot. I provide several control interfaces, such as web control, opencpn plugin etc. An additional service could somehow translate things and provide control but I do not know have a way to test. Can you provide details of the sentences? pypilot uses signalk for wind, gps, and other sensor data but not for autopilot control or configuration unfortunately.

[diverdezzy]

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:

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

[seandepagnier]

I agree. Your simplest solution is to write a helper program that translates. You can use python scripts or manually write your own clients. The opencpn pypilot plugin is entirely c++. It is also possible to simply invoke the pypilot_client command, eg: "pypilot_client ap.enabled=true" to enable the pilot.

In any case, I tried to suggest that the signalk specification include minimal keys for autopilot and to remove all the raymarine specific ones or rather relocate them to ensure it is obvious that they have no effect on other pilots. I suggested adding keys specific to pypilot as well. Instead I am told that pypilot should basically try to be more like a raymarine pilot and stop using settings or features that raymarine pilots do not have. So now I am not really interested in using signalk to control or configure pypilot anymore, it is used just for sensor data.

[TiPegleg]

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:

Dez, I'm essentially in the same boat as you. I have an older T300 raymarine autopilot and st7000 control heads. Honestly, I like the robust push button and display of the st7000's and wanted to re-use them. Let me know if you come up with a solution, would love to implement.

[TiPegleg]

@Dez I'm basically in the same boat as you. I have an older T300 raymarine computer and a pair of st7000 control heads. I actually really like the robust st7000's and wanted to re-use them. I figured since they talk seatalk1 that I then can convert into nmea0183 this would be pretty simple, but I guess not? Let me know if you have a solution, I'd love to implement it.

[sd_tom]

I sort of have been wondering about this as well.  I have a raymarine p70 hanging off my nmea 2000 bus for existing wheel pilot from previous owner.   I'm due a CPT autopilot here in a few weeks and would like to use pypilot to have a network aware controller for it as the CPT guys said the wheel pilot controllers don't have enough peak current.    Anyways, since the P70 is installed, has +/- 1, +/- 10, auto , standby and track/vane mode buttons.. man that would sure be nice to both capture the buttons and provide data to it to display as it looks great, weather resistant and already there.  Plus I already have a chartplotter so have no intention of running opencpn.  So a headless raspberry pi is ideal.

Been looking at canboat utilities so I can try to isolate and sniff the display.  

Looks like steps are something like
- add message parsing to signalk if not already there
- plugin for signalk that in turn calls pypilot_client.  

Otherwise it would be 'tough' to bring in canbus/nmea200 direct to pypilot when all the sensor data also on canbus and pypilot is setup for that for sensors.

[mgrouch]

In aviation drone autopilots run on lower bandwidth and speed than NMEA 2000.
Autopilot is a part of RC controls of a drone. Or am I wrong with my statements?

Thanks

PS: I think I've replied to wrong thread.

[sd_tom]

A few things..
- I only bring up nmea2000 because my AP control head, a raymarine P70 is already canbus/nmea2000/seatalkng.  Takes power off the bus and talks to the AP computer which I will be removing for pypilot.  
- the control heads aren't doing calculations, they are just user interfaces to AP computers located elsewhere.  Just like a GUI.  However maybe someone else knows they may be talking at a higher protocol than just "user pushed >10 button".. maybe they just ship heading or something more encoded to the AP computer.
- not sure why comparison to drone autopilots.. their user interfaces are seperated by a wireless radio and, strangely I have personal experience with those (global hawk anyone) and the autopilot is in the aircraft, the ground stations just sent commands.. . They are a bit fancier than sailboat ones lol

[mgrouch]

- not sure why comparison to drone autopilots.. their user interfaces are seperated by a wireless radio and, strangely I have personal experience with those (global hawk anyone) and the autopilot is in the aircraft, the ground stations just sent commands.. . They are a bit fancier than sailboat ones lol

So autopilot logic is in drone? What does drone runs? What autopilot is run in drone? Just MCU or more power hungry pi with linux?