GitLab

changed milestone to %CB-2024W47

I don't fully understand this one. I hadn't seen the waypoints message type before, and it is not used by ORI currently. I had a look at the example at https://git.noc.ac.uk/communications-backbone-system/backbone-message-format/-/blob/67-mas-dt/examples/mas-dt/waypoints_props.json. Is this message type intended for other purposes e.g. displaying on the UI? Or should ORI also be making use of it?

Regarding adding target to the enum, do you mean we'd have something like "message_type": "target (and consequently publish this message to a different topic)? Or something else?

In any case, I am happy with "publish a message specifying the target coordinates once the target changes", essentially irrespective of the schema. But I think it's worth clarifying what that will look like.

Adding to Dan's point below, this would be the sample message that would need to be published. You would only send 1 position which is the target goal.

We (C2) need to change the position to allow Point (GeoJSON) to streamline positions across platform_status and mission_plan.

{
    "message_type": "target",
    "platform_ID": "unit_399",
    "status_source": "autonomy",
    "platform_timestamp": "2024-11-19T11:49:00Z",
    "positions": [
        {
            "type": "Point",
            "coordinates": [
                -3.0071,
                50.3707
            ]
        }
    ]
}

We can chat about adding it in the mission_plan, but as discussed yesterday, I'm just referring to the new message type called "target" that will need to be published by ORI

Issue description updated

I don't think there's an easy way to meet Ben's requirement for the target in the goto as a comment using this method.

To meet Ben's requirement I think it would be better to use the mission_plan and specify the target as a 4th action with active:false. That way all the SFMC adapter needs to do is put the active action waypoints into the goto file and the inactive waypoints into the goto as comments. No need for a 2nd message. No need for SFMC to maintain state to reconcile content from 2 separate messages.

Thanks Trishna for the explanation, I get it now. I think single position over an array of positions arguably makes more sense for this, as we can't navigate to two places at once =).

Re a new target message versus adding an extra "inactive" waypoint: from my view this is equivalent, so it is up to you, I have no preference.

I think the original intention of the waypoints message was that during dry-run the SFMC adapter - while it wasn't actually sending anything to the real platform - would instead send a message back to the backbone so that we could see that it had received and processed the new mission_plan. We ended up using the simulated dt_399 glider on SFMC instead so we never implemented this process.

This use-case is a bit different and I'm not sure whether it solves Ben's concern from yesterday.

I think if we're going to use this then the SFMC adapter would have to save it in order to add Ben's requested comment to the goto file when it subsequently receives a mission_plan. We might need to add something to the mission_plan message instead to handle this so you just send one message and the SFMC adapter just processes that one message. I haven't got a good idea how to handle that yet.

I guess we could have an active:[true|false] field against each action in the mission_plan and an active:false action was written to the goto as a comment?

After some more thought, I would like to continue down the mission_plan route to approach this. However I don't particularly like your suggestion of using active:false in fear of making this too specific and the SFMC and Positions service having to understand that active:false === a comment in the goto | ingest this as a goal position.

Instead, in the mission_plan schema could we add a goal enum to the action definition https://git.noc.ac.uk/communications-backbone-system/backbone-message-format/-/blob/67-mas-dt/formats/mission_plan.py#L11. In the future we may want to treat these end goals differently (like adding it in as a final waypoints as you suggested rather than what Ben is proposing of falling out of the mission 'AI' mission into the standard MOGli). Additionally, I think we may want to avoid using target in case there is any terminology clash with target_waypoint_ fields.

Perhaps adding "action": "goal" might seem more reasonable (also, yes, rather than the active = true/false - that feels quite project/platform specific)

I think active:false === "a comment in the goto" is quite intuitive. I agree the C2 active:false === "ingest as a goal position" is nasty.

I don't really like action:goal because the plan is intended to be a sequence of actions so having an action which we hard-code everywhere as "don't perform this action" seems wrong to me. It's not very explainable in terms of presenting a clear interface for autonomy to implement.

If you send a mission where the final action is of type "goal" with a location then the platform will not go to this location seems a hard concept to justify.

We could add a goal position outside of the action list but that has the same "if you send this the platform will ignore it" problem in terms of explaining/documenting how it works.

What about leg or segment? Where the mission_plan contains the previous and next node of the line? Although that only applies in the case where the navigation primitive is a LineString. It doesn't work in the general case. I guess it would work if it were a derived lawnmower over a polygon. The case it doesn't work for is just specifying a target point/region like the current spec. Although I guess the previous/from could be optional?

I like the idea of the goal being on the outer bit. What about? *It doesn't limit us to just a target point OR zone. I guess the only extra work technically would be in Positions Service

{
    "header":{
       "message_ID":"b427003c-0000-11aa-a1eb-b1cdf2342fdd",
       "timestamp":"2024-11-16T00:00:00Z",
       "version":2,
       "source":"autonomy_engine",
       "destination":"soar.noc.autosub.unit_399.to_platform.mission_plan",
       "delivery_type":"publish",
       "encoded":false
    },
    "payload":{
      "message_type":"mission_plan",
      "platform_ID":"unit_399",
      "autonomy_engine_plan_ID":"a427003c-0000-11aa-a1eb-b1cdf2342fcc",
      "partial": True|False <--------- OPTIONAL
      "goal":{ <----- OPTIONAL
          "timestamp":"2024-11-16T00:00:00Z",  // time when autonomy engine state changes to this goal
          "feature":{  // ---> "feature" could be a box, point. (e.g. point for linestring primitive, polygon for a primitive even)
             {
                "type":"Feature",
                "properties":{
                   "name":"MAS-DT east",   // this name could match the primitive
                   "type":""
                },
                "geometry":{
                   "type":"Point",   // Any polygon / geojson schema
                   "coordinates":[
                      -4.1777839187560915,
                      50.34173405662855
                   ]
                }
             }
          },
      "plan":[
         {
            "action":"move",
            "start":{
               "type":"Point",
               "coordinates":[
                  -3.0071,
                  50.3707
               ]
            },
            "target":{
               "type":"Point",
               "coordinates":[
                  -3.2371,
                  52.3707,
                  0.0
               ]
            }
         }
      ]
   }
    }
}

^ updated indentation

I think that ^ has the plan nested inside the goal. Was that deliberate?

I still think it's confusing to send a mission_plan containing a goal that specifies a location if the way that plan is processed by the platform ignores that goal altogether. If you came to this fresh having never seen it before you'd expect the behaviour to be that the platform would go to the mission_plan.goal wouldn't you?

Agreed, I think plan and goal need to be at the same level within the object. I think with fresh eyes seeing goal and plan I would have thought that the plan would be used to achieve the goal but I probably would also assume that the goal is being used by the platform somehow. But I think that's up to the adapter to decide how those objects are used.

So the weird thing I guess is that we're artificially mandating that the plan doesn't achieve the goal.

What if the mission_plan had something like a partial:[true|false] property which identified that the plan was a step towards achieving the goal rather than the entire plan for achieving the goal.

That might get confusing, unless we went into % of achieving goal. just being mindful we're not

Confusing how? It's either a partial plan that doesn't achieve the goal or a complete plan that does achieve the goal.

I don't think it's a rabbit-hole. It's not about just delivering MAS-DT. It's about defining an interface through the message schemas that's more intuitive for future partners to implement.

Actually, I think the "partial" can be a little specific to how mas-dt achieves its goal + scope creep. It might be confusing to someone looking at the message fresh. Since we've got better options now, with this smaller details to refine, let's discuss in the AM and list out what design we have finalised here

RESOLVED --> Latest design json example in Issue Description

changed the description

added Status::In Progress label

assigned to @trishna

changed title from Change "waypoint" type message to "position" and add "target" to enum to Refactor mission plan message to include goal and type of mission (partial or not)

changed the description

[DESIGN IN REVIEW WITH @victord] we've updated the Issue Description with the design we're going with (unless, you'd like us to change anything). I'd say forget about what we've spoken about Re: "target" new message type

Summary of Design

In the mission plan, (currently) we have a set of waypoints generated from the AI model.
In the mission plan, (todo) we would like to add another object called "goal" which will contain a single goal/target.
The "goal" obj will have a "feature" to denote target point at the time (eastern or western point) of the transect
Also, instead of using the term "transect", we'll use the term "follow" under "instruction" which would be a better fit (for the planning_configuration message)

Looks good to me, thanks!

mentioned in merge request !56 (merged)

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

closed

GitLab

Refactor mission plan message to include goal and type of mission (partial or not)

Reference design:

Designs

Latest agreed design (mission plan message type)

Deprecated design idea (waypoint message type)

Oh no!

Incoming!