Configuring Ardupilot for UAVCAN

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.

The bus carries CANbus messages not analog data. So it should not matter what is on the bus. The surges caused by strong currents in the actuators should be entirely isolated from the CANbus.

1 Like

It is possible to separate traffic between buses.
Current implementation supports both separation and redundancy.
There is sense in both approaches depending on the application.

1 Like