From 156563296ed115d8559bcc3e47d8e619b77be107 Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 15 Oct 2021 23:09:03 +0300 Subject: [PATCH] Replace DS-015 with UDRAL (#125) https://forum.uavcan.org/t/problems-with-ds-015/1219/44?u=pavel.kirienko https://forum.uavcan.org/t/first-draft-of-the-udral-dsdl-namespace/1438?u=pavel.kirienko Co-authored-by: Kalyan Sriram Co-authored-by: flytrex-vadim Co-authored-by: Silver Valdvee --- .vscode/spellright.dict | 5 + reg/drone/README.md | 181 ----------- .../geodetic/PointStateVar.0.1.uavcan | 7 - .../kinematics/geodetic/StateVar.0.1.uavcan | 7 - .../service/air_data_computer/_.0.1.uavcan | 50 ---- .../service/battery/Parameters.0.1.uavcan | 55 ---- .../service/battery/Parameters.0.2.uavcan | 69 ----- reg/drone/service/battery/Status.0.1.uavcan | 39 --- .../gnss/DilutionOfPrecision.0.1.uavcan | 19 -- reg/drone/service/gnss/Heartbeat.0.1.uavcan | 23 -- reg/drone/service/gnss/Sources.0.1.uavcan | 51 ---- reg/drone/service/gnss/Time.0.1.uavcan | 17 -- reg/drone/service/gnss/_.0.1.uavcan | 61 ---- reg/udral/README.md | 283 ++++++++++++++++++ .../physics/acoustics/Note.0.1.uavcan | 0 .../physics/dynamics/README.md | 0 .../dynamics/rotation/Planar.0.1.uavcan | 2 +- .../dynamics/rotation/PlanarTs.0.1.uavcan | 0 .../dynamics/translation/Linear.0.1.uavcan | 2 +- .../dynamics/translation/LinearTs.0.1.uavcan | 0 .../physics/electricity/Power.0.1.uavcan | 0 .../physics/electricity/PowerTs.0.1.uavcan | 0 .../physics/electricity/Source.0.1.uavcan | 0 .../physics/electricity/SourceTs.0.1.uavcan | 0 .../physics/kinematics/README.md | 0 .../kinematics/cartesian/Point.0.1.uavcan | 0 .../cartesian/PointState.0.1.uavcan | 0 .../cartesian/PointStateVar.0.1.uavcan | 2 +- .../cartesian/PointStateVarTs.0.1.uavcan | 0 .../kinematics/cartesian/PointVar.0.1.uavcan | 0 .../kinematics/cartesian/Pose.0.1.uavcan | 0 .../kinematics/cartesian/PoseVar.0.1.uavcan | 0 .../kinematics/cartesian/PoseVarTs.0.1.uavcan | 0 .../kinematics/cartesian/State.0.1.uavcan | 0 .../kinematics/cartesian/StateVar.0.1.uavcan | 0 .../cartesian/StateVarTs.0.1.uavcan | 0 .../kinematics/cartesian/Twist.0.1.uavcan | 0 .../kinematics/cartesian/TwistVar.0.1.uavcan | 0 .../cartesian/TwistVarTs.0.1.uavcan | 0 .../kinematics/geodetic/Point.0.1.uavcan | 2 +- .../kinematics/geodetic/PointState.0.1.uavcan | 2 +- .../geodetic/PointStateVar.0.1.uavcan | 7 + .../geodetic/PointStateVarTs.0.1.uavcan | 2 +- .../kinematics/geodetic/PointVar.0.1.uavcan | 2 +- .../kinematics/geodetic/Pose.0.1.uavcan | 2 +- .../kinematics/geodetic/PoseVar.0.1.uavcan | 2 +- .../kinematics/geodetic/State.0.1.uavcan | 4 +- .../kinematics/geodetic/StateVar.0.1.uavcan | 7 + .../kinematics/geodetic/StateVarTs.0.1.uavcan | 2 +- .../kinematics/rotation/Planar.0.1.uavcan | 0 .../kinematics/rotation/PlanarTs.0.1.uavcan | 0 .../kinematics/translation/Linear.0.1.uavcan | 0 .../translation/LinearTs.0.1.uavcan | 0 .../translation/LinearVarTs.0.1.uavcan | 0 .../translation/Velocity1VarTs.0.1.uavcan | 0 .../translation/Velocity3Var.0.1.uavcan | 0 .../translation/Velocity3Var.0.2.uavcan | 0 .../physics/optics/HighColor.0.1.uavcan | 0 .../PressureTempVarTs.0.1.uavcan | 0 .../physics/time/TAI64.0.1.uavcan | 0 .../physics/time/TAI64Var.0.1.uavcan | 0 .../physics/time/TAI64VarTs.0.1.uavcan | 0 .../actuator/common/FaultFlags.0.1.uavcan | 0 .../actuator/common/Feedback.0.1.uavcan | 2 +- .../service/actuator/common/Status.0.1.uavcan | 0 .../service/actuator/common/_.0.1.uavcan | 0 .../actuator/common/sp/Scalar.0.1.uavcan | 0 .../actuator/common/sp/Vector2.0.1.uavcan | 0 .../actuator/common/sp/Vector3.0.1.uavcan | 0 .../actuator/common/sp/Vector31.0.1.uavcan | 0 .../actuator/common/sp/Vector4.0.1.uavcan | 0 .../actuator/common/sp/Vector6.0.1.uavcan | 0 .../actuator/common/sp/Vector8.0.1.uavcan | 0 .../service/actuator/common/sp/_.0.1.uavcan | 0 .../service/actuator/esc/_.0.1.uavcan | 25 +- .../service/actuator/servo/_.0.1.uavcan | 52 ++-- .../service/battery/Error.0.1.uavcan | 0 .../service/battery/Parameters.0.3.uavcan | 17 +- .../service/battery/Status.0.2.uavcan | 5 +- .../service/battery/Technology.0.1.uavcan | 0 .../service/battery/_.0.1.uavcan | 16 +- .../service/common/Heartbeat.0.1.uavcan | 0 .../service/common/Readiness.0.1.uavcan | 0 .../service/sensor/Status.0.1.uavcan | 0 84 files changed, 372 insertions(+), 650 deletions(-) delete mode 100644 reg/drone/README.md delete mode 100644 reg/drone/physics/kinematics/geodetic/PointStateVar.0.1.uavcan delete mode 100644 reg/drone/physics/kinematics/geodetic/StateVar.0.1.uavcan delete mode 100644 reg/drone/service/air_data_computer/_.0.1.uavcan delete mode 100644 reg/drone/service/battery/Parameters.0.1.uavcan delete mode 100644 reg/drone/service/battery/Parameters.0.2.uavcan delete mode 100644 reg/drone/service/battery/Status.0.1.uavcan delete mode 100644 reg/drone/service/gnss/DilutionOfPrecision.0.1.uavcan delete mode 100644 reg/drone/service/gnss/Heartbeat.0.1.uavcan delete mode 100644 reg/drone/service/gnss/Sources.0.1.uavcan delete mode 100644 reg/drone/service/gnss/Time.0.1.uavcan delete mode 100644 reg/drone/service/gnss/_.0.1.uavcan create mode 100644 reg/udral/README.md rename reg/{drone => udral}/physics/acoustics/Note.0.1.uavcan (100%) rename reg/{drone => udral}/physics/dynamics/README.md (100%) rename reg/{drone => udral}/physics/dynamics/rotation/Planar.0.1.uavcan (80%) rename reg/{drone => udral}/physics/dynamics/rotation/PlanarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/dynamics/translation/Linear.0.1.uavcan (80%) rename reg/{drone => udral}/physics/dynamics/translation/LinearTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/electricity/Power.0.1.uavcan (100%) rename reg/{drone => udral}/physics/electricity/PowerTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/electricity/Source.0.1.uavcan (100%) rename reg/{drone => udral}/physics/electricity/SourceTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/README.md (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/Point.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/PointState.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/PointStateVar.0.1.uavcan (50%) rename reg/{drone => udral}/physics/kinematics/cartesian/PointStateVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/PointVar.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/Pose.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/PoseVar.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/PoseVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/State.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/StateVar.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/StateVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/Twist.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/TwistVar.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/cartesian/TwistVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/geodetic/Point.0.1.uavcan (87%) rename reg/{drone => udral}/physics/kinematics/geodetic/PointState.0.1.uavcan (80%) create mode 100644 reg/udral/physics/kinematics/geodetic/PointStateVar.0.1.uavcan rename reg/{drone => udral}/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan (63%) rename reg/{drone => udral}/physics/kinematics/geodetic/PointVar.0.1.uavcan (84%) rename reg/{drone => udral}/physics/kinematics/geodetic/Pose.0.1.uavcan (81%) rename reg/{drone => udral}/physics/kinematics/geodetic/PoseVar.0.1.uavcan (89%) rename reg/{drone => udral}/physics/kinematics/geodetic/State.0.1.uavcan (69%) create mode 100644 reg/udral/physics/kinematics/geodetic/StateVar.0.1.uavcan rename reg/{drone => udral}/physics/kinematics/geodetic/StateVarTs.0.1.uavcan (60%) rename reg/{drone => udral}/physics/kinematics/rotation/Planar.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/rotation/PlanarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/Linear.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/LinearTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/LinearVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/Velocity1VarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/Velocity3Var.0.1.uavcan (100%) rename reg/{drone => udral}/physics/kinematics/translation/Velocity3Var.0.2.uavcan (100%) rename reg/{drone => udral}/physics/optics/HighColor.0.1.uavcan (100%) rename reg/{drone => udral}/physics/thermodynamics/PressureTempVarTs.0.1.uavcan (100%) rename reg/{drone => udral}/physics/time/TAI64.0.1.uavcan (100%) rename reg/{drone => udral}/physics/time/TAI64Var.0.1.uavcan (100%) rename reg/{drone => udral}/physics/time/TAI64VarTs.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/FaultFlags.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/Feedback.0.1.uavcan (96%) rename reg/{drone => udral}/service/actuator/common/Status.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/_.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Scalar.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector2.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector3.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector31.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector4.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector6.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/Vector8.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/common/sp/_.0.1.uavcan (100%) rename reg/{drone => udral}/service/actuator/esc/_.0.1.uavcan (91%) rename reg/{drone => udral}/service/actuator/servo/_.0.1.uavcan (80%) rename reg/{drone => udral}/service/battery/Error.0.1.uavcan (100%) rename reg/{drone => udral}/service/battery/Parameters.0.3.uavcan (86%) rename reg/{drone => udral}/service/battery/Status.0.2.uavcan (94%) rename reg/{drone => udral}/service/battery/Technology.0.1.uavcan (100%) rename reg/{drone => udral}/service/battery/_.0.1.uavcan (82%) rename reg/{drone => udral}/service/common/Heartbeat.0.1.uavcan (100%) rename reg/{drone => udral}/service/common/Readiness.0.1.uavcan (100%) rename reg/{drone => udral}/service/sensor/Status.0.1.uavcan (100%) diff --git a/.vscode/spellright.dict b/.vscode/spellright.dict index 4d000d75..ff0f3fa2 100644 --- a/.vscode/spellright.dict +++ b/.vscode/spellright.dict @@ -406,3 +406,8 @@ CAS OOP alignee UML +UDRAL +multirotors +DRone +UAVs +un diff --git a/reg/drone/README.md b/reg/drone/README.md deleted file mode 100644 index 213264f5..00000000 --- a/reg/drone/README.md +++ /dev/null @@ -1,181 +0,0 @@ -# Drone - -This namespace contains the application-specific regulated DSDL namespace for aerial vehicles. -This is the core piece of the [DS-015 UAVCAN Drone Standard](https://github.com/Dronecode/SIG-UAVCAN-Drone). -If you have any questions, feel free to bring them to the [UAVCAN Forum](https://forum.uavcan.org/c/sig/drone-sig/17). - -This namespace contains the following nested namespaces: - -- `physics` -- abstract physical processes and states in the system. -- `service` -- narrowly specialized types for common device classes. - -## Service-oriented architecture - -The user of this standard is advised to get familiar with the basic principles of service-oriented design. -As a quick primer, [read Wikipedia](https://en.wikipedia.org/wiki/Service-oriented_architecture). -For a more in-depth review, please read [The UAVCAN Guide](https://uavcan.org/guide). - -The value of this or any other interoperability standard is in enabling compatible, composable, and extensible -complex systems. -A design that does not put these principles above the resource utilization concerns risks defeating the purpose -of the standard. -Hence, when designing a new network service, put the clarity of your models first, then think about their performance -implications. - -In service-oriented architectures, deciding what capabilities *not* to provide is just as important as -deciding what to include. -Imagine that in an aircraft you have an air data computer publishing the current airspeed. -The air data computer is aware of the placement of the pitot probe and the local effects that may -influence its readings, so correcting for these effects is the task of the air data computer itself. -Therefore, the published airspeed should be the calibrated airspeed (CAS) rather than the raw -indicated airspeed (IAS). -One might be tempted to enrich the service by providing the IAS alongside with CAS for the benefit of -the service consumer and for enhanced flexibility. -While easy to accomplish, it would be a design mistake because it might incentivize service consumers to -depend on the irrelevant implementation details of the service, -resulting in fragile architectures that are also hard to understand, maintain, and verify. -Encapsulation and interface segregation are just as important here as in software design. - -Composability is desirable for high-integrity systems also because it facilitates subsystem isolation for -testing and confines changes to a smaller number of subsystems, -thus reducing the costs of validation and verification. - -These design principles may constitute a departure from the practices commonly accepted in legacy systems, -which is necessitated by the increasing complexity of modern intravehicular software. - -## Typical applications - -The definitions in the `service` namespace contain descriptions of some common use cases -that can be addressed with this standard. -Adopters are expected to mix and match various components to create new network services that were not originally -envisioned by the authors of this standard. -This is possible while retaining full vendor-agnostic compatibility thanks to the service composability capabilities -described earlier. - -A real hardware node would typically implement multiple services concurrently. -For example, a COTS (commercial off-the-shelf) electric drive may realistically implement the following: - -- Naturally, the ESC service. -- The servo service for generality. -- Acoustic feedback by subscribing to `reg.drone.physics.acoustics.Note`. -- Visual feedback via the LED by subscribing to `reg.drone.physics.optics.HighColor`. - -Another service that is interested in tracking the state of, say, a propeller drive -(say, for thrust estimation) would not need to concern itself with the ESC service at all. -Instead, it would simply subscribe to the generalized subject of type -`reg.drone.physics.dynamics.rotation.PlanarTs` published by the unit that drives the propeller -and extract its business-level information from that while being unaware of the specifics of the drive -(the propeller drive may be changed from an electric motor to a turboprop engine without affecting the -thrust estimation service). - -As another example, a flight control unit would not need to depend on the specifics of a GNSS positioning -service to obtain the location of the vehicle. -Instead, it would subscribe to a generic subject of a highly abstract type that models the location of -the vehicle in space (along with other related information such as time and pose), -which may as well be published by a mocap rig. - -## Bandwidth utilization - -Being forward-looking, this design is optimized for transports that offer -the data rates of at least ~4 Mbps and the MTU of at least ~64 bytes. -It is expected that in the foreseeable future all new applications will be leveraging transports whose -data transfer capability is at this level or higher -(this includes, for example, UAVCAN/CAN over CAN FD, UAVCAN/UDP over Ethernet, UAVCAN/serial over RS-422 or USB, etc). - -Applications relying on Classic CAN (maximum data rate ca. 1 Mbps, MTU 8 bytes) can still deploy these network services, -but the designer needs to be aware that most transfers will be multi-frame transfers and the resulting bus utilization -may be comparatively high. -To gauge the worst case bus utilization in a particular application, use the -[Classic CAN bandwidth estimation spreadsheet](https://docs.google.com/spreadsheets/d/1xSBcnnqbHBEZfFg4cqiS1weXHwX3X0MFWpW1WcEBIds/edit#gid=0) -(create a private copy and edit that). -Multi-frame transfers are not expected to cause performance issues because the official -UAVCAN implementation libraries are optimized for handling multi-frame transfers efficiently. - -## Conventions - -### Network service design conventions - -- All physical quantities except error variance should be represented as `float32` by default. - Error variance and covariance matrices should use `float16` by default. - -- Covariance matrices should be represented as their upper-right triangles using the matrix packing rules - defined in the Specification. - -- Types with (co)variance should be suffixed `Var`; types with timestamp should be suffixed `Ts`; - types with both should be suffixed `VarTs`. - The timestamp field, if present, should be the first one; - error (co)variance information should follow the data field(s) it relates to. - -### Port naming conventions - -In UAVCAN, the name of a port (i.e., subject or RPC-service) defines the names of related registers -as described in the documentation for the standard RPC-service `uavcan.register.Access`. -For instance, a node that publishes to the subject named `measurement` would have registers named -`uavcan.pub.measurement.id` and `uavcan.pub.measurement.type` (among others). - -> N.B.: Contrary to other protocols, in UAVCAN, the name of a port is a node-local property that does not affect - network exchanges over that port. - This means that nodes can publish/subscribe to a port even if they name it differently - as long as they are configured to use the same numerical port-ID. - The details are given in the UAVCAN Specification. - -Network service specifications given here under the `service` namespace provide the recommended names for -every defined port. -For example, the smart battery network service specification defines subjects named `status` and `parameters`. - -Using the suggested names in practical implementations directly is not always possible because nodes that -implement different network services (or multiple instances of the same service) would see naming conflicts -(e.g., many services define a subject named `status`). -Hence, implementations are advised to use the recommended port names with a prefix such that ports that -relate to the same instance of a network service share the same prefix. - -Imagine a node that implements two smart battery services (primary and secondary) -and a servo service (suppose we call it the main drive); -then it might have the following registers (among others): - - uavcan.pub.battery.primary.source.id - uavcan.pub.battery.primary.status.id - uavcan.pub.battery.primary.parameters.id - uavcan.pub.battery.secondary.source.id - uavcan.pub.battery.secondary.status.id - uavcan.pub.battery.secondary.parameters.id - uavcan.sub.main_drive.setpoint.id - uavcan.sub.main_drive.readiness.id - uavcan.pub.main_drive.feedback.id - uavcan.pub.main_drive.status.id - uavcan.pub.main_drive.power.id - uavcan.pub.main_drive.dynamics.id - -By virtue of sharing common prefixes, the registers clearly define three network services: - -- `battery.primary` -- `battery.secondary` -- `main_drive` - -The convention can be described in UML notation as follows: - - +-----------------------------------+ - | Network service specification | E.g., the smart battery network service - +-----------------------------------+ defined under reg.drone.service.battery - △ 0..* - ┆ - ┆ implements - ┆ - +-----------------------------------+ Example group "battery.main": - | Prefixed port group | - battery.main.source - +-----------------------------------+ - battery.main.status - │ - battery.main.parameters - │ has - │ - ♢ 1..* - +-----------------------------------+ - | Port | - | (subject or RPC-service) | - +-----------------------------------+ - -Following this convention is highly recommended as it aids one's understanding of the node's functional capabilities -and may enable some systems to implement automatic assignment of port identifiers. - -### Behavioral conventions - -Publishers of measurements or estimates should apply low-pass filtering to avoid frequency aliasing. diff --git a/reg/drone/physics/kinematics/geodetic/PointStateVar.0.1.uavcan b/reg/drone/physics/kinematics/geodetic/PointStateVar.0.1.uavcan deleted file mode 100644 index 85df1399..00000000 --- a/reg/drone/physics/kinematics/geodetic/PointStateVar.0.1.uavcan +++ /dev/null @@ -1,7 +0,0 @@ -# See PointState for details. - -PointVar.0.1 position -reg.drone.physics.kinematics.translation.Velocity3Var.0.2 velocity - -@sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.PointStateVar.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/StateVar.0.1.uavcan b/reg/drone/physics/kinematics/geodetic/StateVar.0.1.uavcan deleted file mode 100644 index d4be7d5f..00000000 --- a/reg/drone/physics/kinematics/geodetic/StateVar.0.1.uavcan +++ /dev/null @@ -1,7 +0,0 @@ -# See State for details. This type extends it with covariance matrices. - -PoseVar.0.1 pose -reg.drone.physics.kinematics.cartesian.TwistVar.0.1 twist - -@sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.StateVar.0.1._bit_length_ diff --git a/reg/drone/service/air_data_computer/_.0.1.uavcan b/reg/drone/service/air_data_computer/_.0.1.uavcan deleted file mode 100644 index eed5fb9f..00000000 --- a/reg/drone/service/air_data_computer/_.0.1.uavcan +++ /dev/null @@ -1,50 +0,0 @@ -# A generic air data computer service. -# -# An air data computer service is generally a non-interactive publish-only service: when activated, -# it keeps publishing its measurements at a fixed rate over several subjects until deactivated. -# The activation/deactivation, if supported, is managed via the standard readiness control service. -# The data update rates and other parameters are controlled via the Register API using implementation-defined -# register names. -# -# An air data computer whose readiness state is SLEEP is allowed to cease all network activity. -# -# An air data computer whose readiness state is STANDBY is recommended to behave as if its state was ENGAGED; -# implementations are recommended to leverage this state to perform any necessary maintenance activities -# such as calibration, self-heating, etc. The service should not report its own status as ENGAGED until said -# maintenance activities have been completed. Therefore, the high-level controler (e.g., the flight -# management unit) may delay the take-off until the service is ready. -# -# An air data computer whose readiness state is ENGAGED is required to comply with the requirements set out below. -# -# An ENGAGED service should publish the following data subjects synchronously at the same configurable rate -# which should not be lower than the specified limit. The measurements should be low-pass filtered -# to avoid frequency aliasing effects. -# -# PUBLISHED SUBJECT NAME SUBJECT TYPE NOTE -# calibrated_airspeed reg.drone.physics.kinematics.translation.Velocity1VarTs -# true_airspeed reg.drone.physics.kinematics.translation.Velocity1VarTs optional -# pressure_altitude reg.drone.physics.kinematics.translation.LinearVarTs assume ISA; NED frame (+down, -up) -# static_air_data reg.drone.physics.thermodynamics.PressureTempVarTs pressure and OAT -# -# Observe that there is no subject for indicated airspeed. This is because per the principles of service-oriented -# design, the air data computer is responsible for applying the necessary transformations on its data to render it -# ready for consumption by clients. If desired, indicated airspeed may be reported over an implementation-defined -# subject. -# -# In addition to the above, an ENGAGED service should publish the following service subjects at an -# implementation-defined rate: -# -# PUBLISHED SUBJECT NAME SUBJECT TYPE -# heartbeat reg.drone.service.common.Heartbeat -# sensor_status reg.drone.service.sensor.Status -# -# Despite being a non-interactive service, it is recommended to subscribe to the readiness command subject. -# This recommendation may be omitted if the service does not support readiness state selection, in which case it should -# always report itself as being ENGAGED. -# -# SUBSCRIBED SUBJECT NAME SUBJECT TYPE -# readiness reg.drone.service.common.Readiness - -float32 MAX_PUBLICATION_PERIOD = 0.1 # [second] - -@extent 0 diff --git a/reg/drone/service/battery/Parameters.0.1.uavcan b/reg/drone/service/battery/Parameters.0.1.uavcan deleted file mode 100644 index b3c7b035..00000000 --- a/reg/drone/service/battery/Parameters.0.1.uavcan +++ /dev/null @@ -1,55 +0,0 @@ -# Smart battery parameter message. It is mostly intended for automated battery charging and maintenance systems. -# This message is modeled after the Smart Battery Data Specification (SBS) and the MAVLink battery status messages. -# -# The values carried by this message are either constant or slow-changing, so, generally, the publishing frequency -# should not be higher than 0.2 Hz, and the priority should be either OPTIONAL or SLOW. -# -# All parameters are required unless specifically stated otherwise. -@deprecated - -truncated uint64 unique_id -# A statistically unique number that can be used to differentiate this exact battery from others. -# Needed for logging purposes. If the battery supports SBS, this value may be computed as CRC64WE of -# (ManufacturerName + DeviceName + ManufactureDate + SerialNumber). -# This value shall be invariant to the identity of the reporting node unless it is an integral part of the battery. -# Vendors may use a constant random number for the 40 most significant bits for vendor identification purposes. - -uavcan.si.unit.mass.Scalar.1.0 mass -# The total mass of the battery, including the packaging, electronics, cabling, and all auxiliary items, if any. -# May be used for predicting the kinematic parameters of the vehicle. -# NaN if unknown. - -uavcan.si.unit.electric_charge.Scalar.1.0 design_capacity -# The maximum total charge of the pack, at 100% SoH, specified by the manufacturer. - -uavcan.si.unit.voltage.Scalar.1.0[2] design_cell_voltage_min_max -# The minimum (end of discharge) and the maximum (end of charge) cell voltages specified by the manufacturer -# at 100% SoH. Example: {2.8, 4.2} V - -uavcan.si.unit.electric_current.Scalar.1.0 discharge_current -uavcan.si.unit.electric_current.Scalar.1.0 discharge_current_burst # At least for 5 seconds. -uavcan.si.unit.electric_current.Scalar.1.0 charge_current -uavcan.si.unit.electric_current.Scalar.1.0 charge_current_fast -uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_treshold # End-of-charging current threshold. -uavcan.si.unit.voltage.Scalar.1.0 charge_voltage # Total charging voltage (not per-cell). -# The key (dis-)charge parameters specified by the manufacturer for the pack. -# This is a reflection of similar parameters from the Smart Battery Data Specification. -# For non-rechargeable batteries all "charge_*" parameters should be NaN. - -uint16 cycle_count -# The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime. -# What constitutes a charge-discharge cycle is implementation-defined. - -void8 # Reserved for possible expansion because batteries with >255 cells exist. -uint8 series_cell_count -# The number of cells connected in series. - -uint7 state_of_health_pct # [percent] -# The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new). -void1 - -Technology.0.1 technology -# The battery technology information may be leveraged by the charger to choose the appropriate charging strategy. - -@assert _offset_.count == 1 # It is intended to be a fixed-size type (although it's not required). -@extent 8 * 63 # Limit to a single-frame transfer over CAN FD. diff --git a/reg/drone/service/battery/Parameters.0.2.uavcan b/reg/drone/service/battery/Parameters.0.2.uavcan deleted file mode 100644 index 62d93dbd..00000000 --- a/reg/drone/service/battery/Parameters.0.2.uavcan +++ /dev/null @@ -1,69 +0,0 @@ -# Smart battery parameter message. It is mostly intended for automated battery charging and maintenance systems. -# This message is modeled after the Smart Battery Data Specification (SBS) and the MAVLink battery status messages. -# -# The values carried by this message are either constant or slow-changing, so, generally, the publishing frequency -# should not be higher than 0.2 Hz, and the priority should be either OPTIONAL or SLOW. -# -# All parameters are required unless specifically stated otherwise. -# For non-rechargeable batteries all "charge_*" parameters should be NaN. -@deprecated - -truncated uint64 unique_id -# A statistically unique number that can be used to identify this exact battery for logging and diagnostic purposes. -# This value should be invariant to the identity of the reporting node unless it is an integral part of the battery. -# If the battery supports SBS, the recommended way to populate this field is from two CRC-32C (Castagnoli) values as: -# - 32 most significant bits identify the vendor as: CRC32C(ManufacturerName) -# - 32 least significant bits identify the battery as: CRC32C(DeviceName + ManufactureDate + SerialNumber) -# If the battery does not support SBS, the vendor may choose arbitrary random numbers. -# Note that these are mere recommendations. The only hard requirement for this field is to be statistically unique. - -uavcan.si.unit.mass.Scalar.1.0 mass -# The total mass of the battery, including the packaging, electronics, cabling, and all auxiliary items, if any. -# May be used for predicting the kinematic parameters of the vehicle. -# NaN if unknown. - -uavcan.si.unit.electric_charge.Scalar.1.0 design_capacity -# The maximum total charge of the pack, at 100% SoH, specified by the manufacturer. - -uavcan.si.unit.voltage.Scalar.1.0[2] design_cell_voltage_min_max -# The minimum (end of discharge) and the maximum (end of charge) resting cell voltage specified by the manufacturer -# at 100% SoH. Example: {2.8, 4.2} V. These voltages correspond to resting voltages; i.e., the stabilized voltages after -# the discharge/charge has been terminated. Voltage below the min may be observed during discharge due to the cell's -# internal resistance. Voltage above the max voltage may be observed during regenerative braking/charging etc due to -# the cell's internal resistance. - -uavcan.si.unit.electric_current.Scalar.1.0 discharge_current -# Recommended continuous discharge current of the battery. - -uavcan.si.unit.electric_current.Scalar.1.0 discharge_current_burst -# Maximum current that may be safely discharged at least for 5 seconds. - -uavcan.si.unit.electric_current.Scalar.1.0 charge_current -# Recommended continuous charge current of the battery. - -uavcan.si.unit.electric_current.Scalar.1.0 charge_current_fast -# Recommended safest highest continuous charge current for the battery. -# This may cause accelerated aging of the battery. - -uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_threshold -# End-of-charging current threshold. Charging may be terminated when the current falls below this threshold. - -uavcan.si.unit.voltage.Scalar.1.0 charge_voltage -# The total voltage(not per-cell) that may be used by the charger to charge the battery pack. - -uint16 cycle_count -# The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime. -# What constitutes a charge-discharge cycle is implementation-defined. - -void16 -# Was used in v0.1 for cell_count. It is now deducible from cell_voltages in Status.0.2. - -uint7 state_of_health_pct # [percent] -# The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new). -void1 - -Technology.0.1 technology -# The battery technology information may be leveraged by the charger to choose the appropriate charging strategy. - -@assert _offset_.count == 1 # It is intended to be a fixed-size type (although it's not required). -@extent 8 * 63 # Limit to a single-frame transfer over CAN FD. diff --git a/reg/drone/service/battery/Status.0.1.uavcan b/reg/drone/service/battery/Status.0.1.uavcan deleted file mode 100644 index 49befd48..00000000 --- a/reg/drone/service/battery/Status.0.1.uavcan +++ /dev/null @@ -1,39 +0,0 @@ -# This low-rate battery status should be published at least once per second. -@deprecated - -reg.drone.service.common.Heartbeat.0.1 heartbeat -# Note that the health code generally should not reflect the battery charge unless the service provider knows -# that the availability of energy in the battery is critical for the safe operation of the vehicle, which is usually -# not the case. For example, if the vehicle is equipped with several batteries that are discharged in series, one -# after another, the depletion of energy in the first battery is not a fault condition and it should not be reported -# as such. This follows from the good service design principles reviewed in https://uavcan.org/guide. -# -# The readiness state depicts the ability of the battery (or its power electronics) to deliver full rated power -# and whether the overdischarge protections are active. -# When the battery is not ENGAGED, 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 ENGAGED, 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 ENGAGED. - -uavcan.si.unit.temperature.Scalar.1.0[2] temperature_min_max -# The minimum and maximum readings of the pack temperature sensors. -# For example, if the pack is equipped with three distributed temperature sensors that read {288, 258.15, 360.5} K, -# the reported array value would be {258.15, 360.5} K. -# If there is only one temperature sensor, both elements shall be of the same value. - -uavcan.si.unit.voltage.Scalar.1.0[2] cell_voltage_min_max -# If v(i) is the voltage of cell number i (or a group of cells connected in parallel), and there are N cells, -# then the first array element is: min(v(x) for x in [0, N)) -# and the second array element is: max(v(x) for x in [0, N)) -# This information is used for gauging the degree of cell disbalance. -# Note that the average cell voltage can be obtained by dividing the battery voltage by the number of cells. - -uavcan.si.unit.electric_charge.Scalar.1.0 available_charge -# The estimated electric charge currently stored in the battery. This is intended for charging and maintenance only. -# Do not use this parameter for endurance prediction! Instead, use the correct energy type from the physics namespace. -# The depth of discharge (DoD), or the state of charge (SoC), can be derived by dividing this value by the -# nominal battery capacity reported in the Parameters message. - -Error.0.1 error - -@extent 63 * 8 # Single-frame transfer over CAN FD. diff --git a/reg/drone/service/gnss/DilutionOfPrecision.0.1.uavcan b/reg/drone/service/gnss/DilutionOfPrecision.0.1.uavcan deleted file mode 100644 index 982d0985..00000000 --- a/reg/drone/service/gnss/DilutionOfPrecision.0.1.uavcan +++ /dev/null @@ -1,19 +0,0 @@ -# The standard DOP estimates (https://en.wikipedia.org/wiki/Dilution_of_precision). -# DOP values should not be confused with accuracy estimates -- those are expressed through the covariance matrices. -# -# Applicable relations: -# gdop = (ndop^2 + edop^2 + vdop^2 + tdop^2)^0.5 -# pdop = (ndop^2 + edop^2 + vdop^2)^0.5 -# hdop = (ndop^2 + edop^2)^0.5 -# -# Fields whose values are unknown should be set to NaN. - -float16 geometric # GDOP -float16 position # PDOP -float16 horizontal # HDOP -float16 vertical # VDOP -float16 time # TDOP -float16 northing # NDOP -float16 easting # EDOP - -@sealed diff --git a/reg/drone/service/gnss/Heartbeat.0.1.uavcan b/reg/drone/service/gnss/Heartbeat.0.1.uavcan deleted file mode 100644 index 182e0e5a..00000000 --- a/reg/drone/service/gnss/Heartbeat.0.1.uavcan +++ /dev/null @@ -1,23 +0,0 @@ -# Optional, extended information on the performance of the GNSS sensor. - -reg.drone.service.common.Heartbeat.0.1 heartbeat - -Sources.0.1 sources - -DilutionOfPrecision.0.1 dop - -uint8 num_visible_satellites # The number of space vehicles visible when the solution was computed. -uint8 num_used_satellites # The number of space vehicles whose signals have been utilized to derive the solution. - -bool fix -# True if a GNSS fix is established (of any dimensionality, e.g., time-only). -# Data consumers should not use this flag and rely on the error estimates reported via covariance matrices instead. -# If the sensor is equipped with other means of deriving the navigation solution (dead reckoning, VIO, UWB, etc.), -# then this flag may not be representative of the actual status of the solution (only matrices are). - -bool rtk_fix -# True if the current mode is RTK and an RTK fix has been established. -# This flag should not be set unless `fix` is also set. -# The availability of base station data is indicated using a separate (orthogonal) flag defined in Sources. - -@extent 8 * 124 diff --git a/reg/drone/service/gnss/Sources.0.1.uavcan b/reg/drone/service/gnss/Sources.0.1.uavcan deleted file mode 100644 index 9643095c..00000000 --- a/reg/drone/service/gnss/Sources.0.1.uavcan +++ /dev/null @@ -1,51 +0,0 @@ -# There are multiple satellite networks and other data sources which provide autonomous geo-spatial positioning -# with global coverage. These flags are used for identifying which of those data sources -# are the source of the location data provided by the GNSS sensor node. -# -# Note that these fields convey no information about the status the navigation solution. Here is a specific example: -# -# - Heartbeat.fix - indicates that a standalone navigation solution is available. -# -# - Heartbeat.rtk_fix - indicates that an RTK fix is established and the integer wavelength ambiguity is resolved. -# -# - Sources.rtk_base - indicates that base station data (usually encapsulated into RTCM stream) is available -# to the receiver, but it says nothing about the status of the navigation solution. - -bool gps_l1 # 1575.42 MHz -bool gps_l2 # 1227.60 MHz -bool gps_l5 # 1176.45 MHz - -bool glonass_l1 # 1602 + k 0.5625 MHz, k in [-7,6] -bool glonass_l2 # 1246 + k 0.4375 MHz, k in [-7,6] -bool glonass_l3 # TBA - -bool galileo_e1 # 1575.42 MHz -bool galileo_e5a # 1176.45 MHz -bool galileo_e5b # 1207.14 MHz -bool galileo_e6 # 1278.75 MHz - -bool beidou_b1 # 1531.098 MHz -bool beidou_b2 # 1207.140 MHz - -void5 # Reserved for other constellations. - -bool sbas # Satellite-Based Augmentation System (WAAS, EGNOS, GAGAN, QZSS, etc.) -bool gbas # Ground-Based Augmentation System, DGPS (IMES, etc.) - -bool rtk_base # Real-Time Kinematics base station data -void3 # Reserved for other RTK-related sources. - -bool imu # Inertial Measurement Unit -bool visual_odometry -bool dead_reckoning # Any dead reckoning equipment (e.g., wheel odometry) -bool uwb # Ultra-wideband positioning -void4 - -bool magnetic_compass -bool gyro_compass -bool other_compass - -void14 # Add new items here to ensure backward compatibility. - -@assert _offset_ == {48} -@sealed diff --git a/reg/drone/service/gnss/Time.0.1.uavcan b/reg/drone/service/gnss/Time.0.1.uavcan deleted file mode 100644 index 11d83f7e..00000000 --- a/reg/drone/service/gnss/Time.0.1.uavcan +++ /dev/null @@ -1,17 +0,0 @@ -# The current time estimated by a GNSS receiver. See TAI64 for details, of which this one is a structural subtype. -# -# TAI is short for International Atomic Time: https://en.wikipedia.org/wiki/International_Atomic_Time. -# TAI is always a fixed integer number of seconds ahead of GPS time. -# Systems that use GPS time as a reference shall convert that to TAI by adding the fixed difference. -# GPS time is not supported for reasons of consistency across different positioning systems and applications. -# -# The error variance is expected to increase if the GNSS signal deteriorates. -# If the signal is lost, this value is expected to grow steadily, the rate of growth dependent on the quality of -# the time keeping hardware available locally (bad hardware yields faster growth). -# Once the signal is regained, this value would drop back to nominal. - -reg.drone.physics.time.TAI64VarTs.0.1 value # Supertype. - -uavcan.time.TAIInfo.0.1 info # Actual information about TAI. This information can be used to convert TAI into UTC. - -@extent 8 * 63 diff --git a/reg/drone/service/gnss/_.0.1.uavcan b/reg/drone/service/gnss/_.0.1.uavcan deleted file mode 100644 index 07560c1e..00000000 --- a/reg/drone/service/gnss/_.0.1.uavcan +++ /dev/null @@ -1,61 +0,0 @@ -# A generic GNSS location sensor device. This service is designed to model any navigation equipment that leverages -# global navigation satellite systems (GNSS) to obtain the final estimates, such as plain standalone GNSS receivers, -# integrated GNSS-IMU units, GNSS-VIO, RTK, PPP, etc. The entirety of the application-layer data provided by this -# sensor is modeled under the physics namespace. This namespace only adds an asbtract documentation and provides -# optional auxiliary types for diagnostic purposes. -# -# Consumers that require global positioning data without the associated diagnostics should not depend -# on this service directly, using the plain physics types instead. This allows the designer to uphold the -# interface segregation principle, resulting in a more composable system that is easier to understand, verify, -# simulate, and maintain. -# -# A compliant implementation of this service should publish the following subjects: -# -# PUBLISHED SUBJECT NAME SUBJECT TYPE TYP. RATE [Hz] -# point_kinematics reg.drone.physics.kinematics.geodetic.PointStateVarTs 1...100 -# time reg.drone.service.gnss.Time 1...10 -# heartbeat reg.drone.service.gnss.Heartbeat ~1 -# sensor_status reg.drone.service.sensor.Status ~1 -# -# The contents and related contracts are defined in the documentation for the referenced data types. -# Time messages should be published synchronously with their kinematic counterparts using the same timestamp value -# unless the ratio of their publication frequencies is not an integer. -# -# The location data along with the accuracy information is published via "point_kinematics". -# Sensors that are able to estimate orientation (e.g., those equipped with IMU, VIO, multi-antenna RTK, etc.) -# should also publish the following in addition to the above: -# -# PUBLISHED SUBJECT NAME SUBJECT TYPE TYP. RATE [Hz] -# kinematics reg.drone.physics.kinematics.geodetic.StateVarTs 1...100 -# -# A GNSS sensor may be well-equipped to act as a time synchronization master, in which case the standard policies -# set out under uavcan.time.Synchronization apply. If the sensor is not a time sync master, then it should -# synchronize itself with the network time and use it for timestamping its estimates. In this case, the estimated -# GNSS time can be obtained via the "time" subject irrespective of which node is the active time sync master. -# If the sensor does not support time synchronization at all, then published timestamp values shall be zero. -# -# A GNSS service is generally a non-interactive publish-only service: when activated, it keeps publishing -# data at a fixed rate until deactivated. The activation/deactivation, if supported (e.g., for reasons of -# energy conservation), is managed via the standard readiness control service. -# The data update rates and other parameters are controlled via the Register API using implementation-defined -# register names. -# -# SUBSCRIBED SUBJECT NAME SUBJECT TYPE NOTE -# readiness reg.drone.service.common.Readiness optional -# -# A GNSS sensor whose readiness state is SLEEP is allowed to cease all network activity. -# -# The published readiness value (part of the heartbeat) should not be conditional on the availability of -# navigational data; rather, it is to reflect the general status of the sensor itself: -# if the GNSS unit is operational, then it is to report itself as ENGAGED even if no fix is available at the moment. -# This is because the sensor status and its outputs are semantically independent entities. -# -# Sensors that rely on externally provided RTCM data (e.g., RTK-enabled units) or emit such data should -# subscribe and/or publish as follows: -# -# SUBJECT NAME SUBJECT TYPE NOTE -# rtcm uavcan.primitive.Unstructured optional -# -# The contents and temporal parameters of the encapsulated RTCM stream are implementation-defined. - -@extent 0 # This type is not intended for runtime use. diff --git a/reg/udral/README.md b/reg/udral/README.md new file mode 100644 index 00000000..832b83f6 --- /dev/null +++ b/reg/udral/README.md @@ -0,0 +1,283 @@ +# UDRAL + +This namespace contains data type definitions, network service specifications, usage guidelines and best practices, +and other documentation relating to the UAVCAN DRone Application Layer Specification (UDRAL). +The specification defines the application layer for applying UAVCAN v1 to (un)manned aerial vehicles, +including multirotors and fixed wing aircraft. + +The definitions are contained in two namespaces: + +- `physics` -- abstract data types to encapsulate many standard physical quantities, in scalar and vector, + timestamped and non-timestamped combinations. +- `service` -- narrowly specialized types for common applications. + +## Design philosophy and goals + +UDRAL is designed per the following goals: + +- Modern, highly orthogonal, consumer-focused service-oriented architecture optimized for composability and reuse. +- Robust interoperability between hardware supplied by different vendors. +- Reasonable bandwidth efficiency that allows satisfactory operation on a Classic CAN bus at 1 Mbps in simple vehicles. + Sophisticated deployments are expected to require a more capable transport, such as Ethernet or CAN FD. +- Plug-and-play (PnP) operation for simple use cases out of the box. + +### Service-oriented architecture + +The user of this standard is advised to get familiar with the basic principles of service-oriented design. +As a quick primer, [read Wikipedia](https://en.wikipedia.org/wiki/Service-oriented_architecture). +For a more in-depth review, please read the [UAVCAN Guide](https://uavcan.org/guide). + +The value of this or any other interoperability standard is in enabling compatible, composable, +and extensible complex systems. +A design that does not put these principles above the resource utilization concerns risks defeating the purpose +of the standard. +Hence, when designing a new network service, put the clarity of your models first, +then think about their performance implications. + +In service-oriented architectures, deciding what capabilities *not* to provide is just as important as +deciding what to include. +Imagine that in an aircraft you have an air data computer (not to be confused with a mere differential pressure sensor) +publishing the current airspeed estimate. +The air data computer is aware of the placement of the pitot probe and the local effects that may +influence its readings, so correcting for these effects is the task of the air data computer itself. +Therefore, the published airspeed should be the calibrated airspeed (CAS) rather than the raw +indicated airspeed (IAS). +The air data computer may require the ground speed estimate for calibration purposes, +in which case it is to subscribe to a ground speed topic published by another service (e.g., a GNSS receiver). +One might be tempted to enrich the service by providing the IAS alongside with CAS for the benefit of +the service consumer and for enhanced flexibility. +While easy to accomplish, it would be a design mistake because it might incentivize service consumers to +depend on the irrelevant implementation details of the service, +resulting in fragile architectures that are also hard to understand, maintain, and verify. +Encapsulation and interface segregation are just as important here as in software design. + +Composability is desirable for high-integrity systems also because it facilitates subsystem isolation for +testing and confines changes to a smaller number of subsystems, +thus reducing the costs of validation and verification. + +These design principles may constitute a departure from the practices commonly accepted in legacy systems, +which is necessitated by the increasing complexity of modern intravehicular software. + +However, the above is not to say that this design has no place for simpler network services that merely produce data +without much processing (e.g., basic sensor nodes), as long as the core values of UDRAL are respected. + +### Transports and bandwidth utilization + +Being forward-looking, this design is optimized for transports that offer +the data rates of at least ~4 Mbps and the MTU of at least ~64 bytes. +It is expected that in the foreseeable future all new applications will be leveraging transports whose +data transfer capability is at this level or higher +(this includes, for example, UAVCAN/UDP over Ethernet, UAVCAN/CAN over CAN FD, UAVCAN/serial over RS-422 or USB, etc). + +Note that UAVCAN v1 allows integrators to selectively disable irrelevant publications by reconfiguring the +appropriate port-ID registers (`uavcan.pub.*.id`), which is a powerful bandwidth management tool. + +Applications relying on Classic CAN (maximum data rate 1 Mbps, MTU 8 bytes) can still deploy these network services, +but the designer needs to be aware that most transfers will be multi-frame transfers and the resulting bus utilization +may be comparatively high. +Multi-frame transfers are not expected to cause performance issues because the official +UAVCAN implementation libraries are optimized for handling multi-frame transfers efficiently. + +The following resources are provided to help the integrator analyze bandwidth usage: + +- [UAVCAN/CAN bandwidth validation: Classic CAN](https://docs.google.com/spreadsheets/d/1zjpdPfmBf9oje2qjLYddlhFfkaQuTJ-VvQjHxzITils/edit) +- [UAVCAN/CAN bandwidth validation: CAN FD](https://docs.google.com/spreadsheets/d/1iK0MegMuEC55c-zTW6ssWhrA_sGUuSlT0S26xv5gytE/edit) + +## Typical applications + +The definitions in the `service` namespace contain descriptions of some common use cases +that can be addressed with this standard. +Adopters are expected to mix and match various components to create new network services that were not originally +envisioned by the authors of this standard. +This is possible while retaining full vendor-agnostic compatibility thanks to the service composability capabilities +described earlier. + +A practical hardware node would typically implement multiple services concurrently. +For example, a COTS (commercial off-the-shelf) electric drive may realistically implement the following: + +- Naturally, the ESC service. +- The servo service for generality. +- Acoustic feedback by subscribing to `reg.udral.physics.acoustics.Note`. +- Visual feedback via the LED by subscribing to `reg.udral.physics.optics.HighColor`. + +Another service that is interested in tracking the state of, say, a propeller drive +(say, for thrust estimation) would not need to concern itself with the ESC service at all. +Instead, it would simply subscribe to the generalized subject of type +`reg.udral.physics.dynamics.rotation.PlanarTs` published by the unit that drives the propeller +and extract its business-level information from that while being unaware of the specifics of the drive +(the propeller drive may be changed from an electric motor to a turboprop engine without affecting the +thrust estimation service). + +As another example, a flight control unit would not need to depend on the specifics of a GNSS positioning +service to obtain the location of the vehicle. +Instead, it would subscribe to a generic subject of a highly abstract type that models the location of +the vehicle in space (along with other related information such as time and pose), +which may as well be published by a mocap rig. + +## Port naming and auto-configuration + +### Port name prefixes + +In UAVCAN, the name of a port (i.e., subject or RPC-service) defines the names of related registers +as described in the documentation for the standard RPC-service `uavcan.register.Access`. +For instance, a node that publishes to the subject named `measurement` would have registers named +`uavcan.pub.measurement.id` and `uavcan.pub.measurement.type` (among others). + +> N.B.: Contrary to other protocols, in UAVCAN, the name of a port is a node-local property that does not affect + network exchanges over that port. + This means that nodes can publish/subscribe to a port even if they name it differently + as long as they are configured to use the same numerical port-ID. + The details are given in the UAVCAN Specification. + +Network service specifications given here under the `service` namespace provide the recommended names for +every defined port. +For example, the smart battery network service specification defines subjects named `status` and `parameters`. + +Using the suggested names in practical implementations directly is not always possible because nodes that +implement different network services or multiple instances of the same service would see naming conflicts +(e.g., many services define a subject named `status`). +Hence, implementations are advised to use the recommended port names with an application-defined prefix +such that ports that relate to the same instance of a network service share the same prefix. + +Imagine a node that implements two smart battery services (primary and secondary) +and a servo service (suppose we call it the main drive); +then it might have the following registers (among others): + + uavcan.pub.battery.primary.energy_source.id + uavcan.pub.battery.primary.status.id + uavcan.pub.battery.primary.parameters.id + uavcan.pub.battery.secondary.energy_source.id + uavcan.pub.battery.secondary.status.id + uavcan.pub.battery.secondary.parameters.id + uavcan.sub.main_drive.setpoint.id + uavcan.sub.main_drive.readiness.id + uavcan.pub.main_drive.feedback.id + uavcan.pub.main_drive.status.id + uavcan.pub.main_drive.power.id + uavcan.pub.main_drive.dynamics.id + +By virtue of such *semantic grouping* with shared prefixes, the registers clearly define three network services: + +- `battery.primary` +- `battery.secondary` +- `main_drive` + +The convention can be described in UML notation as follows: + + +-----------------------------------+ + | Network service specification | E.g., the smart battery network service + +-----------------------------------+ defined under reg.udral.service.battery + △ 0..* + ┆ + ┆ implements + ┆ + +-----------------------------------+ Example group "battery.primary": + | Prefixed port group | - battery.primary.energy_source + +-----------------------------------+ - battery.primary.status + │ - battery.primary.parameters + │ has + │ + ♢ 1..* + +-----------------------------------+ + | Port | + | (subject or RPC-service) | + +-----------------------------------+ + +Following this convention is highly recommended as it aids one's understanding of the node's functional capabilities +and may enable some systems to implement automatic assignment of port identifiers, as described next. + +### Special registers for auto-configuration + +A node can optionally permit automatic configuration of its port-ID registers (such as `uavcan.pub...`, etc.) +by providing special registers intended for this purpose. + +#### UDRAL cookie register + +The *cookie register* is a persistent mutable register named `udral.pnp.cookie` of type `string`. +Its default value is an empty string. + +This register should not be modified by the node locally; +instead, it is intended for remote modification over the register access service during the automatic port-ID +assignment process. + +The purpose of this register is to keep arbitrary state saved by an external node that is responsible for +automatic configuration of network participants. +For instance, on an UAV, the automatic configuration process may be carried out by the flight controller +or a mission computer. +The format and meaning of the stored string is entirely implementation-defined. + +#### Network service discovery registers + +In the example given earlier, we have a group of registers that define ports pertaining to two instances +of the standard UDRAL smart battery service and one instance of the standard UDRAL servo instance. +In order to enable automatic configuration of these services, +the node should announce the fact that they follow the UDRAL specification. +This is done with the help of the network service discovery registers. + +A network service discovery register is an immutable persistent (i.e., constant) register of type `string` +that contains space-separated port name prefixes such as `battery.primary`, `main_drive`, etc. +The name of a service discovery register is the name of the DSDL namespace that contains the service definition. +For example: + +- Register named `reg.udral.service.battery` is used to announce conformance to the UDRAL smart battery service. +- Register named `reg.udral.service.actuator.servo` --- UDRAL servo service. +- Register named `reg.udral.service.actuator.esc` --- UDRAL ESC service. + +The following table shows the registers and their values that announce conformance with the relevant services. +Observe how the main drive group implements two distinct (but similar) services simultaneously. + +Register name | Register type | Value +---------------------------------|-----------------|------------------------------------------- +`reg.udral.srv.battery` | `string` | `battery.primary battery.secondary` +`reg.udral.srv.actuator.servo` | `string` | `main_drive` +`reg.udral.srv.actuator.esc` | `string` | `main_drive` + +It is not necessary to include the leading and trailing name component separators `.` in the prefix names. +Registers that are not known to the auto-configuration authority are to be silently ignored, +which permits addition of implementation-defined ports without breaking compatibility with standard services. + + +#### Type signature register + +In many use cases it is desirable to have the ability to statically check the compatibility between sender and +receiver of a message. This capability could be used both during automatic configuration and by manual configurator tools. +The design allows this by adding an optional register per port that contains a string _data type signature_. + + uavcan.pub.PORT_NAME.type_sig + uavcan.sub.PORT_NAME.type_sig + uavcan.cln.PORT_NAME.type_sig + uavcan.srv.PORT_NAME.type_sig + +Where `PORT_NAME` is a placeholder defined in the +[documentation for `uavcan.register.Access`](https://github.com/UAVCAN/public_regulated_data_types/blob/b02e6899a319ddefbab41b820d167c95dd00174d/uavcan/register/384.Access.1.0.uavcan#L136-L139). +For example: `uavcan.sub.main_drive.setpoint.type_sig` + +Example signature would look like `(u12{u8}a5[f16]=i8)`, and be interpreted as + + - `()` delimit sealed type + - `{}` delimit extensible type + - `b`, `u`, `i`, `f`, `v` followed by size in bits encode primitive types + - `a` and `A` followed by length in items and brackets encode variable and fixed size arrays + - `=` marks byte alignment point + +This is a draft and informal description which would likely change. +Sample proof-of-concept code that generates type string from DSDL and compares two strings for compatibility can be seen at this +(temporary) location: . + + +## Conventions + +- Conventions defined in the UAVCAN Specification shall be followed. + +- All physical quantities except error variance should be represented as `float32` by default. + Error variance and covariance matrices should use `float16` by default. + +- Covariance matrices should be represented as their upper-right triangles using the matrix packing rules + defined in the Specification. + +- Types with (co)variance should be suffixed `Var`; types with timestamp should be suffixed `Ts`; + types with both should be suffixed `VarTs`. + The timestamp field, if present, should be the first one; + error (co)variance information should follow the data field(s) it relates to. + +- Publishers of measurements or estimates should apply low-pass filtering to avoid frequency aliasing. diff --git a/reg/drone/physics/acoustics/Note.0.1.uavcan b/reg/udral/physics/acoustics/Note.0.1.uavcan similarity index 100% rename from reg/drone/physics/acoustics/Note.0.1.uavcan rename to reg/udral/physics/acoustics/Note.0.1.uavcan diff --git a/reg/drone/physics/dynamics/README.md b/reg/udral/physics/dynamics/README.md similarity index 100% rename from reg/drone/physics/dynamics/README.md rename to reg/udral/physics/dynamics/README.md diff --git a/reg/drone/physics/dynamics/rotation/Planar.0.1.uavcan b/reg/udral/physics/dynamics/rotation/Planar.0.1.uavcan similarity index 80% rename from reg/drone/physics/dynamics/rotation/Planar.0.1.uavcan rename to reg/udral/physics/dynamics/rotation/Planar.0.1.uavcan index 649ac32d..7b79fe46 100644 --- a/reg/drone/physics/dynamics/rotation/Planar.0.1.uavcan +++ b/reg/udral/physics/dynamics/rotation/Planar.0.1.uavcan @@ -1,5 +1,5 @@ # Positive torque is co-directed with positive position/velocity/acceleration. # Provided states may allow the consumer to deduce certain hidden states such as the moment of inertia. -reg.drone.physics.kinematics.rotation.Planar.0.1 kinematics +reg.udral.physics.kinematics.rotation.Planar.0.1 kinematics uavcan.si.unit.torque.Scalar.1.0 torque # NaN if unknown @sealed diff --git a/reg/drone/physics/dynamics/rotation/PlanarTs.0.1.uavcan b/reg/udral/physics/dynamics/rotation/PlanarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/dynamics/rotation/PlanarTs.0.1.uavcan rename to reg/udral/physics/dynamics/rotation/PlanarTs.0.1.uavcan diff --git a/reg/drone/physics/dynamics/translation/Linear.0.1.uavcan b/reg/udral/physics/dynamics/translation/Linear.0.1.uavcan similarity index 80% rename from reg/drone/physics/dynamics/translation/Linear.0.1.uavcan rename to reg/udral/physics/dynamics/translation/Linear.0.1.uavcan index 45c5d03d..a29db7a3 100644 --- a/reg/drone/physics/dynamics/translation/Linear.0.1.uavcan +++ b/reg/udral/physics/dynamics/translation/Linear.0.1.uavcan @@ -1,5 +1,5 @@ # Positive force is co-directed with positive position/velocity/acceleration. # Provided kinetic states may allow the consumer to deduce certain hidden states such as the mass of the load. -reg.drone.physics.kinematics.translation.Linear.0.1 kinematics +reg.udral.physics.kinematics.translation.Linear.0.1 kinematics uavcan.si.unit.force.Scalar.1.0 force # NaN if unknown @sealed diff --git a/reg/drone/physics/dynamics/translation/LinearTs.0.1.uavcan b/reg/udral/physics/dynamics/translation/LinearTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/dynamics/translation/LinearTs.0.1.uavcan rename to reg/udral/physics/dynamics/translation/LinearTs.0.1.uavcan diff --git a/reg/drone/physics/electricity/Power.0.1.uavcan b/reg/udral/physics/electricity/Power.0.1.uavcan similarity index 100% rename from reg/drone/physics/electricity/Power.0.1.uavcan rename to reg/udral/physics/electricity/Power.0.1.uavcan diff --git a/reg/drone/physics/electricity/PowerTs.0.1.uavcan b/reg/udral/physics/electricity/PowerTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/electricity/PowerTs.0.1.uavcan rename to reg/udral/physics/electricity/PowerTs.0.1.uavcan diff --git a/reg/drone/physics/electricity/Source.0.1.uavcan b/reg/udral/physics/electricity/Source.0.1.uavcan similarity index 100% rename from reg/drone/physics/electricity/Source.0.1.uavcan rename to reg/udral/physics/electricity/Source.0.1.uavcan diff --git a/reg/drone/physics/electricity/SourceTs.0.1.uavcan b/reg/udral/physics/electricity/SourceTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/electricity/SourceTs.0.1.uavcan rename to reg/udral/physics/electricity/SourceTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/README.md b/reg/udral/physics/kinematics/README.md similarity index 100% rename from reg/drone/physics/kinematics/README.md rename to reg/udral/physics/kinematics/README.md diff --git a/reg/drone/physics/kinematics/cartesian/Point.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/Point.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/Point.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/Point.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/PointState.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PointState.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/PointState.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PointState.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/PointStateVar.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PointStateVar.0.1.uavcan similarity index 50% rename from reg/drone/physics/kinematics/cartesian/PointStateVar.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PointStateVar.0.1.uavcan index 86846319..f0a2515b 100644 --- a/reg/drone/physics/kinematics/cartesian/PointStateVar.0.1.uavcan +++ b/reg/udral/physics/kinematics/cartesian/PointStateVar.0.1.uavcan @@ -1,6 +1,6 @@ # See PointState for details. PointVar.0.1 position -reg.drone.physics.kinematics.translation.Velocity3Var.0.2 velocity +reg.udral.physics.kinematics.translation.Velocity3Var.0.2 velocity @sealed diff --git a/reg/drone/physics/kinematics/cartesian/PointStateVarTs.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PointStateVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/PointStateVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PointStateVarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/PointVar.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PointVar.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/PointVar.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PointVar.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/Pose.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/Pose.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/Pose.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/Pose.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/PoseVar.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PoseVar.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/PoseVar.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PoseVar.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/PoseVarTs.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/PoseVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/PoseVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/PoseVarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/State.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/State.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/State.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/State.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/StateVar.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/StateVar.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/StateVar.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/StateVar.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/StateVarTs.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/StateVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/StateVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/StateVarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/Twist.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/Twist.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/Twist.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/Twist.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/TwistVar.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/TwistVar.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/TwistVar.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/TwistVar.0.1.uavcan diff --git a/reg/drone/physics/kinematics/cartesian/TwistVarTs.0.1.uavcan b/reg/udral/physics/kinematics/cartesian/TwistVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/cartesian/TwistVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/cartesian/TwistVarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/geodetic/Point.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/Point.0.1.uavcan similarity index 87% rename from reg/drone/physics/kinematics/geodetic/Point.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/Point.0.1.uavcan index d7afe7cc..b59a1ebb 100644 --- a/reg/drone/physics/kinematics/geodetic/Point.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/Point.0.1.uavcan @@ -9,4 +9,4 @@ uavcan.si.unit.length.WideScalar.1.0 altitude # Distance between the local mean sea level (MSL) and the focal point of the antenna. Positive altitude above the MSL. @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.Point.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.Point.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/PointState.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/PointState.0.1.uavcan similarity index 80% rename from reg/drone/physics/kinematics/geodetic/PointState.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/PointState.0.1.uavcan index 7ce88578..da9abcfb 100644 --- a/reg/drone/physics/kinematics/geodetic/PointState.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/PointState.0.1.uavcan @@ -5,4 +5,4 @@ Point.0.1 position uavcan.si.unit.velocity.Vector3.1.0 velocity @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.PointState.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.PointState.0.1._bit_length_ diff --git a/reg/udral/physics/kinematics/geodetic/PointStateVar.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/PointStateVar.0.1.uavcan new file mode 100644 index 00000000..17ce7269 --- /dev/null +++ b/reg/udral/physics/kinematics/geodetic/PointStateVar.0.1.uavcan @@ -0,0 +1,7 @@ +# See PointState for details. + +PointVar.0.1 position +reg.udral.physics.kinematics.translation.Velocity3Var.0.2 velocity + +@sealed +@assert _offset_ == reg.udral.physics.kinematics.cartesian.PointStateVar.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan similarity index 63% rename from reg/drone/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan index e894c7e2..ec637442 100644 --- a/reg/drone/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/PointStateVarTs.0.1.uavcan @@ -2,4 +2,4 @@ uavcan.time.SynchronizedTimestamp.1.0 timestamp PointStateVar.0.1 value @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.PointStateVarTs.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.PointStateVarTs.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/PointVar.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/PointVar.0.1.uavcan similarity index 84% rename from reg/drone/physics/kinematics/geodetic/PointVar.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/PointVar.0.1.uavcan index 84052404..35990e79 100644 --- a/reg/drone/physics/kinematics/geodetic/PointVar.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/PointVar.0.1.uavcan @@ -6,4 +6,4 @@ float16[6] covariance_urt # [meter^2] # Element ordering: latitude, longitude, altitude. It is chosen to match the axis ordering of the NED frame. @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.PointVar.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.PointVar.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/Pose.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/Pose.0.1.uavcan similarity index 81% rename from reg/drone/physics/kinematics/geodetic/Pose.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/Pose.0.1.uavcan index 0c1c3130..ae654445 100644 --- a/reg/drone/physics/kinematics/geodetic/Pose.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/Pose.0.1.uavcan @@ -5,4 +5,4 @@ Point.0.1 position uavcan.si.unit.angle.Quaternion.1.0 orientation @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.Pose.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.Pose.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/PoseVar.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/PoseVar.0.1.uavcan similarity index 89% rename from reg/drone/physics/kinematics/geodetic/PoseVar.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/PoseVar.0.1.uavcan index 51ada42f..2810df66 100644 --- a/reg/drone/physics/kinematics/geodetic/PoseVar.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/PoseVar.0.1.uavcan @@ -14,4 +14,4 @@ float16[21] covariance_urt # Z rotation | @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.PoseVar.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.PoseVar.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/State.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/State.0.1.uavcan similarity index 69% rename from reg/drone/physics/kinematics/geodetic/State.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/State.0.1.uavcan index 5dd84f18..7a24ab98 100644 --- a/reg/drone/physics/kinematics/geodetic/State.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/State.0.1.uavcan @@ -3,7 +3,7 @@ # The twist is specified in the child frame (body frame). Pose.0.1 pose -reg.drone.physics.kinematics.cartesian.Twist.0.1 twist +reg.udral.physics.kinematics.cartesian.Twist.0.1 twist @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.State.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.State.0.1._bit_length_ diff --git a/reg/udral/physics/kinematics/geodetic/StateVar.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/StateVar.0.1.uavcan new file mode 100644 index 00000000..ef7f61f3 --- /dev/null +++ b/reg/udral/physics/kinematics/geodetic/StateVar.0.1.uavcan @@ -0,0 +1,7 @@ +# See State for details. This type extends it with covariance matrices. + +PoseVar.0.1 pose +reg.udral.physics.kinematics.cartesian.TwistVar.0.1 twist + +@sealed +@assert _offset_ == reg.udral.physics.kinematics.cartesian.StateVar.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/geodetic/StateVarTs.0.1.uavcan b/reg/udral/physics/kinematics/geodetic/StateVarTs.0.1.uavcan similarity index 60% rename from reg/drone/physics/kinematics/geodetic/StateVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/geodetic/StateVarTs.0.1.uavcan index e0411d23..58cee289 100644 --- a/reg/drone/physics/kinematics/geodetic/StateVarTs.0.1.uavcan +++ b/reg/udral/physics/kinematics/geodetic/StateVarTs.0.1.uavcan @@ -2,4 +2,4 @@ uavcan.time.SynchronizedTimestamp.1.0 timestamp StateVar.0.1 value @sealed -@assert _offset_ == reg.drone.physics.kinematics.cartesian.StateVarTs.0.1._bit_length_ +@assert _offset_ == reg.udral.physics.kinematics.cartesian.StateVarTs.0.1._bit_length_ diff --git a/reg/drone/physics/kinematics/rotation/Planar.0.1.uavcan b/reg/udral/physics/kinematics/rotation/Planar.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/rotation/Planar.0.1.uavcan rename to reg/udral/physics/kinematics/rotation/Planar.0.1.uavcan diff --git a/reg/drone/physics/kinematics/rotation/PlanarTs.0.1.uavcan b/reg/udral/physics/kinematics/rotation/PlanarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/rotation/PlanarTs.0.1.uavcan rename to reg/udral/physics/kinematics/rotation/PlanarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/Linear.0.1.uavcan b/reg/udral/physics/kinematics/translation/Linear.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/Linear.0.1.uavcan rename to reg/udral/physics/kinematics/translation/Linear.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/LinearTs.0.1.uavcan b/reg/udral/physics/kinematics/translation/LinearTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/LinearTs.0.1.uavcan rename to reg/udral/physics/kinematics/translation/LinearTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/LinearVarTs.0.1.uavcan b/reg/udral/physics/kinematics/translation/LinearVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/LinearVarTs.0.1.uavcan rename to reg/udral/physics/kinematics/translation/LinearVarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/Velocity1VarTs.0.1.uavcan b/reg/udral/physics/kinematics/translation/Velocity1VarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/Velocity1VarTs.0.1.uavcan rename to reg/udral/physics/kinematics/translation/Velocity1VarTs.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/Velocity3Var.0.1.uavcan b/reg/udral/physics/kinematics/translation/Velocity3Var.0.1.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/Velocity3Var.0.1.uavcan rename to reg/udral/physics/kinematics/translation/Velocity3Var.0.1.uavcan diff --git a/reg/drone/physics/kinematics/translation/Velocity3Var.0.2.uavcan b/reg/udral/physics/kinematics/translation/Velocity3Var.0.2.uavcan similarity index 100% rename from reg/drone/physics/kinematics/translation/Velocity3Var.0.2.uavcan rename to reg/udral/physics/kinematics/translation/Velocity3Var.0.2.uavcan diff --git a/reg/drone/physics/optics/HighColor.0.1.uavcan b/reg/udral/physics/optics/HighColor.0.1.uavcan similarity index 100% rename from reg/drone/physics/optics/HighColor.0.1.uavcan rename to reg/udral/physics/optics/HighColor.0.1.uavcan diff --git a/reg/drone/physics/thermodynamics/PressureTempVarTs.0.1.uavcan b/reg/udral/physics/thermodynamics/PressureTempVarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/thermodynamics/PressureTempVarTs.0.1.uavcan rename to reg/udral/physics/thermodynamics/PressureTempVarTs.0.1.uavcan diff --git a/reg/drone/physics/time/TAI64.0.1.uavcan b/reg/udral/physics/time/TAI64.0.1.uavcan similarity index 100% rename from reg/drone/physics/time/TAI64.0.1.uavcan rename to reg/udral/physics/time/TAI64.0.1.uavcan diff --git a/reg/drone/physics/time/TAI64Var.0.1.uavcan b/reg/udral/physics/time/TAI64Var.0.1.uavcan similarity index 100% rename from reg/drone/physics/time/TAI64Var.0.1.uavcan rename to reg/udral/physics/time/TAI64Var.0.1.uavcan diff --git a/reg/drone/physics/time/TAI64VarTs.0.1.uavcan b/reg/udral/physics/time/TAI64VarTs.0.1.uavcan similarity index 100% rename from reg/drone/physics/time/TAI64VarTs.0.1.uavcan rename to reg/udral/physics/time/TAI64VarTs.0.1.uavcan diff --git a/reg/drone/service/actuator/common/FaultFlags.0.1.uavcan b/reg/udral/service/actuator/common/FaultFlags.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/FaultFlags.0.1.uavcan rename to reg/udral/service/actuator/common/FaultFlags.0.1.uavcan diff --git a/reg/drone/service/actuator/common/Feedback.0.1.uavcan b/reg/udral/service/actuator/common/Feedback.0.1.uavcan similarity index 96% rename from reg/drone/service/actuator/common/Feedback.0.1.uavcan rename to reg/udral/service/actuator/common/Feedback.0.1.uavcan index 6e5bcbca..504b5a29 100644 --- a/reg/drone/service/actuator/common/Feedback.0.1.uavcan +++ b/reg/udral/service/actuator/common/Feedback.0.1.uavcan @@ -4,7 +4,7 @@ # be lower than the defined limit. # The priority of this message should be the same as that of the corresponding setpoint message. -reg.drone.service.common.Heartbeat.0.1 heartbeat +reg.udral.service.common.Heartbeat.0.1 heartbeat # If ENGAGED, the actuator provides service according to its nominal performance characteristics. # Otherwise, no availability guarantees are provided. # Notice that the feedback type is a structural subtype of the heartbeat type, so one can subscribe to a diff --git a/reg/drone/service/actuator/common/Status.0.1.uavcan b/reg/udral/service/actuator/common/Status.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/Status.0.1.uavcan rename to reg/udral/service/actuator/common/Status.0.1.uavcan diff --git a/reg/drone/service/actuator/common/_.0.1.uavcan b/reg/udral/service/actuator/common/_.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/_.0.1.uavcan rename to reg/udral/service/actuator/common/_.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Scalar.0.1.uavcan b/reg/udral/service/actuator/common/sp/Scalar.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Scalar.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Scalar.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector2.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector2.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector2.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector2.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector3.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector3.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector3.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector3.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector31.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector31.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector31.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector31.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector4.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector4.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector4.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector4.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector6.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector6.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector6.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector6.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/Vector8.0.1.uavcan b/reg/udral/service/actuator/common/sp/Vector8.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/Vector8.0.1.uavcan rename to reg/udral/service/actuator/common/sp/Vector8.0.1.uavcan diff --git a/reg/drone/service/actuator/common/sp/_.0.1.uavcan b/reg/udral/service/actuator/common/sp/_.0.1.uavcan similarity index 100% rename from reg/drone/service/actuator/common/sp/_.0.1.uavcan rename to reg/udral/service/actuator/common/sp/_.0.1.uavcan diff --git a/reg/drone/service/actuator/esc/_.0.1.uavcan b/reg/udral/service/actuator/esc/_.0.1.uavcan similarity index 91% rename from reg/drone/service/actuator/esc/_.0.1.uavcan rename to reg/udral/service/actuator/esc/_.0.1.uavcan index ec185ae8..13d66f98 100644 --- a/reg/drone/service/actuator/esc/_.0.1.uavcan +++ b/reg/udral/service/actuator/esc/_.0.1.uavcan @@ -14,36 +14,31 @@ # the state of the group: sleep, standby, or engaged. In many cases there will be one global subject controlling # the state of the entire system; in other cases there will be dedicated controls on a per-subsystem basis. # -# - Individual subjects, whose subject-ID is offset from the setpoint subject-ID `S` as a function of -# group member index `i` as specified below. +# - Feedback subjects published by each ESC separately, as shown on the diagram below. # -# SUBJECT -# NAME SUBJECT TYPE SUBJECT-ID +# SUBJECT NAME SUBJECT TYPE # +----------------+ -# | Controller |---------+------------+----... setpoint reg.drone.service.actuator.common.sp.* S -# | |-------+-)----------+-)----... readiness reg.drone.service.common.Readiness S+1 +# | Controller |---------+------------+----... setpoint reg.udral.service.actuator.common.sp.* +# | |-------+-)----------+-)----... readiness reg.udral.service.common.Readiness # +----------------+ | | | | # ^ ^ ^ ^ ^ ^ ^ ^ v v v v # | | | | | | | | +---------+ +---------+ # | | | | | | | | |Drive i=0| |Drive i=1| ... # | | | | | | | | +---------+ +---------+ # | | | | | | | | | | | | | | | | -# | | | | | | | +-----+ | | | | | | | feedback reg.drone.service.actuator.common.Feedback S+(i+1)*5+1 -# | | | | | | +---------+ | | | | | | status reg.drone.service.actuator.common.Status S+(i+1)*5+2 -# | | | | | +-------------+ | | | | | power reg.drone.physics.electricity.PowerTs S+(i+1)*5+3 -# | | | | +-----------------+ | | | | dynamics reg.drone.physics.dynamics.rotation.PlanarTs S+(i+1)*5+4 +# | | | | | | | +-----+ | | | | | | | feedback reg.udral.service.actuator.common.Feedback +# | | | | | | +---------+ | | | | | | status reg.udral.service.actuator.common.Status +# | | | | | +-------------+ | | | | | power reg.udral.physics.electricity.PowerTs +# | | | | +-----------------+ | | | | dynamics reg.udral.physics.dynamics.rotation.PlanarTs # | | | | | | | | # | | | +---------------------------+ | | | # | | +-------------------------------+ | | # | +-----------------------------------+ | # +---------------------------------------+ # -# Therefore, in order to configure a group member, one has to set up two parameters: the setpoint subject-ID and -# the group member index. -# # Notice that the physics subjects are timestamped. # -# Vendor/application-specific subjects are not shown here; their subject-IDs are implementation-defined. +# Vendor/application-specific subjects are not shown here. # Vendors are encouraged to publish additional data (e.g., temperatures) on separate subjects. # # @@ -67,7 +62,7 @@ # to enforce unless the drive is ENGAGED because it may require delivering power to the load. # # The setpoint message types that can be used to command a group of drives are defined in -# reg.drone.service.actuator.common.sp; please read the documentation related to that namespace for further information. +# reg.udral.service.actuator.common.sp; please read the documentation related to that namespace for further information. # Servo setpoint message types may also be supported on an implementation-specific basis for enhanced interoperability. # If the group is controlled using different setpoint subjects concurrently, the behavior is implementation-defined. # diff --git a/reg/drone/service/actuator/servo/_.0.1.uavcan b/reg/udral/service/actuator/servo/_.0.1.uavcan similarity index 80% rename from reg/drone/service/actuator/servo/_.0.1.uavcan rename to reg/udral/service/actuator/servo/_.0.1.uavcan index b720df36..0e2076f1 100644 --- a/reg/drone/service/actuator/servo/_.0.1.uavcan +++ b/reg/udral/service/actuator/servo/_.0.1.uavcan @@ -2,8 +2,8 @@ # # The type of load (translational or rotational) dictates which type is used for commanding the setpoint and reporting # the status: -# - reg.drone.physics.dynamics.rotation.Planar[Ts] -# - reg.drone.physics.dynamics.translation.Linear[Ts] +# - reg.udral.physics.dynamics.rotation.Planar[Ts] +# - reg.udral.physics.dynamics.translation.Linear[Ts] # For generality, either or both of these types are referred to as "timestamped dynamics" or "non-timestamped dynamics". # # The default readiness state is STANDBY. While in this state, the servo is not allowed to apply force to the load, @@ -13,21 +13,21 @@ # The subjects defined by this service are shown on the following canvas. Implementers are encouraged to add # custom subjects with additional data. Notice that the physics subjects are timestamped. # -# SUBJECT NAME SUBJECT TYPE RATE -# -# +------------+ setpoint +------------+ (non-timestamped dynamics) (see below) R -# | |----------------->| | -# | | readiness | | reg.drone.service.common.Readiness any -# | |----------------->| | -# | | feedback | | reg.drone.service.actuator.common.Feedback R -# | |<-----------------| | -# | Controller | status | Servo | reg.drone.service.actuator.common.Status any -# | |<-----------------| | -# | | power | | reg.drone.physics.electricity.PowerTs R -# | |<-----------------| | -# | | dynamics | | (timestamped dynamics) R -# | |<-----------------| | -# +------------+ +------------+ +# SUBJECT NAME SUBJECT TYPE RATE +# +# +------------+ setpoint +------------+ (non-timestamped dynamics) (see below) R +# | |--------------------->| | +# | | readiness | | reg.udral.service.common.Readiness any +# | |--------------------->| | +# | | feedback | | reg.udral.service.actuator.common.Feedback R +# | |<---------------------| | +# | Controller | status | Servo | reg.udral.service.actuator.common.Status any +# | |<---------------------| | +# | | power | | reg.udral.physics.electricity.PowerTs R +# | |<---------------------| | +# | | dynamics | | (timestamped dynamics) R +# | |<---------------------| | +# +------------+ +------------+ # # Should it be necessary to control a group of servos in lockstep, an arbitrary number of them may subscribe # to the same setpoint subject (their published subjects would be different of course). @@ -59,26 +59,25 @@ # Some applications may require synchronous independent control of multiple servos in a group, similar to ESC. # To address this, a compliant servo should support another operating mode where the controlled quantity # (position, velocity, force, etc.) is selected statically along with the motion profile (using the register API), -# and the servo subscribes to the setpoint subject of type "reg.drone.service.actuator.common.sp.*". +# and the servo subscribes to the setpoint subject of type "reg.udral.service.actuator.common.sp.*". # Having its index in the group configured statically, the servo fetches the setpoint from the appropriate # index in the setpoint array. # The resulting topology closely resembles that of the ESC service: # -# SUBJECT -# NAME SUBJECT TYPE +# SUBJECT NAME SUBJECT TYPE # +----------------+ -# | Controller |---------+------------+----... setpoint reg.drone.service.actuator.common.sp.* -# | |-------+-)----------+-)----... readiness reg.drone.service.common.Readiness +# | Controller |---------+------------+----... setpoint reg.udral.service.actuator.common.sp.* +# | |-------+-)----------+-)----... readiness reg.udral.service.common.Readiness # +----------------+ | | | | # ^ ^ ^ ^ ^ ^ ^ ^ v v v v # | | | | | | | | +---------+ +---------+ # | | | | | | | | |Servo i=0| |Servo i=1| ... # | | | | | | | | +---------+ +---------+ # | | | | | | | | | | | | | | | | -# | | | | | | | +-----+ | | | | | | | feedback reg.drone.service.actuator.common.Feedback -# | | | | | | +---------+ | | | | | | status reg.drone.service.actuator.common.Status -# | | | | | +-------------+ | | | | | power reg.drone.physics.electricity.PowerTs -# | | | | +-----------------+ | | | | dynamics (timestamped dynamics) +# | | | | | | | +-----+ | | | | | | | feedback reg.udral.service.actuator.common.Feedback +# | | | | | | +---------+ | | | | | | status reg.udral.service.actuator.common.Status +# | | | | | +-------------+ | | | | | power reg.udral.physics.electricity.PowerTs +# | | | | +-----------------+ | | | | dynamics (timestamped dynamics) # | | | | | | | | # | | | +---------------------------+ | | | # | | +-------------------------------+ | | @@ -127,5 +126,6 @@ # positive| negative # power | power # +# An example implementation is available at https://github.com/UAVCAN/demos @extent 0 diff --git a/reg/drone/service/battery/Error.0.1.uavcan b/reg/udral/service/battery/Error.0.1.uavcan similarity index 100% rename from reg/drone/service/battery/Error.0.1.uavcan rename to reg/udral/service/battery/Error.0.1.uavcan diff --git a/reg/drone/service/battery/Parameters.0.3.uavcan b/reg/udral/service/battery/Parameters.0.3.uavcan similarity index 86% rename from reg/drone/service/battery/Parameters.0.3.uavcan rename to reg/udral/service/battery/Parameters.0.3.uavcan index 54c5bd65..4a229922 100644 --- a/reg/drone/service/battery/Parameters.0.3.uavcan +++ b/reg/udral/service/battery/Parameters.0.3.uavcan @@ -48,14 +48,15 @@ uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_threshold # End-of-charging current threshold. Charging may be terminated when the current falls below this threshold. uavcan.si.unit.voltage.Scalar.1.0 charge_voltage -# The total voltage(not per-cell) that may be used by the charger to charge the battery pack. +# The total voltage (not per-cell) that may be used by the charger to charge the battery pack. uint16 cycle_count # The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime. # What constitutes a charge-discharge cycle is implementation-defined. -void16 -# Was used in v0.1 for cell_count. It is now deducible from cell_voltages in Status.0.2. +void8 +uint8 series_cell_count +# The number of cells connected in series. This value should match the array of cell voltages reported via Status. uint7 state_of_health_pct # [percent] # The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new). @@ -68,5 +69,11 @@ uavcan.si.unit.voltage.Scalar.1.0 nominal_voltage # The nominal voltage of the battery pack (not per-cell) as defined by the vendor. # E.g., a typical 22S LiCoO2 pack would usually report 81.4 V here. -@assert _offset_.count == 1 # It is intended to be a fixed-size type (although it's not required). -@extent 8 * 67 +truncated uint40 unix_manufacture_time +# The approximate UNIX Epoch time when the battery was manufactured, zero if unknown. + +uint8[<=64] name +# An arbitrary human-readable textual description of this battery. Empty if unknown/unused. +# Batteries that support SBS are recommended to report the manufacturer name and the device name here. + +@extent 8 * 300 diff --git a/reg/drone/service/battery/Status.0.2.uavcan b/reg/udral/service/battery/Status.0.2.uavcan similarity index 94% rename from reg/drone/service/battery/Status.0.2.uavcan rename to reg/udral/service/battery/Status.0.2.uavcan index 4b1f1cd6..a2b99071 100644 --- a/reg/drone/service/battery/Status.0.2.uavcan +++ b/reg/udral/service/battery/Status.0.2.uavcan @@ -1,6 +1,6 @@ # This low-rate battery status should be published at least once per second. -reg.drone.service.common.Heartbeat.0.1 heartbeat +reg.udral.service.common.Heartbeat.0.1 heartbeat # Note that the health code generally should not reflect the battery charge unless the service provider knows # that the availability of energy in the battery is critical for the safe operation of the vehicle, which is usually # not the case. For example, if the vehicle is equipped with several batteries that are discharged in series, one @@ -20,9 +20,6 @@ uavcan.si.unit.temperature.Scalar.1.0[2] temperature_min_max # the reported array value would be {258.15, 360.5} K. # If there is only one temperature sensor, both elements shall be of the same value. -void64 -# Was cell_voltage_min_max in v0.1. Deprecated in favor of cell_voltages array. - uavcan.si.unit.electric_charge.Scalar.1.0 available_charge # The estimated electric charge currently stored in the battery. This is intended for charging and maintenance only. # Do not use this parameter for endurance prediction! Instead, use the correct energy type from the physics namespace. diff --git a/reg/drone/service/battery/Technology.0.1.uavcan b/reg/udral/service/battery/Technology.0.1.uavcan similarity index 100% rename from reg/drone/service/battery/Technology.0.1.uavcan rename to reg/udral/service/battery/Technology.0.1.uavcan diff --git a/reg/drone/service/battery/_.0.1.uavcan b/reg/udral/service/battery/_.0.1.uavcan similarity index 82% rename from reg/drone/service/battery/_.0.1.uavcan rename to reg/udral/service/battery/_.0.1.uavcan index b74e3fef..a32c0fef 100644 --- a/reg/drone/service/battery/_.0.1.uavcan +++ b/reg/udral/service/battery/_.0.1.uavcan @@ -1,14 +1,14 @@ -# This is the smart battery monitoring service. A smart battery is required to publish the following subjects: +# This is the smart battery monitoring service. A smart battery is required to publish on the following subjects: # -# SUBJECT TYPE TYP. RATE [Hz] -# energy_source reg.drone.physics.electricity.SourceTs 1...100 -# battery_status reg.drone.service.battery.Status ~1 -# battery_parameters reg.drone.service.battery.Parameters ~0.2 +# SUBJECT TYPE TYP. RATE [Hz] +# energy_source reg.udral.physics.electricity.SourceTs 1...100 +# status reg.udral.service.battery.Status ~1 +# parameters reg.udral.service.battery.Parameters ~0.2 # # Observe that only the first subject can be used for estimating the endurance of the power source. The other subjects # are designed for monitoring, diagnostics, and maintenance. # -# Optionally, the battery service can subscribe to a readiness control subject (see reg.drone.service.common.Readiness), +# Optionally, the battery service can subscribe to a readiness control subject (see reg.udral.service.common.Readiness), # which enables the following two optional capabilities: # # - SLEEP mode: when the readiness subject commands the sleep state, the battery management system may enter a @@ -24,9 +24,9 @@ # # If readiness state selection is not supported, the battery may not subscribe to the readiness control subject, # in which case it should permanently report its state as ENGAGED unless the battery is unfit for use (e.g., due -# to degradation of a failure). +# to degradation or a failure). # -# By convention, positive power (current) flows from the DC network into the battery. Therefore, the current is +# By convention, positive current flows from the DC network into the battery. Therefore, the current is # negative when the battery powers the system, and positive when it is being charged. # # Systems that leverage multiple battery packs simultaneously should be configured to publish the status of each diff --git a/reg/drone/service/common/Heartbeat.0.1.uavcan b/reg/udral/service/common/Heartbeat.0.1.uavcan similarity index 100% rename from reg/drone/service/common/Heartbeat.0.1.uavcan rename to reg/udral/service/common/Heartbeat.0.1.uavcan diff --git a/reg/drone/service/common/Readiness.0.1.uavcan b/reg/udral/service/common/Readiness.0.1.uavcan similarity index 100% rename from reg/drone/service/common/Readiness.0.1.uavcan rename to reg/udral/service/common/Readiness.0.1.uavcan diff --git a/reg/drone/service/sensor/Status.0.1.uavcan b/reg/udral/service/sensor/Status.0.1.uavcan similarity index 100% rename from reg/drone/service/sensor/Status.0.1.uavcan rename to reg/udral/service/sensor/Status.0.1.uavcan