- Route to header schema which shows the list of client_IDs relaying the message from the true source of message to final destination of it.
- New message type "autonomy_engine_control". Long term plan is to integrate this as an object into the planning configuration schema, where if an operation has autonomy, the metadata, configurations, any instructions / default settings shall be within this message structure section.
- Additional_data field to platform_status to input any other data from a platform to be published
- Goal object in mission_plan message that consists of a GeoJSON feature (representing the part of primitive that is currently the goal of the given mission plan).
- A `partial` flag that indicates if a mission plan is a partial plan or the entire mission plan
- Added "informational" to enum for primitive's instruction enum (planning configuration)
- Options to primitives (under planning_configuration message) which is only a property when a primitive has an instruction of "follow" or "navigate_to"
- Validate message_ID matches uuid format
- Add definition of instruction_set message
- Added optional primitives to squad schema
### Changed
- Added "instruction" as required under the primitive schema (planning configuration)
- Refactor instructeion_set into platform_instruction_set
@@ -8,6 +8,7 @@ Each message below will be wrapped in a `payload` field and will have a `header`
*`mission_plan`: these would be two message types, i. encoded (platform-specific serialized message) and ii. parsed, human-readable message.
*`platform_status`: these would be two message types, i. encoded (platform-specific serialized message) and ii. parsed, human-readable message.
*`observation`: this would be desired scientific data sent by the platform
*`survey`: this would be demanded track, platform actual path, and survey line
*`acknowledgement`: level of acknowledgment where an acknowledgement is sent when a message is i. received, ii. sent to the next destination (e.g. platform in the water).
*`planning_configuration`: sent from the GUI to initialise the AI model (autonomy engine).
...
...
@@ -68,15 +69,31 @@ eg
*`soar.*.*.*.to_platform.*` - all messages outbound to platforms (hermes)
*`soar.*.slocum.#` - all messages relating to a slocum platform type
## Run Docs
Run the command below and go to `http://127.0.0.1:5000`
## Run Docs & Save Schema When Updating Message Formats
1.Run the command below and go to `http://127.0.0.1:5000`
```
python3 generate_schema_config.py
python3 generate_schema_config.py -f
```
2. Commit any changes to the `backbone-message-format/project/<project_name>/swagger.json`
## Run Tests
Run the command below
We have found slightly different behaviour between the OpenAPI validators in python and javascript.
By running tests in both languages we should protect against messages that pass validation in
one client but fail in another.
Run both tests below:
1. Test 1 - Use python validators
```
python3 -m unittest discover
```
2. Test 2 - Use javascript validators
```
python3 -m unittest tests/test_schemas.py
# Compile schema and run javascript validation tests in docker
