Attendees:
- Pavel Kirienko @pavel.kirienko * Andrew Tridgell
- Kalyan Sriram @coder_kalyan
- James Pattison @auturgy
- Daniel Agar @dagar
- Scott Dixon @scottdixon
- Siddharth Purohit @sidbh
Pavel:
- UAVCANv1 is a is intended to be decentralized and composable. This allows for future proofing and makes further expansion easier to accomplish by making less assumptions and focusing on a less holistic (and therefore limited by the human mind) view of the system.
Andrew: why is composability useful?
Pavel: Not useful for the user of the vehicle, but
Andrew: This seems to be accomplishable with versions. I am yet to see an actual end user benefit to the integrator. This level of decentralization has costs:
- performance/bandwidth
- complexity
- robustness
- integrator headache
What is wrong with creating messages per use case?
Pavel: This encourages designing of extremely specific messages that have limited scope for use.
Andrew: Here’s an example regarding node temperature: different temperatures have very different use cases. Having reusable types loses the association between, say, an IMU device and its temperature.
Andrew: Still doesn’t seem to be a tangible benefit. For current use cases, we need a robust sensor network that is simple, robust, and efficient. The service oriented distributed architecture is not compatible with that, and I don’t like that. Details about different sensors are also lost through this mechanism
Scott: What about the problem of too much centralization caused by flight controller-centric autoconfiguration?
Pavel: Not really a problem as high integrity environments that care should be manually configured either way.
Scott: I am also unable to see the benefits at the application layer - why not go in steps, start with the transport layer benefits of v1 and keep something that is easier to understand?
Andrew: By cleaning up the v0 junk, we won’t actually use a lot of IDs - why not reserve a few for standard sensor messages?
Pavel: I am not worried about running out of IDs or conflicts. It’s instead the question of hard associating the data type contents with its semantics (how it’s used). A range of IDs is a possible solution for type safety.
At this point in time, the conversation drifted towards some very specific examples and thought experiments that I forgot to write down (sorry!) However, here are some key takeaways from the discussion:
Before he left, @scottdixon suggested that we shelve the port ID problem to later and focus on the stuff that we do agree on. While this is a noble idea, it was decided that this is not a good idea because problems such as the message contents are trivial to solve, while these larger architectural values need to be figured out if we want to move forward at all.
Andrew wants tangible benefits to the end user in order to counteract the increased complexity and decreased efficiency of V1. Without that, there doesn’t seem to be any point. He also noted that the transport layer improvements of V1 (CAN-FD and packet extensions/versioning) are very useful, but he doesn’t see the benefits of the V1 application layer ideology.
Pavel expressed that he is very concerned that the applications of UAVCAN in the long run will exceed the capabilities of a rigid application layer. The upfront cost of a more complex application layer specification may be outweighed by future proofing the protocol. This is the primary basis for @pavel.kirienko’s viewpoint on the subject.
The team will likely reconvene next week to continue development.
I likely missed something. If anyone has anything to add, please reply to this post.