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
#1
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.

The problem that I had to solve was that the pypilot design did not include waypoint arrival confirmation logic. I think it should, and allow me to elaborate why. For me it is unacceptible that my autopilot changes heading without my consent. I might be having a nap, be making coffee, be on the radio with a near range oil tanker, or be waving at a sailboat that is sailing abeam of me. I may be reaching and a heading change might cause an accidental gybe, or a heading change might run me into the sailboat or the oil tanker.

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 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.

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. 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.
  • 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]


Attached Files Image(s)
   
Reply
#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
    #3
    > Since it has become apparent that the format won't be able to be compatible with signalk-node, It is now just pypilotServer.

    The jury here is still out on the top-heavy signalk specs anyway, so it may be that one day your version becomes the standard, like ldap succeeded dap, and json succeeded xml.

    > If you are parsing additional nmea sentences for waypoints it should not be an issue.

    I mean the pypilot sending a signal to the UI whenever a waypoint id changes. I don't see what additional nmea sentences you mean that could solve this?

    > 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.

    That latter is actually what I mean, so on that we agree. But why is dropping into compass mode a no-go? It serves the purpose of maintaining heading - what's the drawback then? When confirmed I set the mode back to gps.

    > 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.

    Sorry don't agree. This solution goes way too far for me. My main goal for this feature request is that the pypilot core engine supports some waypoint confirmation mechanism accessible through the pypilotServer infrastructure so that custom UI implementations can make use of it.

    > 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?

    Good question. I only have OpenCPN, and am planning on no other plotter. But given that OpenCPN only seems to provide APB and RMB messages, without RMB arrival status, and that I still prefer this simple, standardised interface above a fully integrated, plugin based solution, yeah, the feature I request would indeed go beyond opencpn plotters. But is is not my primary goal.

    Currently, I had to change the pypilot code to get what I wanted. This now prevents me from easily upgrading; last time it took me a day to upgrade to the latest version of pypilot, refitting my modifications into the changed code. It would be great if the mechanism that I described could be added to the core code. For the time being I'm pretty happy not to upgrade, but when the fuzzy logic machine learning pilot feature becomes available then I'm first in line to upgrade ;-)

    BTW, how do you quote in your replies? I have not found out yet how to do that in the HTML interface to this forum.
    Reply
    #4
    (2020-02-27, 07:40 PM)ironman Wrote: > Since it has become apparent that the format won't be able to be compatible with signalk-node, It is now just pypilotServer.

    The jury here is still out on the top-heavy signalk specs anyway, so it may be that one day your version becomes the standard, like ldap succeeded dap, and json succeeded xml.
    The current standard is somewhat confusing supporting websockets, tcp as well as using http GET and POST requests. The subscriptions are not forwarded so linking servers is inefficient. The data flow is only from server to client (except for PUT which is impractical for streaming data) which makes it a requirement to add a connection from signalk-node server to pypilot which is easy to do through the web interface of signalk, but then pypilot also needs to be a client of signalk-node to get route commands, cross-track error etc... and subscriptions are only supported by websockets so they must be used rather than tcp, and how to discover the signalk server address is unclear, unlike nmea0183 which supports bidirectional data.

    I'm not sure the pypilot format will be suitable, especially with redundant data sources, but the current signalk format is very cumbersome. Maybe the next version will address some of these issues.
    Quote:I mean the pypilot sending a signal to the UI whenever a waypoint id changes. I don't see what additional nmea sentences you mean that could solve this?
    I was talking about route and waypoint sentences
    Quote:> 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.

    That latter is actually what I mean, so on that we agree. But why is dropping into compass mode a no-go? It serves the purpose of maintaining heading - what's the drawback then? When confirmed I set the mode back to gps.
    The drawback is if there are changing currents, the compass course will vary from the gps course.
    Quote:Sorry don't agree. This solution goes way too far for me. My main goal for this feature request is that the pypilot core engine supports some waypoint confirmation mechanism accessible through the pypilotServer infrastructure so that custom UI implementations can make use of it.

    Good question. I only have OpenCPN, and am planning on no other plotter. But given that OpenCPN only seems to provide APB and RMB messages, without RMB arrival status, and that I still prefer this simple, standardised interface above a fully integrated, plugin based solution, yeah, the feature I request would indeed go beyond opencpn plotters. But is is not my primary goal.
    So you want to be able to confirm waypoint arrival from any UI interface of pypilot then? For this, you are going to need a few keys like:

    apb.confirm_waypoint=['off', 'confirm', 'on']

    Now if this value is set to off it will have the current behavior. If it is set to on, then if the waypoint changes it is set to 'confirm' and clients can notify the user and update the state to either on or off. If it is set to 'on' by a client then the waypoint confirmed is updated.

    Would this be sufficient?

    Quote:Currently, I had to change the pypilot code to get what I wanted. This now prevents me from easily upgrading; last time it took me a day to upgrade to the latest version of pypilot, refitting my modifications into the changed code. It would be great if the mechanism that I described could be added to the core code. For the time being I'm pretty happy not to upgrade, but when the fuzzy logic machine learning pilot feature becomes available then I'm first in line to upgrade ;-)
    So far it's fitting models but not actual sail testing yet.
    Quote:BTW, how do you quote in your replies? I have not found out yet how to do that in the HTML interface to this forum.

    Click the "view source" button
    Reply
    #5
    The current standard is somewhat confusing supporting websockets, tcp as well as using http GET and POST requests.

    To share a little background: we started with http for data retrieval and WebSockets for streaming. Tcp was added by popular request (I think I remember you saying that tcp is the preferred mechanism, as well as request-response over ws. Ws and http have standard mechanisms for authentication and secure communications and can be used in browsers, as opposed to tcp lacking of all these qualities/features.

    Maybe we can improve the specification or add documentation to clear up the confusion? I am way too deep in this to see the it - can you expand on this?

    The subscriptions are not forwarded so linking servers is inefficient.

    Like with many things open source feature X is added when sufficient interest and somebody willing to do the work meet. The need for forwarded subscriptions surfaced recently - I am willing to help in the implementation but I'll need help in fleshing out the details and use cases. Care to elaborate on this? Preferably in a Github issue.

    The data flow is only from server to client (except for PUT which is impractical for streaming data)

    This is not true, ws connection has been two way for years and in use by projects like https://github.com/SignalK/SensESP and https://github.com/SignalK/SensESP.

    Or am I missing something about 2 way comms? What exactly is not possible?

    subscriptions are only supported by websockets so they must be used rather than tcp

    No longer true, I implemented this in 1.19, as quickly as I could after OpenCPN integration seemed to provide real interest for it (alas, O will actually be using ws...). See https://github.com/SignalK/signalk-serve...ag/v1.19.0

    how to discover the signalk server address is unclear.

    Again could you please give a little more detail? The process is documented at https://signalk.org/specification/1.4.0/...ction.html and people have successfully implemented discovery. If there's something missing in the docs (or the discovery mechanism) let's improve them!
    Reply
    #6
    (2020-02-28, 02:57 AM)seandepagnier Wrote: So you want to be able to confirm waypoint arrival from any UI interface of pypilot then?   For this, you are going to need a few keys like:

    apb.confirm_waypoint=['off', 'confirm', 'on']

    Now if this value is set to off it will have the current behavior.   If it is set to on, then if the waypoint changes it is set to 'confirm' and clients can notify the user and update the state to either on or off.  If it is set to 'on' by a client then the waypoint confirmed is updated.

    Would this be sufficient?

    Almost, if you'd make it ['off', 'confirm-left', 'confirm-right', 'on'] I think I'd be all done. Please don't forget apb.auto_gps either.

    seandepagnier Wrote:
    ironman Wrote:BTW, how do you quote in your replies? I have not found out yet how to do that in the HTML interface to this forum.

    Click the "view source" button

    Got it now thx.

    Sorry did not want to stir any ongoing discussion regarding signalk with an off-topic remark. I don't know enough about it to raise it. Typically I understand visionary things 10 years too late.
    Reply
    #7
    (2020-02-27, 05:06 PM)seandepagnier Wrote: Otherwise you can use regular waypoint mode in the plugin and get waypoint confirmation.

    I almost overlooked this remark. I did not know the autopilot_route plugin had this facility, but I found 'Waypoint Bearing' now as one of the modes, and the option 'Confirm bearing change on waypoint arrival'! I must admit that I have not tested the plugin on board yet, as I had some problems getting it stable in the lab, which I actually still have (v 0.4, Linux only - I don't have the setup or skill for compiling it on Windows). I have the impression it has not been released for general use. Is this being used already?
    Reply
    #8
    While it is cool that it makes the course changes automatically it should at least warn that your approaching the way-point.
    Reply
    #9
    First, thanks for the reply and interest.

    (2020-02-28, 12:17 PM)tkurki Wrote: The current standard is somewhat confusing supporting websockets, tcp as well as using http GET and POST requests.

    To share a little background: we started with http for data retrieval and WebSockets for streaming. Tcp was added by popular request (I think I remember you saying that tcp is the preferred mechanism, as well as request-response over ws. Ws and http have standard mechanisms for authentication and secure communications and can be used in browsers, as opposed to tcp lacking of all these qualities/features.

    Maybe we can improve the specification or add documentation to clear up the confusion? I am way too deep in this to see the it - can you expand on this?
    I think signalk is confusing at first because as mentioned the specification is "heavy" there are a lot of details and it's more complicated than nmea or other formats but also more powerful.

    By converse the pypilot specification can fit on a single page and supports forwarding subscriptions, but doesn't handle multiple sources for the same key since this feature is not utilized by pypilot anyway.

    Quote:The subscriptions are not forwarded so linking servers is inefficient.

    Like with many things open source feature X is added when sufficient interest and somebody willing to do the work meet. The need for forwarded subscriptions surfaced recently - I am willing to help in the implementation but I'll need help in fleshing out the details and use cases. Care to elaborate on this? Preferably in a Github issue.

    It seems this is already needed if the signalk server makes a client connection to another signalk server so that it can subscribe to all the messages its own clients subscribed at whatever the fastest rate for each one is.

    I will open an issue. I agree with you completely. The difficulty for me is implementing in javascript what is needed.
    Quote:The data flow is only from server to client (except for PUT which is impractical for streaming data)

    This is not true, ws connection has been two way for years and in use by projects like https://github.com/SignalK/SensESP and https://github.com/SignalK/SensESP.
    This is very good news. Maybe because I was using tcp sockets but I just got websockets working with python now so as long as "updates" can go both ways it is going to work. The next step is making "subscriptions" also go both ways.
    Quote:how to discover the signalk server address is unclear.

    Again could you please give a little more detail? The process is documented at https://signalk.org/specification/1.4.0/...ction.html and people have successfully implemented discovery. If there's something missing in the docs (or the discovery mechanism) let's improve them!

    Discovery is great for some applications but I am not sure about pypilot.

    It is possible to have two openplotters each with a signalk-node server and a single pypilot. So in this case pypilot would need to discover both plotters to update their signalk. It is not clear which plotter it should receive updates for route following or other autopilot control. You could just run signalk-node on a single openplotter but then if it goes down the other plotter will stop too.

    Also possible is two pypilots (one backup standby) and a single signalk-node server. In this case they could both discover the single signalk node server and maybe it would work as intended after all, but could cause unintended consequences.

    If there are two plotters and two pilots it is not as clear how the connections should be made.. how data will flow and avoid loops but also allow any of these devices to stop working without disabling the rest.

    The alternative is to just have the user manually add a signalk connection to pypilot from the node-server setup once that is fully supported. This would give the most control but is an extra step and if changing network setup annoying.


    Any thoughts on this? Is it possible to have detection by default unless connections are specified and how would this be supported?
    Reply


    Forum Jump:


    Users browsing this thread: 1 Guest(s)