2020-08-19, 02:44 AM
(This post was last modified: 2020-08-19, 03:02 AM by seandepagnier.)
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.
what would be perfect is subjective. It is really difficult in fact because pypilot has a lot of parameters that just don't have a parallel in other autopilots, like the motor slew speed or period, or even the different gains and pilots that can be set.
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.
The other option and one I still hope can eventually work would be to map the pypilot keys directly into signalk. Obviously this will not work with a generic autopilot interface, and there are more than 100 of these now, but it would allow complete control of pypilot through signalk. In order to do this, the server needs to send subscriptions to clients rather than only receiving them. So if two clients subscribe to a key that a third client provides, with say a period of 2 seconds for one and 5 for the other, then the server would send the subscription of the minimum period (2 seconds) to the client that provides the data so that it knows can produce the data only at this rate.
So far when I send data to the signalk server I just output it at 2hz or so, without knowing what rate to actually send because I have no idea if any clients on the server actually care about it or not, and with so many possible keys and things like gyro biases or accelerometer residuals that are usually not important but could be interesting to log, normally you don't want to bother passing all this to the server all the time.
This also allows linking servers quite easily chaining them together and keeping the throughput down because only data that is actually subscribed to at that rate is sent.
as for arrival circle and all of that, I would rather keep it in opencpn or whatever is graphically making the routes and out of the autopilot. The user needs visual interaction for this anyway and opencpn already handles this so sending it to the autopilot only makes sense if opencpn is likely to crash or something, but it's not.
I don't think arrival circles are good anyway. I prefer route position bearing (which makes corrections to follow a route) It is always correcting to get close to the actual route and doesn't use cross track error which can lead to overshoot as the course can change significantly right when you reach a waypoint rather than correcting this error naturally all along. This is not normally desirable anyway and is definitely not how you would normally manually follow a route.
the waypoint arrival and cross track error logic comes from airplanes and in my opinion not really relevant for boats on the water. It's questionable if it's even best for airplanes. From the pilots I've met, they seem to think they know more about boating because they are pilots but in fact these same pilots rely heavily on their engines and I have never used one. So the autopilot route plugin supports 3 or 4 different route following methods with tunable parameters and it's up to the user to decide which is best and so it only needs to send a gps heading to the autopilot, and this makes the interface in signalk simpler because it doesn't need to ever send waypoints, cross track error, arrival radius or any of this to the autopilot, it's all handled in opencpn.
what would be perfect is subjective. It is really difficult in fact because pypilot has a lot of parameters that just don't have a parallel in other autopilots, like the motor slew speed or period, or even the different gains and pilots that can be set.
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.
The other option and one I still hope can eventually work would be to map the pypilot keys directly into signalk. Obviously this will not work with a generic autopilot interface, and there are more than 100 of these now, but it would allow complete control of pypilot through signalk. In order to do this, the server needs to send subscriptions to clients rather than only receiving them. So if two clients subscribe to a key that a third client provides, with say a period of 2 seconds for one and 5 for the other, then the server would send the subscription of the minimum period (2 seconds) to the client that provides the data so that it knows can produce the data only at this rate.
So far when I send data to the signalk server I just output it at 2hz or so, without knowing what rate to actually send because I have no idea if any clients on the server actually care about it or not, and with so many possible keys and things like gyro biases or accelerometer residuals that are usually not important but could be interesting to log, normally you don't want to bother passing all this to the server all the time.
This also allows linking servers quite easily chaining them together and keeping the throughput down because only data that is actually subscribed to at that rate is sent.
as for arrival circle and all of that, I would rather keep it in opencpn or whatever is graphically making the routes and out of the autopilot. The user needs visual interaction for this anyway and opencpn already handles this so sending it to the autopilot only makes sense if opencpn is likely to crash or something, but it's not.
I don't think arrival circles are good anyway. I prefer route position bearing (which makes corrections to follow a route) It is always correcting to get close to the actual route and doesn't use cross track error which can lead to overshoot as the course can change significantly right when you reach a waypoint rather than correcting this error naturally all along. This is not normally desirable anyway and is definitely not how you would normally manually follow a route.
the waypoint arrival and cross track error logic comes from airplanes and in my opinion not really relevant for boats on the water. It's questionable if it's even best for airplanes. From the pilots I've met, they seem to think they know more about boating because they are pilots but in fact these same pilots rely heavily on their engines and I have never used one. So the autopilot route plugin supports 3 or 4 different route following methods with tunable parameters and it's up to the user to decide which is best and so it only needs to send a gps heading to the autopilot, and this makes the interface in signalk simpler because it doesn't need to ever send waypoints, cross track error, arrival radius or any of this to the autopilot, it's all handled in opencpn.