uavcan-octocopter2

 

What is UAVCAN

UAVCAN is designed for highly-reliable, real-time intra vehicle networking. The protocol balances rich abstractions with determinism to support complex, software-defined vehicle systems while enabling standard analysis modalities used to validate safety critical systems. These objectives are reflected in the simple feature list at the start of each UAVCAN specification and have translated into a simple and robust design.

UAVCAN is comparable to CANaerospace or CANopen both in complexity and the availability of a formal specification, making it suitable for critical and real-time applications. The high-level communication semantics provided are stateless publish-and-subscribe and request-response. Due to this emphasis on statelessness and static configurations, UAVCAN is more appropriate for field applications and tangible products than research and experimental applications.

In V0 there was not much consideration given to customized solutions but in v1 this is a primary design input. V1 is designed to first allow rapid prototyping using datatypes that are highly generic but which may be unoptimized for a particular bus (i.e. for some systems use of discrete si values for all data interchange may result in considerable bus loads). v1 then encourages system designers to coalesce and further structure data interchanges into custom types as they solidify the functions on their system. These custom interfaces would, presumably, be highly optimized.

This leaves a third use-case that is still somewhat undefined in v1 which is the industry standard interface types similar to the types defined in v0. The plan is to develop profiles administered by the community that govern datatypes by industry segment. For example, the first profile would be largely similar to v0’s equipment types and would be specific to the px4/dronecode ecosystem. Similarly the UAVCAN development group would solicit industry input for profiles covering spacecraft, larger autonomous vehicles, industrial robotics, etc. As with ROS, the UAVCAN development community values networking and data interchange capabilities more than support for any one use case. In-fact, the lack of legacy from automotive applications is one of the benefits of this new technology over older ones.

UAVCAN uses DSDL (Data Structure Description Language) for the design specifications, which will be familiar to anyone who has designed ROS datatypes. An example of a design decision at transport layer that makes the protocol suitable for deterministic and real time systems would be: no arbitrary-size data structures are allowed, with the result that entities are to be defined with upper-size boundaries.

High quality, MIT-licensed reference implementations are available for UAVCAN. This frees developers from dealing with the protocol at an implementation level.

UAVCAN has decentralized node system that simplifies the failure mode analysis. Nodes share the bus and have equal rights on it. There are no required initialization sequences and nodes can come and go at any time without disruption to the system. This characteristic allows system designers to provide “plug and play” functionality where peripherals can be attached and detached from a vehicle bus without having to power it down or restart any software processes. . It is required that data frame delivery be assured in UAVCAN; this is considered as a design trade-off to keep the protocol simple. UAVCAN has proven to be a reliable protocol in low data latency applications and has attained performance levels comparable to low-level, specialized protocols like DShot.

UAVCAN can be implemented with a relatively low SLOC and its operational requirements are also very low. An example is the NicaDrone OpenGrab EPMv3 that runs a UAVCAN node on a low resource MCU using only 8K RAM and 32K ROM.

Evolution of UAVCAN

The first version of UAVCAN (labelled version 0) was developed and deployed on numerous vehicle systems and various other embedded and robotics applications and remains in use today. A new version of UAVCAN (labelled version 1) is currently under development which incorporates the lessons and experience gained through these deployments. This new version will add support for CAN-FD as part of its initial release and looks ahead to subsequent revisions which will enable the protocol to run over other communications mediums. This support for network types other than CAN bus will allow safety-critical systems to use UAVCAN v1 abstractions on top of heterogenously redundant busses.

At the time this article was published UAVCAN v1’s specification was nearing completion and new reference implementations were being actively developed by its open-source community.

The current version also supports research and experimental systems as well as low-demand deployments. This is done by making two definitions for the standard data types:

  • uavcan.si (international system of units) and
  • uavcan.primitive (arbitrary scalars and vectors)

These definitions allow UAVCAN application design without defining custom data types while supporting high-optimized, custom types to be authored for systems where this is required.  Introduction of data type versioning and deprecation of data type identifiers are other changes between the two versions of UAVCAN.

UAVCAN Integration

The open standard UAVCAN is publicly available on GitHub with MIT-license and adopters and integrators can freely access the reference implementations without any approval. Development from a prototype stage to production can be carried out without legal or procurement involvement. The obstacles for adopting UAVCAN is kept minimal by this type of open license and also by the support tools setup by the UAVCAN team such as documentation, open libraries, discussion forums etc.

From a technical perspective, the overhead is kept at a minimum and only a single function is required to implement – this is known as the Heartbeat Message that all nodes must publish. Most production deployments can be integrated with a small set of standard application functions such as the Heartbeat and uptime, diagnostics and data flow statistics, plug and play and node update over the data bus.

UAVCAN Future

The UAVCAN team aims to keep the protocol simple so as to minimize barriers in adoption and integration. Currently, the primary scope is safety-critical applications and UAVCAN is intended to be maintained with high quality software standards in order to meet the requirements of safety-critical application integrators.  The UAVCAN team is working toward achieving formal standardization of the protocol with two major field deployments. The UAVCAN organization encourages adopters to publicly acknowledge their reliance on the protocol as this will benefit the success and popularity of UAVCAN.  

References

https://forum.uavcan.org/t/uavcan-a-highly-dependable-publish-subscribe-protocol-for-real-time-intravehicular-networking/557