Scheduler V1

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

UTM Scheduler API v1

Jira Ticket

UTM-2011

Context

Due to the highly-dense organization of hubs, the existing Coordination API for flight plans is impractical if drones are to abide by the operational radius which must act as a buffer around a drone mid-flight.
To account for this, Uncrew requires an API which defines a set of deconflicted departure/approach paths from the landing zones of a hub which have slimmer operational radii, allowing transit of many drones from the same hub simultaneously.

Decision

The proposed solution to this problem is an API that acts as an interface between HubOps and Uncrew, allowing the former to create a landing zone based on the coordinate of a particular landing pad.
With landing zone location entities established, UTM will be able to associate departure/approach paths for each, and with a new version of the Coordination API, Uncrew will be able to associate these landing zones with a flight plan on creation.
Additionally, this new version of the Coordination API will allow Uncrew to specify the shape of a flight plan in terms of segments, each with their own radius and timestamps.
This will allow for more effective use of airspace during departure/approach and improved flight plan segmentation capabilities.

“Sausage in the Sky” model causes conflicting operational volume conflicts at hubs:

Invalid Image Path

Replace “sausage” with “Noodle in the Sky” during departure/approach (specify smaller radius for these volumes), utilize full radius once far enough away from hub:

Invalid Image Path

Specification

The API shall have the folowing endpoints

• POST /api/location/

  • body: landing zone request entity

• GET /api/location/[id]?altitude-ref=[ref]

• PATCH /api/location/[id]

  • body: partial landing zone entity

• DELETE /api/location/[id]

Location Request

For Hubops to notify UTM of a landing zone, the following payload is required for the POST endpoint

{
  "id": "murphy-lz-1",
  "latitude": 32.123,
  "longitude": -80.123,
  "altitude": 123,
  "altitude-ref": "navd88",
  "type": "LZ"
}

Upon receiving such a request, UTM can then populate departure-path/approach-path, mark the location as active, and normalize the altitude to WGS84 using the Altitudes API.

Location

{
  "id": "murphy-lz-1",
  "latitude": 32.123,
  "longitude": -80.123,
  "altitude": 162,
  "is-active": true,
  "type": "LZ",
  "approach-path": [[-80.222, 32.222, 183], [-80.123, 32.123, 183], [-80.123, 32.123, 123]],
  "departure-path": [[-80.123, 32.123, 123], [-80.123, 32.123, 183], [-80.222, 32.222, 183]]
}

Uncrew, having received the id of the landing zone from Hubops, can then make a CREATE flight plan request taking these coordinates into account, and specifying the landing zone being taken off from.

The coordinates field will also be updated in the new Coordination API version to instead be named segments.
These objects must contain an array of latitude, longitude, & altitude coordinates, as well as a radius and start/end-time fields.
These keys will allow Uncrew to slim the operational radius during arrival/departure and/or segment flight plans according to the timestamps.

Updated CREATE Flight Plan Request

{
  "mission-id": "test-drone",
  "distance-unit": "ft",
  "altitude-ref": "agl",
  "ocdv-distance": 4988.97,
  "authority": "mock",
  "segments": [
    {
      "coordinates": [
        [-96.64999, 32.922682, 0.0],
        [-96.64999, 32.922682, 50.0],
        [-96.615143, 32.916485, 55.0],
        [-96.615143, 32.916485, 0.0]
      ],
      "start-time": "2024-01-08T12:00:00Z",
      "end-time": "2024-01-08T12:05:00Z",
      "radius": 8.5
    },
    {
      "coordinates": [
        [-96.64999, 32.922682, 0.0],
        [-96.64999, 32.922682, 50.0],
        [-96.615143, 32.916485, 55.0],
        [-96.615143, 32.916485, 0.0]
      ],
      "start-time": "2024-01-08T12:00:00Z",
      "end-time": "2024-01-08T12:05:00Z",
      "radius": 30.0
    }
  ]
}

This process can be summarized by the following

Indended Flow

1. Hubops uses POST endpoint to create a landing zone location with a coordinate & unique id

   1. UTM stores this landing zone, converting the altitude from the provided ref to WGS84 internal representation

2. UTM then updates this entity to have deconflicted departure/approach paths for Uncrew to query

3. Hubops stores this id to associate with a drone, communicates this relation to Uncrew

4. Uncrew can then query the departure/approach paths by specifying the landing zone id & desired altitude-ref

   1. UTM converts internal WGS84 altitude ref to NAVD88 and sends back landing zone with departure/approach path(s)

5. Based on the coordinates of the departure/approach paths, Uncrew can request a flight which incorporates them into the coordinates

   1. UTM will release a new version of the API which allows for the specification of an operational radius at a given point

6. At a point in the future, Hubops can mark a landing zone as inactive via PATCH endpoint, or remove it entirely via DELETE if necessary

Invalid Image Path

Dependencies

Invalid Image Path

Consequences

• If data duplication (& possible misalignment) is to be avoided, Hubops and Uncrew will need to make a query to the Synchronizer API to guarantee up-to-date coordinates for departure/approach paths, not putting these coordinates into long term storage themselves.
• UTM will need to add the ability to specify variable operational intent radius when generating InterUSS operational intent volumes

Alternatives Considered

• Reserve a large volume of airspace around the entire hub during hours of operation

  • Simplifies the amount of airspace reserved
  • Would complicate code needed to deconflict flights with this volume
  • Complicates flight plan model by splitting into 3 separate parts instead of 1 contiguous volume

• Rely entirely on operational intent volumes for pathfinding