UAVCAN v1.0 effort: Pyuavcan dev32 and Libcanard v0.2 were released today

Pyuavcan: https://github.com/UAVCAN/pyuavcan/releases/tag/1.0.0.dev32
Libcanard: https://github.com/UAVCAN/libcanard/releases/tag/v0.2
Also, an older release of libuavcan that marks the same milestone: https://github.com/UAVCAN/libuavcan/releases/tag/v1.0.0rc-last

These intermediate releases mark the point where we stop actively advancing the existing v0-compatible implementations, shifting the focus towards UAVCAN v1.0 - the first stable release of the specification. The main ideas behind UAVCAN v1.0 are outlined here: Stockholm Summit recap

1 Like

Will all pre 1.0 releases (pyuavcan, libuavcan, GUI tool etc.) still be available on github? If so, will it remain in same repo or be put elsewhere?

The intention is to keep them available where they are now.

1 Like

Is c++ 03 going to be abandoned?

Yes, the version of libuavcan that Scott is currently working on requires at least C++11.

1 Like

Okay this is good news.

I finished work in the transmit queue and tests pass for the avl tree and the other systems. QoS changes (on tests) need review from your part, so the tree gets merged and then the QoS api signature and types gets removed I guess.

Can we add nodes to the spec?

David, not sure what you mean. Could you elaborate, please?

I’d like to develop a UAVCAN enabled OSD. I want to avoid using a UART tunnel and instead define a set of CAN messages the just carry the necessary info. So, for example, there’s an ESC node. I want a telemetry set of UAVCAN messages. Does that make sense?

1 Like

Yes. You can just define your own messages and services for that, and then make them publicly available for reuse by users of your equipment. In UAVCAN v1.0, we chose to avoid defining any application-specific data types within the standard, delegating that to vendors (users) instead.

OK. I understand that. So answer this then. Where is the manner in which an ESC node or a GPS node communicates? Where is the definition of node specific message then?

There are two major approaches: some basic functionality can be interfaced using the SI or primitive types (defined in the namespaces uavcan.si and uavcan.primitive). For example, one could command an array of ESC by publishing uavcan.primitive.array.Natural8, or one ESC by publishing, for example, uavcan.si.angular_velocity.Scalar. An ESC can report its status to the bus by either publishing separate SI messages, like uavcan.si.electric_current.Scalar, uavcan.si.angular_velocity.Scalar, etc, or by publishing a vendor-specific status message (or both, for extra compatibility).

A GNSS receiver node is unlikely to benefit from SI or primitive types due to the complex nature of the output; hence, it makes sense to use a vendor-specific message (possibly based on the legacy uavcan.equipment.gnss.Fix2), optionally providing some very minimal degree of service via SI/primitive types.

There currently are none of the vendor-specific messages you are inquiring about, but I intend to publish a GNSS fix message as a starting point and a reference for future contributions once we’ve finished with the v1.0 spec draft. As explained earlier, this message will not be included in the uavcan namespace; rather, it will likely be located under a different namespace named after a company (zubax), but the MIT license will permit its unconstrained reuse in third-party applications, obviously. The idea is that other vendors will be contributing their data types in a similar fashion under the MIT license. It obviously is also possible to define private data types for internal use; the details are explained in the specification draft.

You can find the draft here: http://new.uavcan.org/specification (this is a temporary location while we’re working on the new website); chapter 2 and section 5.2.6 should be of particular interest here.

Hope this helps!

I believe in not reinventing the wheel. The “standard” for location data already exists in SAE J1939-71 Vehicle Application Layer . Why not use what’s being used in motor vehicles?

The short answer is that the approach taken by J1939 and likewise standards (aimed at legacy motor applications or industrial systems) is unfit for the types of applications targeted by UAVCAN. You may notice that they are being augmented, and at some point will be replaced, by more capable data exchange systems (e.g. SOME/IP, AFDX), because such legacy protocols are unable to meet the data exchange demands of modern systems. This is somewhat covered in this long post here (not in-depth, unfortunately; I may prepare another post focusing on our motivation at some point later): Alternative transport protocols.

1 Like

Thanks for the clarification