Blogs

Greetings.

This is a cross-post from the ArduPilot blog.

UAVCAN was first announced six years ago, in early 2014, as an RFC doc published on this website. Over the following few years, it saw adoption in numerous systems – mostly UAV, naturally, but also including spacecraft, micromobility vehicles, and even racing cars. The vast empirical data collected from fielded systems over the years allowed us to identify the weak points in the design and eventually enabled us to come up with the rectified, field-proven stable design which we call UAVCAN v1.0.

The stable version was first announced about 18 months ago. Expectedly, the fact that v1.0 breaks wire compatibility with the original design based on that first RFC caused concern among the adopters. The resistance is understandable and we are certainly not blind to the costs of migrating the existing ecosystem to a different format, but we are confident that the costs are justified. This is because the design imperfections of v0 if left unrectified would be far costlier to the ecosystem in the long term than a breaking change introduced now.

The design issues of v0 that affect the UAV industry the most were neatly summarized by Tridge himself in a thread on the UAVCAN forum. As one can see from reading the thread, his input was incorporated into the v1 design. Specifically, that includes an improved approach to data type extensibility and versioning, and the ability to construct heterogeneous networks where the experimental v0 can co-exist with the stable UAVCAN v1.

While we are at it, I would like to quote myself from the thread on the necessity of the breaking change:

UAVCAN v1 is being deployed in highly complex vehicular applications where v0 could not be used due to its inherent limitations, only some of which were reviewed here. The most critical issue in v0 is the syntax-semantics entanglement, which by itself was an underlying cause for some other, more apparent issues, such as the over-specification of the standard data types. UAVCAN v0 is a great protocol for trivial UAV applications with unsophisticated hardware setups and straightforward design requirements, such as those that can be found in various basic industrial applications or hobby machines. The problem of v0 is that it breaks outside of that domain, and it is not possible to take v1 out of there without breaking backward compatibility. While the transition is painful, it is beneficial for everyone, especially the existing adopters of v0, because the much-improved architecture of v1 will increase the reach and coverage of its ecosystem, effectively increasing the available product options for integrators and at the same time increasing the reachable market for product manufacturers.

The improved ecosystem management policies and the new technical capabilities enable a very long design lifespan for v1 […]

Considering the state of the industry at large, one can see that v1 is a fundamental improvement over v0.

Having discussed and defined the design requirements, the last few months were spent updating the Specification and finalizing the reference implementation libraries. This work was completed just a few days ago, yielding the following results:

• Libcanard v1 – an updated version of the venerable Libcanard v0. It comes with 100% test coverage and a rigorous timing/resource utilization model for the benefit of high-integrity embedded systems.
• PyUAVCAN v1 – a redesigned from scratch version of the old PyUAVCAN v0 based on async API.
• The Crash Course, covering the basics and explaining the differences from v0.

I am happy to report that v1 is already here and one can build an actual v1 hardware node. I am hopeful that the ArduPilot community will find it just as useful as we do, and that it would find its way into AP_Periph as the default option along with v0.

While v1 is already usable, there is still some work to be done. We are grateful to NXP Semiconductors and other major adopters for helping us advance the project, but there is always more work than we can handle, so we can use all the help we can get. The current areas of focus are outlined in the recent UAVCAN Roadmap.

UAVCAN has been extensively validated in the field across many industries over the last six years, which gives us the confidence to state that the design lifespan of v1 should exceed at least a decade.