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