@tridge CUAV supports your suggestions and thank you for your efforts to prevent uavcan from generating more forks. As a hardware manufacturer, we are very troubled by the difference in standards. There are already many uavcan devices on the market, and uavcan is still discussing protocol compatibility (V1 and v0). The standard has fallen far behind the product, and v1 and v0 are not compatible, which will force hardware manufacturers to abandon uavcan 1.0. Switch to other can protocols; although our hardware supports FD_CAN; but we should avoid occupying too much CAN bandwidth; because it is a trend to use can to replace traditional interfaces, including can ESC, can airspeed, and can smart battery.
1 Like
Thank you everyone for the criticism. Based on the extensive feedback accumulated here, we have resolved to cancel the DS-015 project and start a new application-layer standard on top of UAVCAN v1.0 under the exclusive governance of the UAVCAN Consortium. The Consortium is ideally positioned to provide a neutral ground for its members to collaborate on the standard.
I am going to formulate a more detailed proposal and share it with the key stakeholders privately to secure initial alignment. A public announcement will follow.
4 Likes
I’ve been following the conversation here over the last few days and I can see that there is a very high level of energy and commitment to create a standard - otherwise the debate wouldn’t be this intense. I personally believe that simplicity is key for adoption (and for keeping things maintainable) and so having messages that you can wrap your head around within seconds instead of minutes is essential.
Back when we started DS-015 the UAVCAN consortium didn’t exist formally and in today’s world it seems to be the kind of neutral ground that can enable wider collaboration, so I wholeheartedly believe that creating a fresh, new effort here would be a good thing for the industry.
Completely resetting the effort seems fair as it originally started with message definitions that were not too far away from what v0 is carrying but with some cleanups - and coming back to this spirit seems like a consensus everyone could potentially agree on.
10 Likes
This topic has been closed, but @pavel.kirienko has suggested I post a final message.
We need a replacement for DS-015, one that meets the requirements for an efficient, reliable message set for sensors and actuators for drones. That new message set should be created on an open forum. I’ve suggested a topic in this forum. Network protocols created in the open tend to be technically better than those created behind closed doors.
We also need to address a few “elephants in the room”.
The first is the fact that for years now the official position on the UAVCAN website is that new designs should use v1. That should not be the case until v1 is actually workable. The key decision point for a new release of a protocol or a software package should be “what would give the best result for a new user?”. A new vendor being pointed at v1 now would do them a great disservice.
The second big thing is the lack of focus on the migration path from v0 to v1. The fact that the core tools for v0 and v1 can’t even be installed at the same time makes this glaringly obvious. We can’t build an ecosystem which gives users a clear migration path if developers can’t doing any monitoring and analysis of a mixed bus.
Finally we need to seriously consider the problem of protocol fragility. The v1 protocol embraces lack of inherent type safety as a virtue. The little example I gave above of a situation where we end up with a cast from one packet type to another and a misinterpretation of data is a massive problem. This needs to be addressed in a truly robust fashion. I know v1 is trying to be ambitious in its goals, and ambition is fine if it is backed up with rigorous answers to basic properties like robustness. The suggestion I made for a class ID in CANDevices is a band-aid over a major problem in v1, but at least it gives us something to counter the inherent fragility of v1.
Finally, I was very hard on DS-015 above. If individuals took offence at the approach I took then I apologise for that. Please remember that this is part of a much longer conversation where the problem with DS-015 and v1 have been raised many times, and it just wasn’t cutting through to get a good technical result.
We can create a great network protocol to replace v0, but we do need to keep the focus on the key requirements for any good protocol:
- robustness
- clarity
- efficiency
The DS-015 standard lacked all 3. We’re vastly better off without it.
11 Likes