Extending MISSION_ITEM_REACHED with more detailed status

[nexton-winjeel]

Throwing this one out to get some input. Currently, the MISSION_ITEM_REACHED message only tells us when we get to a mission item. It would be nice if we could get more detailed status while executing a mission item. For example:

• MAV_CMD_NAV_LOITER_TURNS could report:
  • number of turns completed; and
  • total number or number remaining.
• MAV_CMD_NAV_LOITER_TIME and MAV_CMD_NAV_RETURN_TO_LAUNCH could report:
  • time elapsed; and
  • total time or time remaining.

I think most mission commands would be covered by one of:

1. count_completed and total_count;
2. time_elapsed and total_time; or
3. percentage_complete.

What would be the best way to implement this? Extend the MISSION_ITEM_REACHED message with new fields? Extend a different message? Or add a new message (e.g. MISSION_ITEM_REACHED_STATUS)?

[hamishwillee]

Thanks @sypaq-nexton . The short answer is that this is not the first time that this has come up, bit I don't have an answer that satisfies me. I'll add to the dev call next week for discussion.

A few thoughts:

• The place I would think first to add additional information is MISSION_CURRENT as it has both total number and sequence and is streamed - so you do have some kind of progress.
• Current count of loiter and percentage time of loiter should be easy to calculate.
• I don't think you'd append these to an existing message. The problem is that there are so many things you might append to mission_current to provide status - each one adding to the size.
• If we did this I think I'd want to either have dedicated status messages for various events, with an enum to indicate the event and a field(s) to indicate the value for the event. So mission_update with enum loiter_turn 3/6. mission_update with loiter_time enum - value in seconds or whatever.
• Lots of other possible events interfaces - a formatted STATUSTEXT. An EVENT.

It's certainly worthy of more thought - definitely nice to be able to see on a GCS that you're on the last round of a loiter.

[nexton-winjeel]

Hi @hamishwillee, thanks for the response.

Some more comments:

• The reason I didn't suggest changing MISSION_CURRENT is because it's streamed, and I don't think it makes sense to add fields for information that is only applicable to some mission items.

• I'm looking at this from the context of driving the UI on a GCS, so STATUSTEXT and EVENT are non-starters (they are too ad-hoc).

• I'm not sure what you mean by "have dedicated status messages for various events, with an enum to indicate the event"? My initial thoughts were that it would be either a single message with an enum for how to interpret the fields, e.g.:

  <enum name="MISSION_ITEM_STATUS_TYPE">
    <description>
      Determines how to interpret the following `completed` and `total` fields.
    </description>
    <entry value="0" name="MISSION_ITEM_STATUS_TYPE_COUNT">
      <description>The `completed` field is the number of iterations completed, and the `total` field is the total number of iterations.</description>
    </entry>
    <entry value="1" name="MISSION_ITEM_STATUS_TYPE_DURATION">
      <description>The `completed` field is the elapsed time in seconds, and the `total` field is the total time in seconds.</description>
    </entry>
    <entry value="2" name="MISSION_ITEM_STATUS_TYPE_PERCENTAGE">
      <description>The `completed` field is a percentage. The `total` field is not used.</description>
    </entry>
  </enum>
  
  <message id="000" name="MISSION_ITEM_STATUS">
    <description>Reports the status of a long-running mission item.</description>
    <field type="uint16_t" name="seq">The sequence number of the current mission item.</field>
    <field type="uint8_t" name="status_type" enum="MISSION_ITEM_STATUS_TYPE">The type of status being reported. Determines how to interpret the following `completed` and `total` fields.</field>
    <field type="uint32_t" name="completed">The current completion status of this mission item.</field>
    <field type="uint32_t" name="total">The completion status at which this mission item will be finished.</field>
  </message>

  or a set of dedicated messages, e.g.:

  <message id="000" name="MISSION_ITEM_STATUS_COUNT">
    <description>Reports the status of a long-running mission item as a count of iterations.</description>
    <field type="uint16_t" name="seq">The sequence number of the current mission item.</field>
    <field type="uint32_t" name="count_completed">Number of iterations this mission item has completed.</field>
    <field type="uint32_t" name="total_count">Total number of iterations this mission item will complete.</field>
  </message>
  <message id="000" name="MISSION_ITEM_STATUS_DURATION">
    <description>Reports the status of a long-running mission item as a duration.</description>
    <field type="uint16_t" name="seq">The sequence number of the current mission item.</field>
    <field type="uint32_t" name="elapsed_time">Time, in seconds, this mission item has been active.</field>
    <field type="uint32_t" name="total_time">Total time, in seconds, this mission item will be active.</field>
  </message>
  <message id="000" name="MISSION_ITEM_STATUS_PERCENTAGE">
    <description>Reports the status of a long-running mission item as a percentage.</description>
    <field type="uint16_t" name="seq">The sequence number of the current mission item.</field>
    <field type="uint8_t" name="percentage_completed">The completion status of this missions item, as a percentage.</field>
  </message>

I don't have time to dive into this at the moment, but I hope to get to it sometime soon...

[hamishwillee]

@sypaq-nexton Thanks very much - just a few comments:

There is some precedent for this discussion. I am thinking perhaps this can be reused: https://mavlink.io/en/messages/common.html#ORBIT_EXECUTION_STATUS

The reason I didn't suggest changing MISSION_CURRENT is because it's streamed, and I don't think it makes sense to add fields for information that is only applicable to some mission items.

If they are zero by default and we are sure-ish that we won't extend them, then the cost of extension fields depends on what is no longer zero-truncated. That is probably worth it, though we'd need broad agreement from consumers.

I'm looking at this from the context of driving the UI on a GCS, so STATUSTEXT and EVENT are non-starters (they are too ad-hoc).

If you mean "ad hoc" in terms of where they are rolled out and standardizing the event/text, I agree.

I'm not sure what you mean by "have dedicated status messages for various events, with an enum to indicate the event"? My initial thoughts were that it would be either a single message with an enum for how to interpret the fields, e.g.:

This the same as your idea (ish) but encoding the states in two fields. So MISSION_ITEM_STATUS_TYPE indicates the type of operation and how the second field is interpreted - percentage complete, remaining time, or count remaining. YOu could also have two fields as you did.

<field type="uint8_t" name="operation" enum="MISSION_ITEM_STATUS_TYPE" invalid="0">Mission state machine state. MISSION_STATE_UNKNOWN if state reporting not supported.</field>
<field type="uint32_t" name="to_complete" invalid="0">Time, percentage, iterations etc based on operation.</field>  

These could be part of mission_current, or in their own message, or we could do it the way you have proposed. There are advantages/disadvantages to each.

Broadly speaking it is "politically" easier to get stuff appended to old messages than get new messages, and if you're doing that the enum approach is efficient because you can extend it easily with a new enum. Each new message costs a bit of flash. On the other hand, I really like the simplicity of having a separate message for each thing we want to do.

[hamishwillee]

Had a chat about this in dev call. This is proposal from Julian #2029