Just had a call with @TSC21, @PetervdPerk, @dagar where Nuno suggested that we describe the scope of the current effort on the forum so that we could use it as a guideline. This is the post for that. I suggest that we also use this thread for posting the notes from our weekly sync calls.
The text below is a slightly redacted excerpt from a statement of work that Zubax & Auterion have agreed upon. If you spot anything missing, please post a reply.
This document uses the term “master node” for conciseness. UAVCAN is a flat peer network that does not designate special function nodes; the terms used here are due to the specifics of the current PX4 architecture. We expect that the terms will become obsolete with the development of the distributed dPX4 architecture.
This effort is focused on providing the bare minimum functionality sufficient to gain the initial adoption, with the intention to enhance the functionality later incrementally while maintaining full backward compatibility with the first revision of the standard.
One important feature that will not be available in the first (MVP) published version of the standard is the full plug-and-play support. Providing this feature in the MVP standard is impractical because it requires implementing complex logic on the master side. The necessary behaviors will be introduced in a later revision of the standard; they will be entirely confined to the “master” side of the network, requiring no change in the other network participants. Products that comply with the MVP standard will be automatically PnP-capable at no additional cost for the manufacturer.
Technical objectives
UAVCAN references
The DS-015 standard will not attempt to redefine the services and functionality provided by the core UAVCAN specification.
The DS-015 standard will make the following features – optional per the UAVCAN specification – mandatory:
- The node info service:
uavcan.node.GetInfo. - The register service:
uavcan.register.Access,uavcan.register.List. - The software update service (bootloader protocol):
uavcan.node.ExecuteCommand,uavcan.file.*.
Domain-specific services
The domain-specific networked services provided by the standard will be architected according to the principles explained in the aforementioned Interface Design Guidelines.
The first version of the standard will define the following services only:
- ESC control and status reporting.
- Actuator control and status reporting.
- Air data computer interface.
- Battery management system interface.
The corresponding DSDL definitions will be developed on a feature branch at https://github.com/UAVCAN/public_regulated_data_types/ and merged into master upon completion. The DSDL definitions will not be included in the body of the standard document to avoid divergence.
The Kocherga bootloader
Kocherga is an MIT-licensed UAVCAN bootloader for deeply embedded systems that is architected to support UAVCAN via any of the standard and proposed transports, such as UAVCAN/CAN or UAVCAN/serial, and to be compatible with low-end baremetal MCU platforms that dedicate as little as 32 KiB of ROM for the bootloader. It is designed to support UAVCAN v1 as well as UAVCAN v0 with automatic protocol version detection.
Kocherga is intended to implement a UAVCAN-compliant brick proof update protocol that is robust against interruption, ensuring that the updated system can always recover itself from any process failure (excepting hardware failures) autonomously.
Kocherga is organized as a header-only library written in an embedded-friendly subset of C++17. The library implements the platform-agnostic functions of the bootloader such as the UAVCAN protocol state machine and pluggable transport implementations such as UAVCAN/CAN or UAVCAN/serial.
The library sources are continuously analyzed by two distinct static analyzers (Clang-Tidy and SonarQube) and are covered by unit tests to minimize the risk of unintended behaviors.
Kocherga ships a binary post-processing tool that accepts a compiled application firmware binary and extends it with the bootloader-specific metadata such as the ROM error detection code and version info.
At the moment, the library architecture is developed fully but the implementation and the test suite are incomplete. The core protocol state machine is not finalized and the pluggable transports are missing.
Application examples
Master node service consumers
A series of basic application examples should be provided on the PX4 side showcasing how to leverage UAVCAN-based distributed services. These would be essentially adapters, or glue logic, linking the networked services with the PX4 internals.
Specifically:
- ESC control with mixer integration (uORB status bridge integration is optional at this stage).
- Actuator control with mixer integration.
- Air data to uORB bridge.
- BMS to uORB bridge.
The listed items are application-level functions. Aside from those, it will be necessary to implement the following auxiliary system services to boot up the network:
- Plug-and-play node-ID allocation (but no automatic subject-ID assignment).
- Subject-ID configuration via PX4 configuration parameters.
We will limit our involvement to high-level guidance only.
Service provider nodes
The examples should be focused on CAN FD-capable embedded computing units, of which there are currently only two major offerings: the new NXP automotive series and the new SAM chips from Atmel. The NXP UCAN dev kit provides a virtually complete evaluation set for UAVCAN applications, so we will focus on it exclusively. We will advise the NXP team to ensure that their demo complies with the requirements set forth in the standard. The scope of our advice will be limited to the behaviors observable on the network; issues pertaining to software architecture, documentation, development tools, build system, etc. may be left unsupervised.
There exist specialized UAVCAN demoboards from mRobotics, RaccoonLab, BluCAN, and probably other vendors, but they are ill-suited for new designs due to being based on an outdated platform that does not support CAN FD and is not AEC-Q/ASIL-qualified.
Bootloader protocol
We will advise the PX4 team and the NXP team on the implementation of the bootloader both on the host side and on the client side. Since this topic will be explored in depth by the Kocherga integration documentation, this assistance will not require any significant commitment on our part.
Features intentionally left out from the MVP
The following features are considered vital but they are intentionally removed from the first revision of the standard to be introduced later:
- Full plug-and-play support (see Automatic configuration of port identifiers).
- MAVLink bridge for QGC integration. There is a MAVLink/UAVCAN interaction specification for UAVCAN v0, but it is not in active use at the moment. It will require an update.
- Core data types modeling common concepts such as geometry (pose, orientation, etc.) and physical states.
- Other standard services such as GNSS sensor status, optical flow sensor status, etc.
- Security facilitation services – key exchange, authentication, etc. These features may be implemented in the core UAVCAN standard as opposed to a domain-specific standard like DS-015.
- Hardware design recommendations (see Removal of the physical layer specification).
Shipping
The objective of this work is not only to define a standard but to enable the industry participants to build standard-compliant systems. This requirement implies that after the standard is completed, further work will be needed to turn it into a complete end-to-end solution. This is outlined in this section.
Adopter documentation
User documentation for developing DS-015-compliant systems will be provided on the UAVCAN forum as a sticked wiki post in the Drone SIG category. We anticipate that the first edition of the post will include only the following basic elements:
- A brief introduction into the standard, why it is important, and where to find it.
- Examples of compliant systems available on the market (the list is impractical to keep up-to-date, though).
- Step-by-step technical intro.
- Links to open-source references (e.g., NXP BMS 772)
PX4 user documentation
A new section under https://docs.px4.io/master/en/peripherals/ will be defined describing the UAVCAN-specific functionality of the autopilot. Aside from being a user guide for UAVCAN-specific functions, the section will also serve as an informal technical specification for vendors of UAVCAN peripherals. The section will contain the following subsections:
- Description of the UAVCAN initialization sequence (for users).
- Description of the UAVCAN CLI application – purpose and commands.
- The bootloading logic and related SD card file system organization.
- UAVCAN networked services (not to be called “peripherals”):
- ESC interface
- Actuator interface
- Air data computer interface
- BMS interface
The documentation will not provide detailed step-by-step guides. That can be added later by a third party, shall the need arise. The main objective here is to build the new documentation structure focused on UAVCAN v1.
This section requires tight collaboration with the PX4 documentation team (Hamish?).