GitLab

How do we represent Ben's matrix of pre-defined files to set the profiling behaviour?

What we've come up with is this:

• A new instruction_set message which contains the encoded files themselves and the classification by speed/data transmission
• The planning_configuration message will contain a list of the instruction sets made available by the PI
• ORI can then send an instruction_set message using one of the options defined in the planning configuration as the payload
• This is separate from the mission_plan message which is used to define the list of waypoints for the goto file

An instruction set is a collection of static or templated configuration files For MAS-DT these will be fully static slocum files (sample99.ma, tbdlist.dat and y095.ma)

• Define instruction set
  • Properties
    • files is an array of file schemas
      • Each file has a name and b64 encoded content
    • categories a key:value pair object which classifies it (for MAS-DT by speed and data volume)
• Define instructions schema
  • instructions is an array of instruction sets
• Add instructions schema to planning_configuration
• Add test fixtures
  • instruction_set
  • planning_configuration

changed milestone to %CB-2024W35

added Partner::NOC Project::MAS-DT Status::Sprint Priority Weight::3 labels

changed the description

Inside planning configuration

{
  "instructions": [
    {
      "categories": {
        "speed": "fast",
        "data": "none"
      }, 
      "actions": [
        // is this the schema or the actual action 
        // with an empty or default populated waypoint list
        {
          "action_type": "waypoint_list",
          "parameters": {
            "waypoints": {
              "type": "array",
              "items": {
                "$ref": "https://geojson.org/schema/Point.json"
              }
            }
          }
        }
      ],
      "files": [
        {
          "name": "goto_l10.ma",
          "content": "b64 stuff"
        },
        {
          "name": "yo95.ma",
          "content": "b64 stuff"
        },
        {
          "name": "sample99.ma",
          "content": "b64 stuff"
        },
        {
          "name": "tbdlist.dat",
          "content": "b64 stuff"
        }
      ]
    }
    // ... more instruction sets
  ]
}

I'm not very comfortable with the variable actions being inside the otherwise fixed instruction set.

My original plan for the planning_configuration capabilities was to define a schema that a client could validate a mission against. So like ballast_pump_volume: enum[300, 380, 460].

Now with the instruction set concept that's slightly different. We're not saying "this parameter must have one of these valid values" we're saying "you must provide one of these collections of files exactly as-is (but you can set these waypoint parameters)"

It's not easy with this design to define a planning_configuration that explains to ORI what they can do.

I think we should either:

1. not send them the files at all.
2. separate the static instruction set from the variable waypoint list parameter

So in option 2 ORI send 2 messages:

1. an instruction_set message where the payload is one of the static options defined in planning_configuration.instuctions
2. a mission_plan message where the payload is an actions list containing a single action of action_type=waypoint_list

The 1st message results in sample99.ma, yo95.ma and tbdlist.dat in to-glider

The 2nd message results in goto_l10.ma in to-glider

They are not sent as a single message and don't have to be sent together. ORI could send "go faster" and then send waypoints for 5 dives and then send "go slower" before sending the next 5 dives.

changed the description

created merge request !42 (merged) to address this issue

mentioned in merge request !42 (merged)

changed the description

added Status::In Review label and removed Status::Sprint Priority label

added Status::In Progress label and removed Status::In Review label

marked the task Define instruction set as completed

marked the task Properties as completed

marked the task files is an array of file schemas as completed

marked the task Each file has a name and b64 encoded content as completed

marked the task categories a key:value pair object which classifies it (for MAS-DT by speed and data volume) as completed

changed the description

added Status::In Review label and removed Status::In Progress label

assigned to @danjon

Looks good overall. A few comments:

1. We are happy to send separate instruction_set and mission_plan messages. As I mentioned before, if we do modify these parameters during a mission, then we will do so for each surfacing event / dive instruction. We can perhaps avoid sending an instruction_set message if the action decided by the planner uses the same parameters as the previous one.
2. Something that is missing currently is a specification of the precise parameters to be used e.g. depth and number_yos for each instruction set. The planner needs to know the range of possible values at the start of the mission. Maybe this can go at the same level as the categories and files fields in this message.
3. For the actions field: presumably, we can use this for specifying the types of actions that we can send (e.g., that they need to be a list of waypoints) and not some initial backup actions themselves. Since this is inside the initial planning_configuration message, our planner does not yet know anything about this mission.

1. Yes that's what I was thinking. You could use the same instruction set for 5 dives and only send a new one as and when you wanted a different configuration.

2. Agreed. We're talking about this. You could decode and parse the file content but I'm hoping we can encode the fixed parameter values contained in the instruction set as part of the content. I've made a version with this included. The question is whether we can find the time to create the UI to handle this. If we can do it, it might look like this

3. In the MR I've not created the actions field in this message. As per this discussion I think it's cleaner that the instruction set is a static payload you just send and you still use the mission_plan to send waypoints.

1. Right, yes, so we are essentially in agreement. What I was trying to imply is that frequency of configuration changing >> frequency of configuration staying the same, whereas what you're saying is the inverse. But functionally the mechanism should work in exactly the same way.
2. That example message looks great. I'd have an (opinionated) preference for the fixed parameter values to be supplied so that we don't need to understand the glider message formats ourselves. IMO this would kind of defeat the purpose of having the extra abstraction layer to begin with.
3. Sounds good, agreed.

mentioned in merge request !41 (merged)

marked the task Define instructions schema as completed

marked the task instructions is an array of instruction sets as completed

marked the task Add instructions schema to planning_configuration as completed

marked the task Add test fixtures as completed

marked the task planning_configuration as completed

mentioned in issue #64 (closed)

mentioned in issue #48 (closed)

mentioned in issue #53 (closed)

mentioned in issue #49 (closed)

changed milestone to %CB-2024W37

mentioned in issue #68

closed