In order to kick-start this work, I would like to invite the participants to submit their proposals for the low-level technical requirements for the standard. Per the standard V-model, the requirements defined at this stage will be used to gauge the feasibility of the design proposals submitted at later stages of the project.
The proposals should be published in separate topics and then linked from this thread for visibility.
I suggest that the proposals include at least the following items:
A (non-exhaustive) list of typical functional nodes the standard should apply to. For example, ESC, range sensor, etc.
For UAVCAN/CAN networks specifically, the following spreadsheets should be filled out for a typical UAVCAN v0 configuration that should be supported by the upcoming new standard (create a copy before editing):
The objective of this item is to determine the available network bandwidth slack.
Transfer latency bounds for some of the typical subjects (e.g., ESC setpoint messages).
The extent of auto-configurability supported by the first iteration of the design.
Specify which items of the UAVCAN Interface Design Guidelines should not apply, and state the reason why.
Per the group’s workflow guidelines, the next step would be to evaluate the proposals, implement amendments as necessary, and choose one as the winner accepted by the SIG. Shall the group fail to converge in a reasonable timeframe, a voting session will be set up.
I would recommend the group to hold the progress until at least the following members have submitted their proposals:
until we have a concrete proposed msg set to provide context for these decisions we’d be voting in a vacuum. If you are thinking that this decision becomes binding on the group then you’re just setting up the whole process to fail.
We can’t give latency bounds for ESC setpoints because it is so context dependent. The bounds for a 100g drone are totally different from a 1 tonne vehicle. The only sane answer is “as low as possible while transmitting the requested information”.
The same with the Q on the interface guidelines - all of the guidelines should be fair game to be ignored if there is a good technical reason for the specific message, but we can’t have any sensible discussion on those technical reasons without having some concrete msgs to discuss.
Surely you have at least a vague image of what you want to achieve before you start doing something, otherwise you won’t get much done. What I am suggesting is that we have this vague image documented.
I read it as you can give latency bounds if you define them as a function of MTOW. Let’s get it documented as such.
I am certain that you can come up with a sensible solution for a problem by keeping the entire context in your head, but this approach may not scale well for teams containing more than 1 person.
