2020-08-25, 04:19 PM
(This post was last modified: 2020-08-25, 04:58 PM by seandepagnier.)
There are essentially 2 GPS modes:
1) following a gps course. pypilot does this normally in gps mode
2) following a route. pypilot sets the gps course from APB nmea sentences if it receives them staying in gps mode.
Now some users want to ignore the APB messages at times, and follow a true non-changing gps course and be able to switch this on and off from the autopilot. So they want to be able to tell the autopilot to ignore the plotter or not. I believe some autopilots actually have a separate "nav" mode. I'm not sure I personally like this but I do want to support as many features as possible and have not come up with a solution yet. For me, I can do this from opencpn which I need anyway to make the route.
It seems that steering.autopilot.target.headingTrue should be used if steering.autopilot.mode is gps. But then what about navigation.courseGreatCircle.nextPoint.bearingTrue? Should opencpn set both if the route is active so that the autopilot doesn't need to read "navigation" keys at all?
It seems like all the keys for rhumbline and great circle are duplicated... again I would prefer to just have a key specifying which calculation is used since this would simplify client logic as well, but it seems everyone else wants to have as many keys as possible in signalk.
The spec seems to be trying to say that following routes should be from point to point but alternative logic already exists. So I suggest something like:
navigation/courseGreatCircle/xte/bearingTrackTrue
navigation/courseGreatCircle/routePositionBearing/bearingTrackTrue
navigation/courseRhumbLine/xte/bearingTrackTrue
navigation/courseRhumbLine/routePositionBearing/bearingTrackTrue
This is 4 keys for a single key, so there will end up with around 40 keys
I would prefer:
navigation/bearingTrackTrue
navigation/mode (xte or routePositionBearing)
navigation/coordinates (rhumbLine or greatCircle)
This would end up using about 12 keys with less lines of code in every implementation. The problem gets worse because there are a few more than xte and route position bearing
OpenCPN outputs APB not using great circle but mercator bearings. The autopilot route plugin lets you choose mercator or great circle calculations. The math is really completely different (spherical trigonometry), but on segments that are not very long the result is nearly the same.
So far to my knowledge nothing from opencpn outputs signalk, it only reads signalk at this time, so this needs to be added in the future. How AP nmea sentences are currently getting converted is unclear since nmea doesn't specify mercator or great circle.
1) following a gps course. pypilot does this normally in gps mode
2) following a route. pypilot sets the gps course from APB nmea sentences if it receives them staying in gps mode.
Now some users want to ignore the APB messages at times, and follow a true non-changing gps course and be able to switch this on and off from the autopilot. So they want to be able to tell the autopilot to ignore the plotter or not. I believe some autopilots actually have a separate "nav" mode. I'm not sure I personally like this but I do want to support as many features as possible and have not come up with a solution yet. For me, I can do this from opencpn which I need anyway to make the route.
It seems that steering.autopilot.target.headingTrue should be used if steering.autopilot.mode is gps. But then what about navigation.courseGreatCircle.nextPoint.bearingTrue? Should opencpn set both if the route is active so that the autopilot doesn't need to read "navigation" keys at all?
It seems like all the keys for rhumbline and great circle are duplicated... again I would prefer to just have a key specifying which calculation is used since this would simplify client logic as well, but it seems everyone else wants to have as many keys as possible in signalk.
The spec seems to be trying to say that following routes should be from point to point but alternative logic already exists. So I suggest something like:
navigation/courseGreatCircle/xte/bearingTrackTrue
navigation/courseGreatCircle/routePositionBearing/bearingTrackTrue
navigation/courseRhumbLine/xte/bearingTrackTrue
navigation/courseRhumbLine/routePositionBearing/bearingTrackTrue
This is 4 keys for a single key, so there will end up with around 40 keys
I would prefer:
navigation/bearingTrackTrue
navigation/mode (xte or routePositionBearing)
navigation/coordinates (rhumbLine or greatCircle)
This would end up using about 12 keys with less lines of code in every implementation. The problem gets worse because there are a few more than xte and route position bearing
OpenCPN outputs APB not using great circle but mercator bearings. The autopilot route plugin lets you choose mercator or great circle calculations. The math is really completely different (spherical trigonometry), but on segments that are not very long the result is nearly the same.
So far to my knowledge nothing from opencpn outputs signalk, it only reads signalk at this time, so this needs to be added in the future. How AP nmea sentences are currently getting converted is unclear since nmea doesn't specify mercator or great circle.