ESC driver

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.

An EscDriver reads per-motor telemetry from electronic speed controllers as a stream of EscTelemetry samples. DShot telemetry, KISS and BLHeli32 protocols share this interface. ESC drivers are read-only by design. Motor setpoints flow through the flight controller, not through the agent.

The interface

from ados.sdk.drivers.esc import (
    EscDriver,
    EscCandidate,
    EscCapabilities,
    EscSession,
    EscTelemetry,
)

class MyEscDriver(EscDriver):
    async def discover(self) -> list[EscCandidate]:
        ...

    async def open(self, candidate, config) -> EscSession:
        ...

    async def close(self, session) -> None:
        ...

    def capabilities(self, session) -> EscCapabilities:
        ...

    async def telemetry_iterator(self, session):
        # async generator yielding EscTelemetry, one per motor per update
        ...

Candidates

Unlike the other kinds, EscCandidate has a required motor_count field:

EscCandidate(
    driver_id="com.example.my-esc",
    device_id="serial-ttyS2",
    label="4-in-1 ESC telemetry on ttyS2",
    bus="uart",
    motor_count=4,
)

Capabilities

EscCapabilities(
    protocol="dshot-telemetry",
    motor_count=4,
    has_rpm=True,
    has_temperature=True,
    has_voltage=True,
    has_current=False,
    update_hz=200.0,
)

Telemetry samples

EscTelemetry(
    timestamp_ns=ns,
    motor_index=0,
    rpm=12500,
    temp_c=42.0,
    voltage_v=22.1,
    current_a=0.0,
    throttle_pct=37.5,
)

Report 0.0 for a value the protocol does not carry, and set the matching has_* flag to False in EscCapabilities so your GCS half knows to hide it.

Opening the driver from your plugin

Your plugin calls discover(), open() and consumes telemetry_iterator itself, then publishes the samples with ctx.telemetry.extend. The pattern is on Driver layer. A direct telemetry wire needs hardware.uart; telemetry carried in the MAVLink stream needs mavlink.read.

Next steps

Driver layer

The shared contract and the manifest table.

Hardware testing

Test with a mock serial backend.

Payload actuator driver

The next driver kind.

Start here

Tutorials

Reference

SDKs

Deep dives

Test and distribute

The interface

Candidates

Capabilities

Telemetry samples

Opening the driver from your plugin

Next steps

Driver layer

Hardware testing

Payload actuator driver

​The interface

​Candidates

​Capabilities

​Telemetry samples

​Opening the driver from your plugin

​Next steps

Driver layer

Hardware testing

Payload actuator driver

The interface

Candidates

Capabilities

Telemetry samples

Opening the driver from your plugin

Next steps