Web-based autopilot route

[seandepagnier]

I think we should clear a little what we are talking about when we say "autopilot".

In my current understanding we have separate but sometimes overlapping entities here:
- "navigation computer" - a practical example is following a route and outputting "hey autopilot, please steer this way, and this is where we are in relation to the route I'm following". OpenCpn autopilot plugin, iSailor mobile app's "NMEA Autopilot" feature , which both output nmea0183. All MFDs/chart plotters
- "autopilot" - for example my Simrad TP 32, that can hold a heading on its own (or using magnetic heading from an external source), steer to wind with external wind data and follow instructions from a navigation computer
- "autopilot control" - often separate from the autopilot, but for example in the tillerpillot case integrated. Some display autopilot/steering/navigation related data, such as autopilot mode, xte, heading etc and have "button" for control, such as changig the ap mode, engage/disengage, alter heading/wind angle (+/- 1/10), acknowledge arrival/waypoint switch

This "autopilot control".. so it still requires the navigation computer to make the route?

I have made the needed changes to the control portion of pypilot to work on esp32 (using micropython) so it's possible to configure and control pypilot from a wireless esp32 remote control. It does all of what you said except for "acknowledge arrival waypoint" as I don't agree with xte. I prefer to follow a route and the pilot does not acknowledge anything it just goes from one waypoint to the next. If it doesn't, you could run aground in a channel if you don't acknowledge in time, so I really just want the opposite which is to disengage if the autopilot is steering wrong somehow and take over control.

I never would send waypoints from opencpn, only the course to steer. Maybe some people would like this and it can be added eventually.

Speaking of which: Sean, could you please explain in more detail what you meant with command?

What you refer to as "target" I use the word "command"

I don't want to see implementation specific paths in the data model, so please no pypilot or nmea2000. What if tomorrow I implement jsPilot that supports some features that are today only available in PyPilot and some only in APs with N2K interface? Doesn't really add value.

The drive to support integration with NMEA devices has resulted in som e paths that may or may not make sense. I don't think we need to spend time debating stuff that is in the spec now that seems irrelevant - if the systems we create have no use for them they don't bother us much, unless we expend energy on debate...

They bothered me because it seems like the signalk spec is trying to tell me the right way to implement an autopilot. If these are top level autopilot keys, then any control interfaces are likely to have interfaces for them that will not be fully functional.

I would like them to be under autopilot.nmea2000 and then I have nothing more to complain about. Now it is clear to everyone where these keys apply and don't and they shouldn't expect them to work with pypilot (because otherwise people will and ask why they don't work)

>I don't understand why there are two unless the boat is assymetrical.

My tillerpilot mechanical setup is asymmetrical. If/when its electronics give up the ghost one day my plan is to put pypilot in control...

So.. does it fit in different places depending on which tack you are on, or does it always have more range in one tack? If it does, why don't you mount it in the center? If you don't need to, then the extra range on one side is probably not useful anyway. I know it may seem like I'm fighting to reduce keys when it's just another if statement etc... I am, because I can forsee there will end up being many more keys than we discussed and the fewer total keys the better and easier to deal with in the future.

- a client requesting certain update rate and server passing the request on to the sensor
as it is not autopilot/steering specific

I think the server should just pass the combined subscriptions of it's other clients whenever a new client connects. The subscription format is already defined, but currently it's only sent from clients to the server.

In the pypilot data model the clients all can "register" (signalk it will be advertise) what keys they produce with the server. This way when a "watch" (in signalk subscription) is received by the server it knows which client to send it to (after combining it with existing subscriptions)

So basically it sends the highest data rate subscription to the client producing the data, and uses a priority queue to deal with the various data rates of different clients and different keys. This also is nice because the server knows exactly how long it can sleep before it needs to wake up and send data. The client also uses a priority queue as the first item has the lowest timeout to deal with the various different keys that could be at different rates.

There is already a working pypilot and signalk client which relays data between the two. Currently it just sends or receives wind, gps, rudder angle, and imu (send only) and the rate is fixed to 2hz to avoid too much cpu. If this were working with subscriptions it would allow mounting pretty much every pypilot key under a signalk path which would be pretty cool and variable rates as needed. It would be possible to use with node red or whatever else with ease.

You could also chain signalk servers together and get all the features and rates with minimum cpu and bandwidth.