Raffaele Montella - I'm writing a plugin to man...
I'm writing a plugin to manage MOBs. Now it registers to vessels.self.notifications.mob, as receive the notification with state: "emergency", it reads data.position and saves it in vessels.self.navigation.mob.position alongside the time of the event in vessels.self.navigation.mob.time. Then it registers to vessels.self.navigation.position, each update it computes: vessels.self.navigation.mob.distance, vessels.self.navigation.mob.headingTrue, vessels.self.navigation.mob.elapsed (in seconds). Optionally the MOB position can be set as next waypoiny automatically and then restored the previously set navigation waypoint once the MOB alarm has canceled. The idea is using (if available) grib files with wind at 10m and surface current to apply the leeway correction of the mob position. My concern is I put the mob data in vessels.self.navigation.mob because apparently I didn't find a better place reading the documentation. Aim I wrong? What do you suggest? I'd like to make freeboard-sk able to draw on the map the SAR pattern computed considering the last know position or the position updated by the leeway.
30 Replies
If we think of mob as a special kind of waypoint then your plugin could be a resourceprovider for waypoints. Then the course api could provide the ”navigate to mob” features and the derived properties like distance and heading
Likewise for the search pattern as route
That leaves the mob specific properties like elapsed time. But maybe that would be better expressed by persisting the timestamp of the mob notification, independent of the delta’s timestamp
If we think of mob as a special kind of waypointDoes we think so?
A couple of other points for consideraton.
1. The pob (person overboard) notification should have an identifier (id) as we can't assume there will only be one from the same source. Addiitionally the id could then be used as a key for subsequent operations and / or linking to resource entries.
2. Capture the position the alarm was raised in the alarm message.
FSK currently does this by extending the notification to include a
data object which allows the POB position to be dispayed on the map.
The data section could also be used to capture additional properties such as the timestamp.Thank you so much! @Teppo Kurki I updated the plugin to work in the suggested fashion (https://github.com/OpenFairWind/mob-signalk-plugin) . But this arose another question: if I set a destination using the course APIs specifying the href, what if I move the position of the waypoint? Is the bearing adjusted automatically? (I'm thinking about the dead reckoning implementation leveraging grib files). @AdrianP do you think a future version of FSK will add a time property inside the data element?
@Raffaele Montella if you move the waypoint position you are using as an href then you will need to call set destination again with the same href to update the destination position.
The course API doesn't watch for changes in the referenced resource.
I will add a timestamp to the mob alarm notification in FSK.
I am looking to release a new version after the next server release.
The MOB in the GaladrielMap SK edition.
BTW, the
notification/mob path is only available to an authorized user, which is completely wrong.Now, FairWindSK (QT6 Custom Browser for Signal K node server, https://github.com/OpenFairWind/FairWindSK) automatically enables the MOB bottom bar when a notifications.mob alarm is raised. A new waypoint is created, and the next waypoint is finally set to the MOB position. https://github.com/OpenFairWind/mob-signalk-plugin does it. In the future, the plugin will support a simplified map view with a SAR interface and a dead reckoning algorithm that moves the MOB waypoint with wind and surface current.
I don't think that doing MOB through the waypoint is a good idea.
The point of the MOB is rarely set at the moment when a man falls overboard. Almost never. It is placed when and where someone has seen something. Therefore, peoples on board should be able to put a MOB points in different places.
In addition, a man can fall from another boat, and ours is just involved in the rescue. In this case, watchers should be able to put dots in different places.
That is, the MOB dots are a very different entity than waypoints.
my earlier comment about resources and waypoints was more a start to thinkt about how MOB handling & related features are similar to what we have elsewhere in the SK data model, but we should also think about how MOB is different and what special features we would want for it
what is a waypoint: in most abstract it is a named position that we can
- display on the map
- calculate bearing and distance to
- modify: change position (case above: first put it when mob is noticed, then possibly move it, using boat's track as reference)
- set course to: calculate derived properties like which direction to steer to & generate autopilot control instructions
but waypoint does not have a timestamp as a first class property
then if we take @Raffaele Montella 's case above about estimating the mob's trajectory it is like a track: a sequence of timestamped positions, with a special case of having timestamped positions streching into the future
then search pattern: is it just a route? that can be activated in the course api and have the autopilot follow?
one way forward would be to describe a typical sequence of events during a MOB and how it should be in SK: what APIs would be used and how it would be reflected in deltas and in API responses, then move on to how it would be implemented in server, APIs, plugins and apps - @Raffaele Montella would you be interested in drafting something like this? could be a shared doc like google doc or just a markdown document in a Pull Request or a wiki page
MOB as a special case could also warrant a separate V2 API, that might be the best way forward to solve the issue with authentication and the current generic notifications data model in v1
@AdrianP started work with v2 notifications API, but i felt that we need a more thorough rework of the whole notifications area and that effort has stalled. I chatted about this with @Matti Airas already quite a while ago, but have not been able to give it proper attention
GitHub
[WIP] feature: Notifications API by panaaj · Pull Request #1560 · S...
This PR has been REFACTORED from the original scope which was:
"Introduce an API under /signalk/v2/api/notifications to provide support for raising and clearing alarms for the standard ala...
I'll rehash my thoughts later today when I get back home!
Related OpenCPN discussion https://github.com/OpenCPN/OpenCPN/discussions/4253
GitHub
User notification infrastructure · OpenCPN OpenCPN · Discussion #42...
As of #4251 it seems like we would benefit from a new way to present asynchronous user messages. That is, something between the too invasive dialog boxes and just logging a message (which normally ...
One topic that might need addressing is the concept of alarm vs notification. The Signalk spec uses these interchangeably but I personally think they are two different concepts.
An alarm is a condition that requires action and generally will have a lifecycle attached to it.
A Notification is an indication of an event or state that may (or may not) be a call to action.
Alarms will usually raise notifications but notifications are not necessarily alarms.
Also they have different lifecycles.
So I think it's worth having an agreed definition of both first to avoid ambiguity as we move forward with this.
For example this is OpenBridge's approach https://www.openbridge.no/pattern/alert
@AdrianP can you elaborate on the different lifecycles?
It might also be interesting to create these MOB entries automatically (and raise the relevant alerts) if an AIS MOB beacon ("vessel" with MMSI starting with
974) is detected.Sure. There’s also https://digitalyacht.co.uk/product/mobalert/
Digital Yacht UK
MOB Alert - Man Over Board Button - Digital Yacht
MOB Alert generates MOB alarms for NMEA 2000 plotters and MFDs, by creating a synthetic AIS MOB SART beacon alert for the network as well as standard MOB PGNs.
Ah you meant the use case ”mob other than own vessel detected”
MOB is a MOB. If this plugin detects these beacons, it'll work for either case. On our boat the other part of the crew is likely sleeping when a MOB could occur, and so automation is quite crucial
So the beacon could be from own vessel (with related mmsi? How are these assigned, is there relation to the vessel’s primary ais?) or unrelated, like in a race fleet mob
The beacons have their own MMSI (in that 974 range), so for legacy systems they appear as a vessel. Ours also get the vessel MMSI flashed in, but that's so they can make a DSC call to mothership when they activate
I’d think mob from own vessel is different from detecting another ais mob beacon
I think the only way to distinguish would be to enter the specific MMSIs for your own beacons
But then you could maybe do cool things like if the vessel is on autopilot automatically heaving to when somebody goes over board. The fancy NKE systems do that
Alarms can have various statuses whilst being active e.g. acknowledged, silenced.
Notifications are transient in nature and are cleared once viewed.
Example would be an alarm clock.... The alarm is activated at the set time, the sound is the notification and the alarm is still active if the snooze button is pressed (notification cleared) and remains so until it is stopped.
so is "battery voltage too high" an alarm or a notification? if it is transient, goes away after a while?
But then you could maybe do cool things like if the vessel is on autopilot automatically heaving to when somebody goes over board.A good way to run on the rocks.
so is "battery voltage too high" an alarm or a notification?The most important thing is that you arrive to conclusion, and do not require me to rewrite my plugins every six months.
you have a point, but a lot of people sail in areas where running aground is very unlikely when heaving to. it is not like you will stay heaved to. unless you are solo
you sound like we have been breaking backwards compatibility all the time. afaik this is not the case
anyway, I think that notifications is an area where the signalk v1 did not do a great job and to move forward, to the next level, we need to change things that will require changes in existing software. but this is why i would like to
- have discussion on various points now, so that the next version is subtantially better and we don't need to redo right away one more time
- we should strive to keep v1 stuff working
eventually we will need a way to switch off v1 features, as we don't want to have both coexist and send duplicated messages with slightly different content
I finished my writeup on the Signal K alarm modeling. It doesn't fit one message, so I'll post it on #specification as a separate thread.
you sound like we have been breaking backwards compatibility all the time.😄
have discussionPersonally, I don't think the SignalK data model is a good one. And v.2 is worse than v.1. But for some reason you have accepted this data model. And I'm going to use your model for as long as it possible. The important thing is to achieve stability.
We can continue the conversation in #specification but to answer the question...the condition to be rectified (battery over voltage) is an alarm, the way it is brought to your attention is a notification.