Waypoint Arrival Confirmation

[seandepagnier]

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

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

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

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?

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.

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