This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Web-based autopilot route
#21
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)