Homepage GitHub

Arduino UAVCAN Library

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.

1 Like

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 ... */

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

1 Like

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.

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

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

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

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 ?

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

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

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?

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

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.