GitLab

Closes #47 (closed)

changed milestone to %CB-2024W35

added Project::MAS-DT Status::In Progress Weight::2 labels

added 16 commits

• 3daab322 - refactor: load geojson defs from published schemas
• 673cab5c - chore: add flake8 config
• bbded930 - lint: fix black and flake8 errors
• 72554c78 - refactor: change geo data to geojson refs
• 3bdc5ca4 - feat: import geojson multi definitions
• 591aa906 - lint: run black
• 735243de - chore: recompile schema
• dc538669 - refactor: revert change to emergency schema
• c307438b - refactor: make imported schemas available to tests
• 8e9a8b4c - fix: correct argparse default behaviour
• 84b9750e - feat: downgrade geojson to 3.0.x compatible schema
• f1b4198c - refactor: replace deprecated validator interface
• dcbfd70c - docs: update changelog
• 7803c4e8 - refactor: commit cache of remote refs
• 4bdd1516 - chore: lint changes with black
• 0fdc727d - refactor: use geojson or separate properties

Compare with previous version

changed target branch from 67-mas-dt to 70-refactor-geojson-loading-for-serving-from-nucleus

added 1 commit

• 37f3d637 - feat: allow position coordinates in either format

Compare with previous version

requested review from @victord

marked this merge request as ready

We should discuss some of these fields that probably aren't useful/needed outside of soar

I know this is just an example, but would be nice to have a mas-dt.x.x.x instead of soar.x.x.x in "destination"

Agreed. Will do.

changed this line in version 5 of the diff

Approved with small recommended update to example

approved this merge request

A few comments from my side:

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

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

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

1. Understood, sounds good.
2. 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.

added 1 commit

• 59da19ce - chore: update example message to current project

Compare with previous version

added 24 commits

• 59da19ce...c9e06ada - 21 commits from branch 70-refactor-geojson-loading-for-serving-from-nucleus
• ee5e2d0a - refactor: use geojson or separate properties
• 4ed8bbda - feat: allow position coordinates in either format
• df39ab35 - chore: update example message to current project

Compare with previous version

mentioned in commit 64d1d6cb

merged