UAVCAN

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
UAVCAN
UAVCAN logo.png
UAVCAN GUI tool screenshot.png
Developer(s)Zubax Robotics / UAVCAN Consortium[1]
Initial release2014
Repositoryhttps://github.com/UAVCAN
Written inC++, C, Python, Rust, JavaScript
Operating systemCross-platform
LicenseMIT license
Websiteuavcan.org

UAVCAN (Uncomplicated Application-level Vehicular Computing and Networking) is a lightweight protocol designed for reliable intra-vehicle communications using various communications transports, originally destined for CAN bus[2] but targeting various network types in subsequent revisions.[3]

History[edit]

The first RFC broadly outlining the general ideas that would later form the core design principles of UAVCAN was published in early 2014.[4] It was a response to the perceived lack of adequate technology that could facilitate robust real-time intra-vehicular data exchange between distributed components of modern intelligent vehicles (primarily unmanned aircraft).

Since the original RFC, the protocol has been through three major design iterations, which culminated in the release of the first long-term stable revision in 2020 (6 years later) labelled UAVCAN v1.0. In the meantime, the protocol has been deployed in numerous diverse systems including unmanned aerial vehicles,[5][6] spacecraft,[7] underwater robots,[8] racing cars,[9] general robotic systems,[10] and micro mobility vehicles.[11]

UAVCAN v1.0 is positioned by its developers as a highly deterministic, safety-oriented alternative to high-level publish-subscribe frameworks such as DDS or the computation graph of ROS, which is sufficiently compact and simple to be usable in deeply embedded high-integrity applications.[12] UAVCAN has been shown to be usable with bare metal microcontrollers equipped with as little as 32K ROM and 8K RAM.[13]

The protocol is open and can be reused freely without approval or licensing fees. The development of the core standard and its reference implementations is conducted in an open manner, coordinated via the public discussion forum.[14] The project is funded through annual membership fees submitted by the members of the UAVCAN Consortium[1] and voluntary contributions from the adopters. As of 2020, the project is supported by several major organizations including NXP Semiconductors[15] and the Dronecode Project.[16]

Design[edit]

UAVCAN provides zero-cost abstractions that are approachable and familiar to software engineers[17] without compromising on functional safety and determinism.[3] As a new technology, it is unencumbered by legacy[3] and borrows heavily from recent developments in the field of general information technology.[18] The protocol offers a stateless publish-subscribe communication model where a node can begin operation immediately upon connection to the network to accommodate high-integrity applications.[12]

The protocol has two clearly separated major components:[19] the transport layer that works on top of reliable vehicular networks such as Ethernet or CAN FD, and the transport-agnostic presentation (serialization) layer based on the so-called Data Structure Description Language (DSDL). The protocol has been shown to be implementable in less than 1000 logical lines of code.[20]

DSDL is ideologically similar to the interface description language used in ROS, except that it introduces additional static constraints in order to render the solution suitable for real-time high-integrity embedded systems. The similarity prompted some developers to interface ROS with UAVCAN using automated translation layers.[10]

Core principles[edit]

The protocol is built around the following core design principles that are intended to ensure that the solution is well-suited for modern complex safety-critical vehicular systems.

  • Democratic network — There is no master node. All nodes in the network have the same communication rights; there should be no single point of failure.
  • Facilitation of functional safety — UAVCAN system designers have the necessary guarantees and tools at their disposal to analyze the system and ensure its correct behavior.
  • High-level communication abstractions — The protocol supports publish/subscribe and remote procedure call communication semantics with statically defined and statically verified data types (schema). The data types used for communication are defined in a clear and platform-agnostic way, that can be easily understood by both machines and humans.
  • Facilitation of cross-vendor interoperability — UAVCAN provides a common foundation that different vendors can build upon to ensure that their equipment is interoperable. UAVCAN provides a generic set of standard application-agnostic communication data types.
  • Well-defined generic high-level functions — UAVCAN defines standard services and messages for common high-level functions, such as: network discovery, node configuration, node software update, node status monitoring, network-wide time synchronization, plug-and-play node support, etc.
  • Atomic data abstractions — Nodes are able to exchange large data structures that exceed the capacity of a single transport frame. UAVCAN performs automatic data decomposition and reassembly at the protocol level, hiding the related complexity from the application.
  • High throughput, low latency, determinism — UAVCAN adds very low overhead to the underlying transport protocol, which ensures high throughput and low latency. This makes UAVCAN well-suited for hard real-time applications.
  • Support for redundant interfaces and redundant nodes — UAVCAN is suitable for applications that require modular redundancy.
  • Simple logic, low computational requirements — UAVCAN targets a wide variety of embedded systems, from high-performance on-board computers, to extremely resource-constrained microcontrollers. It is inexpensive to support in terms of computing power and engineering hours, and advanced features can be implemented incrementally as needed.
  • Rich data type and interface abstractions — An interface description language is a core part of the technology, allowing deeply embedded subsystems to interface with higher-level systems directly (and in a maintainable manner), while enabling simulation and functional testing.
  • Support for various transport protocols — UAVCAN is usable with several different transports, and can be extended to support other transport protocols in the future.
  • API-agnostic standard — Unlike some other networking standards, UAVCAN does not attempt to describe the application program interface (API). Any details that do not affect the behavior of an implementation observable by other participants of the network are outside of the scope of the specification.
  • Open specification and reference implementations — The UAVCAN specification is, and will always be, open and free to use for everyone. The reference implementations are distributed under the terms of the permissive MIT License or released into the public domain.

Transport layer[edit]

UAVCAN/CAN[edit]

The CAN transport is built on top of CAN and CAN FD using 29-bit identifiers. The CAN payload includes a fixed-size overhead of one byte per frame for the needs of the transport layer.[19]

UAVCAN/UDP[edit]

The UAVCAN/UDP transport has been proposed for real-time Ethernet-based vehicular networks. The design is said to be influenced by AFDX, DDS/RTPS, and SOME/IP.[18]

Standard data types[edit]

Like other similar technologies, UAVCAN provides a library of common data types, managed and curated by the protocol maintainers, that are intended to address certain common issues in popular applications.[21] These data types supplement vendor-specific or application-specific data types defined by adopters, much like a programming language would normally define a standard library to be relied upon by software developed by the user. The protocol specification provides a set of rules intended to avoid conflicts and enhance interoperability of data types defined by independent vendors.[22]

External links[edit]

References[edit]

  1. ^ a b https://uavcan.org/consortium
  2. ^ "About UAVCAN". Retrieved 28 Feb 2020.
  3. ^ a b c "UAVCAN - Kvaser - Advanced CAN Solutions". Retrieved 16 October 2019.
  4. ^ "Drones discuss | UAVCAN - CAN bus for UAV". groups.google.com/forum/#!topic/drones-discuss. Retrieved 2020-02-27.
  5. ^ Meier, Lorenz (2017). Dynamic Robot Architecture for Robust Realtime Computer Vision (Thesis). ETH Zurich. doi:10.3929/ethz-a-010874068.
  6. ^ "ArduPilot Developer | CAN bus and UAVCAN protocol". ardupilot.org. Retrieved 2020-02-27.
  7. ^ Losekamm, Martin; Milde, Michael; Poschl, Thomas; Greenwald, David; Paul, Stephan (2016). Real-Time Omnidirectional Radiation Monitoring on Spacecraft (paper). doi:10.2514/6.2016-5532.
  8. ^ Bhat, Sriharsha; Stenius, Ivan; Bore, Nils; Severholt, Josefine; Ljung, Carl; Torroba Balmori, Ignacio (2019). "Towards a Cyber-Physical System for Hydrobatic AUVs". OCEANS 2019 - Marseille. pp. 1–7. doi:10.1109/OCEANSE.2019.8867392. ISBN 978-1-7281-1450-7.
  9. ^ http://robotek.no/filer/dokumenter/Revolve-NTNU.pdf
  10. ^ a b "GitHub - MonashUAS/Canros: UAVCAN to ROS interface".
  11. ^ https://www.electric-skateboard.builders/t/all-new-2019-vesc-tool-release/83619
  12. ^ a b https://forum.uavcan.org/t/uavcan-a-highly-dependable-publish-subscribe-protocol-for-real-time-intravehicular-networking/557
  13. ^ https://diydrones.com/profiles/blogs/new-opengrab-epm-v3-for-uav-cargo-holding
  14. ^ https://forum.uavcan.org/
  15. ^ https://community.nxp.com/docs/DOC-345215
  16. ^ "Dronecode | Leading open-source components for UAVs". www.dronecode.org. Retrieved 2020-02-27.
  17. ^ http://www.olliw.eu/2017/uavcan-for-hobbyists/
  18. ^ a b https://forum.uavcan.org/t/alternative-transport-protocols/324
  19. ^ a b https://uavcan.org/specification
  20. ^ https://github.com/UAVCAN/libcanard
  21. ^ https://github.com/UAVCAN/public_regulated_data_types
  22. ^ https://forum.uavcan.org/t/data-type-regulation-policy-and-membership-fees/707