Web-based autopilot route

[emilecantin]

mostly i'm just ranting because I had zero input on the spec and it seems to be based on existing nmea2000 autopilots... so... don't take it too critically.

So I suggest basic keys for:
mode   --  compass, gps, wind, true wind
command   -- the command for the above mode.  I don't like having separate keys for each mode's command it seems redundant to me and just more work for each client interface to deal with.
enabled -- I guess this could be rolled into the mode but I suggest it isn't so the mode can be known or changed even when the autopilot is off.

this is really the basics, only 3 keys needed.  command can move the motor when not enabled.  

Looking at the published spec (https://signalk.org/specification/1.4.0/...gautopilot), it looks like we're not that far from your suggestions:

We have:

• autopilot.state: missing enum values, but would conceivably be something like "enabled", "disabled", "error", etc., mapping to your "enabled" proposal
  
• autopilot.mode: again missing enum values, but would map to the values you mention
  
• autopilot.target: that's where it diverts; it's using different sub-keys for different value "types", but you would presumably only look at the pertinent one depending on the mode you're in.
  

I think we should really specify the target a bit more, as it doesn't make sense to provide a wind angle when steering a GPS course. We should explicitely define this as invalid, and clients (or autopilots) could safely ignore nonsensical values.

Other than these main three, we also have:

• autopilot.deadZone
  
• autopilot.backlash
  
• autopilot.gain
  
• autopilot.maxDriveCurrent
  
• autopilot.maxDriveRate
  
• autopilot.portLock
  
• autopilot.starboardLock
  

Which seem to me like the main params you'd want to tweak in an autopilot. I propose we keep that top level relatively succinct (but I'm open to adding a few more), and that we create pilot-specific sub-keys that could be "owned" by that specific pilot's maintainer, and store arbitrary data. In this case, we could define a autopilot.pypilot key where Sean can store whatever he wants (including the full internal tree). Other clients would have to add specific support for this, but it wouldn't risk any compatibility issues with other pilots.