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
Waypoint Arrival Confirmation
#2
(2020-02-27, 01:31 PM)ironman Wrote: Back in the early 90's there was this thing about decoupling application logic from the UI logic, and one solution was to work with what was called a blackboard: a common data store that both UI and application could read from, and write to. The signalk infrastructure of pypilot is an excellent example of such a blackboard. Basically, both lcd.py and ray.py interfaces are able to steer, and react upon, the underlying autopilot logic, through signalk. A loosely coupled interface, we would say today.

Since it has become apparent that the format won't be able to be compatible with signalk-node, It is now just pypilotServer. This is unfortunately due to limitations in signalk-node format, so maybe in a future version it will work out and a simpler translation layer would give the same level of compatibility, but for now a javascript plugin needs to be developed for signalk-node because signalk-node doesn't support subscriptions through routing yet.

For now there are a few python scripts that convert pitch, heel and magnetic heading to signalk-node.
Quote:OpenCPN, providing RMB or APB messages, does not forewarn waypoint arrivals. You could rely on waypoint arrival radius (e.g. RMB Arrival Status), but if you pass the waypoint beyond that radius the plotter will flick to the next track without warning anyway. What you (Sean) have done in the OpenCPN autoroute plugin takes waypoint anticipation to a whole new level, which is really brilliant, but too brilliant for my taste, because it makes my concern even bigger: instead of implicitly warning me with an abrupt heading change, it sort of secretly sneaks into a new heading now. Now you could build some waypoint confirmation mechanism in the
Yes, but it is a more efficient path for the boat to sail. In any case the way it reacts greatly depends on the distance set in the plugin.

Otherwise you can use regular waypoint mode in the plugin and get waypoint confirmation.
Quote: autoroute plugin, but there's more. Firstly, this interface is not loosely coupled, and secondly it relies on OpenCPN not crashing. Normally an autopilot will maintain heading when a plotter conks out. Now it seems reliant on some plotter plugin inside the cabin that I cannot reach from the cockpit.
Actually, if opencpn crashes, pypilot will (at least should!) just maintain the current heading.
Quote:In ray.py I used an ugly file-based mechanism for nmea.py to notify my UI of a) the fact that there is a waypoint change, and b) what direction that waypoint change is. This file-based mechanism will not work on a separate piece of (ECD) hardware, so this notification would need to be make use of the signalk blackboard.
If you are parsing additional nmea sentences for waypoints it should not be an issue.
Quote: Indeed, as you say, a separate mode could achieve this. I can imagine, however, that introducing a new mode could have a vast impact on the whole pypilot application. 

So I would suggest the following:
  • a config boolean e.g. 'enable_waypoint_confirmation', defaulting to false.
  • in nmea.py logic that puts the autopilot in 'compass' mode IF waypoint id changes, current mode is 'gps' and waypoint confirmation is enabled. The last commanded heading should be maintained.
You would not want to drop to compass mode unless gps is actually lost. It is most desirable to hold the current gps course, or the course of the current segment.
Quote:
  • the same logic should also fill a new variable in signalk, e.g. 'waypoint', that is filled with information about the new waypoint. As a minumum I would like to know whether the new waypoint is left or right, so I know where to look.
  • the UI should then monitor that waypoint variable and the ui builder can then eat his heart out with bells or whistles in notifying the skipper about the waypoint.
  • when the skipper confirms the waypoint change, the ui should put the autopilot back in 'gps' mode and possibly clear the waypoint variable.
  • [Image: attachment.php?aid=821]

    I think that if you really want to build waypoint arrival into the autopilot in this way, it is going to need the receive the entire route. Otherwise, losing opencpn you will still not be able to go to the next waypoint.

    The only real advantage of this would be, you also want the confirmation from several different interfaces and for them all to work together than only be able to confirm waypoints from opencpn correct?
    Reply


    Messages In This Thread
    Waypoint Arrival Confirmation - by ironman - 2020-02-27, 01:31 PM
    RE: Waypoint Arrival Confirmation - by seandepagnier - 2020-02-27, 05:06 PM
    RE: Waypoint Arrival Confirmation - by ironman - 2020-02-29, 07:45 PM
    RE: Waypoint Arrival Confirmation - by ironman - 2020-02-27, 07:40 PM
    RE: Waypoint Arrival Confirmation - by tkurki - 2020-02-28, 12:17 PM
    RE: Waypoint Arrival Confirmation - by ironman - 2020-02-28, 11:57 PM
    RE: Waypoint Arrival Confirmation - by johnm - 2020-03-03, 02:24 AM

    Forum Jump:


    Users browsing this thread: 1 Guest(s)