I am also in favor of a dev call; I think the forum is “too asynchronous” causing us to get frustrated at each other instead of coming to a consensus. I would suggest a weekly call for now. I am not at liberty to choose a time, but invite @tridge @pavel.kirienko and @dagar to suggest a time that works for everyone (Daniel, Vincent, and I are on the same continent so thats easier). We can always transition to a forum once we have something in place.
I agree that technical discussions don’t mean much if the members fundamentally agree on what they want to see in the standard - but I think we can come to a conclusion, especially though a call. The fact is, UAVCANv0 exists - and that’s our starting point. While my personal feelings on the matter lean towards Pavel’s vision of a distributed, abstract and flexible network, we need to recognize that v0 is what is currently vendors/adopters as well as autopilot implementors are used to (and quite honestly, it works reasonable well).
All of this said, nothing moves a project forward like some tangible progress. After a certain point, technical discussions start to stagnate and don’t bring us closer to a UDRAL standard that anyone can use. I feel that it would be better to 1) outline some basic requirements (which has already largely been done) and 2) throw a rough draft together, with the full disclosure that it is not ready for stable use.
At the risk of being a bit too rushed, I have created a google document: https://docs.google.com/document/d/1oD-ngXTAG6-qQePqgSZkpUgQCgGF4Bc7O19cXCfDaK4/edit?usp=sharing It is currently owned by AmadorUAVs (my drone team, which is also a consortium member) but if Pavel or someone else would like to transfer ownership that is fine with me. We may end up scrapping the document 2 weeks from now but I feel that at least we will have something to work with. I have given edit access to anyone with the link.
On the bright side, I do think there’s some things we can agree on:
- (maybe not completely in agreement) fixed port IDs don’t look like they will happen
- We really need some type safety standards. Currently I like @pavel.kirienko’s UDRAL class idea, but it will likely need some revision before we end up adopting anything. For the sake of having something concrete, I will start to put together device classes on the google document.
- Nesting can be useful, but too much nesting (as seen in DS-015) causes unnecessary complexity, overhead, and developer headaches. Please, let us try to non-rigidly constrain the amount of nesting.
- The need for a good automatic integration system that captures 90% of user requirements is paramount. It has become clear that this is a prerequisite to adoption, not something we can add on later. I like the ideas being discussed in Port type safety enforcement but I think we are waiting on @dagar and @tridge to give their opinions on the matter.
- Let us please make a compromise between efficiency and architectural values. As @tridge pointed out, DS-015 makes a complete mess of this, wasting bytes on what is, after all, a limited bus (classic CAN). Designing something that only works properly on CAN-FD is IMO not a good idea at all. It will be many more years before CAN-FD becomes a standard on the market; I am yet to see any vendors even supporting it, even on newly released hardware. Besides, keeping an eye on efficiency is healthy. Now, that said, making poor abstraction choices with the goal of saving a couple bytes so that a message can be crammed into fewer CAN frames, is also not a good solution. It makes a mess of the datatype definitions and makes the standard less future proof. I think a good compromise would be to split up messages that are semantically separate while also questioning the addition of fields to a message beyond what is necessary (for example, the controversial covariances in DS-015, which I personally see little use for, are quite large).