2020-08-22, 12:07 PM
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 changing the ap mode, engage/disengage, alter heading/wind angle (+/- 1/10), acknowledge arrival/waypoint switch
In general I'd like to talk about in more precise terms just to ease communication, an example being heading and course instead of compass and gps.
Speaking of which: Sean, could you please explain in more detail what you meant with command?
In Signal K control/command is usually separate from "sensor data", eg. data about the current value of something. Control messages are HTTP PUTs or (ws) messages with put syntax: https://github.com/SignalK/specification...ocs/put.md
______________________________________
To be able to make concrete progress I created a wiki page that I invite you to edit & expand. Discussion on the wiki page is probably less than fruitful, but it might work for collaborative editing and discussion here? (I'd much prefer a github issue to a forum like this, but I can concede..)
https://github.com/SignalK/specification...paths-2020
______________________________________
autopilot.target - I agree with Emile, having explicit keys for different data items is much better: explicit, less chance for error / bugs.
This is also more in line with the rest of the SK data model: a somewhat similar example is that we don't just send "depth" as reported by a sensor and then separately tell if the sensor happens to adjust for transceiver installation depth or not.
> So what are you gaining by having separate keys besides making all of the clients have to have extra logic?
An AP that supports several modes already hsa separate logic for handling the different modes - that must be an order of magnitude more code than the logic needed for separate paths.
We gain explicitness - a practical example would be ease of debugging, you see that the data is a wind target when you were expecting it to be heading.
This allows also managing these separately: you may set target course while the AP is in wind mode and then switch to course mode.
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 some 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...
>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...
______________________________________
I'll create a separate issue about extending subscription model to cover
- a sensor advertising what data it has available
- the server subscribing to the data
- a client requesting certain update rate and server passing the request on to the sensor
as it is not autopilot/steering specific
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 changing the ap mode, engage/disengage, alter heading/wind angle (+/- 1/10), acknowledge arrival/waypoint switch
In general I'd like to talk about in more precise terms just to ease communication, an example being heading and course instead of compass and gps.
Speaking of which: Sean, could you please explain in more detail what you meant with command?
In Signal K control/command is usually separate from "sensor data", eg. data about the current value of something. Control messages are HTTP PUTs or (ws) messages with put syntax: https://github.com/SignalK/specification...ocs/put.md
______________________________________
To be able to make concrete progress I created a wiki page that I invite you to edit & expand. Discussion on the wiki page is probably less than fruitful, but it might work for collaborative editing and discussion here? (I'd much prefer a github issue to a forum like this, but I can concede..)
https://github.com/SignalK/specification...paths-2020
______________________________________
autopilot.target - I agree with Emile, having explicit keys for different data items is much better: explicit, less chance for error / bugs.
This is also more in line with the rest of the SK data model: a somewhat similar example is that we don't just send "depth" as reported by a sensor and then separately tell if the sensor happens to adjust for transceiver installation depth or not.
> So what are you gaining by having separate keys besides making all of the clients have to have extra logic?
An AP that supports several modes already hsa separate logic for handling the different modes - that must be an order of magnitude more code than the logic needed for separate paths.
We gain explicitness - a practical example would be ease of debugging, you see that the data is a wind target when you were expecting it to be heading.
This allows also managing these separately: you may set target course while the AP is in wind mode and then switch to course mode.
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 some 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...
>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...
______________________________________
I'll create a separate issue about extending subscription model to cover
- a sensor advertising what data it has available
- the server subscribing to the data
- a client requesting certain update rate and server passing the request on to the sensor
as it is not autopilot/steering specific