Web-based autopilot route

[seandepagnier]

First, thanks for taking the time to post this and please don't be dissuaded by my strong opinions.   We will reach an inevitable agreement (I my latest code now pypilot does now automatically detect and exchange data with signalk node server for wind, gps, imu etc..)

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.

This is my disagreement.   You are requiring redundant logic to be re-duplicated in every client that is implemented to deal with the different targets when only one is used.  Also missing the true-wind mode.   What about autopilots that implement more modes than we have discussed?  How will they set a target?   Why wouldn't you just set autopilot.target to the course you want to steer in the mode you are in?

You say it doesn't make sense to provide wind angle in the same field as a gps course, but it is just a number.   So what are you gaining by having separate keys besides making all of the clients have to have extra logic?   If there is a single key and target, the +10 button can just add 10 to the target instead of having to check which mode it's in and then update that specific key even though none of the other keys can be used in that mode.  What am I missing?

Other than these main three, we also have:

• autopilot.deadZone
  
• autopilot.backlash
  

I propose most of these are not useful to most users and should not be main parameters.   I think main parameters should be ones that are applicable to all autopilots, not just a specific one and we seem to agree on this.

This leaves us with
/vessels/<RegExp>/steering/autopilot/state
/vessels/<RegExp>/steering/autopilot/mode
/vessels/<RegExp>/steering/autopilot/target

The other parameters are pilot specific and it would be great to put them in a separate category such as autopilot.nmea2000 or wherever they are actually used.   Can we make a list of autopilots intended to be supported by signalk and what parameters each support? This will help determine how they can be classified and maybe some autopilots can share parameters without making them main parameters.

What about tacking, manual dodging, and manual control?  Can these be handled as a main parameter?

Please understand I am frustrated by the possibility of the signalk standard for autopilots being designed specifically to fit proprietary systems.

---

autopilot.deadZone
autopilot.backlash

These are autopilot specific. In my opinion they are the wrong way to implement the control logic. pypilot has instead a servo.period which sets the minimum amount of time the motor can move or be stopped which seems to work in a wide range of sea states.

pypilot supports alternative pilots and one day, a pilot may be implemented that does use these parameters for comparison purposes, but in any case these are clearly pilot specific.

autopilot.gain

pypilot has 7 gains for the basic autopilot, so a single gain field is not very useful

autopilot.maxDriveCurrent
autopilot.maxDriveRate

According to the signalk specification, these are also not useful parameters to set for any autopilot. the maxdrivecurrent will limit the motor current to a maximum amps?? This is not what you want to do if you want the autopilot to get back on course (and thus minimize errors as well as power consumption)

pypilot has a maximum current setting which is used to detect end of travel (without rudder feedback) and detect if the system is jammed or shorted.

The maxDriveRate is also impossible to set in radians per second if you don't have rudder feedback, and even if you did, you want the motor to move quickly. pypilot does have servo.speed.max to limit motor speed (in relative terms) but it is only actually useful if you used say a 12 volt motor on a 24 volt system to avoid burning it out.

If the idea is the limit power consumption, pypilot does this by setting the minimum motor speed, not the maximum speed or current. This ensures the motor is running at this speed or stopped which is more efficient than running too slowly especially on a high friction drive. The best setting for efficiency (but not noise) is to make the motor run at full speed or stopped on lead screws, and with ball screws you can set it to lower values.

pypilot also has slew speeds to limit acceleration and deceleration which is really important to adjust on some drive units to ensure smooth operation.

autopilot.portLock
autopilot.starboardLock

I don't understand why there are two unless the boat is assymetrical. pypilot has just rudder.range