can (2)

UAVCAN v1.0 is here


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.

Read more…


At mRobotics our commitment continues with the DIY community. From San Diego California we design and manufacture the necessary hardware to build platforms and solutions based on Ardupilot and PX4. And now we show you the next high-tech GPS that has build-in CAN, which includes many and special improvements to achieve maximum accuracy in positioning and guidance for safe navigation.

One of them is that we have incorporated the RM3100, a new Geomagnetic Sensor. Like a pair of glasses, the RM3100 Geomagnetic Sensor enables you to see magnetic fields clearly. 

The RM3100 Geomagnetic Sensor is the highest performance sensor in its class with over 10 times better resolution and over 20 times lower noise than the leading Hall Effect sensor. It makes precise magnetic field measurements, which enables accurate calculation of heading and orientation. The earth’s magnetic field provides absolute reference for heading measurements and accurate motion tracking. Geomagnetic sensors are used to measure the earth’s magnetic field; however, in real world conditions, the earth’s magnetic field is often distorted by other surrounding fields. System components such as batteries, shielding materials, or motors will distort the geomagnetic field near the sensors. An additional design challenge is the changing magnetic environment that temporarily distorts the field like metal parts in furniture, a passing car, or nearby cell phones and computers. Geomagnetic sensors must first be able to see the different magnetic fields in order for the designer to separate earth’s magnetic fields and compensate for the distortions. PNI Sensor’s RM3100 eliminates any “blur” in your magnetic field measurements making distortion error correction a snap, and ultimately allowing you to easily and accurately calculate absolute orientation and heading of a drone or vehicle.

I share a little information that Jordi Muñoz comments about the new "mRo Location One GPS" that we are coming soon to launch.

For more information or questions please feel free to write me directly at just mention me in the mail body ;) or follow us on our social networks at

Best regards!

Pedro Matabuena
mRo Director
Twitter: @pmatabuena

[Jordi Muñoz]

"Can you see the PCBs that are side by side? Can you spot the differences?

The one on the right is an early prototype, it has a lot of holes(vías) to "clamp" the ground plane. The one on the left is clean! Why? Well, we are experimenting (sorry for keeping all the engineering fun). The left one is a new concept that uses blind vías which are drilled by laser on the inner layers (4 in total). This allows us to have a very clean ground plane, which leaves the cooper of the first layer free of "artifacts", and the ground is attached around the antenna pin -The ground plane shape and dimension is a fundamental component of the patch antenna-, the idea is to create a more predictable behavior.
This new GPS is known as mRo Location One and has build-in CAN. It also has the new RM3100 compass, the only one currently working and supported by Ardupilot (via CAN), this mag has extreme performance and we salivate every time we fly with it. We also added a "bump" to all of our GPSs, the bump is the little piece of land on the front where the magneto resides, an attempt to keep it away from all disturbances and boost performance.
This module is ready for mass production and it will be released with the new uBlox M9N, which has true multiconstallation support and higher refresh rate.




Read more…