Reporting motor impulse under implicitfast: am I separating the force samples correctly?

[Slagathore]

Intro

Hi!

I am a solodev / researcher hobbyist (my masters was in chemistry lol). The project I'm doing right now is creating true physics locomotion with godot, rapier, and mujoco - all without RL, training, or hidden/extra forces moving the body.
https://github.com/Slagathore/LoColemotion

My setup

MuJoCo: 3.11.0, native CPU implementation. MJX was not used.
API: Python, using the official MuJoCo bindings with CPython 3.11.9.
NumPy: 2.4.6.
Architecture: x86-64 / AMD64, Intel Core i7-12700K.
OS: Windows 11 Pro for Workstations, version 24H2. Current OS build: 26100.9457.

My question

Hi, I’m Cole. I’ve been building LoColemotion, a portable Rust locomotion SDK with native adapters for Godot/Jolt, Rapier/Parry and MuJoCo. The other half of the project is an experiment harness that preregisters the questions and pass conditions, binds the source and runtime, requires qualification and authorization, and retains failed and invalid attempts.

I’d appreciate a check on how I’m describing one MuJoCo integration finding.

The retained study used MuJoCo 3.11.0 on Windows, the official Python wheel, and five 1/600 s implicitfast steps per 1/120 s controller command. In the first declared unloaded scalar cell, I retained the actuator force after mj_step2, before a subsequent mj_forward, separately from the force recomputed at the post-step state.

The first internal step gave:

• Force captured after mj_step2: −6 N·m
• Force recomputed at the post-step state: −1.5 N·m
• Motor impulse inferred from momentum change: −0.010 N·m·s

For the unsaturated portion of this exact fixture, the post-state force multiplied by the timestep agrees with the momentum change. The force captured before that recomputation still matters for identifying saturation and checking the force-time budget.

An earlier attempt sampled the wrong stage for its declared evaluation. The harness kept that attempt invalid; the corrected study had its own identity and passed its complete declared 24-cell grid.

[Short review packet, figure, exact profiles and original CSV](https://github.com/Slagathore/LoColemotion/blob/main/sdk/docs/ENGINE_REVIEW_PACKET.md)

Is this a sound way to distinguish the force observation used for budgeting from the effective motor impulse under implicitfast? Is there a recommended native measurement approach I should use before extending this reporting to models with contacts?

Minimal model and/or code that explain my question

This is the complete one-hinge model used for the first declared cell (unloaded_vn075_izero). It has zero gravity, no contacts, no passive joint damping and no external torque. It requires no binary assets.

The Python below is a shortened extraction of the original sampling sequence. I have not run this extraction as a separate experiment; the observations in my question come from the retained qualified run linked below.

Save the XML as model.xml and the Python as sampling.py in the same directory. The example prints 15 internal steps, grouped as three outer commands with five internal steps each.

Model:

Complete MJCF

<mujoco model="sporespore_mujoco_velocity_only_vh4">
  <compiler angle="radian" inertiafromgeom="true"/>
  <option timestep="0.0016666666666666668" gravity="0 0 0" integrator="implicitfast" solver="Newton" iterations="20" ls_iterations="7" cone="elliptic"/>
  <worldbody>
    <body name="child" pos="0 0 0">
      <joint name="hinge" type="hinge" pos="0 0 0" axis="1 0 0"
             armature="0.01" damping="0" limited="false"/>
      <geom name="child_geom" type="box" pos="0 0 0" size=".1 .1 .1"
             mass="1" contype="0" conaffinity="0"/>
    </body>
  </worldbody>
  <actuator>
    <velocity name="motor" joint="hinge" gear="1 0 0 0 0 0"
              ctrllimited="false" kv="10"
              forcelimited="true"
               forcerange="-6 6"/>
  </actuator>
</mujoco>

Code:

Python sampling sequence (MuJoCo 3.11.0)

import mujoco
import numpy as np

# Use the full XML shown above, saved as model.xml beside this script.
if mujoco.__version__ != "3.11.0":
    raise RuntimeError("This example targets MuJoCo 3.11.0.")

model = mujoco.MjModel.from_xml_path("model.xml")
data = mujoco.MjData(model)
observation = mujoco.MjData(model)
mass = np.empty((model.nv, model.nv), dtype=np.float64, order="C")

joint = model.joint("hinge").id
actuator = model.actuator("motor").id
qpos = int(model.jnt_qposadr[joint])
dof = int(model.jnt_dofadr[joint])
dt = float(model.opt.timestep)

data.qvel[dof] = 0.0
mujoco.mj_forward(model, data)
print("step,time_s,completed_force_Nm,recomputed_force_Nm,motor_impulse_Nms,qvel_rad_s")

# Three outer commands, each held over five internal physics steps.
for outer in range(3):
    for substep in range(5):
        mujoco.mj_step1(model, data)
        velocity_before = float(data.qvel[dof])
        mujoco.mj_fullM(model, data, mass)
        inertia_before = float(mass[dof, dof])
        data.ctrl[actuator] = -0.75
        data.qfrc_applied.fill(0.0)
        mujoco.mj_step2(model, data)

        # Retain these before any later force recomputation.
        completed_force = float(data.actuator_force[actuator])
        velocity_after = float(data.qvel[dof])
        impulse = inertia_before * (velocity_after - velocity_before)

        # Recompute on separate data, preserving the stepping data.
        observation.time = data.time
        observation.qpos[:] = data.qpos
        observation.qvel[:] = data.qvel
        observation.act[:] = data.act
        observation.qacc_warmstart[:] = data.qacc_warmstart
        observation.ctrl[:] = data.ctrl
        observation.qfrc_applied.fill(0.0)
        observation.xfrc_applied.fill(0.0)
        mujoco.mj_forward(model, observation)
        recomputed_force = float(observation.actuator_force[actuator])

        step = outer * 5 + substep
        print(f"{step},{data.time:.17g},{completed_force:.17g},"
              f"{recomputed_force:.17g},{impulse:.17g},{velocity_after:.17g}")

For this unloaded, one-DoF fixture, the momentum-inferred motor impulse is M * (v_after - v_before). This calculation is specific to the fixture; it does not separate motor impulse from other forces in a contact-rich model.

The first three rows of the original retained data, rounded for readability:

Internal step (zero-based)	Force captured after mj_step2 (N m)	Force recomputed at the post-step state (N m)	Momentum-inferred motor impulse (N m s)
0	-6	-1.5	-0.010
1	-1.5	-0.75	-0.00125
2	-0.75	-0.375	-0.000625

Original 1,800-row CSV

Review packet and retained declarations/closures

Original model and sampling implementation

This figure shows the first 12 internal steps of the first declared VH4 cell, unloaded_vn075_izero, from the original retained run. The full 1,800-row trace for that cell is linked above.

Confirmations

• I searched the latest documentation thoroughly before posting.
• I searched previous Issues and Discussions, I am certain this has not been raised before.

[Wahaj18]

Yes—the split you are making is real, and for an unloaded hinge with implicitfast it is a sound way to separate “force that participated in this substep” from “force evaluated at the post-step state.”

In the pipeline docs, mj_step1 runs through the position/velocity stages and stops before forces are finished; mj_step2 runs actuation → acceleration → constraints → integration. Actuator outputs are written in mj_fwdActuation into mjData.actuator_force (and assembled into mjData.qfrc_actuator). So the value you read immediately after mj_step2, before another forward pass, is the force that belonged to that completed step.

Calling mj_forward on the updated qpos/qvel (your observation copy) recomputes actuation at the new state with the same ctrl. With a velocity-dependent or saturated motor, that post-state force can differ from the in-step force—exactly the −6 N·m vs −1.5 N·m pattern you saw. Matching recomputed_force * dt to the momentum change on the unsaturated cells is what you want for “effective impulse over the step”; keeping the pre-recompute actuator_force is what you want for saturation / force-time budget bookkeeping.

A couple of tightenings I would make before contacts:

1. Prefer a native sensor over ad-hoc reads where you can: actuator_force copies mjData.actuator_force, and jointactuatorfrc reports the generalized force from all actuators into one hinge/slider (XML sensor reference). Same quantities, less chance of sampling the wrong index after the model grows.
2. When contacts appear, momentum change is no longer “motor impulse only”—constraint forces participate. Keep the same two force samples for budgeting/saturation, but treat ΔL as the net generalized impulse (actuator + constraints + applied). I think the clean check is to compare jointactuatorfrc (or qfrc_actuator) against the residual after subtracting measured constraint contributions, rather than expecting raw Δ(mv) to equal actuator_force·dt alone.
3. Your mj_step1 → write ctrl → mj_step2 split is the supported way to inject controls that depend on mid-step kinematics for single-step integrators (implicitfast included). Just remember that path is not valid for RK4.

So: keep both samples, document which one is “completed step” vs “post-state evaluate,” and switch impulse accounting to net generalized impulse as soon as contacts are on. The unloaded fixture logic looks right.

[Slagathore]

Thanks, this is the check I wanted. Taking both suggestions: actuatorfrc / jointactuatorfrc sensors instead of indexed reads, and net generalized impulse once contacts are in.

For anyone who lands here later, the source explains why the post state force is the one that actually got applied under implicitfast:

src/engine/engine_forward.c (around line 1587 in 3.11.0): implicitfast builds qH = M - dt * qDeriv and solves against that. qDeriv comes from mjd_smooth_vel, which includes mjd_actuator_vel. A velocity actuator’s force is linear in qvel, so the step ends up applying the force at the post step velocity. That’s why recomputed_force * dt matches the momentum change on the unsaturated steps.
src/engine/engine_derivative.c (around line 2044): mjd_actuator_vel skips any actuator that’s clamped by forcerange. No derivative means that step goes explicit, so the applied impulse is just the clamped force times dt. First row: −6 × (1/600) = −0.010.

So the two samples are the budget’s view (completed step force, catches saturation) and the integrator’s view (post state force, what actually moved the joint when unsaturated), and momentum change agrees with whichever one applied. Marking this answered.