Skip to main content
The driver base classes and data types ship in both SDKs (ados.sdk.drivers in Python, ados_sdk::drivers in Rust), and the method contracts on these pages match them. The agent does not route drivers. It never calls discover(), open() or the iterators. register_*_driver calls return not_implemented, and the sensor.*.register capabilities are refused at grant time. A driver plugin opens and runs its own device from its lifecycle hooks, as the first-party Gimbal v2 plugin does. No Mission Control panel renders driver output.
A GpsDriver decodes a position-fix stream from a u-blox, NMEA, RTK or vendor-specific receiver into GpsFix samples. Drivers for RTK receivers also accept RTCM correction payloads.

The interface

Receivers without RTK must raise NotImplementedError (Python) or return DriverError::NotSupported (Rust) from inject_rtcm. Never drop corrections silently. The Rust trait uses an associated Session type and returns a SampleStream<GpsFix> (a boxed async stream) from fix_iterator:
GpsFix and GpsCapabilities carry the same fields in both languages.

Capabilities

Fix samples

fix_type follows the common convention: 0 no fix, 2 2D, 3 3D, 4 DGPS, 5 RTK float, 6 RTK fixed. horizontal_accuracy_m, vertical_accuracy_m, course_deg and metadata are optional.

Opening the driver from your plugin

Your plugin calls discover(), open() and consumes fix_iterator itself, and calls inject_rtcm with corrections it receives. The pattern is on Driver layer. A serial or USB-CDC receiver needs hardware.uart. inject_rtcm writes over the link the driver already opened, so it needs no extra capability.

Next steps

Driver layer

The shared contract and the manifest table.

Hardware testing

Test with a mock serial backend.

ESC driver

The next driver kind.
Last modified on October 11, 2026