CAN is an protocol used to send messages between computers. It's ubiquitous in cars and trucks, and is increasingly popular in small Unmanned Aerial Vehicles (UAVs), AKA drones. Here are some features that make it appealing:
This article doesn't go into details about the CAN spec; it focuses on applicability to UAVs.
Terminology note: A node refers to any CAN device. CAN nodes generally include a dedicated MCU (or other computer) that intermediates between one or more sensors, controllers (etc), and other devices on the bus. Nodes can exchange messages with each other in a peer-to-peer manner. The flight controller is a node, and so are all devices connected to it on the CAN bus.
CAN can be used to interface between a flight controller (FC) and different types of hardware. This includes sensors data, control commands, and system status. For example, these devices may be connected on the same CAN bus:
This list of CAN hardware shows an example of devices compatible with the Ardupilot flight-controller firmware. This PX4 documentation page describes CAN support in the PX4 firmware.
Using CAN allows simplified wiring. For example, a flight controller might expose one or more CAN ports. CAN nodes often have at least 2 ports to allow daisy-chaining. This can reduce the length of wiring compared to having every device connect to a flight controller directly. For example, if there are several sensors located at the front of an aircraft, a single set of 4 wires can be run from the flight controller to the front, powering and transmitting data to and from all devices in that area.
It's also easy to make a CAN hub; it's just a splitter.
The above is true for any bus. CAN is distinguished by combining being a bus, with differential voltages. For example, SPI is a bus, but is best suited for on-PCB-routing. RS485 is suitable for running wires outside the PCB, but isn't a bus.
CAN is well-suited to networks with many devices, due to its built-in deconfliction and message re-sending.
CAN devices on UAVs are usually connected using a 4-wire connector that includes a ground reference, power at voltages ranging from 5 to 30V, and the CAN high and CAN low differential signal wires. DroneCAN recommends the following connector standards, on their Hardware design recommendation page:
With all devices on the same bus, debugging and testing communication protocols and device status is simplified: A device that inspects the communications can be connected anywhere on the network, and all communication can be monitored. Ardupilot and PX4 can transmit this data over their USB port when plugged into a computer, using the Serial CAN interface.
Software like DroneCAN GUI can then display all CAN messages. Or, they can be monitored in Ardupilot's MissionPlanner software, or PX4's QGroundControl.
Here's an example of DroneCAN GUI:
There are 2 hardware variants of CAN: CAN-FD, and the original CAN. CAN-FD is a newer version that supports higher data rates, and larger frame sizes (larger payloads).
Original CAN supports up to 8-byte frames, and 1Mbit/s data rate. CAN-FD supports 64-byte frames, and 8Mbit/s data rate. Note that many tranceivers, including those on DroneCAN devices, are limited to lower speeds, like 5Mbps.
Original CAN and CAN FD devices can, in principle, exist on the same network. CAN FD's in arbitration process is limited to 1Mbps for compatibility, but can send and receives data at a higher rate.
When designing a new system, CAN-FD is a better choice. It's backwards-compatible, which helps integration with non-FD systems. This article contains a detailed comparison.
Of note, the STM32 series of microcontrollers is popular for both flight controllers, and CAN nodes across the UAV community. Older STM32s (Like F0, F4 etc) support original. New ones like G4, H5, and H7 support both.
CAN networks can simplify flight-control logic, and reduce flight-controller CPU load by offloading tasks to nodes. This is due to DroneCAN and Cyphal's standard APIs, and the microcontrollers built into each node.
For example, a node that includes a GNSS receiver, an IMU, and other sensors might provide fused position solution directly; it can read the sensors connected to them, perform sensor fusion, and send the completed computation on the CAN bus. This frees flight controllers from implementing this filtering, and frees its CPU to perform other tasks. This is a practical method of system concurrency, vice having the flight controller perform all computation and IO handling directly. Here are some cases where this approach shines:
For more info on the DroneCAN API, check out files in its DSDL repo here.
CAN architectures like DroneCAN allow for standardized system statuses. With any sensors, flight control firmware can implement system status checks, and adjust flight behavior, and display messages to operators as required. CAN networks can provide an abstraction over this. For example, all DroneCAN devices are required to regularly broadcast their status. This makes it easy for the flight controller to assess overall system status: The nodes perform their own diagnostics, and a missing status update could be an indicator of a problem. This can reduce the amount of status-checking code performed by flight control firmware.
In addition to system status, other metadata is specified to be reported as required, like number of messages transmitted or received.
The MCUs on CAN nodes output and receive serial data on a pair of wires, usually referenced between ground and 3.3V; this is similar to other protocols like UART, SPI, and I2C. These signals are routed as traces on the node's PCB. Bo fore leaving the node at its CAN connector, the signals connect to a CAN transceiver; this is a dedicated piece of hardware. Transceiver convert the signals to into differential signals, which are passed over the wires.
A node's communication speed may be limited by the capabilities of its transceiver. For example, The CAN-FD protocol is designed to work at speeds up to 8Mbits/s, and most MCUs are capable of this speed. However, many transceivers are limited to speeds of 5Mbits/s or slower.
Can device firmware can be updated over CAN itself, eg when using a bootloader designed for this like AP_Periph. This is convenient, as it allows updating all nodes from a single application, using the same interface they use for normal communication. Ie, USB isn't required.
There are two common communications protocols for UAVs (drones): Cyphal, and DroneCAN. These are higher-level protocols that exist as an abstraction over the CAN hardware and standards. Both DroneCAN and Cyphal split from an earlier project called UAVCAN.
These protocols serve several loosely-connected purposes: - They provide common APIs for a given class of peripheral. This allows for simplified flight-controller code, and easy interchange of hardware. DroneCAN's is the Device Structure Description Language (DSDL). Cyphals' is described in Chapter 3 of its specification.
They standardize metadata, encoded in both the CAN ID, and a tail byte embedded in the frame. This includes the type of message being sent, its priority, and other information. It also includes a standard way to split a payload into multiple frames, with error-checking.
They include the concept of a node ID that uniquely identifies a node on the bus. This is generally assigned by the flight controller.
CAN IDs include standardized message types, used for identifying the class of data the message contains.
They specify parameters to reduce risk of interference between devices on a bus.
They provide a standard way to update firmware, and configure node settings. This is implemented, for example, in the Mission Planner PC software. It allows all compatible nodes to be updated and configured in one place:
These higher-level layers on top of CAN define standards that allow nodes that comply with one to coexist on a bus with other nodes that comply. They're responsible for one of CAN's key features on UAVs: Interoperability of parts. This is what allows interchanging of devices with minimal configuration required.
Dronecan was created by Pavel Kirienko; it's currently maintained by others, as Pavel has switched his priorities to Cyphal.
DroneCAN has the following weaknesses that stem from its UAVCAN roots. The will, I hope, be fixed in the future:
Of note, DroneCAN maintainers have expressed that they will not address these, to maintain backwards compatibility. These limitations are transparent to users, but provide an obstacle for development and maintenance of node and flight-controller firmware. It provides inertia to developing new CAN devices, and may hinder ecosystem development.
Overall, it's clear that the DroneCAN protocol maintainers intend users to use libraries rather than implementing the protocol.
Cyphal's scope is beyond CAN, and has implementations on other protocols, including ethernet. It eschews the simplicity and plug-and-play capability of DroneCAN for more flexibility. It is currently only supported by the PX4 firmware, and there are few devices that support it.
Cyphal includes a detailed specification. Overall, writing firmware (for a flight controller or other node) that supports Cyphal is a daunting task, and setting up a system using Cyphal is complex.
