DS-015: the drone namespace #81
Conversation
|
The documentation is a bit lacking still, and some data types or namespaces may need to be moved here and there, but the general structure is unlikely to change drastically. We will know as we go along adding new data types. If you need more context, please refer to the links provided in the OP post. |
|
I just pushed a number of changes to address the comments left here by Nuno & Peter and to close the pending TODO. This is still a draft but it may be good for merging. |
pavel-kirienko
force-pushed
the
ds-015-initial
branch
from
b303eed
to
2c4b088
Compare
pavel-kirienko
force-pushed
the
ds-015-initial
branch
from
f8b9ef0
to
81e1c60
Compare
…ocumentation is a WIP
|
FYI @RomanBapst |
|
We are setting up an hard timeline for the review of this PR at the 13th of October (Tuesday), after the Dronecode SIG call. Thanks in advance for everyone reviewing this PR! |
|
At the risk of being redundant, I want to state once again our policy concerning the units of measurement because it seems to occasionally cause some confusion. Every unit of measurement used in this design is either a base or derived SI unit. Exceptions may appear in the future, but I don't think that this is a likely scenario. It follows that we don't have RPM (it's radian/second), ampere-hours (coulombs), watt-hours (joules), degrees Celsius/Fahrenheit (kelvin), degrees (radian), etc. The motivation for this choice is provided in the UAVCAN Guide. The units of measurement are not mentioned for fields that are of type float32 joule
@sealed |
| # When the battery is not armed, it may limit the output power below the nominal rated value and disconnect the load | ||
| # should the charge level fall below the critical level. | ||
| # When the battery is armed, it is not permitted to limit the output power or energy regardless of the risk of damage. | ||
| # If the adaptive protection is not supported, the battery should always report its status as ARMED. |
pavel-kirienko
force-pushed
the
ds-015-initial
branch
from
56372be
to
aeeaaad
Compare
Co-authored-by: Jacob Schloss
|
Just pushed a couple of inconsequential changes:
|
There was a problem hiding this comment.
LGTM! Great job @pavel-kirienko! Thanks for everyone on the Dronecode SIG that provided their insights during the last months to help define the requirements for this first set of data types. This is the beginning of something great! @mrpollo please pass this message and thanks as well!
|
Had a suggestion to include all the individual cell voltages of the pack on the bms status (https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/service/battery/Status.0.1.uavcan) . I believe it would help with
|
This PR brings in the first iteration of domain-specific services for drones. The background is explained on the forum at https://forum.uavcan.org/t/ds-015-mvp-progress-tracking/936.
This design is optimized for CAN FD and more capable transports (such as UAVCAN/UDP or UAVCAN/serial), but it is, nevertheless, compatible with Classic CAN. See this spreadsheet for more info: https://docs.google.com/spreadsheets/d/1xSBcnnqbHBEZfFg4cqiS1weXHwX3X0MFWpW1WcEBIds/edit
Every definition here bears version number v0.1, meaning that nothing is release-ready yet. We will start stabilizing things as soon as production systems leveraging these services will start being released.
Related thoughts: https://forum.uavcan.org/t/on-multi-agent-services-and-design-guidelines/947
GitHub does not (yet) support syntax highlighting for DSDL files, so I recommend viewing the files locally using VSCode with the uavcan.dsdl extension. Just clone this repo and open its directory in VSCode, then accept all recommended extensions.