Placement Of UTM Interraction

Andi Lamprecht ·2026-05-11· 7 min read· Accepted

Placement of UTM Interaction

Jira tickets:

• UNCREW-3288

Placement of UTM Interaction

Jira tickets:

• UNCREW-3288

Context

Every Uncrew mission is submitted to UTM as a flight intent and as I type this, the submitting happens in the MissionsService when the supervisor, having reviewed the mission plan, decides to assign it to an operator. The code, of course, is written in golang. Two forces now challenge this setup:

• UNCREW-3287 adds a new scenario where the UAV itself plans a flight - a contingency flight in response to finding itself in some kind of peril. The UAV needs reserve the airspace for this new plan with the UTM, i.e.: it needs to seek the UTM’s approval. There has not been a case to date that the UAV would need to ask the MissionsService for something and there is no API request path leading from the UAV to MissionsService. One would need adding thus introducing a circular dependency between the MissionsService and Avatar. Unlike the MissionsService, Avatar is thought to be a high-availability, mission-critical component that contingency failsafes need. In other words UNCREW-3287 is the force that wants to move the UTM interaction from the MissionsService to the Avatar.

• Meanwhile UNCREW-3285 exposes a problem with our mission workflow. Because we don’t submit our flight plans to UTM until the supervisor approves them and because we aren’t expected to do anything to prevent multiple unassigned plans to queue up, the chances of these plans to collide on submission increase. Consider the following airfield/site. The way we have designed our departure and arrival paths will have LZ1 and LZ3 share the same initial altitude. All things being equal and empty, the chance of LZ1 facing a delivery to the north-west corner of the site is 25% and so is the chance of LZ3 facing a delivery to the north-east corner of the site. With 12.5% probability, whichever is the 2nd delivery to be reviewed and assigned by the supervisor, shall be rejected by UTM as conflicting with the first.

This probability grows with the number of flights and it is arguably too high. This suggests that Uncrew should reserve the airspace the moment it holds a plan for it.

Who Does the Scheduling?

There is an important product dilemma/question shaping this ADR: Can a client dump a bunch of missions onto Uncrew at one go and expect Uncrew operations decide when to fly which? Or are the missions sent to Uncrew expected to be flown in the order they have been submitted and each within some pre-agreed operationally-reasonable time? Is each mission Uncrew receives essentially ready to be flown, UAV on the ground, parcel attached and batteries charged?

Another way of asking this question is: does each create-mission request behave like an independent airliner requesting permission to taxi to the runway or does it behave like an airline requesting takeoff slots for whole day?

If clients can dump an hour-worth of missions onto Uncrew expecting it to do the scheduling, then Uncrew cannot reserve airspace upon reception of each mission unless it performs the scheduling function and works out how to align them in time. This can be done either by Uncrew code or by the supervisor. The former is a serious feature to ask for because pathfinder isn’t yet fully 4D, i.e.: it can’t seek to optimize paths by waiting for airspaces to clear.

Uncrew mission scheduling is a part of the long term product vision.

Supervisor Does the Scheduling

The reality where the Uncrew human Supervisor is in charge of mission scheduling might look like so:

Summary

• If we don’t reserve airspace on mission creation, the supervisor is presented with missions that aren’t deconflicted and, with high probability, the supervisor will have to replan each before assignment.
• If Uncrew is expected to do the scheduling or is unsure, then it cannot reserve airspace on mission creation.
• HubOps seem to do the scheduling in the standard operating conditions, but tends to pile missions up when testing.
• If we ever want to reserve airspace on mission creation, we will have to do it without assigning the mission either to the operator or to UAV. The operator may be unknown at the point of mission reception, while the UAV may be still flying the previous mission.

Decision

• We will want to put scheduling function into Uncrew in the long term, but have to deal with the short-term where missions coming from HubOps are mostly scheduled and if they are not, they just need means of de-entanglement.

  • We shall offer the “Replan” button as the main scheduling tool to the Supervisor. Even if Uncrew doesn’t do scheduling, the Supervisor may still not make it in time to assign the mission before it expires and they will need the Replan button for that.
  • The Replan function is to be implemented by the MissionsService and it shall allow the caller specify the earliest mission takeoff time. This time may be exposed in the UX or just default to now.

• We will keep the status quo keep reserving airspace late upon assignment and not creation, but fearing that supervisors will have to replan most of missions, we want to prepare for the change here.

  • We shall structurally decouple mission assignment from reserving airspace.
  • MissionsService Assign function should to be able to work out if the airspace is reserved for the mission and reserve it, if it isn’t.
  • With this approach the missions are not deconflicted upon creation and the risk of them conflicting upon submission is high. We shall live with this risk and continue to create missions for a specific takeoff time, hope they will be deconflicted upon submission and ask the Supervisor to replan when they are not.

• The Avatar shall be able to submit flight intents directly to UTM, but we decide for the MissionsService to keep its integration with UTM. Reserving airspace doesn’t even need a UAV, so for the purpose of strategic deconfliction among missions, the airspace reservation shouldn’t be a UAV’s function.

  • Avatar and MissionsService shall share library code and configuration
  • We avoid introducing additional dependency between Avatar and MissionsService.

• Segmenting the mission is conceptually a part of airspace reservation, but estimating its best/worst time has to move to planning.

  • (Onboard) UFC will one day need to understand what’s the earliest and latest when it’s expected to get to some waypoint and decide to speed up or slow down.
  • Communicating this uncertainty to our clients seems like a prudent think to do;
  • Communicating earliest and latest takeoff time to our Supervisors and Operators becomes an imminent necessity.
  • The Mission Plan Items communicated to Avatar and UAV shall need new members:

        message MissionItem {
          oneof type {
            TakeoffUAVCommand takeoff = 1;
            DropOffUAVCommand drop_off = 2;
            LandUAVCommand land = 3;
            WaypointUAVCommand waypoint = 4;
            LoiterUAVCommand loiter = 5;
          }
      +   types.TimeRange start = 6;
      +   types.TimeRange end = 7;
        }

• Moving time uncertainty to planning also means that the Mission Plan Items stored by the MissionsService and communicated to the Frontend and HubOps shall also need new members:

        message MissionItem {
          int32 objective_seq = 1;
      -   google.protobuf.Duration estimated_time = 2;
      +   google.protobuf.Duration estimated_time = 2; [deprecated]
          units.v1.Meters ground_distance_meters = 3;
          ...
          MissionItemDetail detail = 5;
      +   types.TimeRange start = 6;
      +   types.TimeRange end = 7;
        }

• Finally we shall invoke UTM’s activate (to unequivocally communicate our intention to start the mission) upon StartMission.

Please note additional complexity in the interaction with the pathfinder.

Alternatives Considered

All the alternatives we considered have been discussed in-line in the Context.

Airspace Overbooking

Voices are heard that moving the airspace reservation to happen earlier will consume more airspace. This isn’t true provided that we indeed don’t reserve more airspace is space and time. The fact that we do it earlier bares no difference to the amount of airspace we reserve.