# UAVCAN Drone Application Layer SIG guidelines

**URL:** <https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280>\
**Category:** General\
**Created:** [June 2, 2021, 4:54pm UTC](https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280 "2021-06-02T16:54:05Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**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:43pm UTC](https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280/7 "2021-06-11T16:43:46Z")

</div>

> [@tridge](#):
>
> would it be published during the development process, or only at the end?

My expectation is that the repository will be updated incrementally as the group progresses, so outside observers will be able to see roughly the current WIP at all times.

> [@tridge](#):
>
> I think the most useful thing I could do to start is put together a suggested message set for the core messages, like I suggested in my CANDevices proposal. I could put that in a git repo and the other members here could discuss and poke holes in it on this forum. I think we could make a lot of progress very quickly that way.

This is fine in general but I think it would save much effort to you and other participants if we first agreed on what exactly we are building before actually starting the work. This requires that the technical requirements are put forth and agreed upon. Can you please briefly describe what are you trying to achieve before publishing any definitions? Otherwise, we are risking facing two negative consequences:

- Psychological anchoring might make the group reluctant to accept competitive design goals once an implementation proposal is already in place.

- The discussion may become less organized as core goals will be discussed alongside minute technicalities of the implementation.

> [@tridge](#):
>
> The big thing that I really want to know is how we will handle the type safety issue that I raised previously. I proposed using a field in the CANDevices msgs for that, but what I’d much prefer is to reserve a range of subject IDs for these CANDevices, so given a subject ID we instantly know what type of msg it is. That would make configuration vastly simpler and much more robust.

Case in point: you are implicitly proposing here that the ease of _manual_ configuration be a critical design goal. Let’s make such proposals explicit.

This thread is not intended to be the place for technical discussions, it is a meta-discussion. You and @dagar appear to be interested in this specific technical matter, so let us discuss it separately. **EDIT:** see [Port type safety enforcement](https://forum.opencyphal.org/t/port-type-safety-enforcement/1303)

---

_[View the full topic](https://forum.opencyphal.org/t/uavcan-drone-application-layer-sig-guidelines/1280)._