@lorenz.meier predicts that the current set of regulated data type management policies is unsustainable. In his view, the current approach where we combat fragmentation of interfaces used in the UAVCAN ecosystem by encouraging vendors to use and extend existing solutions instead of defining their own is likely to fail because independent vendors are inherently prone to short-sighted behaviors. Fundamentally, the minimization of fragmentation is in the best interest of users and integrators of UAVCAN equipment. Market forces should drive the appropriate response from vendors, but the resulting indirection requires long-term reasoning which they lack, which results in a net loss for all involved parties. According to Lorenz, we should search for a solution that allows participants of the ecosystem to align their interests through a shorter chain of inferences.
The above is my interpretation; I am happy to be corrected if my channeling of his view is distorted.
The intention of the current policies is to bootstrap a well-formalized process of maintaining vendor-agnostic regulated interfaces for common tasks (such as commonly used types of sensors or actuators). Parallels can be found in the standard CANOpen profiles, standard USB classes, Bluetooth profiles, and certain commonly used data types defined in ROS. The UAVCAN team lacks the expertise and resources necessary to provide a workable set of standard interfaces for common use cases at this point. It also lacks the necessary political leverage to solicit required inputs from existing adopters. Our solution to the problem is an incremental process, where we set out rules that should enable us to increase the involvement of vendors in the data type regulation process gradually, with the long-term aim to eventually turn the resulting set of involved parties into a well-regulated consortium that will be capable enough to define and maintain the aforementioned set of vendor-agnostic regulated interfaces.
We recognize that the incremental process runs the risk of fragmentation, especially considering that its success is very sensitive to the performance of the UAVCAN maintainers. However, we do not have a better solution at the moment.
It has been proposed to implement a formal compliance assessment process as a way to minimize the aforementioned risk. The compliance assessment process is, essentially, a direct re-implementation of the USB-IF Logo License policy: UAVCAN vendors who are interested in ensuring that their equipment is strictly compliant to the letter of the standard submit their products to compliance testing for a fee, obtaining the right to use a recognizable feature (such as a particular logo) with the product. It is predicted that the increased involvement of vendors will reduce the risk of fragmentation.
The crucial aspect of the logo policy is that it in no way infringes upon the open nature of the standard, remaining a completely optional feature only for the interested members of the ecosystem. In order to underline its optionality, the logo policy may need to be implemented as an addition outside of the main body of the standard.
This post is to highlight the following issues that may require discussion:
-
Does the current regulated namespace management policy require updates before it is deployed in UAVCAN v1?
-
Are there any concrete proposals for the implementation of the compliance testing process and the related fees and legal issues?
FYI @anton.krol
Never.
As a result, each company will duplicate types, etc. Do you want to adjust types for companies? This is a dead end. Want a ZUBAX or another company? But, this should be in the examples or test. Everything should be as abstract as possible.