Mission feasability check status

[jperez-droneup]

Currently, the mission feasibility check is made when assigning a mission to the UAV. However, if the check fails we still get a success status on the upload_mission call even though the check might have failed. The results of the check are printed to the status text telemetry, but this is difficult to parse.

There should be a way to query the last mission feasibility check results (possibly just pass/fail, but preferably more detail), and a way to explicitly run the checker. In the case that a mission parameter has changed (such as a geofence), the user may want to re-check the mission to ensure it is still feasible. We may also want to check it to verify before calling start_mission.

@hamishwillee https://discord.com/channels/1022170275984457759/1129508414414925994

[hamishwillee]

Discussed this in the MAVLink call.

Proposal is a message that provides information about a feasibility check. The message is emitted whenever the feasibility checker is run - after an upload or when the user decides they want to start a mission. We might also have a command to explicitly run the feasibility checker.

@jperez-droneup Would you be interested in defining such a message in development.xml - and possibly providing an implementation?

Note, an alternative would be to standardize the format of STATUSTEXT or event messages for this purpose. That is a valid approach too, but given it would have to happen in two places is more problematic.

[julianoes]

@bkueng could this be covered by events already?

[bkueng]

Yes as part of the arming reporting. You can check generically if you can run the mission mode. If it fails you get a list of reasons why you cannot run the mission. One of them is a missing valid mission: https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/HealthAndArmingChecks/checks/modeCheck.cpp#L120

If I recall correctly there was also a push in PX4 to directly run feasibility checks on upload and fail the upload accordingly.

[julianoes]

fail the upload accordingly.

Interesting. but we don't have an error to report that, see: mavlink/mavlink#1710

[hamishwillee]

@bkueng could this be covered by events already?

ArduPilot don't use events yet - they use STATUSTEXT of some format for most things. While I'd be very happy to use events for this kind of thing if it was standardized, until events is widely supported AND the particular events for feasibility are standardized in some way, not sure how we can do so.

So I'm still keen on a message, and possibly a command to trigger feasibility checks on request. Happy for some kind of counter proposal.

[jperez-droneup]

It seems like a message would be the easiest way to implement this given the current infrastructure and taking into account Ardupilot. Is this something you would be able to put together?

[julianoes]

I'm not opposed but I'm busy on other work. If you need to move this up my priority list, you can always consider sponsoring me.

[julianoes]

@hamishwillee and I just talked about this on the MAVLink call and found that the events system would be the right way to go about this. We might need @bkueng's help to get this drafted properly though.

[hamishwillee]

Re the comment above, the idea is inspired by @bkueng implementation of prearm checks in PX4 using Events. From the docs:

Note that internally PX4 runs arming checks at 10Hz. A list of the failed checks is kept, and if the list changes PX4 emits the current list using the Events interface. The list is also sent out when the GCS connects. Effectively the GCS knows the status of prearm checks immediately, both when disarmed and armed.

I would say might be the right way to address this.

What events give us is a way to define both standardized and custom feasibility checks. The events can also be translated and shared with the ground station in a standard way.
What continuously running the checks does is give us a way to clear the failed checks as needed.

It's cool, but only PX4 has implemented Component Information and EVENTs. I'm also not sure that the mission checks can be run continuously at high enough rate.

Instead of events you could have a message with bitmask fields for standard and custom checks failing and stream this, or emit on change.
Instead of continuously running checks you could have a command that triggers the check to be run and emits either events or above message.

I think events are a really good way to go for this, but not sure what it means to "standardize" this behaviour so flight stacks and GCS can implement to it without having to know about each other. Perhaps it is as simply as defining an event category.

[bkueng]

but not sure what it means to "standardize" this behaviour so flight stacks and GCS can implement to it without having to know about each other

There's a common event namespace intended for that: https://github.com/mavlink/libevents/blob/main/events/common.json#L52