Servers by jDrones

UAVCAN v1.0 is here


UAVCAN was first announced six years ago, in early 2014, as an RFC doc published on 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:

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.

I would like to thank the ArduPilot community, especially @jpkh and @tridge, for being instrumental in the promotion of UAVCAN.


Thanks Pavel!
Do you have any numbers for flash size for a firmware that supports both v0 and v1 using libcanard?

I don’t have an exact number but my educated guess would be a dozen K, give or take, assuming an ARM CM target platform.

Thanks for the update Pavel. We’re going to be releasing a whole bunch of UAVCAN enabled products during this year including laser altimeters, sense-and-avoid Lidar, multi-beam Lidar and 3d mapping Lidar. We’re really looking forward to moving away from any dependance on I2C and other less-suitable protocols. :grinning:


Apart from the work to do the port, the biggest issue will probably be the bootloader. We’ll need a fw loading client that talks both v0 and v1 as current bootloaders for shipped boards are v0. The bootloader is very space constrained. We may need to leave it as v0 for a while and rely on clients being able to talk both v0 and v1.

After familiarising myself with v0 and v1, the things stopping me using v1 are:

  • uavcan_gui_tool is v0 only (and windows .exe are years old)
  • trying to install v1 python library ‘pyuavcan’ vs v0 library ‘uavcan’ failed for many reasons… like requiring python3.7 minimum (I use ubuntu18 stock 2.7 and 3.6)…
  • speaking of pyuavcan, it is documented as requiring to uninstall v0 before installing v1 despite different pip module names, and me having many scripts that need v0 and that I dont want to break…
  • and the ‘basic’ pyuavcan example on the v1 doc website is nearly 400lines! ( what happened to Hello World? I want a basic example to be 20 lines, and to send a packet and receive a packet, done)
  • all the CAN nodes in my office are v0, so I what’s the point ?
  • no dual-stack in Ardupilot, yet, if ever.
  • no MissionPlanner support.

Yes. We are building Yukon as a replacement. It is going to offer an improved UX and more advanced features compared to the old GUI tool. Given that, there are no plans to build v1 support into the old tool.

That’s because the example is intended to demonstrate all major library features and different transports, and also because much of these 400 lines are explanatory comments. You may also want to look at this, more hello-world-y kind of example; it is intended for use in Jupyter:

Do you know when you will have some UAVCAN altimeters ready for sale?

Hi Dave - the first UAVCAN altimeter will most likely be the LW24 shown below. All the dev work and testing is completed but there is a delay on tooling due to the epidemic. My guess is that it will be about three months before they start coming off the production line. Physically it is slightly larger than the LW20 and weighs 30g. Other preliminary specs for the LW24 are:

Comms - UAVCAN, serial,I2C and RS232 (optional)
Power - 5V to 24V DC
Range - 100m
Update rate - over 100 readings per second

1 Like

Very nice. I was about to order a sf11/c but then I saw that you were working on the new one, so I wasn’t sure which route I was going to take. It mainly had to do around pricing and availability

Servers by jDrones