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 CameraDriver reads frames from a physical or networked imaging device. Visible, thermal, depth and multi-spectral devices share this interface. The worked CameraDriver subclass is LeptonUvcDriver in the FLIR Lepton plugin (extensions/thermal-camera-flir-lepton-usb, file agent/src/altnautica_thermal_camera/driver.py). The plugin is a development preview: capture needs a libuvc backend the agent does not ship, so it is not published.

The interface

Candidates

CameraCandidate carries driver_id, device_id, label, bus, and optional vid_pid and metadata:
Keep device_id stable across reboots when the bus can produce a stable identifier (USB serial, CSI lane, RTSP URL). Where that is impossible (raw V4L2 indexing), produce an id that is at least deterministic within one boot.

Capabilities

Returned once per session, after open:
radiometric=True means every pixel encodes a temperature and FrameBuffer.radiometric_k carries the per-pixel Kelvin matrix.

Frame buffers

data is a memoryview so your consumers can avoid copies. Put driver-specific fields under metadata.

Opening the driver from your plugin

Your plugin constructs the driver and drives it. This is the shape of the FLIR Lepton plugin’s on_start:
Declare the bus capability the device needs (hardware.usb.uvc, hardware.camera.csi or hardware.usb). The full table is on Driver layer.

Testing without hardware

Inject a mock backend that produces synthetic frames through the driver’s constructor. The FLIR Lepton plugin ships MockUvcBackend in agent/tests/mock_backend.py for exactly this. See Hardware testing for the pattern.

Next steps

Driver layer

The shared contract and the manifest table.

Vendor binaries

When libuvc or a vendor library is required.

Hardware testing

Mock backends and bench rigs.

Gimbal driver

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