DroneCAN was created to continue the development of the widely used UAVCAN v0 protocol. This protocol has proven itself as robust and feature rich and has been widely deployed in the commercial drone industry and enjoys broad support among industry partners. The proposed introduction of the UAVCAN v1 protocol involved changes to UAVCAN that increased complexity and did not offer a smooth migration path for existing deployments. After extended discussions within the UAVCAN consortium it was decided that the best solution was to continue development of UAVCAN v0 under the name DroneCAN.
This article provides guidance to setup DroneCAN protocol on ArduPilot.
The physical CAN port, and its driver selected as DroneCAN protocol, should be enabled first. Please refer to the CAN Bus Setup
DroneCAN is a lightweight protocol designed for reliable communication in aerospace and robotic applications via CAN bus. The DroneCAN network is a decentralized peer network, where each peer (node) has a unique numeric identifier - node ID and that is only one parameter needs to be set for basic setup.
Detailed description of protocol can be found at https://uavcan.org/
DroneCAN Peripheral Types Supported¶
ArduPilot currently supports the following types of DroneCAN peripherals:
DroneCAN Adapter Node
DroneCAN device type is selected by:
GPS,Compass, Barometer, ADSB Receiver, LED, Buzzer, Safety Switch/LED, and Airspeed devices are automatically identified in the DroneCAN protocol
Power Module: BATT_MONITOR or
DroneCAN Setup Parameters¶
shown for the first DroneCAN driver, second driver has identical parameters
CAN_D1_PROTOCOL if set for DroneCAN(1) has the following associated parameters:
CAN_D1_UC_POOL: a memory pool for the driver of this size will be allocated if possible. The default size can usually be reduced, saving RAM for other functions and features, if the CAN traffic is light, as with GPSes or Compass, as opposed to ESCs.
DroneCAN Adapter Node¶
These devices are general purpose DroneCAN nodes with I/O ports that allow the attachment of non-DroneCAN ArduPilot peripherals to the DroneCAN bus via UART ports, I2C, SPI, and/or GPIOs. See DroneCAN Adapter Nodes.
DroneCAN ESC and Servo Configuration settings¶
See DroneCAN ESCs for information on DroneCAN ESCs.
Each DroneCAN ESC or Servo will have an programmed ID or channel address corresponding to the autopilot’s servo/motor output channel. These are set by switches on the ESC or via a setup/configuration program, depending on the ESC.
There are three parameters that determine which autopilot servo/motor channels are sent to the CAN ESC and/or Servos: For the examples below, the values are shown for CAN driver #1.
CAN_D1_UC_NODE - which is the node ID of the autopilot sending the commands to the ESCs so that there can be differentiation between multiple sources on the CAN bus
CAN_D1_UC_ESC_BM - bitmask that determines which autopilot servo/motor output signals are sent to the DroneCAN ESCs.
CAN_D1_UC_ESC_SRV - bitmask that determines which autopilot servo/motor output signals are sent to the Servos on DroneCAN Servos
In the bitmap masks, each bit position represents an ESC or servo ID number that the corresponding autopilot servo/motor channel command will be directed to. For example, 00001111 (15 decimal) would send commands to ESC or SERVO IDs 0 through 3.
When using DroneCAN ESCs/Servos, you can set the
SERVOx_FUNCTION for those, but still use those outputs on the autopilot for GPIOs using the SERVO_GPIO_MASK parameter. The autopilot outputs will become GPIOS and the corresponding
SERVOx_FUNCTION will be sent out DroneCAN.
To reduce bandwidth, the CAN_D1_UC_ESC_BM and CAN_D1_UC_ESC_SRV_BM params should be set to enable only the motor and servo channels you need CAN signals to be sent to. In addition, the CAN_D1_UC_ESC_OF parameter lets you further maximize bandwidth by offsetting the ESC position to the first time slots on the bus, eliminating empty time slots. For example, if the ESCs are on outputs 5 to 8, an offset of 4 will transport them in the first 4 timeslots which would otherwise be empty and consume bandwidth.
GPS configuration settings¶
If there is a DroneCAN GPS device, it has to be enabled in
subgroup of parameters.
TYPE parameter should be set to 9 for corresponding GPS receiver in autopilot.
DroneCAN LED configuration¶
DroneCAN Rangefinder configuration¶
RNGFNDx_TYPE = 24 to enable DroneCAN rangefinder type. Rangefinder data received over DroneCAN will only be used if the received sensor_id matches the parameter
RNGFNDx_ADDR. For AP_Periph firmware based adaptor nodes, this value is 0, so
RNGFNDx_ADDR must be set to 0. Other DroneCAN rangefinders may differ. See also DroneCAN Adaptor Node instructions.
DroneCAN Node ID Conflicts¶
When a device is attached and recognized, it’s node ID and hardware ID are entered into a database which is stored between power cycles. If multiple devices with the same node ID and different hardware IDs are used (swapping smart batteries, for example, with the same node ID), a conflict will arise in the database. This will require the use of the CAN_D1_UC_OPTION parameter to allow the database to be reset on the next boot, or conflicts in the database to be ignored.
CAN FD (Flexible Data rate)¶
If the DroneCAN port is attached to CAN FD peripherials, setting CAN_D1_UC_OPTION bit 2 (+ value 4) will enable this mode.
CAN FD requires a larger memory pool allocation than normal. Default is 24KB instead of the normal 12KB.
ArduPilot and DroneCAN provide a means to directly communicate with DroneCAN devices on the CAN BUS attached to the autopilot: SLCAN. Enabling SLCAN and communicating with the DroneCAN devices is dependent on the autopilot’s processor. F7/H7 processors use one method and F4, a different method.