Libcanard v5.0 proposal

pavel.kirienko · March 24, 2026, 3:34pm

Soon I am going to merge libcanard v5.0 to stage it on the master branch. The new version introduces a new API, adds support for legacy UAVCAN v0/DroneCAN compatibility, and adds support for the tentative new message format with 16-bit subject-ID, intended to support automatic topic allocation. The new version also reduces the memory consumption significantly and improves the RX reassembler.

github.com/OpenCyphal/libcanard

v5.0 alpha

master ← experimental

opened 03:18PM - 24 Mar 26 UTC

pavel-kirienko

+17490 -25154

v5 is a major rework based on the experience gained from extensive production us…e of the previous revisions. The API has been redesigned from scratch and as such there is no migration guide available; please refer to the examples and read the new `canard.h` to see how to use the library -- the new API is much more ergonomic than the old one. Ignore the commit history, it will be squashed into a single commit. Main changes: - Support for new protocols alongside Cyphal v1.0: - Cyphal/CAN v1.1, which adds support for 16-bit subject-IDs (like in UAVCAN v0) via a new CAN ID layout format. - UAVCAN v0 aka DroneCAN, a legacy predecessor to Cyphal v1.0 that is still widely used. - Anonymous messages can no longer be transmitted, but they can still be received. - A new passive node-ID autoconfiguration based on a simple occupancy observer. This method is decentralized and is compatible with old nodes. A node-ID can still be assigned manually if needed. - Automatic CAN acceptance filter configuration based on the current subscription set. The configuration is refreshed whenever the subscription set is modified or the local node-ID is changed. - New TX pipeline using per-transfer queue granularity with efficient CAN frame deduplication across redundant interfaces, which resulted in a major reduction of heap memory footprint (typ. x2+ reduction). - New RX pipeline supporting priority level preemption without transfer loss and reduced memory consumption. The old revision was susceptible to transfer loss when the remote initiated a higher-priority multi-frame transfer while a lower-priority multi-frame transfer was in flight. The v5 revision maintains concurrent reassemblers per priority level, enabling arbitrary priority nesting. Closes #184 Closes #223 Closes #247

pavel.kirienko · April 6, 2026, 1:27pm

I am seeing there’s not a lot of feedback coming in so I will proceed to merge it soon. Can’t afford to delay this effort because if I don’t reach some pre-release milestone now, it will be hard to resume this work later. Until v1.1 is officially out we’re still flexible so feel free to submit feedback later on.

Same policy will apply to PyCyphal, Cy, and other libraries involved in the v1.1 work.