MAVLINKHUD
Download App MAVLink HUD for Android

OPEN_DRONE_ID_BASIC_ID

ID: 12900
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_BASIC_ID message provides the unique identification of the Unmanned Aircraft (UA), serving as the digital "license plate" for Remote ID compliance.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts ID to GCS or Remote ID Module)
  • RX (Receive): Autopilot (Receives config from GCS)

Usage

ArduPilot supports the full OpenDroneID protocol stack. It can act as the source of Remote ID data (TX) or as a configurator for external RID modules.

Core Logic

The implementation is in AP_OpenDroneID::handle_msg within libraries/AP_OpenDroneID/AP_OpenDroneID.cpp:768.

  1. RX: If the GCS sends this message, ArduPilot updates its internal RID state (pkt_basic_id).
  2. TX: ArduPilot periodically broadcasts this message to connected MAVLink peripherals (like a WiFi RID transmitter) to ensure they are broadcasting the correct ID.

Data Fields

  • target_system / target_component: Target.
  • id_type: Type of ID (MAV_ODID_ID_TYPE), e.g., Serial Number, CAA Registration ID.
  • ua_type: Type of vehicle (MAV_ODID_UA_TYPE).
  • uas_id: The unique ID string (max 20 bytes).

Practical Use Cases

  1. Regulatory Compliance:
    • Scenario: Operating in FAA or EASA airspace.
    • Action: The drone broadcasts its ANSI/CTA-2063 Serial Number so that local authorities can identify the aircraft without physical access.
  2. Fleet Management:
    • Scenario: A swarm show with 50 drones.
    • Action: The central computer verifies that every drone on the network is reporting the correct, pre-assigned uas_id before arming.

Key Codebase Locations

OPEN_DRONE_ID_LOCATION

ID: 12901
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_LOCATION message reports the vehicle's dynamic state (Position, Altitude, Velocity) for Remote ID compliance. This is the most frequent message in the ODID protocol (typically 1Hz).

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts location to GCS/RID Module)
  • RX (Receive): Autopilot (Receives updates if using external GPS)

Transmission (TX)

The message is generated by AP_OpenDroneID::send_location_message.

Core Logic

The implementation is in libraries/AP_OpenDroneID/AP_OpenDroneID.cpp.

It pulls data from the AHRS and GPS:

  • latitude / longitude: Current position.
  • altitude_barometric: Barometric altitude relative to takeoff.
  • altitude_geodetic: GPS altitude (WGS84).
  • height: Height above ground/takeoff.
  • speed_horizontal: Ground speed.
  • direction: Course over ground.

Data Fields

  • target_system / target_component: Target.
  • status: Status (MAV_ODID_STATUS) e.g., Airborne, Ground, Emergency.
  • direction: Direction (0-360 deg).
  • speed_horizontal: Speed (cm/s).
  • speed_vertical: Vertical speed (cm/s).
  • latitude / longitude: Position (degE7).
  • altitude_barometric: Baro Alt (m).
  • altitude_geodetic: GPS Alt (m).
  • height_reference: Reference datum.
  • height: Height (m).
  • horizontal_accuracy / vertical_accuracy / barometer_accuracy / speed_accuracy: Accuracy metrics.
  • timestamp: Time since boot.
  • timestamp_accuracy: Time accuracy.

Practical Use Cases

  1. Airspace Safety:
    • Scenario: A medical helicopter is flying low near a drone operation.
    • Action: The helicopter's ADS-B In or traffic awareness system receives the drone's OPEN_DRONE_ID_LOCATION broadcast, alerting the pilot to the drone's precise location and altitude.
  2. Flight Recorder:
    • Scenario: Post-flight path analysis.
    • Action: The GCS logs these messages to reconstruct the 3D flight path with high-fidelity velocity vectors, useful for verifying flight boundaries were respected.

Key Codebase Locations

OPEN_DRONE_ID_AUTHENTICATION

ID: 12902
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_AUTHENTICATION message provides authentication data for the Unmanned Aircraft. This allows observers to verify that the broadcast Remote ID data is authentic and has not been spoofed.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts auth data)
  • RX (Receive): Autopilot (Receives auth config)

Transmission (TX)

The message is handled by AP_OpenDroneID.

Core Logic

It transmits an authentication signature or page of authentication data. Since auth data can be large, it may be split across multiple messages (pages).

Data Fields

  • target_system / target_component: Target.
  • authentication_type: Type of authentication (MAV_ODID_AUTH_TYPE).
  • data_page: Page number.
  • last_page_index: Last page index.
  • length: Length of data in this page.
  • timestamp: Timestamp.
  • authentication_data: Raw data buffer (up to 23 bytes).

Practical Use Cases

  1. Anti-Spoofing:
    • Scenario: A malicious actor tries to broadcast fake drone locations to disrupt an airport.
    • Action: Security systems check the digital signature provided in this message against a trusted registry. The fake broadcasts fail validation and are flagged as spoofed.
  2. Secure Access:
    • Scenario: A delivery drone enters a secure facility.
    • Action: The facility's receiver validates the authentication token to confirm the drone is an authorized delivery vehicle before opening the landing bay.

Key Codebase Locations

OPEN_DRONE_ID_SELF_ID

ID: 12903
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_SELF_ID message allows the operator to provide a free-text description of the flight or vehicle. This is often used for "Mission Description" or "Emergency Text" in the Remote ID broadcast.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts self-ID)
  • RX (Receive): Autopilot (Receives config)

Transmission (TX)

The message is handled by AP_OpenDroneID.

Core Logic

It broadcasts the configured description string.

Data Fields

  • target_system / target_component: Target.
  • description_type: Type of description (MAV_ODID_DESC_TYPE).
  • description: Description string (up to 23 bytes).

Practical Use Cases

  1. Emergency Communication:
    • Scenario: A drone is performing an emergency medical delivery.
    • Action: The operator sets the description to "EMERGENCY MEDICAL BLOOD". Anyone receiving the RID signal sees this text and understands the priority nature of the flight.
  2. Mission Identification:
    • Scenario: Multiple survey teams are working in the same area.
    • Action: Team A sets their description to "Survey Team A", allowing them to distinguish their drones from Team B on the monitoring app.

Key Codebase Locations

OPEN_DRONE_ID_SYSTEM

ID: 12904
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_SYSTEM message provides operator location and system metadata. This includes the pilot's location (Takeoff or Live GCS location) and the altitude reference.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts system data)
  • RX (Receive): Autopilot (Receives GCS/Operator location)

Transmission (TX)

The message is handled by AP_OpenDroneID.

Core Logic

It pulls the Operator Location either from the GCS (via OPEN_DRONE_ID_SYSTEM_UPDATE) or uses the vehicle's home location if GCS location is unavailable.

Data Fields

  • target_system / target_component: Target.
  • flags: Flags.
  • operator_latitude: Operator Lat (degE7).
  • operator_longitude: Operator Lon (degE7).
  • area_count: Count of area points.
  • area_radius: Radius of operation.
  • area_ceiling: Ceiling height.
  • area_floor: Floor height.
  • category_eu: EU Category.
  • class_eu: EU Class.
  • operator_altitude_geo: Operator Altitude (Geodetic).
  • timestamp: Timestamp.

Practical Use Cases

  1. Pilot Accountability:
    • Scenario: A drone is flying dangerously near a crowd.
    • Action: Law enforcement checks the Remote ID broadcast. The operator_latitude/longitude points them to the pilot's location, allowing them to intervene directly.
  2. Home Point Verification:
    • Scenario: A user sets up for a long-range flight.
    • Action: The GCS sends its GPS location to the drone. The drone broadcasts this as the Operator Location, ensuring compliance with regulations that require the pilot's location to be known.

Key Codebase Locations

OPEN_DRONE_ID_OPERATOR_ID

ID: 12905
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_OPERATOR_ID message broadcasts the Operator ID (e.g., FAA Registration Number or CAA Operator ID) required for Remote ID compliance.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts Operator ID)
  • RX (Receive): Autopilot (Receives Operator ID config)

Transmission (TX)

The message is handled by AP_OpenDroneID.

Core Logic

It broadcasts the configured Operator ID string.

Data Fields

  • target_system / target_component: Target.
  • operator_id_type: Type of ID (MAV_ODID_OPERATOR_ID_TYPE).
  • operator_id: Operator ID string (up to 20 bytes).

Practical Use Cases

  1. Compliance Audits:
    • Scenario: An aviation authority audits drone operations at a commercial site.
    • Action: They monitor the RID broadcast and compare the operator_id against their database of registered commercial operators to ensure the company is compliant.
  2. Incident Reporting:
    • Scenario: A drone crashes on private property.
    • Action: The homeowner uses a RID scanner app to read the operator_id, which can be provided to authorities to identify the owner for insurance claims.

Key Codebase Locations

OPEN_DRONE_ID_MESSAGE_PACK

ID: 12915
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_MESSAGE_PACK allows packing multiple OpenDroneID messages into a single MAVLink payload. This is efficient for bandwidth-constrained links or for ensuring atomic updates of RID data.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Broadcasts packed data)
  • RX (Receive): Autopilot (Parses packed data)

Transmission (TX)

ArduPilot can parse this message if received from a peripheral, but typically transmits individual ODID messages for compatibility.

Data Fields

  • target_system / target_component: Target.
  • single_message_size: Size of each message in the pack.
  • msg_pack_size: Total size.
  • messages: Buffer containing concatenated ODID messages.

Practical Use Cases

  1. Bandwidth Optimization:
    • Scenario: A telemetry link has very limited bandwidth (e.g., LoRa).
    • Action: Instead of sending 5 separate MAVLink headers for Basic ID, Location, System, etc., the system packs them into one MESSAGE_PACK, reducing overhead and ensuring all data arrives together.
  2. Atomic Updates:
    • Scenario: Updating the Remote ID state on a companion computer.
    • Action: The Autopilot sends a pack containing both the new Location and the new Vector. The companion computer processes them simultaneously, avoiding a race condition where the location updates before the vector.

Key Codebase Locations

OPEN_DRONE_ID_ARM_STATUS

ID: 12918
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_ARM_STATUS message reports the health and arming status of the Remote ID system. It allows the Remote ID module (e.g., a DroneCAN device) to block the vehicle from arming if the RID system is not healthy or compliant, and provides a text error message explaining why.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Forwards RID status to GCS)
  • RX (Receive): Autopilot (Receives status from DroneCAN RID module)

Usage

ArduPilot acts as a bridge for this message.

Core Logic

The implementation is in handle_arm_status within libraries/AP_OpenDroneID/AP_OpenDroneID_DroneCAN.cpp:215.

  1. Reception: The Autopilot receives a dronecan.[remoteid](/field-manual/remote-id/core-concepts-and-regulations.html).ArmStatus message from the CAN bus.
  2. State Update: It updates the internal AP_OpenDroneID state, which the Arming Checks (AP_Arming) monitor. If the status is not "Good", the autopilot will refuse to arm.
  3. Forwarding: It immediately forwards the status to the GCS via MAVLink so the pilot can see the error message (e.g., "RID: System Failure").

Data Fields

  • status: Status (MAV_ODID_ARM_STATUS) e.g., GOOD_TO_ARM, PRE_FLIGHT_CHECKS_FAIL.
  • error: Text error message (up to 50 bytes).

Practical Use Cases

  1. Pre-Flight Safety:
    • Scenario: A user tries to arm the drone, but the Remote ID module has not yet acquired a GPS lock.
    • Action: The module sends OPEN_DRONE_ID_ARM_STATUS with status FAIL and error "Wait for GPS". The autopilot blocks arming, and the GCS displays "Wait for GPS" to the pilot.
  2. Tamper Detection:
    • Scenario: The Remote ID antenna is disconnected.
    • Action: The module detects the hardware fault and reports "Antenna Fail". The drone prevents takeoff, ensuring regulatory compliance.

Key Codebase Locations

OPEN_DRONE_ID_SYSTEM_UPDATE

ID: 12919
Supported (TX & RX)

Summary

The OPEN_DRONE_ID_SYSTEM_UPDATE message allows the Ground Control Station (GCS) to send real-time updates about the Operator's location to the drone. This is crucial for satisfying the Remote ID requirement to broadcast the pilot's location, especially if the pilot is mobile.

Status

Supported (TX & RX)

Directionality

  • TX (Transmit): Autopilot (Forwards update to RID module)
  • RX (Receive): Autopilot (Receives Operator Location from GCS)

Usage

The GCS typically sends this message at 1Hz if the GCS has a GPS source (e.g., tablet GPS).

Core Logic

The implementation is in AP_OpenDroneID::handle_msg within libraries/AP_OpenDroneID/AP_OpenDroneID.cpp:777.

  1. Reception: The Autopilot receives the message from the GCS.
  2. Update: It updates the internal pkt_system structure with the new operator_latitude, operator_longitude, and operator_altitude_geo.
  3. Transmission: The Autopilot then uses these updated values when constructing the OPEN_DRONE_ID_SYSTEM message broadcast to the Remote ID module.

Data Fields

  • target_system / target_component: Target.
  • operator_latitude: Operator Lat (degE7).
  • operator_longitude: Operator Lon (degE7).
  • operator_altitude_geo: Operator Altitude (Geodetic).
  • timestamp: Timestamp.

Practical Use Cases

  1. Mobile Command Center:
    • Scenario: A pilot is operating from a moving vehicle.
    • Action: The GCS sends OPEN_DRONE_ID_SYSTEM_UPDATE continuously. The drone updates its broadcast to reflect the pilot's changing position, ensuring compliance with "Mobile GCS" regulations.
  2. Dynamic Home Point:
    • Scenario: The drone takes off from a boat.
    • Action: As the boat moves, the GCS updates the operator location. If the drone needs to RTL (Return to Launch), it can use this updated operator location (depending on configuration) or at least correctly report where the pilot is currently located.

Key Codebase Locations