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:
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, afteropen:
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’son_start:
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 shipsMockUvcBackend 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.