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.
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.
I need to review more of the details here, but my first thought is to strongly suggest carrying support for both side-by-side (eg src/drivers/uavcan and src/drivers/uavcan-legacy) to allow phasing out v0 over time and not disrupt the existing users. For most boards the default configuration can afford the additional flash, and it won’t really matter for actual products that often disable everything they don’t use.
I am all for that! Do I understand it correctly that this is a tentative green light? Could you, perhaps, outline a threshold for us in terms of the ROM footprint that the dual-stack implementation should not exceed?
Unless there is a compelling reason to rip up what has taken 5 years to get too, I see zero justification for this move!
UAVCAN is something that we have been working on for over 6 years now, it has cost me, my company, the community 100’s of thousands of dollars in boards that turned to bricks because you kept changing your mind just before any project could take off!
Now that UAVCAN has actually taken off, you come up with this crazy plan to announce that all the work of heaps of people in the community, not just you, was some crazy experiment that you are going to scrap and destroy so that you can start from scratch yet again?
Why don’t you run off, and start phoenixCAN?
CubePilot will be continuing to build on 0.9, we will continue to fund the support of CAN in ardupilot, and continue to assist PX4 users of our hardware in this matter.
This is an insane move Pavel!
When this “Standard” fragments, you will only have yourself to blame!
Hey Philip, thanks for the feedback. I think the UAVCAN community agrees with you; we want to avoid fragmentation. The UAVCAN protocol needs the support of the community to prevent this.
The goals and justification behind v1 are mainly motivated by the demanding needs of the ecosystem, and the current UAVCAN implementing vendors. Pavel and Scott made an excellent summary here (Oct. 2018).
Pavel has a follow-up post (Jul 2nd) with a better context for the move and covers the benefits in full.
It’s been a long road to standardize behind v1, and there’s still lots to do. The team has a plan forward and would benefit from your support as an implementing vendor.
I think we (the UAVCAN team) understand your concerns, and we are willing to discuss how this move affects your hardware and, most importantly, how it benefits your customers. Let’s work together.
Today I have been chatting to the project leads of Ardupilot, and PX4 on Skype along with many of our competitors.
And from what came of those discussions, all agree on the need for arbitration messages support, and additional extensions to be added, as well as general improvements to the implementation.
What was absolutely shunned was any possibility of removing support for what is a trusted, and deployed standard in the industry.
There are no compelling arguments in any of those articles to remove support for 0.9
Not only that, but to even contemplate trying to add Ethernet of any sort into this is unjustified.
Rather than calling for the loyal community to work with you to break the standards, how about you and Pavel actually work with the PX4 project lead, and the Ardupilot Project lead, and build on the protocol? The community doesn’t want you to break 0.9
And we are rather annoyed with the public claim that this was all some kind of experiment!
I don’t think it’s going to be that difficult to keep both v0 and v1 side by side for as long as needed. The existing UAVCAN module in PX4 hasn’t had any major work since 2015/2016.
The original proposal was based on the assumption that supporting both v0 and v1 would be impossible due to ROM footprint limitations. Seeing as that assumption was incorrect, the revised plan is to keep v0 as-is and add v1 alongside it so that the damage to the ecosystem is minimized.