Add support for libcanard as a managed component for Cyphal/CAN protocol (IEC-348)

[Flexblue]

Is your feature request related to a problem?

The ESP-IDF provides a robust and well-maintained low-level driver for the TWAI (CAN) peripheral. However, for developing advanced, reliable, and interoperable distributed systems, a higher-level protocol is essential. Currently, there is no officially supported, managed component in the ESP-IDF ecosystem for a modern, high-integrity publish/subscribe protocol over CAN bus, such as Cyphal.

Developers working on applications in robotics, unmanned systems (drones, rovers), industrial automation, and light electric vehicles often require features like:

• Zero-configuration, plug-and-play node discovery.
• A robust publish/subscribe communication model.
• Network-wide time synchronization.
• Support for high-integrity and functionally safe designs.

Without an official component, developers must manually clone, integrate, and maintain libraries like libcanard themselves. This process is time-consuming, error-prone, increases the maintenance burden, and leads to fragmented, non-standard implementations across the community. This friction significantly slows down development and raises the barrier to entry for using ESP32 in these critical application domains.

Describe the solution you'd like.

I propose the integration of libcanard as an officially supported, managed component available through the ESP-IDF Component Manager.

libcanard is a lightweight, high-quality, C99/C11 implementation of the Cyphal/CAN protocol stack. Cyphal (formerly known as UAVCAN) is an open, lightweight data bus standard designed for robust intra-vehicular communication in aerospace and robotic applications.

Making libcanard a managed component would mean:

1. Easy Integration: Developers could add it to their projects with a simple command, like idf.py add-dependency espressif/libcanard.
2. Guaranteed Compatibility: The component would be tested and maintained against new versions of ESP-IDF, ensuring stability.
3. Standardization: It would provide a "go-to" solution for the community, fostering better collaboration and code reuse.
4. Accelerated Development: Developers could focus on their application logic instead of wrestling with library integration and low-level protocol details.

This would unlock the full potential of the ESP32's built-in CAN controller for a wide range of advanced applications.

Describe alternatives you've considered.

While there are alternative approaches to implementing Cyphal/CAN on ESP-IDF, none address the core issues of ease of use, standardization, and long-term maintenance as effectively as integrating libcanard as a managed component:

• Manual integration of libcanard: Requires developers to clone the repository, configure build systems, resolve dependencies, and maintain compatibility with ESP-IDF updates—this is error-prone and creates fragmented implementations.
• Using other Cyphal libraries: Alternatives like uavcan (legacy) or less mature implementations lack the active maintenance, lightweight design, and C99/C11 compliance of libcanard, which is specifically optimized for embedded systems like ESP32.
• Custom protocol implementations: Building a proprietary publish/subscribe protocol over TWAI negates interoperability with the broader Cyphal ecosystem (used in robotics, aerospace, etc.) and requires reinvesting effort in solving well-established problems (e.g., node discovery, time sync).

None of these alternatives provide the same combination of ecosystem alignment, reliability, and developer convenience that an officially managed libcanard component would offer.

Additional context.

Cyphal is rapidly gaining adoption in industries where ESP32 is already a popular choice, including:

• Small unmanned aerial vehicles (drones) for communication between flight controllers, sensors, and payloads.
• Ground robotics (rovers, AGVs) for coordinating motors, perception modules, and control systems.
• Industrial automation for real-time communication between edge devices and controllers.

By integrating libcanard, ESP-IDF would position itself as a first-class platform for these use cases, aligning with the growing demand for interoperable, safety-focused embedded systems.

The libcanard library is actively maintained by the OpenCyphal community, with a focus on compliance with the latest Cyphal specifications (e.g., version 1.0) and minimal resource usage—key traits that match ESP32's constraints (memory, processing power). This makes it an ideal fit for ESP-IDF's component ecosystem.

Finally, adding libcanard as a managed component would reduce the barrier to entry for new developers, enabling them to leverage ESP32's TWAI peripheral with a production-ready protocol stack in minutes rather than days.

[suda-morris]

Hi @Flexblue

Thank you for your support! Releasing libcanard to the IDF Registry is indeed a great suggestion!

May I ask what kind of application will you use ESP32 equipped with the Cyphal CAN protocol stack? How would you recommend us conduct testing?