UAVCAN - Octocopter


An overview of UAVCAN

Ever since its release in 1986, CAN has been the popular choice for implementing inter-device communication in Automotive and other Industrial Automation areas. Originally meant for facilitating the mandatory OBD-II vehicle diagnostics standard in automotive industry, the CAN technology has advanced to the level of international standardization and is supporting highly robust, reliable, standardized and secure device communication in a wide variety of Industrial Areas. The CAN network protocols are standardized and there are lower-layer protocols like the ISO 11898 series and higher-layer protocols like CANopen, SAE J1939, MilCAN etc. These higher-layer protocols are developed over the basic CAN, by different manufacturers and organizations for usage in one or more specific industrial applications of their interest. For example, CANopen’s main application has been in automotive/automation and MilCAN’s in military and DeviceNet for industrial automation and so on.

The UAVCAN is another CAN based higher-layer lightweight protocol designed for reliable communication in aerospace and robotic applications via CAN bus. The UAVCAN Development Team is in charge of maintaining the protocol .specification and advancing it based on the industrial and adopter feedback.

The UAVCAN network is a decentralized peer network where each peer (node) has a unique numeric ID and has the same communication rights along with other nodes. This node ID is the only one parameter needs to be set for basic setup. This makes the UAVCAN, a democratic network without a master node and with no single point of failure. The peer-to-peer communication among nodes takes place using any of the following methods:

  • Message broadcasting –data exchange with Transmit and Register (publish/subscribe) semantics.
  • Service invocation – for facilitating peer-to-peer Request/Response communications.

Features and Pros of UAVCAN

One of the prominent advantages of UAVCAN over CAN is its design specification that facilitates “capability to exchange large data structures that cannot fit into a single CAN frame”. Coupled with this, the dynamic node ID allocation feature allows induction of any node into a CAN bus without manual configuration.

  1. Lightweight, deterministic and easy to implement network protocol.
  2. Democratic network with no master node and hence with no single point of failure.
  3. Large payloads (that could not fit into a single CAN frame) can be exchanged between nodes using automatic transfer decomposition and re-assembly at the protocol level in a UAVCAN network.
  4. Efficient network-wide time synchronization with microsecond precision that allows for high throughput low latency communication.
  5. Dynamic node ID allocation combined with automatic CAN bus bit rate detection makes it easy to implement nodes that can join any UAVCAN network without any manual configuration. These sorts of nodes are referred to as plug-and-play nodes.
  6. Supports double and triple modular redundant CAN bus.
  7. Can be used in deeply embedded, resource constrained, hard real-time systems like an autonomous unmanned vehicle system.
  8. Open and free to use (MIT License) specification and high quality reference implementations.

Cons of UAVCAN

The Core Design Goals for UAVCAN nodes and applications are meant to acquire all the required functionality and protocol specifications expecting from a UAVCAN network. These goals sometimes present restrictions and limitations for UAVCAN device and application development.

  1. UAVCAN nodes should provide automatic transfer decomposition and reassembly of long payload data frames at the protocol level itself. The UAVCAN application should not be left with this responsibility. This adds additional complexity in node programming.
  2. UAVCAN targets aerospace equipments where the communication involves high throughput low latency messaging and hard real-time control loops, device programming is challenging and require high level of expertise.
  3. Aviation vehicles like unmanned aerial vehicles (UAV) and drones are equipped with extremely resource-constrained microcontrollers and this imposes severe restrictions on the amount of logic needed to program the protocol.
  4. The D-Subminiature connectors are the largest connector type defined by UACAN. Its high size and weight may make it unsuitable for many aviation vehicular applications.
  5. The UAVCAN M8 connector may also be a poor fit for vehicles having space and weight constraints.
  6. The UAVCAN Micro Connector currently allows only board-level connections and no panel mounted options are available. Also no shielding is available for it and hence not suitable for safety-critical hardware.

Common Industrial Applications for UAVCAN

UAVCAN is mainly designed for aerospace and robotic applications. It is widely being used in autonomous unmanned aerial vehicle systems (UAV) such as drones, hex copters, fixed wing UAVs etc. The standard components of a UAV are:

  1. Hardware – the sensors, controller and output devices.
  2. Firmware – the code that runs on the controller.
  3. Software – the interface to the controller, also called as the Ground Control Station (GCS)

Following are some applications/projects that make use of UAVCAN:

  1. ArduPilot is an open source autopilot system supporting multi-copters, traditional helicopters, fixed wing aircraft and rovers. The ArduPilot firmware is integrated with different boards (hardware) to control unmanned vehicles of all types. ArduPilot uses CAN bus messaging in which HAL drivers are used for providing hardware CAN bus support and UAVCAN protocol handles all high level work.
  2. The open source Dronecode project hosted under the Linux Foundation provides a collaborative and shared platform for UAVs and is being utilized by various industries and companies for housing their UAV projects such as PX4, MAVLink, QGroundControl, etc. The platform provides all the needed components for a complete UAV solution including flight control hardware, autopilot software ground control station and programming APIs for customization and advanced use cases. UAVCAN is the integral part of the Dronecode core infrastructure, enabling it to achieve highly sophisticated and real-time messaging capabilities needed by any UAV platform.
  3. Orel 20 (Zubax Robotics) is a board-level BLDC (Brushless DC) motor controller used in propulsion systems of light unmanned aircraft and watercraft. It supports UAVCAN interface with optional dual redundancy to be connected with other needed components in setting up UAVs like quadcopters, drones, etc.
  4. Zubax GNSS 2 is a multipurpose high-performance board-level positioning module with compass and barometric altimeter for robots and unmanned vehicles. Along with other protocols, it also provides the UAVCAN (doubly redundant CAN bus) interface that offers capabilities like self diagnosis and failure detection.
  5. Babel from Zubax is an advanced USB-CAN and UART-CAN adapter that can be used either as a standalone tool or as an OEM component in larger systems. It is used as a diagnostic, monitoring and development tool for UAVCAN networks and also as a generic CAN/UAVCAN development board.




Node initialization

Does not need any specific initialization. A node starts functioning immediately upon powering up the bus.

Manual configuration

High level functions

Network discovery, node configuration, node firmware update, node status monitoring, network-wide time synchronization, dynamic node ID allocation

Manual node configuration, Firmware upgrade through CAN Bootloader.

Node status reporting

 A node must report its status and presence by broadcasting messages of type uavcan.protocol.NodeStatus

Status check through arbitration bit.

Time synchronization

Supports network-wide precise time synchronization with a resolution of up to 1 CAN bus bit period.

No separate clock signal to synchronize a node in the CAN bus. The CAN frame itself is used for synchronization.

File transfer

Yes. A node can access to the file system on remote nodes.

Dynamic node ID allocation

Yes, nodes can be added to the CAN bus at any time without manual configuration.

Manual configuration only?

Automatic CAN bus bit rate detection


No, manual only

Types of frames

  • Message frame
  • Anonymous message frame
  • Service frame
  • Data frame
  • Remote frame
  • Error frame
  • Overload frame

Communication methods

  1. Message broadcasting – for serialized data exchange
  2. Service invocation – peer-to-peer request/response interactions

Message based broadcasting.

Type of data (frame) transfers

  1. Single-frame transfer where data is entirely contained in a single CAN frame.
  2. Multi-frame transfer – transfer during which the payload is distributed over multiple CAN frames.

Single-frame transfer

CAN frame format

Only CAN 2.0B frame format (29-bit identifiers).

11-bit and 29-bit identifiers

Projects/Organizations/Companies associated with UAVCAN

  1. Zubax Robotics
  2. Pixhawk
  3. ArduPilot
  4. PX4
  5. DroneCode
  6. NicaDrone