Firmware version v0.5.0 is coming soon. To help beta test it now, please check it out on GitHub.

ODrive Documentation

High performance motor control

View the Project on GitHub madcowswe/ODrive

Help improve these docs: submit edits using the link in the top right.

If you need help, please search or ask the ODrive Community.

ODrive Communication Protocol

Communicating with an ODrive consists of a series of endpoint operations. An endpoint can theoretically be any kind data serialized in any way. There is a default serialization implementation for POD types; for custom types you must (de)serialize yourself. In the future we may provide a default serializer for structs. The available endpoints can be enumerated by reading the JSON from endpoint 0 and can theoretically be different for each communication interface (they are not in practice).

Each endpoint operation can send bytes to one endpoint (referenced by its ID) and at the same time receive bytes from the same endpoint. The semantics of these payloads are specific to each endpoint’s type, the name of which is indicated in the JSON.

For instance an int32 endpoint’s input and output is a 4 byte little endian representation. In general the convention for combined read/write requests is exchange, i.e. the returned value is the old value. Custom endpoint handlers may be non-compliant.

There is a packet based version and a stream based variant of the protocol. Each variant is employed as appropriate. For instance USB runs the packet based variant by default while UART runs the stream based variant.

Packet format

We will call the ODrive “server” and the PC “client”. A request is a message from the PC to the ODrive and a response is a message from the ODrive to the PC.

Each request-response transaction corresponds to a single endpoint operation.



Stream format

The stream based format is just a wrapper for the packet format.