Is there a particular reason why canardRxAccept and rxSessionUpdate does not return the error codes which are the cause of the problem while in the code the cause is clear?
For example:
canardRxAccept
canard.c:1054 out = 0; // No matching subscription.
canard.c:1059 out = 0; // Mis-addressed frame (normally it should be filtered out by the hardware).
canard.c:1064 out = 0; // A non-UAVCAN/CAN input frame.
rxSessionUpdate
canard.c:835 if (correct_transport && correct_toggle && correct_tid)
There used to be a demo that with some effort could be compiled and executed. Is an akin demo that will work with v1? Will it be included as part of the socketcan tests?
Hi Hugo! There is no such thing at the moment, but we would welcome it emphatically if one created it independently (in a separate repo). At the moment all we have to offer in this sense is:
The demo given in the Libcanard README (it’s not a complete example but it’s better than nothing).
hey… I have created two example node repos (url upon request since the url might change). One node just listens to the heartbeat while another only produces a heatbeat. Next step for me is to create a template repo of a basic node project for vscode with the idea of slowly adding code to implement different sections of Chapter 5 of the UAVCAN Specification. I would like to petition that the code be part of the UAVCAN repo? If not I will be happy to host it at github. Please advise.
Our general unspoken policy was to keep only the core software components under the UAVCAN repo: implementation libraries, DSDL, the spec, core tools, the website, and such. We cut down even on the platform-specific drivers, removing the multiple repos and dumping everything into one place to keep the organization well-focused on the things of primary importance instead of some hardware-specific nuance. The story of examples is identical to that: we have separate v0 demos maintained by third parties (if you search the Web you will find many) but none by the dev team. I am inclined to keep it this way.
However, this is suboptimal in the sense of discoverability: unless you advertise your examples feverishly, people may fail to find them, and nobody would benefit. So I suggest that we set up a sticked wiki-post on this forum (in this very category because your demos are libcanard-based) that any regular visitor could edit to keep it up-to-date with links to existing demos, unofficial tutorials, and similar useful things out there. If you are okay with that, please go ahead and kickstart that wiki post here.
I think @aentinger and @TSC21 should be aware of this discussion.
Great work Easy compilable and executable examples will make it easier for any novice to tip their toes into UAVCAN development. Therefore I heartily endorse Pavel’s suggestion of setting up a sticky post gathering relevant code examples.
I believe 107-Arduino-UAVCAN, an Arduino library providing an abstract and simple to use UAVCAN interface, might also be a relevant entry to that example page. I’m not sure if you got to open such a page yet, since @pavel.kirienko is most familiar with this forum and it’s configuration I’d ask him to setup the page which then we can fill with content.
I will add them by the end of the week. Currently working on the platform-specific component(PSC) for Arduino AVR. I already have an .ino sending a heartbeat (turning on the LED too) using a timer interrupt on an Arduino Mega. . Going to use the " MCP_CAN Library for Arduino" by Corey Fowler (unless someone has a better suggestion?) in combination with code from the libcanard/socketcan PSC to produce a basic libcanard/avrcan PSC. I will also look at the avr driver from v0.
Thus having a C template project for Linux and a C template project for Arduino AVR.
Libcanard v1.0.0 is now (finally) available. The road from the first commit to the first stable release took about five years, so this is a major milestone for us.
Here is the migration guide from Libcanard v0.100 to the stable v1.0.0. It is super short:
Update your subject-ID idenfiers by clearing the two most significant bits. The maximum subject-ID was 32767 (15 bits), it was contracted down to 8191 (13 bits) in the Specification v1.0-beta. For example, the subject-ID of 32085 (0x7d55) would become 7509 (0x1d55). Notice that in many cases, this change does not really affect wire compatiblity between v0.100 and v1.0.0 (unless low subject-ID values are used) because the two removed bits are set to 1 when transmitting and ignored when receiving. This is now stabilized in Specification.
When creating new subscriptions, the parameter extent should contain the extent of the data type, not just the maximum size of the object. Here is the explanation from the docs:
The “extent” refers to the minimum amount of memory required to hold any serialized representation of any compatible version of the data type; or, in other words, it is the maximum possible size of received objects. This parameter is determined by the data type author at the data type definition time. It is typically larger than the maximum object size in order to allow the data type author to introduce more fields in the future versions of the type; for example, MyMessage.1.0 may have the maximum size of 100 bytes and the extent 200 bytes; a revised version MyMessage.1.1 may have the maximum size anywhere between 0 and 200 bytes. It is always safe to pick a larger value if not sure. You will find a more rigorous description in the UAVCAN Specification.
The tacit plan is to develop and release libuavcan before the end of next year with incremental functionality being released throughout the year. This is not a solid plan, however, and relies on finding additional contributors to collaborate on this effort.
Firstly a big thanks on your awesome work, developing and implementing the UAVCAN standard and now pushing it to v1.0.
My query on the above migration guide:
Setup: A dual-stack application. I have a set of ESCs using v0 libcanard and running on STM32G4 board. I’m trying to command them from a v1 libcanard publisher. The DSDL I’ve used is the one which worked with v0, but upgraded to v1.0 specification by
Included @extent in the DSDL file, and used Nunavut to generate appropriate serialization code.
Named the data-type identifier as an unregulated fixed-port type, in a different root namespace following v1 specification.
Questions:
Was hoping to get the reception of (v1) frames working on the ESCs as per the suggestion in the migration guide above i.e. changed the mask of MSG_FROM_TYPE_ID(x) from 0x7FFFU to 0x1FFFU (in v0 canard.c) to clear the most significant two-bits of the subject ID. Couldn’t get lucky with that; is there anything else I’m missing here? Would this dual-stack setup work?
Do I need to take care of the toggle-bit in (received) payload frames as touched upon here?
Side notes:
Was able to verify the reception (and decoding) of v1 Canard RX transfers using SocketCAN media-layer.
Updating the MSB bits as above on the ESCs having v0 libcanard didn’t seem to affect much, as they behaved as expected with v0-based commands sent from uavcan_gui_tool.
Nope. UAVCAN v0 and v1 can coexist on the same bus, but they cannot communicate with each other. UAVCAN v0 is no longer recommended for new designs; I strongly advise you to get in touch with your ESC vendor and ask them to support UAVCAN v1 natively.
I think this answer renders the other questions irrelevant. Feel free to point your vendor to this forum if they need help getting v1 supported.
Easy compilable and executable examples will make it easier for any novice to tip their toes into UAVCAN development. Therefore I heartily endorse Pavel’s suggestion of setting up a sticky post gathering relevant code examples.
I shall proceed to add a suitable post immediately.