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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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).
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).
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.
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.
