Inventory UAV Checkin

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

Drone ON/OFF statuses

Context

The drone fleet’s expansion necessitates robust management of the inventory service, representing the drones’ operational status, details, and associated metadata within our system.

Decision

Handling Drone Off Scenarios:

• Off Duration Tolerance:

  • If a drone goes off (stops checking in) with an assigned mission, its status within the inventory service remains unchanged for up to 1 hour. This threshold accounts for short-term disconnections during crucial operations.
  • If a drone goes off without an assigned mission(inventory service will know about it from check in payload), its status within the inventory service remains unchanged for up to 10 minutes since the last received checkin.

Drone Status Definition:

• On:

  • A drone is considered ON within the inventory service if there’s continuous communication and regular checkIn received within predefined intervals.

• Off:

  • A drone is deemed Off within the inventory service based on the criteria mentioned above under “Off Duration Tolerance”.

Inventory Service Initialization and Termination logic:

• Inventory Service Initialization and Termination:

  • Initialization:

    • Drone change status to On in the inventory service and create avatar when the drone checks in and if it doesn’t have pre-existing avatar in cloud (considering the off duration tolerance).

  • Termination:

    • Drone change status to Off when one of Off Duration Tolerance is reached.

Check In Metadata:

Heartbeat signals sent by drones are accompanied by metadata, providing insights into the drone’s operational status and health:

• Timestamp: Indicates when the heartbeat was sent.
• Sequence number: Helps in determining if the heartbeat was out-of-sequence.
• Drone ID: Unique identifier for the drone.
• Battery Level: Current battery percentage or voltage.
• GPS Coordinates: Drone’s current location.
• Operational Status: In-mission, idle, charging status, etc.

List of metadata can be modified in any time.

Check In GRPC implementation example:

service TrustedUAVsService {
  // Periodic check-ins for already trusted Unmanned Aerial Vehicles (UAVs) to check
  // further authority or possible commands or updates from Inventory
  rpc Checkin(CheckinRequest) returns (stream CheckinResponse);
}

CheckinRequest message that the drone sends, encapsulating its metadata for each heartbeat.
The server responds with a CheckinResponse message for each heartbeat received.

Heartbeat Timeout:

The Inventory Service expects to receive a heartbeat from each drone within a specified timeout range. This heartbeat timeout is set between 20 to 60 seconds. If no heartbeat is received in this duration, preliminary actions or alerts might be triggered, even before the drone is marked as “off” based on the aforementioned scenarios.

Alternatives Considered

Direct Data Retrieval from Avatar and Mission Services:

Instead of receiving comprehensive heartbeat messages, we could retrieve pertinent data directly from avatar and mission services.

• Pros: Reduces the size and frequency of heartbeat messages, potentially improving performance and reducing network overhead.
• Cons: Significantly increases the complexity of internal communications between services, introducing potential points of failure and maintenance challenges.

Data Retrieval from Flight Logs via Pub/Sub:

Instead of relying on heartbeats, the Inventory Service could subscribe to flight logs published to a pub/sub system. These logs would provide real-time data on drone operations.

• Pros: Asynchronous and scalable model, potentially reducing the need for real-time heartbeats and offering flexibility in data processing.
• Cons: Introduces dependency on the reliability of the pub/sub system, and may also necessitate more complex data filtering and processing mechanisms to discern meaningful insights from raw flight logs.