Well, crap. I just spend the last hour editing my own summary instead of reading yours. I’ll just post my summary as well which has far less detail but does touch on some other topics discussed at the summit:
On October 2nd and 3rd three of the UAVCAN maintainers; Pavel Kirienko (BDFL), Kjetil Kjeka (rustifarian), and Scott Dixon (the FD guy), held a summit in Stockholm Sweden to discuss version 1 of the UAVCAN specification. At the meeting’s conclusion the attendees agreed that a first draft of UAVCAN v1 should be ready by the end of October. An announcement will be made on this forum when the draft is ready for public comment and feedback. After the draft is released work will begin to adapt the four reference implementations; pyuavcan, uavcan.rs, libcanard, and libuavcan. As the maintainers gain insight into the impact the new specification has on each implementation, and as changes are made in response to public comments, estimated milestone dates will be released for each project. Pavel Kirienko (BDFL) will setup and run a weekly developer call Mondays at 6pm (UTC) to coordinate these efforts.
The GPL licensing encumberment found in the gui_tool project was discussed. The consensus was to scrap the current pyqt implementation in favor of a UI technology that offered better licensing terms. It was suggested that a python implementation that exposed its GUI via a web server (e.g. In the same manner Jupyter notebooks are served locally) should be designed. This would allow the use of a more modern and flexible JavaScript GUI toolkit but would still leverage pyuavcan as its core implementation. This approach would also easily allow UI remoting from containers or virts to host platforms that do not support CAN-FD (e.g. OSX). The major concerns were a lack of experience in developing JavaScript UIs by the current UAVCAN contributors and a lack of time given the large amount of work the v1 port will require for the core implementations. This lead to a discussion about soliciting more active contributions from the community to accelerate the v1 port and to help implement the new GUI tool. Scott Dixon agreed to ask for more support from his organization but was not able to make a hard commitment on this point. Pavel Kirienko, of Zubax robotics, offered that his company may be able to offer limited, additional help with the pyuavcan port.
Kjetil re-raised his proposal to require “code compatibility” between all minor revisions within a given major version of the protocol (see the github thread here). This was discussed at length but it was agreed that the group would not come to consensus on this issue at the summit.
The majority of the two days was spent discussing Data Types in general and the standard UAVCAN type definitions specifically. The following points are the key decisions emerging from this lengthy discussion:
- All types under the “protocol” namespace will remain for v1 and will remain, largely, unchanged.
- All vehicle-specific types will initially be omitted from the v1 specification. As vendors manufacturer v1 compliant hardware Subjects will be added to support their product class.
- It was agreed that the v0 standard types were deficient because they lacked the refinement that comes from use. Because of this v1 should only add standard Subjects if and when real products require support for them.
- This decision requires a dedicated section in the specification detailing the manufacturer engagement process.
- The standard will no longer use the term “Data Type ID” but will rename this concept to “Subject”. Likewise, Service Type ID will be referred to as simply Service ID.
- V1 will adopt a model of System State, Physical Processes, Physical Quantities, Data Types, and Bit streams.
- This model will obviate the need for sensor and actuator indices in messages.
- All physical quantities will be float32
- Because v1 will sacrifice some bus efficiency to present a more generic “publish and subscribe” semantic it will become even more important that v1 implementations improve support for custom Subjects and Services. Scott and Kjetil both stressed the importance of custom DSDL to the success of the v1 protocol.
Finally, it was resolved that the Swiss make the best chocolates and that Amazon Web Service’s† Stockholm office was a very gracious host. We would like to thank them again for the coffee and the whiteboards.
†Please note that neither Amazon Web Services, its parent companies, nor its subsidiaries sponsor, directly support, nor make any claims for this open-source software project. We were guests as a benefit of my (Scott Dixon) employment and as part of a project that I contribute to for my own professional curiosity and sense of fair play.