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 LidarDriver yields point-cloud frames from a spinning, solid-state or single-line ranging device.

The interface

Capabilities

Frames

Each LidarFrame holds timestamp_ns, sequence, optional metadata, and points, a tuple of LidarPoint in the sensor body frame: +x forward, +y left, +z up, in metres.
Drivers that get no return at some angles skip those points rather than emit zeros.

Single-line and spinning sensors

The driver layer does not distinguish single-beam rangefinders from 3D LiDARs. A 1D rangefinder yields frames with points_per_frame=1.

Opening the driver from your plugin

Your plugin calls discover(), open() and consumes frame_iterator itself, then publishes what it derives (nearest obstacle, a downsampled scan) with ctx.telemetry.extend or ctx.events.publish. The pattern is on Driver layer. Most LiDARs need hardware.uart or hardware.usb.

Next steps

Driver layer

The shared contract and the manifest table.

Hardware testing

Replay recorded data when no sensor is on the bench.

GPS driver

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