Refactor the drone.physics namespace

It might look like a huge changeset, but it is not.
There are no semantic changes whatsoever, just renamings:
- reg.drone.{physics, service} => reg.drone.{phy, srv} because we are hitting the name length limit.
- dynamic and kinematic states have been slightly reorganized with no semantic changes to allow the addition of navigation types and air data types (coming next).
- Added one simple type for linear velocity with covariance, to be used with the air data types next.

.vscode/spellright.dict

@@ -399,3 +399,4 @@ DS-015
 allocatees
 Allocatee
 ABCD
+srv

reg/drone/README.md

@@ -6,8 +6,8 @@ If you have any questions, feel free to bring them to the [UAVCAN Forum](https:/
 
 This namespace contains the following nested namespaces:
 
-- `physics` -- abstract physical processes and states in the system.
-- `service` -- narrowly specialized types for common device classes.
+- `phy` -- abstract physical processes and states in the system.
+- `srv` -- narrowly specialized types for common device classes.
 
 ## Composable services
 
@@ -22,7 +22,7 @@ Make sure you understand 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 concrete service definitions given in the `service` namespace are intended for service implementers
+The concrete service definitions given in the `srv` namespace are intended for service implementers
 in the first place.
 If your objective is to depend on a service, then focus your attention on the other namespaces,
 because they provide a generalized view of common processes that is invariant to the means of their implementation.
@@ -32,13 +32,13 @@ For example, a COTS ESC 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`.
+- Acoustic feedback by subscribing to `reg.drone.phy.acoustics.Note`.
+- Visual feedback via the LED by subscribing to `reg.drone.phy.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.Angular1DTs` published by the unit that drives the propeller
+`reg.drone.phy.dynamics.Angular1DTs` 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).

reg/drone/phy/dynamics/README.md

@@ -0,0 +1,3 @@
+# Dynamic states
+
+Dynamic states extend kinematic states (defined in the adjacent namespace) with forces acting on the body.

reg/drone/physics/dynamics/Angular1D.0.1.uavcan → reg/drone/phy/dynamics/rotat/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.Angular1D.0.1 kinematics
+reg.drone.phy.kinematics.rotat.Planar.0.1 kinematics
 uavcan.si.unit.torque.Scalar.1.0 torque  # NaN if unknown
 @sealed

reg/drone/physics/kinematics/Linear1DTs.0.1.uavcan → reg/drone/phy/dynamics/rotat/PlanarTs.0.1.uavcan

@@ -1,3 +1,3 @@
 uavcan.time.SynchronizedTimestamp.1.0 timestamp
-Linear1D.0.1 value
+Planar.0.1 value
 @sealed

reg/drone/physics/dynamics/Linear1D.0.1.uavcan → reg/drone/phy/dynamics/trans/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.Linear1D.0.1 kinematics
+reg.drone.phy.kinematics.trans.Linear.0.1 kinematics
 uavcan.si.unit.force.Scalar.1.0 force  # NaN if unknown
 @sealed

reg/drone/physics/dynamics/Linear1DTs.0.1.uavcan → reg/drone/phy/dynamics/trans/LinearTs.0.1.uavcan

@@ -1,3 +1,3 @@
 uavcan.time.SynchronizedTimestamp.1.0 timestamp
-Linear1D.0.1 value
+Linear.0.1 value
 @sealed

reg/drone/phy/kinematics/README.md

@@ -0,0 +1,8 @@
+# Kinematic states
+
+This namespace contains data types that model basic [kinematic](https://en.wikipedia.org/wiki/Kinematics) states.
+
+A full kinematic state of a rigid body or fluid includes its position, velocity, acceleration, and orientation.
+The data types contained here model either full or partial kinematic states (e.g., there are types for velocity only).
+
+Forces acting on the body or fluid are part of its *dynamic* state, so they are excluded from the model.

reg/drone/physics/kinematics/Angular1DTs.0.1.uavcan → reg/drone/phy/kinematics/rotat/PlanarTs.0.1.uavcan

@@ -1,3 +1,3 @@
 uavcan.time.SynchronizedTimestamp.1.0 timestamp
-Angular1D.0.1 value
+Planar.0.1 value
 @sealed

reg/drone/physics/dynamics/Angular1DTs.0.1.uavcan → reg/drone/phy/kinematics/trans/LinearTs.0.1.uavcan

@@ -1,3 +1,3 @@
 uavcan.time.SynchronizedTimestamp.1.0 timestamp
-Angular1D.0.1 value
+Linear.0.1 value
 @sealed

reg/drone/service/actuator/common/Feedback.0.1.uavcan → reg/drone/srv/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.drone.srv.common.Heartbeat.0.1 heartbeat
 # If armed, 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

reg/drone/service/actuator/esc/_.0.1.uavcan → reg/drone/srv/actuator/esc/_.0.1.uavcan

@@ -20,18 +20,18 @@
 #
 #                                                   SUBJECT     TYPE                                        SUBJECT-ID
 #  +----------------+
-#  |   Controller   |---------+------------+----... setpoint    reg.drone.service.actuator.common.sp.*      S
-#  |                |-------+-)----------+-)----... arming      reg.drone.service.common.Arming             S+1
+#  |   Controller   |---------+------------+----... setpoint    reg.drone.srv.actuator.common.sp.*          S
+#  |                |-------+-)----------+-)----... arming      reg.drone.srv.common.Arming                 S+1
 #  +----------------+       | |          | |
 #   ^ ^ ^ ^  ^ ^ ^ ^        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.Angular1DTs      S+(i+1)*5+4
+#   | | | |  | | | +-----+ | | |      | | | |       feedback    reg.drone.srv.actuator.common.Feedback      S+(i+1)*5+1
+#   | | | |  | | +---------+ | |      | | | |       status      reg.drone.srv.actuator.common.Status        S+(i+1)*5+2
+#   | | | |  | +-------------+ |      | | | |       power       reg.drone.phy.electricity.PowerTs           S+(i+1)*5+3
+#   | | | |  +-----------------+      | | | |       dynamics    reg.drone.phy.dynamics.rotat.PlanarTs       S+(i+1)*5+4
 #   | | | |                           | | | |
 #   | | | +---------------------------+ | | |
 #   | | +-------------------------------+ | |
@@ -67,7 +67,7 @@
 # to enforce unless the drive is ARMED 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.drone.srv.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.
 #

reg/drone/service/actuator/servo/_.0.1.uavcan → reg/drone/srv/actuator/servo/_.0.1.uavcan

@@ -1,10 +1,10 @@
 # A servo can actuate either a translational or rotary load using electric power from the high-voltage DC bus.
 #
-# The type of load (translational or rotary) dictates which type is used for commanding the setpoint and reporting
+# The type of load (translational or rotational) dictates which type is used for commanding the setpoint and reporting
 # the status:
-#   - reg.drone.physics.dynamics.Linear1D[Ts]
-#   - reg.drone.physics.dynamics.Angular1D[Ts]
-# For generality, either or both of these types are referred to as "*1DTs" (timestamped) or "*1D" (non-timestamped).
+#   - reg.drone.phy.dynamics.rotat.Planar[Ts]
+#   - reg.drone.phy.dynamics.trans.Linear[Ts]
+# For generality, either or both of these types are referred to as "timestamped dynamics" or "non-timestamped dynamics".
 #
 # The default arming state is DISARMED. While disarmed, the servo is not allowed to apply force to the load,
 # and the setpoint subject is ignored. The servo shall enter the disarmed state automatically if the arming subject
@@ -15,17 +15,17 @@
 #
 #                    SUBJECT                            TYPE                                            RATE
 #
-#   +------------+   setpoint       +------------+      reg.drone.physics.dynamics.*1D  (see below)     R
+#   +------------+   setpoint       +------------+      (non-timestamped dynamics) (see below)          R
 #   |            |----------------->|            |
-#   |            |   arming         |            |      reg.drone.service.common.Arming                 any
+#   |            |   arming         |            |      reg.drone.srv.common.Arming                     any
 #   |            |----------------->|            |
-#   |            |   feedback       |            |      reg.drone.service.actuator.common.Feedback      R
+#   |            |   feedback       |            |      reg.drone.srv.actuator.common.Feedback          R
 #   |            |<-----------------|            |
-#   | Controller |   status         |   Servo    |      reg.drone.service.actuator.common.Status        any
+#   | Controller |   status         |   Servo    |      reg.drone.srv.actuator.common.Status            any
 #   |            |<-----------------|            |
-#   |            |   power          |            |      reg.drone.physics.electricity.PowerTs           R
+#   |            |   power          |            |      reg.drone.phy.electricity.PowerTs               R
 #   |            |<-----------------|            |
-#   |            |   dynamics       |            |      reg.drone.physics.dynamics.*1DTs                R
+#   |            |   dynamics       |            |      (timestamped dynamics)                          R
 #   |            |<-----------------|            |
 #   +------------+                  +------------+
 #
@@ -36,7 +36,7 @@
 # that contains a finite value is taken as the commanded setpoint. The following non-negative finite fields define
 # the motion profile, where negative and non-finite values are ignored.
 #
-# For example, a linear dynamics message containing the following values:
+# For example, a translational dynamics message containing the following values:
 #   position     = +0.35
 #   velocity     = NaN
 #   acceleration = NaN
@@ -59,25 +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.drone.srv.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     TYPE
 #  +----------------+
-#  |   Controller   |---------+------------+----... setpoint    reg.drone.service.actuator.common.sp.*
-#  |                |-------+-)----------+-)----... arming      reg.drone.service.common.Arming
+#  |   Controller   |---------+------------+----... setpoint    reg.drone.srv.actuator.common.sp.*
+#  |                |-------+-)----------+-)----... arming      reg.drone.srv.common.Arming
 #  +----------------+       | |          | |
 #   ^ ^ ^ ^  ^ ^ ^ ^        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    reg.drone.physics.dynamics.*1DTs
+#   | | | |  | | | +-----+ | | |      | | | |       feedback    reg.drone.srv.actuator.common.Feedback
+#   | | | |  | | +---------+ | |      | | | |       status      reg.drone.srv.actuator.common.Status
+#   | | | |  | +-------------+ |      | | | |       power       reg.drone.phy.electricity.PowerTs
+#   | | | |  +-----------------+      | | | |       dynamics    (timestamped dynamics)
 #   | | | |                           | | | |
 #   | | | +---------------------------+ | | |
 #   | | +-------------------------------+ | |

reg/drone/service/battery/Status.0.1.uavcan → reg/drone/srv/battery/Status.0.1.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.drone.srv.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

reg/drone/service/battery/_.0.1.uavcan → reg/drone/srv/battery/_.0.1.uavcan

@@ -1,9 +1,9 @@
 # This is the smart battery monitoring service. A smart battery is required to publish the following subjects:
 #
 #   SUBJECT                 TYPE                                            TYP. RATE [Hz]
-#   energy source state     reg.drone.physics.electricity.SourceTs          1...100
-#   battery status          reg.drone.service.sensor.battery.Status         ~1
-#   battery parameters      reg.drone.service.sensor.battery.Parameters     ~0.2
+#   energy source state     reg.drone.phy.electricity.SourceTs              1...100
+#   battery status          reg.drone.srv.sensor.battery.Status             ~1
+#   battery parameters      reg.drone.srv.sensor.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.