We are creating a battery monitor system that we already have working with UAVCAN v1. However, since Ardupilot uses UAVCAN v0, we want to make it work with that as well. The trick is, they use C++ headers generated using a custom Python script, and we would rather use plain C headers. So, I could use their DSDL file for the data type they use and compile it using the latest Nunavut version, but I’m worried about compatibility. Has much changed in the serialization algorithm since then, and if I serialize a message with my Nunavut-generated headers, will it be able to decode it on the other side?
Unfortunately, this is not going to work.
The optimal course of action is to approach the ArduPilot maintainers (@jani.hirvinen @tridge) and inform them that the ecosystem is converging on the stable version of UAVCAN, which is v1, and there is demand in having v1 supported.
Manufacturers should be targeting the stable protocol - v0 - as it’s supported by both key flight stacks, and is proven.
v1 will see a lot of churn as it’s rolled out as it’s basically untested. Pushing vendors to it prematurely is irresponsible and will harm the ecosystem.
V0 was never called “stable” but “experimental” instead: UAVCAN
It is now legacy and deprecated.
I agree with @pavel.kirienko, new hardware should support the V1 and existing hardware should be updated to support V1 as much as possible.
1 Like
not really. When originally announced what is now called v0 was supposed to be frozen in a stable release, all the way back in 2014.
This is from Pavel in August 2014:
UAVCAN is a lightweight protocol designed for highly reliable communication
in UAV and robotic applications via CAN bus. Its key features are the
following:
- Very low data overhead - which makes it suitable for high frequency
distributed control loops.- Democratic network - no single point of failure.
- Supports network-wide time synchronization with sub-millisecond
resolution.- Allows to efficiently exchange datagrams longer than can fit a single
CAN frame.- Publish/subscribe or request/response exchange patterns.
- Doubly-redundant or triply-redundant CAN bus support.
- Lightweight, easy to implement protocol (minimal sensor node can be
implemented in less than 300 lines of C99 http://uavcan.org/Examples).- Can be used in deeply embedded systems (the full featured reference
implementation in C++ runs on a 32K ROM, 8K RAM MCU).- The specification and the reference implementation are open and free
to use (MIT License).Half a year ago, UAVCAN RFC was first announced here:
http://diydrones.com/profiles/blogs/uavcan-can-bus-for-uav. Since then,
UAVCAN got a complete specification http://uavcan.org/UAVCAN_specification
and a full featured portable reference implementation in C++
http://uavcan.org/Libuavcan for Linux and embedded systems. It’s worth
noting that the list of officially supported embedded platforms includes
NXP LPC11C24 http://uavcan.org/Libuavcan_platform_documentation:_LPC11C24 - a
low-cost ARM Cortex-M0 MCU with an embedded CAN controller and a CAN
driver, i.e. a true single-chip solution for cost-efficient CAN bus
applications.Current release is a preliminary release, which means that some aspects of
the specification can be changed in a way that can break backward
compatibility. The specification and the standard data type set are
expected to be frozen by the end of 2014, which would make a final release.
Since the final release, standard data types won’t ever change at all, but
new types still can be added (it doesn’t break the backward compatibility).
Yes, but it never happened. Instead, we made v1 out of that. It does not mean that v0 was ever stable.