Inverse dynamics control

Overview

Inverse dynamics control treats the robot as if every joint were actuated. It asks which generalised force would produce a commanded acceleration, using the robot's dynamics model 2412.09816 §3 2412.09816 eq. 5.

The two cards use this computation in different places. In 2412.09816 §3 it is the core of a feedback controller for a legged robot. In 2603.05493 §6.3 the same kind of pass runs for each candidate trajectory inside an optimiser, and its output is checked against torque limits. The second use is a feasibility check, not a feedback loop.

A legged robot is not fully actuated, since the body is only moved through the contact forces of the feet. The feedback controller therefore has two further jobs: pick contact forces that can be realised, and map the rest of the command onto the joints. The 2412 card covers both jobs for a quadruped 2412.09816 §3.

The 2412 design rests on three assumptions. Each foot in contact does not slip 2412.09816 §2.1. At least two feet are in contact at any time, so the base map has full row rank 2412.09816 §3. The gait and step length are chosen so that the Jacobians do not become rank-deficient 2412.09816 §3. The experiments are on flat ground with a trotting gait 2412.09816 §6.

The 2603 torque check rests on a payload model. Its headline result uses a 3 kg payload at the end effector, but the paper does not describe how that payload enters the inertial model 2603.05493 §7.1.

Variants

The first three variants come from one paper. The last comes from the second card, and it is a constraint on a planner, not a controller.

Exact friction cone with a projected-gradient solver

The contact forces come from a regularised least-squares problem. It penalises the base-wrench error, the size of the forces and their change from the previous step, and it keeps the friction cone exactly rather than a linear pyramid 2412.09816 eq. 12 2412.09816 eq. 14. The paper solves it with its own method, GPGD, which takes a Newton-type step and then projects each foot's force onto the bounds and the cone 2412.09816 alg. 1 2412.09816 §4. Card: Distributed Inverse Dynamics Control for Quadruped Robots using Geometric Optimization.

Null-space split of joint tracking

The joint torques are projected into the null space of the map from joint torques to base wrench. The paper argues that this leaves the base motion unchanged, so the base task has priority over the joint task 2412.09816 eq. 16 2412.09816 eq. 18 2412.09816 eq. 19. The projector is printed in a form that does not multiply out, so the proof form is the one to implement 2412.09816 §3; see the sketch below. This split is separate from the force solver and can be used with any force distribution that gives the base wrench.

Baselines in the same paper

The card compares against two controllers that run on the same robot. Null-space inverse dynamics control, NSPIDC, does not enforce the friction constraints, so its contact forces can slip 2412.09816 §2.2. QP balance control adds the joint torques directly to the base torques, which changes the base motion 2412.09816 §2.3.

Inverse dynamics as a torque constraint in trajectory optimisation

The planner represents each joint's trajectory as a uniform cubic B-spline and optimises its control points 2603.05493 §4. Torque limits are constraints in that optimisation. Each candidate is passed through an RNEA (inverse dynamics) pass, so a trajectory that asks for too much torque under the given payload is penalised 2603.05493 §3 2603.05493 §6.3. The gradient through this pass is computed with an adjoint RNEA, which costs O(n) and avoids forming an n-by-n Jacobian 2603.05493 alg. 5 2603.05493 §6.3. The adjoint's selector s_k is not defined in the paper, so check its index and sign conventions against a reference RNEA; the authors used Pinocchio in their own tests 2603.05493 alg. 5 2603.05493 §8.

The reported effect is on the whole planner. On a Franka benchmark of 2600 problems with a 3 kg payload, success was 99.7%, against 77.1% for cuRobo 2603.05493 §7.1 2603.05493 fig. 11. The comparison includes the spline, collision and energy terms, so it does not isolate the torque term. The cost of the dynamics term is reported separately: with dynamics on, the time per trajectory-optimisation iteration rose from 97.7 us to 132.8 us, and end-to-end time from 35 ms to 42 ms 2603.05493 §7.2 2603.05493 tab. 3. Card: cuRoboV2: Dynamics-Aware Motion Generation with Depth-Fused Distance Fields for High-DoF Robots.

When to use which

Implementation sketch

The sketch follows the equations cited on each line. It is our arrangement, not a listing from the paper. The model estimates M_hat and eta_hat come from the caller, since the paper does not say where they are obtained 2412.09816 eq. 5. It covers the 2412 feedback controller. The RNEA used for torque limits in 2603.05493 alg. 4 is a different routine and is not sketched here.

# One inverse-dynamics step for a legged robot  [§3; eqs. 5, 9, 12-19]
# Output: tau (12,) joint torques

def inverse_dynamics_step(q, dq, desired, stance, params):
    # Commanded acceleration: PD per DOF around the desired motion  [eq. 9]
    err = space_minus(desired.q, q)
    acc_cmd = desired.acc + Kp @ err + Kd @ (desired.dq - dq)
    # Generalised force from the estimated model  [eq. 5]
    tau_full = M_hat @ acc_cmd + eta_hat
    tau_base, tau_joint = tau_full[:6], tau_full[6:]
    # Contact Jacobians, rows for stance feet only  [eqs. 10, 11]
    J_ab, J_aa = contact_jacobians(q, stance)
    # Contact forces: base-wrench fit with the exact cone  [eqs. 12-14]
    forces = solve_cone_qp(J_ab, tau_base, prev_forces, stance, params)
    # Stance-leg torques that produce those forces  [eq. 15]
    tau_stance = -J_aa.T @ forces
    # Joint torque to base wrench map, and its null-space projector  [eqs. 16, 18]
    J_base = -J_aa.T @ pinv(J_ab.T)
    N = eye(12) - J_base @ inv(J_base.T @ J_base) @ J_base.T
    # Joint tracking acts only in the null space  [eq. 19]
    return tau_stance + N @ tau_joint

The printed projector in 2412.09816 eq. 18 does not multiply out, so the sketch uses the transposed form that the paper's proof uses 2412.09816 §3. The force solver needs one correction to be implementable. As printed, 2412.09816 alg. 1 never copies the new iterate back into the current one, so a literal reading repeats the same step. The paper does not say how the warm start prev_forces relates to the solver's starting point 2412.09816 alg. 1 2412.09816 §3. The stop test is an absolute tolerance of 1e-2 with no unit given 2412.09816 alg. 1.

Contradictions

No claim is contradicted across the two cards, because they use inverse dynamics for different purposes 2412.09816 §3 2603.05493 §6.3. Within the 2412 paper, the printed force-solver algorithm does not match the text it describes: its iterate is never updated, although its stop test assumes that it is 2412.09816 alg. 1 2412.09816 §4. The text also calls the orientation study in §6.1.1 an experiment, while its figure caption says simulation 2412.09816 §6.1.1 2412.09816 fig. 10.

Papers

• Distributed Inverse Dynamics Control for Quadruped Robots using Geometric Optimization: an inverse dynamics controller for an 18-DOF quadruped, with an exact-cone force solver (GPGD), a null-space joint split and a gait and estimation stack; author-reported in simulation and on a Unitree Go2.
• cuRoboV2: Dynamics-Aware Motion Generation with Depth-Fused Distance Fields for High-DoF Robots: a GPU motion stack whose trajectory optimiser evaluates RNEA and its adjoint to enforce torque limits; author-reported against cuRobo and other planners, with the dynamics term not isolated.