For UAVCAN, 2019 is marked by rapidly growing adoption and significant advancement of the technological base of the project. Besides unmanned aircraft of all shapes and sizes that the protocol was originally proposed for, it is being successfully deployed in other types of innovative robotic and vehicular applications ranging from electric race cars to satellites. We are excited to see how our work helps teams manage the complexities of highly sophisticated distributed vehicular computing systems while ensuring functional safety and determinism.
The name UAVCAN stands for Uncomplicated Application-level Vehicular Communication And Networking. Those who are interested in why we chose this name will find the article (and the video) we published last July relevant: UAVCAN: a highly dependable publish-subscribe protocol for real-time intra-vehicular networking.
In a nutshell this article details the following story of UAVCAN’s development: Between its inception in 2014 and 2016, the protocol underwent several design iterations guided by the empirical feedback we were receiving from field deployments. The iterations were followed by a period of stabilization upon which we were able to collect sufficient empirical data not only from the field of UAVs but also from other domains where the protocol was found to be useful. By 2018, our newly obtained extensive practical experience, improved understanding of the trends in vehicular computing (occasionally we use the term “software-defined vehicles”), and the deep expertise generously supplied by some of the early adopters, allowed us to shape the final product – UAVCAN v1.0. The analysis and processing of this empirical data culminated in the conclusions and major design decisions made at the Stockholm Summit in late 2018. Based on the resolutions made at the summit, we immediately began work on the core specification and production-grade core components of the new v1.0 ecosystem.
An upgrade path to v1 that could retain backward compatibility with existing fielded systems running the old version of the protocol – which we call v0 – could not be formulated. While a breaking change is damaging to the ecosystem, we are confident that it is in the interest of the current and future users, because it enables the two updates to the design of the protocol that are critical for its long-term success: data type versioning and the removal of data type identifiers.
Data type versioning enables changes to released data types while ensuring backward compatibility and/or a well-defined migration path. It allows a complete vehicle system to evolve its parts incrementally and allows vendors to innovate without breaking compatibility with their existing install base. Lack of support for data type evolution would make the protocol risky to deploy at scale and could prevent its own advancement in the long term.
The removal of data type identifiers solves an architectural flaw of v0 where syntax and semantics of data are described by the same parameter. Such coupling is undesirable because it prevents the definition of generic, context-agnostic interfaces. This problem was addressed by replacing data type identifiers with a higher-level semantic identifier called port-ID, making the protocol’s communication model resemble conventional publish-subscribe frameworks.
The high-level outcome of the changes is that UAVCAN v1.0 is designed with scalability and long-term stability in mind. Thanks to the above described and other robust provisions built into the core specification, we intend to avoid future breaking changes that are as draconian as the current v0 to v1 change. Indeed, the difficulty of updating from v0 illustrates the issues specifically addressed by v1.0.
The early feedback we received from the adopters regarding the breakage shows that we may have under-informed them about the scope of the required changes to existing hardware and software, so let us clarify it in bullet points:
- No hardware changes are needed to migrate from v0 to v1.
- The software changes can be implemented by swapping v0 libraries with their v1 alternatives, with minor updates to the application logic to accommodate the changes in the architecture of the protocol:
- Replace data type identifiers with port-IDs.
- Switch to the new, simpler plug-and-play node-ID allocation protocol.
- Update some high-level standard data types.
- It is possible to support both v0 and v1 in the same device, provided that the integrator/user is able to specify which version of the protocol to use (e.g., by setting appropriate configuration parameters). We recommend that complex systems leveraging v0, such as UAV autopilots, add support for v1 alongside v0 and keep both for the duration of the transitory period.
- We are happy to assist vendors on the best approach to the migration. Feel free to contact us via the forum.
We are working on a comprehensive migration guide that will allow our existing adopters to have their systems migrated from v0 to v1 by following robust practical instructions.
The UAVCAN project is somewhat unique in its commitment to develop usable software while also defining and maintaining a stand-alone standard; the UAVCAN Specification. Because of this we believe the software we provide is a primary and tangible product of the project built not only to demonstrate but also as a standard of excellence.
The cornerstone piece of the emerging software suite is Libuavcan – a full-featured verifiable UAVCAN v1.0 implementation in C++11 for safety-critical real-time systems. The work is led by Scott Dixon (@scottdixon) of Amazon – a generous contributor to the project. We are on track to release an early production-grade version by Q1 2020, just in time for integration into PX4 v1.11.
Despite the paramount importance of Libuavcan, that product alone is not sufficient for the protocol to find widespread adoption. Complex deployments cannot be done without sophisticated diagnostic and debugging tools, which in turn are built on top of flexible protocol implementations with rich introspective capabilities. To this end, we have already released PyUAVCAN v0.4 – a full-featured implementation of UAVCAN v1 in Python for building diagnostic and debugging tools on top of. We are proud to report that this is the first implementation of v1 to reach release.
The third and last critical piece that is a prerequisite for completing the release of UAVCAN v1.0 is the graphical user interface. Seeing as UI/UX experts are somewhat underrepresented in our team, it should not be surprising that v0 was equipped with user software of questionable usability and quality:
On this end, we were unable to make much progress. We started Yukon – the new user application for building and debugging v1 networks – but the work stalled in its early days due to the departure of the lead developer.
The lack of a solid open-source tool maintained by the UAVCAN team slows down adoption. User software is the face of the project whose importance cannot be overstated. We believe that the availability of robust and dependable tooling is often the main driving factor behind one’s decision to adopt a technology, especially so in larger enterprises.
There is another, somewhat lower-level symptom of the problem which one can probably guess by looking at the following links, showcasing UAVCAN user interfaces built by vendors of UAVCAN equipment:
- VESC Tool
- Octanis Electron-CAN
- Hitec Servo GUI
- UAVCAN-Web
- (the list is certain to be incomplete, but it should make the point clear)
The common problem being that, while it’s great to have an assorted set of tools to choose from, much more could have been accomplished if there was a solid open-source solution available.
We have already drafted up a comprehensive work plan for the GUI effort, yet, our ability to execute it is hindered by the lack of human resources. To ensure the success of the project and to allow the core team to stretch the technological envelope further I would encourage adopters who build products and services based on UAVCAN to contribute in one of the following ways:
- Publicly acknowledge that your products and/or services are built on UAVCAN. Ideally, give us permission to put your logo on the front page (the reverse also helps).
- Dedicate engineering workforce. About 70% of our communication is entirely public, happening on the forum, on GitHub, and on the weekly dev call. Coordinating with us is easy.
- Sponsor an external contractor. There are excellent experts out there who can help you and the project by solving practical problems.
- Raise awareness.
The best entry point for initial coordination is the dev call (every Wednesday at 18:00 UTC); those who are based in a timezone that is not compatible with the call schedule are welcome to propose a new time for a second weekly call.
Currently we are maintaining a dedicated homepage for UAVCAN v1 at new.uavcan.org; the homepage is the most up-to-date collection of resources and materials concerning the project. The new prefix will be dropped as soon as the official release of v1 has taken place, which we expect to happen synchronously with the release of PX4 v1.11 in Q1 2020.
Looking into the far future beyond v1.0, we see several major directions the project is going to be evolving in:
- Support for other transports besides CAN. There is active research underway on using UAVCAN with Ethernet and other robust high-throughput transports for modern vehicular systems. This includes heterogeneous (dissimilar) transport redundancy that combines the advantages of wired and wireless links for ultra-reliable applications; the related theoretical base is outlined in the WAIC project.
- Increased quality bar. We are continuously working on increasing the quality and dependability of our open-source software, which forms a foundation for complex distributed vehicular systems to stand upon.
- Standardization. A major adopter has generously supplied the necessary resources and expertise to formally standardize UAVCAN. This work is on hold until we have collected sufficient empirical data from at least two major field deployments.