Mission Configuration Data Item

In the discussion of Implement new mission opaque ID protocol by peterbarker · Pull Request #20834 · ArduPilot/ardupilot · GitHub @peterbarker made this comment.

The suggestion that came out of the DevCall yesterday is to just go fully opaque - so the GCS never checksums anything, just has some sort of autopilot-generated token which can be used to uniquely identify a mission configuration (almost certainly a checksum).

A unique mission token is a great idea, but it can’t possibly be a checksum. A unique identifier has to be unique and immutable and a checksum is neither. A UID/GUID would work and its probably the best way to do this.

The implication of this great idea is that there needs to be a mission configuration “header” data entity stored separately from the mission/waypoint items, fence items and rally points.

This is a very powerful concept that might help to solve a number of the challenges with working with “missions” as currently implemented. In particular, this creates a place to store “common” information relating to a mission such as:

  • Mission Name
  • Mission Description
  • Mission Home Location
  • Mission Version (incremented each time any waypoint, fence or rally changes)
  • Mission Checksum/Checksum Version (the subject of the PR above)
  • Mission Signature
  • Mission Create Date/Time
  • Mission Update Date/Time
  • Overrides for specific parameter values that only apply for the mission
  • I’m sure there might be more now there is a place for them

Here’s an idea that struck me while I couldn’t sleep while thinking about this: parameter overrides for a specific mission. The obvious ones that come to my wider are
FENCE_ENABLE and/or FENCE_AUTOENABLE, and RTL_AUTOLAND which often need to change depending on whether the loaded mission has a fence and a landing in it or not. As soon as you think of this though - the ability to override a parameter just for a specific mission is a very powerful idea, I’m sure it could be used for a number of things.

The data model for this probably looks like this:


Implication of this is that the ID (UID) of the Mission Configuration should to be added to Mission Item, Fence Item and Rally Point Item as a foreign key. This then creates the possibility of easily being able to manage having multiple missions currently loaded into a vehicle with the ability to select the “current mission configuration”. It might take time to get there, but the possibilities abound.

This architecture addresses the following use cases/user stories:

As a quite new user of ArduPilot, I have found the following challenges with working with missions that IMO need an architectural solution to address, hence my suggestion:-

  1. As a pilot, I want to be able to load and save missions to and from the FC and be able to easily manage which mission is loaded and keep track of where (on the FC or on my PC) is the latest/correct version of the mission.
  2. As a pilot, I want to be able to validate that the correct mission is on the aircraft, so that I know I am flying the mission I intended.
  3. As a pilot, I want to be able to identify the mission, by some kind of id AND description, so that I can keep track of the specific mission and it’s purpose.

Those are the core ones, but there are other things I think I should be able to do with missions that I find frustrating that I can’t do. I don’t know if others want these, but I’d be really surprised if not:-
5. As a pilot, I want to be able to load multiple missions on the FC prior to a trip to the field and select the mission to run before each flight, which might be a different mission for each flight, so that I can carefully preplan the mission but select what I want to fly based on the circumstances. For example I have a field where the wind sometimes comes from the south and sometimes from the north. I’d like to pre-program a north takeoff/land and south takeoff/land version of the mission and select the right one at the field without having to reload the mission while at the field.
6. As a drone service provider, I want to be able to ensure that the correct mission is on the plane and has not been tampered with or modified. Ideally this should be cryptographically verified.
7. As a drone service provider, I want to be able to create a known reliable version of a mission and load it on 10’s or even 100’s of vehicles knowing that I can be guaranteed that exactly the same mission is loaded on each vehicle.
8. As a drone service provider, I want to be able to link logs, footage and sensor data for a flight to a specific programmed mission so that I can provide auditable results to a customer guaranteeing that the data they receive for multiple flown missions is the result of a specific contracted mission plan.
9. As a mission planner, I’d like to be able to construct sub-missions that can be reused and composed into larger missions without having to code the entire mission from beginning to end. I’d like to have reusable geofences for specific fields and takeoff and landings for different wind conditions and be able to combine those with sub-missions for specific flights and destinations. This would help me to be able to reliably and correctly create missions with the minimum of effort and reduce the potential for errors.
10. As a pilot, I’d like specific parameters and options, such as the “Home” location, or particular parameters to be associated with a particular mission, to prevent errors and potential crashes due to options or parameters not being set correctly for the mission being flown.
11. As a mission planner or pilot, I’d like to be able to link a mission to a particular vehicle or vehicle type to prevent potential crashes or other problems due to a mission being loaded onto the incorrect vehicle.

1 Like

A lot of these considerations seem to have been discussed in the context of MavLink here File Format Standardization · Issue #989 · mavlink/mavlink · GitHub