This post outlines the scope of the upcoming modifications to PX4 associated with the release of UAVCAN v1.0.
The plan is to replace UAVCAN v0 with v1 in PX4 v1.11, whose release is scheduled in March 2020. The work on the PX4 side will be led by Nuno Marques of dronesolutions.io. We will also be updating PX4 Sapog (which the Holybro’s Kotleta runs on) and all devices manufactured by Zubax to support UAVCAN v1. We are unlikely to have the bandwidth to directly contribute to other projects, such as VESC, but we certainly can dispense some helpful advice or maybe two.
Currently, the work is blocked by the ongoing development of Libuavcan v1, which is a v1-capable scratch rewrite of the old Libuavcan. The rewrite also brings a much cleaner architecture and native support for safety-critical applications through the extensive verification suite. Interested parties can follow the work on GitHub or they can send @scottdixon, who is doing this single-handedly, an encouraging PM or maybe two.
The scope of the PX4 modifications is not very extensive because we are not planning to introduce any new features, at least not yet. The intention is to merely migrate what we already have in v0 to v1 and discard some unneeded stuff while we are at it. There is no intention to support both v0 and v1 in the same build because both of the versions of Libuavcan are feature-rich and internally complex, which necessitates a large ROM footprint. We could, however, go back and review this decision if the PX4 maintainers greenlighted the hybrid v0/v1 stack to require ~50k of ROM (or maybe ~80k).
Roughly, the following updates are expected to take place on the PX4 side:
- The underlying implementation of the stack will be swapped from Libuavcan v0 to Libuavcan v1. The API of the new library is going to be different, also the new standard data types are syntactically different due to a sweeping refactoring, but the core semantics of the protocol did not change.
- The plug-and-play node-ID allocation protocol has been simplified drastically in v1; much of it will probably be implemented in Libuavcan, so the application will not be affected significantly (some hundreds LoC may need to be removed).
- The automated node enumeration feature will be removed (for unfamiliar: this is what allows one to assign the ESC indices by turning the props in the correct order). There is no counterpart for that in v1, at least not yet. This feature is considered to be of low importance.
- Obsolete examples (
src/drivers/uavcannode
,src/drivers/uavcanesc
) will be removed. - I am not sure whether it is necessary to update the old UAVCAN bootloader code to v1, considering that now we have a standalone dedicated MIT-licensed library for the same purpose: https://github.com/Zubax/kocherga. I am currently inclined to drop the old bootloader and direct users to the new library instead.
- Possibly refactor the implementation of the firmware update server which runs in a separate thread, depending on the resolution of https://github.com/UAVCAN/libuavcan/issues/268.
Despite the language used above implying that the planned work is strictly refactoring, it might actually be easier to rewrite the logic from scratch using the existing implementation as a reference. We will discuss and decide separately whether a clean-sheet approach is warranted.
Everyone involved with PX4 is welcome to submit feedback and proposals here.