# Low-level technical requirements **URL:** \ **Category:** General\ **Created:** [June 4, 2021, 9:35pm UTC](https://forum.opencyphal.org/t/low-level-technical-requirements/1294 "2021-06-04T21:35:29Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [June 4, 2021, 9:35pm UTC](https://forum.opencyphal.org/t/low-level-technical-requirements/1294/1 "2021-06-04T21:35:29Z")
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. ![image](https://forum.opencyphal.org/uploads/default/original/1X/6f07078ada2ebca6fa12d7122aa787b4cbb3900d.png) 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): - 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](https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280), 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: - @tridge - @dagar ---
**Author:** ![tridge](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/tridge/32/119_2.png) [@tridge](https://forum.opencyphal.org/u/tridge)\ **Post date:** [June 11, 2021, 9:17am UTC](https://forum.opencyphal.org/t/low-level-technical-requirements/1294/2 "2021-06-11T09:17:09Z")
> [@pavel.kirienko](#): > > Per the [group’s workflow guidelines](https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280), 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. 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. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [June 11, 2021, 4:48pm UTC](https://forum.opencyphal.org/t/low-level-technical-requirements/1294/3 "2021-06-11T16:48:58Z")
> [@tridge](#): > > until we have a concrete proposed msg set to provide context for these decisions we’d be voting in a vacuum. 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. > [@tridge](#): > > 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”. 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.