On the new waypoint field: this is intended to report the next waypoint that will be followed, right? In the mission_plan message we aim to specify a list of waypoints, with the first one being the planner-derived "clever" waypoint, and the rest being backups. Do we maybe want to report back this entire list of waypoints instead? I don't think it's necessarily needed, but perhaps we want to be consistent.
Given that we will allow changing parameters with the instruction_set messages, perhaps we should also report back the values of these parameters in the status messages after the dive (in case changing them might have failed for some reason?). Maybe this would need to be handled in a different issue.
The waypoint field in the platform status should contain the target point that the slocum is currently trying to navigate towards. So if you were to send a new plan but that new plan failed to transmit that field would tell you that the slocum performed the last dive based on the previous instructions.
We're having a think about how to manage communicating the parameters in the instruction set. So the sbd/tbd data will tell you which parameter values the slocum was operating under. What we need to figure out is how you know what parameter values the instruction set contains. You could decode and parse the ma files but I'm wondering whether we can populate those as part of the instruction set definitions so you have a list of the fixed parameters set by those files.
You would still have to check whether the dive parameters matched the instruction set you sent (in case the file transfer failed)
For this one, we would prefer to know the parameter values from the instruction sets and not have to extract them ourselves (essentially the same point as #62 (comment 259744)). Agreed that we'd need to check the match with the dive parameters after the fact.
