Skip to content
Interuss Streaming

Interuss Streaming

Andi Lamprecht Andi Lamprecht ·· 4 min read· Accepted
ADR-0131 · Author: Sybil Melton · Date: 2025-02-07 · Products: shared
Originally ADR-0079-INTERUSS-STREAMING (v7) · Source on Confluence ↗

InterUSS Streaming

Context

UTM-1948

Flight Plans

Uncrew needs a way to plan missions with a specified path of 3D coordinates (lat, lon, altitude) start and end times, as well as a number of other attributes.

UTM has provided APIs to create and manage these Flight Plans.

Operational Intents

UTM needs a way to coordinate flights between DroneUp and other industry operators. To do this, UTM communicates with a local Discovery and Synchronization Service (DSS) to discover flights from other operators, as well as let other operators know what we are doing.

Using the Flight Plans we know about, we create, submit, and store Operational Intents to the DSS local to that flight.

A single Operational Intent may contain many 4D Volumes (3D space over a span of time). This tells us when and where a drone may be flying over the span of a flight, effectively reserving the airspace for that flight.

Decision Drivers

  • Uncrew needs a way of learning about other operators’ flights
  • Uncrew needs these flights returned in a gRPC endpoint as MVT Tiles

Decision

A new suite of Operational Intent APIs will be created to fetch simplified versions of our known Operational Intent Volumes.

To best tailor this new service to the needs of Uncrew, a gRPC streaming endpoint will be created, returning MVT Tiles of all our known Operational Intent Volumes.

Operational Intent Volume

Generally, the schema for a single Operational Intent Volume will be something to this effect:

{
  "operational-intent-id": 123,
  "mission-id": "00000000-0000-0000-0000-000000000000",
  "flight-source": "droneup",
  "start-time": "2024-07-29T00:00:00Z",
  "end-time": "2024-07-29T01:00:00Z",
  "ceiling": 100.0,
  "floor": 50.0,
  "altitude-ref": "navd88",
  "altitude-unit": "m",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [ -76.184855, 36.8426951 ],
        [ -76.184855, 36.8427500 ],
        [ -76.184923, 36.8427500 ],
        [ -76.184923, 36.8426951 ],
        [ -76.184855, 36.8426951 ]
      ]
    ]
  }
}

Note: The geometry in the example above is in GeoJSON format for readability. Geometries in an MVT payload will have their own format.

Operational Intent APIs

Invalid Image Path

gRPC MVT Volumes

A gRPC Subscription endpoint is provided to stream Operational Intent Volumes in an MVT Tile format.

Given some Tile Coordinates, clients may begin listening for volumes. Upon connection, Operational Intent Volumes will be fetched from the UTM API service that both intersect with the requested Tile Coordinates as well as occur on or after the time the subscription begins.

Following this initial subscription, any new Operational Intent Volumes, intersecting with the tile of interest, will be sent down to those subscribing clients.

Redis

The gRPC Subscription service needs a way to learn about Operational Intent changes in real-time. To do this, the service will listen to a Redis stream, populated by the UTM API service and containing all the Operational Intents that have been changed in some way.

GET Operational Intent Volumes

A REST endpoint is provided to convert a single Operational Intent into a GeoJSON FeatureCollection of its volumes. This is used by the gRPC subscription service to fetch Operational Intent Volumes one-by-one, as Operational Intents are read in from the Redis Stream.

GET GeoJSON Volumes

A REST endpoint is provided to return a FeatureCollection of Operational Intent Volumes that intersect with some given Tile Coordinates and (optionally) a start and end time.

This is primarily used by the gRPC subscription service to send current Operational Intent Volumes to new subscribers upon the start of their connection.

GET MVT Volumes

A REST endpoint is provided to return an MVT payload of these Operational Intent Volumes, following the same API interface as the GeoJSON endpoint.

Problems & Alternate Approaches

Some requests can be slow, as each Operational Intent must be converted from WGS84 to NAVD88.

One solution to this may be to perform this altitude conversion upon reception of the Operational Intent and store this NAVD88 altitude along with the WGS84 altitude.

Consequences

  • No database connection, hence the new REST APIs.
  • Requests may be slow at times
Last updated on