[NEEDS FEEDBACK] ESC Message Set

mrpollo · August 19, 2020, 4:44pm

DS-015 UAVCAN Drone Communication Standard

The following messages are ready for final review from the main stakeholders, and from ESC implementors/manufacturers everywhere.

ESC Messages

ESCPowerCommand
ESCPowerCmdGroup
ESCComandType
ESCFeedback
ESCFeedbackGroup
ESCStatus
ESCFailure
ESCState
ESCSignal
ESCInfo

Note: the messages can be found on the DS-015 document (linked below) on the Actuator Messages section, see below for a screenshot.

What are we looking for?

Feedback regarding the messages, we think the above message list gives us enough data and control to be able to operate correctly. We are looking for feedback on fields, data rates, and anything we might be missing.

How to share feedback?

Please share your comments in this thread, or directly on the DS-015 document, clearly marking it as feedback coming from this forum post.

Where is this coming from?

The DS-015 team is meeting bi-weekly, for status updates, and we are hoping to streamline the development and decision making process involved in the spec. Please join us on the next call, or follow the forum posts for meeting minutes.

Deadline for feedback

The UAVCAN team is meeting next on September 1st, 2020 (14-days from now), the goal is to have feedback collected by then, and move to the next message group.

Resources

DS-015 group meeting minutes for August 18

DS-015 Standard Draft Document

nacansino · August 29, 2020, 8:57am

Was the public access for DS-015 removed? I was able to open the document the day this post was posted, but currently, I cannot open it.

mrpollo · August 30, 2020, 3:19am

Not sure what happened with the original link I posted, but I have added an updated link with access for everyone @nacansino thanks for the heads up

aentinger · September 15, 2020, 6:41am

Hi I just want to check in and ask @mrpollo what’s the current state of the proposed UAVCAN V1 ESC message set? I’d like to add support for it to 107-Arduino-UAVCAN as well as PX4/sapog as soon as the ESC message set is part of the standard.

pavel.kirienko · September 15, 2020, 7:15am

I am not Ramon but I can answer for him here: I am literally about to embark on the task of finishing up the proposal for the ESC types (and then some other types). The total scope of this undertaking is outlined here:

Up to now, I was working on these things, which are also necessary for DS-015 although we did not mention them in the plan:

github.com/OpenCyphal/specification

Beta PR 2 of 2: delimited serialization

OpenCyphal:master ← OpenCyphal:beta-2

opened 01:59AM - 11 Sep 20 UTC

pavel-kirienko

+764 -239

Fixes https://github.com/UAVCAN/specification/issues/90 Context, motivation, …discussion: https://forum.uavcan.org/t/data-type-extensibility-and-composition/827 Implementation: https://github.com/UAVCAN/pydsdl/pull/45; its documentation: https://pydsdl--45.org.readthedocs.build/en/45/ ----- This is the last PR separating us from v1.0-beta; you will notice that I have renamed the document into "**Specification v1.0-beta**" in this branch already. The changeset is large because it required updating many independent sections of the document. I recommend reviewing it by simply reading chapter **3 DSDL**, without any regard for the diffs. Afterward, the second pass can be done by looking at the diffs only. There are some inconsequential changes in the script `render_dsdl.py` that are safe to ignore. This script is seriously getting out of hand and I wish someone could rewrite it using a proper template engine like Jinja. I never expected it to grow so complex. I also removed the term "data schema" from the spec because it did not reflect the reality accurately and was used incorrectly in several places. Instead, we now use "data type". This change made it painfully obvious that service types should not even belong in the category of serializable types because they are not serializable, but I suppose we'll not be changing this detail now unless someone is willing to volunteer.

github.com/OpenCyphal/libcanard

Libcanard v1.0

OpenCyphal:master ← OpenCyphal:beta

opened 11:52PM - 14 Sep 20 UTC

pavel-kirienko

+282 -208

- Update CI to Ubuntu 20.04, GCC 10, Clang 10 (also fix a couple of minor nitpic…ks from the new clang-tidy) - Implement https://github.com/UAVCAN/specification/issues/94 - Implement https://github.com/UAVCAN/specification/issues/90 - Fix the NaN handling issues discovered by Scott in https://github.com/UAVCAN/nunavut/pull/115 - Bump the version number to **v1.0**. A long way from the first commit https://github.com/UAVCAN/libcanard/commit/6d7d39eae1d399da9bb4f62e292a5e70cbffd75d pushed in 2015. This PR will not be merged and may incur changes until https://github.com/UAVCAN/specification/pull/97 is approved. I debated whether it's worth [renaming "subscription" into "listener" to avoid confusion](https://forum.uavcan.org/t/how-to-use-services-correctly-in-libcanard/927/2?u=pavel.kirienko): > In Libcanard, there is a bit of an implementation-specific terminology mishap: it uses “subscribe” in the sense of “tell the library that the application wants to receive this kind of transfers”; the mishap is because I couldn’t find a better word to use. Maybe I should have used “listen” instead, like canardRxListen? I wonder if we should change it. In the end, I decided to not change it, keeping the old verbiage. If there is interest, it's not too late to do it now. FYI @TSC21 @PetervdPerk-NXP @dagar **EDIT:** it's worth noting that despite the subject-ID range review, this changeset does not render Libcanard v1.0 wire-incompatible with v0.100, excepting fringe cases of low importance. This is because the compatibility implications have been taken into account by https://github.com/UAVCAN/specification/pull/96.

aentinger · September 15, 2020, 8:38am

Thank you for getting back to me. Looks like things move towards the finish line which is fantastic. I’ve initially embarked on the UAVCAN journey because I wanted to control the Zubax Orel 20 ESCs (via legacy UAVCAN). But right around the time I started my exploration UAVCAN V1 appeared in alpha state which made it seem like it would be worth to wait and go for UAVCAN V1 from the start. I’m glad we are finally getting close(r).