Homepage GitHub

Arduino UAVCAN Library

Applications & Usage
#1

Hello,

As those of you which keep tabs on the Viper Quadcopter topic probably already know I’ve been working on libcanard-based Arduino library allowing the usage of the UAVCAN protocol via the Arduino platform. I’m happy to say this work has reached a stage where it can be presented to the wider public: 107-Arduino-UAVCAN. It’s currently only available via direct download from github but will be available shortly via the Library Manager.

A first idea on how to use the library can be gained from taking a look at the README of the repository. Examples demonstrating publishing and subscribing as well as service client/service server are available here. Taking a look at the test code compiled and executed upon every push to the repository gives further insight into the libraries usage and design philosophy.

Currently one message type (uavcan/node/Heartbeat.1.0) and one service type (/uavcan/node/ExecuteCommand.1.0) are available within the library although it should be fairly easy to add other types (and maybe this process can even be automated in some way? - that’s smth I’ve not looked at all yet).

Please keep in mind that this is an Arduino library and as such has been designed with simplicity in mind. Therefore certain choices where made that limit the power the programmer has compared to directly using libcanard without any abstraction layers. Nonetheless it should provide a smooth first start into the usage of UAVCAN without having to go through all the steps necessary with bringing any embedded project off the ground.

Edit: It’s now also available via Arduino IDE Library Manager.

2 Likes
Libcanard: Examples, Starters, Tutorials
#2

Hello :wave:
I’m looking at https://github.com/UAVCAN/public_regulated_data_types/blob/master/uavcan/node/430.GetInfo.1.0.uavcan#L41

uint64[<=1] software_image_crc

and I can’t help but wonder how an optional uint64_t would be serialised. Will it be prepended by an implicit length field that either says 0 or 8?

E.g. software_image_crc being encoded → 

uint8_t  | len                    | 8
uint64_t | software_image_crc_val | 0xDEADBEEFCAFE1337
/* Next entry ... */

or software_image_crc being NOT encoded → 

uint8_t | len | 0
/* Next entry ... */
#3

0 or 1 (section 3.7.4.2 Variable-length array types)

1 Like
#4

Good morning @pavel.kirienko :coffee:

Thank you for getting back to me. Now that you write it it’s obvious to me that a optional data field is just a special array case, that is an array with a length of zero. I was led astray by the fact that it’s not advertised as an array type but rather as a optional field that’s either there or not.

#5

But but, it is though: uint64[<=1] – that’s an array type.

#6

Version 1.0.2 has just been released. Major changes are the replacement of the self-coded serialisation/deserialisation logic by the one generated via nnvg as well as support for uavcan/node/Version.1.0 and uavcan/node/ID.1.0.

1 Like
#7

Version 1.0.3 has just been released. The API has changed so that the library is now directly fed with CanardFrame typed CAN frames. This change is precedented by the release of 107-Arduino-MCP2515:v1.2.0 which allows to directly send/receive CAN frames via MCP2515 and Arduino enabled boards.

1 Like
#8

Hello, thank you for this work it’s very useful. I have an simple question why does this work only for samd and mbed arduinoCore and not for classic Arduino Uno or nano ? CPU architecture, not powerfull enough, easier like that ?

#9

Thank you :sunny: It’s possible that the AVR based Arduino’s could run 107-Arduino-UAVCAN when considering raw computing and memory requirements. However, C++11 and STL support leaves much to be desired for on the AVR platform and while it should be possible to compile for AVR pulling in 3rd party libraries providing STL I wouldn’t want to bet on the performance.

1 Like
#10

Version 1.1.0 has just been released :rocket:

The most important change is that the library now supports UAVCAN v1.0-beta.

Thanks to @pavel.kirienko for not despairing over my numerous questions and continuous prodding on various issues :wink:

2 Likes
#11

Hello, I can’t seem to make your new example to work (UAVCAN-GNSS-Node). The UAVCAN-Heartbeat-Publish does not work for me either.

I use an Arduino nano 33 iot with a MCP2515 card (link). I can’t see the heartbeat node neither on QgroundControl (Pixhawk4 with PX4 v1.11) nor on UAVCAN GUI Tool (bluePill) but the Zubax GNSS node works on both.

Configuration tested:

  • Pixhawk→ZubaxGNSS→MPC2515(with 120ohm resistor) + Arduino_33_iot

  • UAVCAN_GUI_Tool (bluePill) → MPC2515(with 120ohm resistor) + Arduino_33_iot

  • Pixhawk → ZubaxGNSS → UAVCAN_GUI_Tool (bluePill)

  • Pixhawk → ZubaxGNSS → UAVCAN_GUI_Tool (bluePill) and the MPC2515(without 120ohm resistor) +Arduino_33_iot between GNSS and bluepill

With all these configurations Pixhawk, GNSS and UAVCAN_GUI_tool work fine but not one display the heartbeat node.

The pinout between arduino and MPC2515 :

arduino : MPC2515
D11 : SI
D12 : SO
D13 : SCK
D3 : CS
D7 : INT
and off course VCC and GND

Did I make a mistake in this configuration?

#12

This is because all of the other equipment you mentioned here runs UAVCAN v0. There is work underway to release preliminary UAVCAN v1 support (MVP) in PX4 in the very near future (I suspect it’s about a week away, but @TSC21 knows best). For now, please use the PyUAVCAN CLI for testing.

1 Like
#13

Hi :wave:

The pin-out looks very much correct, you can try and run MCP2515-Loopback on your Nano 33 IoT and check if you see the following output on your serial (timestamp may differ):

[ 4232231] ID 1 DATA[0] 
[ 4242479] ID 2 DATA[4] CA FE CA FE 
[ 4252705] ID 3 DATA[8] CA FE CA FE CA FE CA FE 
[ 4262682] ID 4 DATA[4] 21 0 0 EC 
[ 4272643] ID 7FF DATA[0] 
[ 4282847] ID(EXT) 80000000 DATA[0] 
[ 4292947] ID(EXT) 9FFFFFFF DATA[0]

Other than that I’ve got to confirm @pavel.kirienko’s assesment, that is that UAVCAN V1 is currently not supported my any tools except pyuavcan cli. In order to clarify this and safe future early adopters the trouble I’ve augmented the repositories README with a warning.

#14

@pavel.kirienko it is not a week away. There’s an identified need of properly define the network services.

#15

OK, MCP2515-Loopback is a good debugging tool, I found that the Arduino pin-out was not good, the nano_33_iot can’t use D7 with attachInterrupt() function. I changed it to the D9.

I hope we will be able to use it with PX4 soon.

Thanks to all 3 for your answers

1 Like
#16

For general information: I’ve created a separate github project in order to untangle the UAVCAN on Arduino effort from the Viper MAV project (so far only Viper MAV was pursued and tracked within the 107-systems github org).

#17

Version 1.2.0 has just been released :rocket:

There are loads of minor consolidating changes, however the most important change is that the library does now support ESP32.

2 Likes
#18

I’ve just released version 1.3.0 :rocket:

Nearly all UAVCAN DSDL types currently specified within UAVCAN/public_regulated_data_types are supported. The only ones missing are public_regulated_data_types/uavcan/si (also see #98).

Aside from this one, there are a couple of easy to tackle issues available: #92 and #99. Any help would be greatly appreciated :sparkling_heart:

1 Like
#19

107-Arduino-UAVCAN:v1.3.1, the Arduino library for UAVCAN has been released. Support for ESP32 has been fixed (didn’t compile, due to erroneous macro expansion).

1 Like
#20

107-Arduino-UAVCAN:v1.4.0 has just been released. Contains all DSDL types as per public_regulated_data_types@0a773b9 and does support the community contributed Raspberry Pi RP2040 core arduino-pico. This means the library can be run on any of the RP2040 based boards provided by this core.

@pavel.kirienko I see that public_regulated_data_types#125 eliminated /reg/drone. Please advise on whether or not to update the DSDL types within 107-Arduino-UAVCAN. I’d rather avoid reinstating reg/drone within a couple of months, so I’d prefer to keep them for now as is.

2 Likes