At the call today we were discussing my recent changeset to the DSDL repository and its key architectural decisions. A solid workflow requires that all participants of the DS-015 workgroup are up to date on the high-level technical requirements and on the best applicable practices. It may be sensible to split the workgroup into two levels: one defines the high-level business requirements, the other develops the appropriate technical solutions.
The above-mentioned pull request is ready for a careful review. Keep in mind though that everything bears the version number of v0.1 so nothing is stable yet. I expect that there will be changes as we move towards stabilization in collaboration with vendors and first adopters. Most importantly, the docs will be expanded and clarified.
@aentinger you may want to give it a look if you haven’t already.
Just had an ad-hoc sync call with Nuno. As we have nearly completed the work on the first SoW excepting the user documentation-related tasks that are blocked by the lack of the entities they are intended to document, we are redirecting the remaining time and budget to other activities.
The first such activity is to finalize and release Nunavut v1.0.0. The plan is for me to work together with @scottdixon starting next week to hopefully publish the release sometime in November. It is hard for me to give a precise estimate at the moment because I am not that familiar with the codebase; I expect this to change next week.
After Nunavut v1.0.0 is released or when my active involvement is no longer required, I may switch my focus to the development of a new low-level driver for the STM32 FDCAN controller (as found in STM32H7 and other new chips) accompanied with a demo application that adopters may easily repurpose into conformant UAVCAN v1-enabled products. The exact technical requirements are to be defined later.
Also, concurrently with the above I will be consulting our collaborators (first of all, @PetervdPerk and @dagar) on the implementation of UAVCAN v1 in PX4 and the reference designs from NXP.
The expectation is that these steps will accelerate the adoption of UAVCAN v1 and allow the current adopters to switch from v0 to v1.
Analysis of the current state of the MVP - we currently miss a way to define the network services on code, rather than just comments on a file. This will enable a faster integration of specific devices that offer specific pre-defined, templated and standerdized functions (ex. battery, ESC), and improve the UX for UAVCAN v1 a lot.
A working prototype can be delivered for evaluation of the UAVCAN v1 current state, but this might result on pushing-back adopters of the new v1, since the UX is quite worse than v0 (requires much more user integration, quite different from what existed with v0) - this needs to be addressed.
The naming of MVP for the first implementation in PX4 might suggest that all is completely ready for usage - that might be true if we consider that a user is expected to manually integrate their device and make itcompliant with the spec and the network service definition, which will probably not be the case for the overall community expecting to use UAVCAN v1 (expectations of an out-of-the-box P&P solution vs a completely manual free-form definition of the subjects).
Peter:
Still working on bringing the latest Nunavut and data types into the BMS-772
Pavel:
No updates on the register naming and network service definition standardization
Daniel:
No updates on the PX4 MVP.
Action items:
Pavel:
To finish and merge the Nunavut PR
To work on the register naming and network service definition standardization
Daniel Agar:
Colaborate on the presentation of a solution for codable network definitions
Peter:
Colaborate on the presentation of a solution for codable network definitions
Nuno:
To create a forum post that presents the above problem and two possible concepts of a solution to it - make it the highest priority atm.
At the UAVCAN dev call today @aentinger raised the question of missing network service definitions and 3D geometry data types for GNSS positioning hardware.
@TSC21 We discussed it as a low-priority problem with you a while ago and we decided to postpone it until the first MVP is out. Given that we are approaching the MVP release, I suggest we include the geometry data types and global positioning service into the near-term roadmap, assuming that Auterion is interested in pursuing this.
Positioning is an often requested capability so pushing this forward now will help early stage adoption.
Can you please add this to the agenda for the next call?
@pavel.kirienko as you might have understood, there are currently other matters that come up as more urgent to solve and follow-up upon. Adding more data types at this point is not going to help on anything if the MVP is not defined and in place. Let’s please focus on those first and then add the GNSS network service.
Let me provide a bit of background information here. Following up on the UAVCAN weekly dev call on 2020/11/18 I’ve created a minimal Arduino based UAVCAN use case demo in the form of a GNSS node.
This software, although not yet complete has been already taken for a test ride by @vivienJ and possibly others. One of the things missing for completion are location data types which is why I’ve asked about them on the UAVCAN weekly dev call on 2020/11/25. I could whip up my own preeliminary location type but am reluctant to do so as it would possibly stick around and be hard to eliminate going forward.
Consequently completion of the use case is blocked until a location type has been properly defined.