I agree with @Eosbandi; although as the original developer of UAVCAN, I am, obviously, heavily biased.
We spent a few years observing how UAVCAN is slowly gaining traction while collecting feedback, and now we’re using that experience to rectify certain design issues that are present in the current version of the protocol. In preparation for the first stable release (which we call UAVCAN v1.0), we are committed to fixing the existing high-level design issues that we were able to identify thanks to the extensive feedback we received (much of which came from the ArduPilot community, thank you):
- An overly restrictive and opinionated set of standard data types that forces one to build their systems in a very particular way.
- High resource utilization.
- Lack of support for other transports such as CAN FD.
- Poor support for vendor-specific and application-specific data types.
I suspect that some of these issues might have contributed to KDE Direct going their own way rather than adopting UAVCAN. We are open to their comments and opinions to try and make the standard more accommodating to other vendors.
Everyone is welcome to track our progress and contribute their opinions on the brand new UAVCAN discussion forum available at https://forum.uavcan.org. If you are not familiar with the ongoing work, then the following thread should be a good starting point: https://forum.uavcan.org/t/stockholm-summit-recap/170.
Thank you.