Configuring Ardupilot for UAVCAN

I thought I would add to the UAVCAN article I just posted a note on configuring UAVCAN in Ardupilot. I have built a UAVCAN quad and it is so cool because there are only three connections to the flight controller. Power, CANbus and RCin are all that is required! The UC4H GPS/MAG adapted HERE GNSS, the 4 Zubax ESCs are connected UAVCAN and OlliW’s UAVCAN Powerbrick are all daisy-chained together on the CANbus network.

I used Arducopter 3.6dev because it has revised and more consistent UAVCAN parameters.

First we need to turn UAVCAN on.
In the advanced parameters you will find the CAN tree. Expand that and you will see:

UAVCAN is capable of fully redundant wiring. A significant step toward greater reliability. You will see two sets of parameters for a CANbus 1 and a CANbus 2. I am using only CANbus 1 for simplicity here. CANbus in the Arudpilot firmware is designed to support multiple CANbus implementations so we first set the protocol to UAVCAN.
next we select the driver

Thanks to EShanaev for clarifying the documentation.
Arducopter is setup to handle multiple CANbus implementations so the CAN_P parameters are designed to control parameters needed for the physical transport aspects of CANbus and the CAN_D are designed to handle the protocol level features. So we see that CAN_P1_driver turns on the CANbus ports. The CAN_P1_BITRATE controls the speed of the CANbus interface. While the CAN_D1_PROTOCOL chooses the CANbus implementation as UAVCAN and CAN_D1_UC parameters control features specific to UAVCAN vs say KDECAN.

Now we have to reboot. The number of CAN parameters visible will increase once CANbus is enabled.

Next we see
This is a bitmap mask, each position in the binary number represents an ESC to be turned on or off. In my case, of a quad, I have four ESCs, hence 0000 1111 =15. The positions are relative to the ESC index, with the first binary position (the “1” furthest to the right in this binary number 0000 1111) representing esc_index=0. Next position, the second “1” from the right, represents esc_index=1. So for an Arducopter Quad the esc_index=0 is the front right motor and esc_index=1 is the back left motor and so forth.
You enable each ESC individually this way.

If you remember from the UAVCAN article this is a network of devices called nodes and each node on the bus must have a unique number assigned. The default for the Arducopter flight controller is 10 but that is an arbitrary assignment and you can use any number scheme you like as long as each node has a unique number on the bus.

LIke the ESC bitmask the servo bitmask enables servos on the bus. I have none so 0 disables all servo messages.

The CANbus is a serial bus and this parameter sets the “baud rate” at a million. Fast!

CAN_P1_DEBUG=1 sets the level of debug messages on the bus.

CAN_P1_DRIVER=1 turns on CANbus 1

There is a complete duplicate of these parameters for CAN_D2 if you are using both buses.

Lastly, we set the GPS type parameter to indicate we are using a CANbus GPS.

Pretty slick, eh? Three connections to the flight controller and one cable type and connector for all the other CANbus devices. Try it, you’ll like it. :slight_smile:

Straight off the build, no tuning, stabilize mode:


@mike Thank you a lot for a great post!

1 Like

It has been a great learning experience.

Can you tell me what the CAN_P1 parameters are used for, like CAN_P1_UC_PROTOCOL=
As in my image above I would expect CAN_D1_PROTOCOL and CAN_D1_DRIVER not a mixture of CAN_D1_PROTOCOL and CAN_P1_DRIVER when CAN_D1_DRIVER exists in the documentation.


1 Like

Actually that’s a bug in autogenerating of parameter list for wiki.

CAN_PX_ group are physical port settings with CAN_P1_DRIVER being a link to the driver that this port uses.
CAN_DX_ group are settings for protocol itself, with CAN_DX_UC_ being settings for UAVCAN.

As you pointed out, the ports can have connection to different drivers or to the same one for redundancy.

1 Like

Great, thanks very much. That makes sense.

1 Like

I wonder, does the current mechanism also allow running UAVCAN and a 11bit protocol at the same time on one bus (which would probably imply two drivers for one bus)? The UAVCAN pages explicitly mention that scenario.

1 Like

What is explicitly mentioned in documentation is that if there are other devices comunicating with CAN 2.0A then UAVCAN can live with the presence of their communication.
Two drivers for one bus obviously will not work in current code.

1 Like

well, I think it wouldn’t/shouldn’t be really difficult to extend the mechanism to allow to register a driver for 29bit and one for 11bit. In the low level driver it would be just a case testing if it is 29bit or 11bit for calling the appropriate driver … the libcanard is made such that it can be used for 29bit and 11bit, so I would be surprised if this wouldn’t be so for libuavcan too. Just thinking about Code Bounty for DJI CANBus.
Anyway, you answered my question :slight_smile: Thx.

Now, the port driver (interface) supports both 29 and 11 bit.
So the issue is to separate the data flow and send 11 bit not to UAVCAN (or other 29 bit driver) but to other driver which accepts 11 bit.

Hello,thank u for your sharing.I am a new man for UAVCAN ,and I have some problem about how does the Ardupilot node broadcast its message in the APM program. now I can open the CAN port and make my PC receive some 1HZ data through a CAN-USB equipment from my pixhawk.what should I do to continue my study.THANK U!

How about making a CANbus SLCAN to see messages on the bus? or an adapter for I2C M8N GPS to work UAVCAN?

I have used my own can adapter to see the message on the can bus ,and there’s some data .But What I want to know is the method to make my Pixhawk send a message which is defined by me.


Work through what @kd0aij is doing here:
and here:

Also the UAVCAN specifications and examples are on Especially Libcanard,

The bug was fixed. Parameter list in wiki is OK now.

Thanks very much for putting this together Mike! And to all the devs working on CAN! I am sure this will save MANY people a lot of work. Including me in the future.

I’ll put this on the test list for the dev frame for 2018.

I am enthusiastic Coby because I think it offers so much to Ardupilot users.

  1. Simpler, cleaner more reliable wiring with the same standardized connectors for all components.
  2. Possible for a totally redundant wiring scheme.
  3. An integrated troubleshooting tool that can “see” whats going on, even with a fully assembled aircraft without taking it apart.

Agree on all points. Will be really nice when we have CAN everywhere (or as much as makes sense).

Sorry, lazy question, but will we be able to run one bus for sensors and one for actuators (servos, ESC’s)?

There really is no need to use the two buses that way. Remember CANbus devices are smart devices. So the bus is equal opportunity. The second bus is designed for redundancy. Which means you can have two devices with one being the backup for the primary.

OK. Look forward to seeing how this all goes. Have some friends who design/build a commercial product that separates the buses between actuators and sensors. My understanding is it was for possible noise on the actuator bus but I have no idea if that’s really required.