OPEN SOURCE DEEP DIVE
ProceduralLocomotion: Torque-Balanced Procedural Ragdoll Biped Locomotion without RL or Mocap
An engine-native Unity architecture: hand-tuned PD balance controller plus raycast-triggered per-foot IK with ConfigurableJoint physics — physically simulated ragdoll biped balance and locomotion without mocap, offline optimization, or RL, with control-theory derivation and an evaluation protocol.
Project Positioning: Getting Up a Ragdoll Biped Without RL or Motion Capture
Torque-Balanced Procedural Locomotion for Ragdoll Bipeds is a Unity 3D open-source architecture for physically simulated bipedal balance and locomotion. What makes it distinctive is what it does not use: no motion capture reference data, no offline optimization, no reinforcement learning. The entire system consists of three small, independently tunable controllers — a hand-tuned PD balance controller, a geometrically-triggered per-foot IK solver, and a target-seeking movement controller — coupled through minimal shared state, with all skeletal physics delegated to Unity's built-in ConfigurableJoint. It is aimed at solo developers and small teams who want physically-reactive characters without the compute, tooling, or reference-data infrastructure that academic control pipelines require.
Core Architecture: Three Minimal Controllers
Most physically-simulated characters rely either on offline optimization against a biomechanical objective or on RL policies trained against motion-capture data. This project deliberately takes the opposite path:
| System | Function |
|---|---|
| Balance Controller | A PD controller applying corrective root torque every physics step to keep the ragdoll upright (uprightTorqueStrength = k_p, balanceDamping = k_d) |
| Per-Foot IK Solver | Independent raycast-triggered foot placement; steps alternate via a simple IsMoving() check — no explicit gait timing signal |
| Target-Seeking Movement | Drives rotation and velocity toward the nearest tagged target |
Two companion subsystems follow the same design philosophy: procedural hand reach & anchoring (a shoulder-pivoted reach envelope with lock-and-pivot climbing/bracing) and a physical interaction handoff (detect, snap, and control-remap for pushing movable objects). Joint limits and spring/damper responses come entirely from PhysX — there is no custom dynamics model anywhere in the stack.
The Scientific Part: A Falsifiable Control-Theory Model
Where this project goes beyond a typical game-engine demo is in its treatment of the balance controller as a first-order scientific object. Rather than tuning gains by feel, the author derives a linearized second-order control-theory model — characterized by natural frequency and damping ratio — directly from the implementation. The model produces falsifiable predictions about recovery time and stability that are then tested empirically. The paper (included in the repository's /paper directory) contains the full theoretical derivation and evaluation results.
The evaluation protocol ships with reference C# instrumentation:
- Perturbation recovery sweep — 48 trials (6 magnitudes × 8 trials), run fully unattended via the
PerturbationLoggercomponent; the demo shows the ragdoll reacting in real time to thrown objects and recovering balance through PD torque - Gait regularity logging — dry run completed, data insufficient — documented honestly rather than papered over
- Gain-space stability sweep and per-frame cost profiling — protocols defined, not yet run
One methodological finding is worth noting: the initial perturbation range turned out to be too conservative to characterize real recovery dynamics — exactly the kind of honest limitation reporting that distinguishes research from marketing.
Engineering and Usage
The project requires Unity 3D with the PhysX backend, plus Cinemachine, Animation Rigging, and the Input System packages. Evaluation scripts are standalone components designed to sit alongside production scripts without modifying them: attach RagdollResetter to the character root, PerturbationLogger to run sweeps, and GaitLogger with both IK foot references to log step regularity. Trials trigger from the Inspector context menu or via keybinds; CSV logs land in Application.persistentDataPath. Gain tuning follows classic second-order-system intuition: too much torque relative to damping yields visible wobble (underdamped), too much damping yields sluggish recovery (overdamped).
Assessment
This project occupies an interesting niche: it is a locomotion controller for a simulated biped — squarely in the robotics-relevant territory of balance and walking — but executed entirely within a game engine with classical control theory instead of learned policies. Its value for the robotics community is primarily pedagogical and architectural: a clean demonstration that PD-level balance with per-foot geometric IK can produce visibly robust push-recovery behavior, plus a rare example of a hobbyist project shipping a falsifiable control-theory model and an honest evaluation protocol. It is not a sim-to-real pipeline and makes no such claim; two of four planned experiments remain unrun. For teams exploring lightweight, interpretable balance controllers — or building physically-reactive characters without RL infrastructure — it is a well-documented reference implementation.