Redesign the dcmotor controller: setpoint inputs, torque-space gains.

The dcmotor input block is any subset of the canonical list [pos, vel,
ff, voltage], selected with input="pos vel ff voltage" and recorded as
mjtCtrlInput bits in actuator_ctrlspec like pid. Tokens are required in
canonical order: the attribute denotes a set, the block always packs
canonically, and accepting permutations invites reading the string as a
layout choice. The mode flag in gainprm[8] is retired (reserved,
written 0).

Controller gains are now in torque space, as for pid: the controller
commands tau = kp*(q*-l) + kd*(v*-ldot) + ki*x_I + tau_ff over the
present inputs (absent setpoints frozen at zero) and converts to drive
voltage V = R/K * tau + K*ldot. The second term compensates back-EMF,
as the current loop of a real torque-mode driver does (torque commands
are current commands): commanded torque is delivered exactly until a
limit binds, and the torque-speed envelope emerges from the Vmax clamp.
The map uses the nameplate R: thermal resistance growth is not
compensated, so a hot motor under-delivers by R/R(T). A stateless
setpoint dcmotor now matches <pid> exactly, for any K and R; the old
back-EMF droop remains available as the physical behavior of the raw
voltage path. Voltage-space datasheet gains convert by K/R. Controller
inputs require a positive motor constant (the map divides by K), and
controller gains require a controller input.

ff and voltage are distinct inputs, different in kind: ff is a torque
feedforward added to the controller output, uniform with pid's ff
(feedforward in the actuator's output space), while voltage is the raw
terminal voltage of the physical device, injected downstream of the
controller and its Vmax clamp, unclamped (ctrlrange bounds it if
desired). input="voltage" is the default: the plain voltage-commanded
motor, whose behavior is unchanged by this commit. The integrator
always accumulates position error; the old velocity mode's integral
term, ki*(int(u)dt - theta), which tracked the integral of the velocity
command, is retired without replacement, keeping ki mode-independent --
commanded integrated velocity belongs to an integrator activation
state, not to controller gains. slewmax rate-limits the first controller
input -- position setpoint (rad/s), velocity setpoint (rad/s^2) or torque
feedforward (N*m/s), each a real driver feature (reference ramping,
ramped-velocity and ramped-torque input modes); the raw voltage input
is never rate-limited and slewmax requires a controller input.

input="none" selects the empty signature: the actuator owns no controls
at all (nu = 0 is now legal with actuators present) and is purely
passive -- LuGre friction, cogging and back-EMF braking as passive
joint forces. This exists because auxiliary dynamic states (the LuGre
bristle) attach to actuators, not joints. The terminal voltage is
identically zero, i.e. a shorted motor (dynamic braking); motorconst=0
decouples the electrical branch. mjINPUT_NONE is a distinct enum value
because ctrlspec = 0 means "unset, use the type default". History and
delay require an input; the controller voltage override and input read
in mj_fwdActuation are gated on a nonempty block.

The analytic velocity derivative of the controller becomes
dV/dw = -kd*R/K + K, whose second term cancels the back-EMF bias
exactly: the net damping of an unclipped torque-mode motor is -kd, and
of a voltage-mode or passive motor -K^2/R. Viewers label inputs via
mj_actuatorInputName: pos, vel, ff, voltage.

The dcmotor LaTeX design doc is updated accordingly: torque-space
units, the tau->V map and its saturation-generated envelope, the
input-block pipeline figure, and a Passive Operation section.

PiperOrigin-RevId: 965795351
Change-Id: Ibc308ca21bd6bad014e77f950ee08feaad449b73

Author: yuvaltassa

doc/XMLreference.rst

@@ -5691,7 +5691,7 @@ specify them independently.
 
 .. _actuator-general-dyntype:
 
-:at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, pid, muscle, user], "none"`
+:at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, pid, dcmotor, muscle, user], "none"`
    Activation dynamics type for the actuator. The available dynamics types were already described in the :ref:`Actuation
    model <geActuation>` section. Repeating that description in somewhat different notation (corresponding to the mjModel
    and mjData fields involved) we have:
@@ -5711,7 +5711,7 @@ specify them independently.
 
 .. _actuator-general-gaintype:
 
-:at:`gaintype`: :at-val:`[fixed, affine, muscle, pid, so3, user], "fixed"`
+:at:`gaintype`: :at-val:`[fixed, affine, muscle, dcmotor, pid, so3, user], "fixed"`
    The gain and bias together determine the output of the force generation mechanism, which is currently assumed to be
    affine. As already explained in :ref:`Actuation model <geActuation>`, the general formula is:
    scalar_force = gain_term \* (act or ctrl) + bias_term.
@@ -5724,14 +5724,15 @@ specify them independently.
    fixed   gain_term = gainprm[0]
    affine  gain_term = gain_prm[0] + gain_prm[1]*length + gain_prm[2]*velocity
    muscle  gain_term = mju_muscleGain(...)
+   dcmotor DC motor gain (K or K/R), see :ref:`dcmotor<actuator-dcmotor>`
    pid     PID controller with setpoint inputs, see :ref:`pid<actuator-pid>`
    so3     geodesic orientation servo, computed jointly over 3 force outputs, see :ref:`orientation<actuator-orientation>`
    user    gain_term = mjcb_act_gain(...)
    ======= ===============================
 
 .. _actuator-general-biastype:
 
-:at:`biastype`: :at-val:`[none, affine, muscle, so3, user], "none"`
+:at:`biastype`: :at-val:`[none, affine, muscle, dcmotor, so3, user], "none"`
    The keywords have the following meaning:
 
    ======= ================================================================
@@ -5740,6 +5741,7 @@ specify them independently.
    none    bias_term = 0
    affine  bias_term = biasprm[0] + biasprm[1]*length + biasprm[2]*velocity
    muscle  bias_term = mju_muscleBias(...)
+   dcmotor DC motor bias: back-EMF, cogging, LuGre friction, see :ref:`dcmotor<actuator-dcmotor>`
    so3     damping term of the geodesic orientation servo, see :ref:`orientation<actuator-orientation>`
    user    bias_term = mjcb_act_bias(...)
    ======= ================================================================
@@ -5784,8 +5786,9 @@ specify them independently.
 :at:`input`: :at-val:`string, optional`
    Input signature of the actuator: which controls make up its control block, recorded in
    ``mjModel.actuator_ctrlspec``. For gaintype "so3" it selects the orientation chart: "expmap" (3 controls, the
-   default) or "quat" (4 controls); see :ref:`orientation/input<actuator-orientation-input>`. For gaintype "pid" it is
-   a token list selecting the input subset; see :ref:`pid/input<actuator-pid-input>`.
+   default) or "quat" (4 controls); see :ref:`orientation/input<actuator-orientation-input>`. For gaintypes "pid" and
+   "dcmotor" it is a token list selecting the input subset; see :ref:`pid/input<actuator-pid-input>` and
+   :ref:`dcmotor/input<actuator-dcmotor-input>`.
 
 .. _actuator-general-actearly:
 
@@ -6806,8 +6809,11 @@ the stateless case.
 - :ref:`resistance<actuator-dcmotor-resistance>`, :ref:`motorconst<actuator-dcmotor-motorconst>` and
   :ref:`nominal<actuator-dcmotor-nominal>` are each optional, but some combination of them is required.
   See Section 2.1 of the `technical note <_static/dcmotor.pdf>`__.
-- The control :ref:`input<actuator-dcmotor-input>` semantic is either the voltage applied to the motor terminals (the
-  default), or a position or velocity target for a :ref:`PID controller<actuator-dcmotor-controller>`.
+- The control block is selected by :ref:`input<actuator-dcmotor-input>`: any subset of ``[pos, vel, ff]``, where
+  ``pos`` and ``vel`` are setpoint inputs to the on-board :ref:`PID controller<actuator-dcmotor-controller>` and
+  ``ff`` is a torque feedforward added to its output; the ``voltage`` input is the raw terminal voltage. The
+  default is the plain voltage-commanded motor. With
+  ``input="none"`` the actuator has no control inputs at all and acts as a purely passive device.
 - Optional features include electrical dynamics (:ref:`inductance<actuator-dcmotor-inductance>`),
   :ref:`cogging torque<actuator-dcmotor-cogging>`, :ref:`thermal resistance variation<actuator-dcmotor-thermal>`, and
   :ref:`LuGre<actuator-dcmotor-lugre>` friction.
@@ -6946,22 +6952,37 @@ This element has the following custom attributes in addition to the common attri
 
 .. _actuator-dcmotor-input:
 
-:at:`input`: :at-val:`[voltage, position, velocity], "voltage"`
-   Specifies the input signal semantics. In "voltage" mode, the control directly sets applied motor voltage. In
-   "position" or "velocity" modes, the :ref:`PID controller<actuator-dcmotor-controller>` uses the control as a
-   reference setpoint relative to the joint trajectory. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5)
+:at:`input`: :at-val:`string, "voltage"`
+   Input signature: a space-separated subset of the tokens "pos", "vel", "ff" and "voltage", required in this
+   canonical order. The ``pos`` and ``vel`` inputs are setpoints for the on-board
+   :ref:`controller<actuator-dcmotor-controller>`, and ``ff`` is a torque feedforward added to its output, as for
+   :ref:`pid/input<actuator-pid-input>`. The ``voltage`` input is different in kind: it is the raw terminal voltage
+   of the physical device, applied downstream of the controller and its :at-val:`Vmax` clamp.
+   ``input="voltage"`` (the default) is the plain voltage-commanded motor. Absent setpoint inputs are fixed at zero.
+   The keyword "none" selects the empty signature: the actuator has no control inputs and is purely
+   passive, useful for modeling :ref:`friction<actuator-dcmotor-lugre>` and :ref:`cogging<actuator-dcmotor-cogging>`
+   as passive joint forces. The terminal voltage is zero, so back-EMF drives current through the (shorted) motor and
+   brakes the joint; setting :ref:`motorconst<actuator-dcmotor-motorconst>` to zero disables the electrical branch.
+   (see `tech note <_static/dcmotor.pdf>`__, Section 2.5)
 
 .. _actuator-dcmotor-controller:
 
 :at:`controller`: :at-val:`real(6), "0 0 0 0 0 0"`
    PID controller parameters, defined as :at:`controller` = ":at-val:`kp` :at-val:`ki` :at-val:`kd`
-   :at-val:`slewmax` :at-val:`Imax` :at-val:`Vmax`". Depending on the :at:`input` mode, the controller stabilizes
-   either position or velocity. If the :at:`input` mode is voltage, :at-val:`kp`, :at-val:`ki`, :at-val:`kd` are
-   ignored. :at-val:`Vmax` sets the maximum drive voltage :math:`v_{\max}` (Volt); in position/velocity modes it clamps
-   the controller output, in voltage mode it clamps the control signal (if :at:`ctrlrange` is also set, the tighter
-   limit wins). A value of 0 (the default) disables the respective feature. When positive, :at-val:`slewmax` limits the
-   setpoint rate-of-change, :at-val:`Imax` clamps the integrator state (anti-windup), and :at-val:`Vmax` clamps the
-   drive voltage. (see `tech note <_static/dcmotor.pdf>`__, Section 2.5)
+   :at-val:`slewmax` :at-val:`Imax` :at-val:`Vmax`". The gains are in torque space, as for
+   :ref:`pid<actuator-pid>`: the controller commands the torque
+   :math:`\tau = k_p (u_{pos} - l) + k_d (u_{vel} - \dot{l}) + k_i x_I + u_{f\!f}` over the inputs present in the
+   :ref:`input<actuator-dcmotor-input>` signature, absent setpoints being fixed at zero, and drives the voltage
+   :math:`v = (R/K)\,\tau + K \dot{l}`, the second term compensating back-EMF as in a current-controlled driver:
+   commanded torque is delivered exactly until a limit is reached. Torque-space gains from datasheet voltage-space
+   values are obtained by multiplying by :math:`K/R`. The integrator state
+   :math:`x_I` accumulates position error and requires the ``pos`` input; controller gains require a controller
+   input and a positive :ref:`motorconst<actuator-dcmotor-motorconst>`.
+   A value of 0 (the default) disables the respective feature. When positive, :at-val:`slewmax` limits the
+   rate-of-change of the first input (position setpoint in rad/s, or with signatures lacking ``pos``, velocity
+   setpoint or torque feedforward), :at-val:`Imax` clamps the integrator state (anti-windup), and :at-val:`Vmax`
+   clamps the drive voltage :math:`v_{\max}` (Volt), upstream of the raw ``voltage`` input.
+   (see `tech note <_static/dcmotor.pdf>`__, Section 2.5)
 
 .. _actuator-plugin:
 
@@ -6982,7 +7003,7 @@ Associate this actuator with an :ref:`engine plugin<exPlugin>`. Either :at:`plug
 
 .. _actuator-plugin-dyntype:
 
-:at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, pid, muscle, user], "none"`
+:at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, pid, dcmotor, muscle, user], "none"`
    Activation dynamics type for the actuator. The available dynamics types were already described in the :ref:`Actuation
    model <geActuation>` section. If :ref:`dyntype<actuator-general-dyntype>` is not "none", an activation variable will
    be added to the actuator. This variable will be added after any activation state computed by the plugin (see

doc/_static/dcmotor.pdf

@@ -31,6 +31,28 @@ Actuation
   identical to :ref:`position<actuator-position>`. The input signature is any subset of ``[pos, vel, ff]``, selected
   by :ref:`input<actuator-pid-input>`; absent setpoint inputs are fixed at zero, so the control vector contains no
   inert entries.
+- The :ref:`dcmotor<actuator-dcmotor>` on-board controller is redesigned: the
+  :ref:`input<actuator-dcmotor-input>` attribute selects any subset of ``[pos, vel, ff, voltage]``, where ``pos``
+  and ``vel`` are setpoints for the controller, ``ff`` is a torque feedforward, and ``voltage`` is the raw terminal
+  voltage (the default, a plain voltage-commanded motor). Controller gains are in torque space, as for
+  :ref:`pid<actuator-pid>`, and the drive voltage compensates back-EMF as in a current-controlled driver: commanded
+  torque is delivered exactly until a limit is reached. The keyword ``input="none"`` selects the empty signature:
+  the actuator has no control inputs and is purely passive, so friction, cogging and back-EMF braking can be used
+  as passive joint forces.
+
+.. admonition:: Breaking API changes
+   :class: attention
+
+   - The mode-flag semantics of :ref:`dcmotor/input<actuator-dcmotor-input>` ("voltage", "position", "velocity",
+     selecting the interpretation of a single control) are replaced by input signatures, and the controller gains
+     changed from voltage space to torque space. The old velocity mode's integral term (integrated-velocity
+     tracking) is retired without replacement; the integrator always accumulates position error.
+
+     **Migration:** Voltage-commanded motors (the default) are unchanged. Replace ``input="position"`` with
+     ``input="pos"`` and ``input="velocity"`` with ``input="vel"``, and multiply the controller gains by
+     :math:`K/R` (torque per volt). The motor's back-EMF damping, previously felt in addition to the controller's
+     damping, is now compensated: to preserve behavior when the velocity setpoint is zero, add :math:`K^2/R` to the
+     converted :at-val:`kd`.
 
 Engine
 ^^^^^^