Why does joint PID tracking in a Simscape Multibody leg model degrade when Spatial Contact Force is enabled, while it works well without ground contact (XZ plane)?

I am simulating a simplified lower-limb / prosthetic leg in Simscape Multibody with 3 revolute joints (hip, knee, ankle). The motion is intended to be planar in the sagittal plane (XZ).What I am doing

• I provide reference joint trajectories for hip/knee/ankle from a gait dataset (10 concatenated gait cycles) using three timeseries signals:
• hip_ts, knee_ts, ankle_ts
• Each joint is controlled by a joint-level PID/PD block that outputs a torque
• The measured joint angles q are taken from the joint sensors and fed back to the controller (scopes show reference vs simulated for each joint).

What works (no contact)

If I disable ground contact, the joint tracking is reasonably good for all joints (hip/knee/ankle). The simulated angles follow the reference signals with small error.

The problem (with contact enabled)

When I enable foot–ground contact using Spatial Contact Force (foot geometry vs ground plane), the tracking becomes much worse:

• large tracking errors / oscillations appear
• the behavior looks unstable or heavily disturbed during stance/contact phases
• the same PID gains that work without contact no longer work

What I suspect / questions

I am trying to understand what is causing this degradation when contact is enabled:

1. Is this mainly due to the contact model parameters (stiffness, damping, friction) creating stiff dynamics that destabilize the joint PID?
2. Could the issue be caused by unintended extra DOFs at the hip/base (e.g., the hip not fully constrained in the plane), so contact forces introduce out-of-plane motion or additional dynamics?
3. Is it conceptually wrong to expect simple joint PID tracking to work well when contact forces are present, and should I instead use:

• impedance control at the joints,
• inverse dynamics / computed torque,
• or a constraint-based approach for stance?

What I can provide

• Screenshot of the Simulink/Simscape model (joint controllers + Spatial Contact Force block)
• Scope screenshots showing reference vs actual joint angles for hip/knee/ankle
• Contact block settings (stiffness/damping/friction) and solver settings if needed

Question: What are the most common reasons why enabling Spatial Contact Force makes joint-level PID tracking degrade dramatically in Simscape Multibody, and what specific checks/changes would you recommend (contact parameters, solver, constraints/DOFs at hip/base, control structure)?

Answer 1

[Jan Janse van Rensburg]

The Core Problem: Over-Constraint

The fundamental issue is that your model is mechanically over-constrained.

You are likely fixing the Hip frame in space (making it immovable). When the foot hits the ground, you create a closed kinematic chain. Since the hip cannot move up, the PID controllers force the leg to try and penetrate the ground to satisfy the recorded joint angles.

This creates a conflict: The ground won't move, the hip won't move, but the angles must change. The result is massive force fighting and instability.

Solutions

To fix this, you need to introduce compliance (movement) into the system.

1. The Quick Fix (Compliant Ground)

• Allow the Ground to move instead of the leg.
• Place a Cartesian Joint between the World frame and the Ground.
• Add high stiffness/damping (spring-damper) in the Z-direction of that joint.
• Result: The ground "gives way" slightly when the foot pushes down, preventing the infinite force spike.

2. The Better Approach (Vertical Hip Motion)

• Allow the Leg/Hip to move vertically.
• Add a Prismatic Joint (Z-axis) between the World frame and the Hip.
• Add a mass to the Hip (e.g., half the wearer's body mass) to represent the upper body inertia.
• Result: When the foot pushes the ground, the hip is lifted up naturally, mimicking real walking physics.

3. The "Correct" Approach (Full Simulation)

• Model the entire system as a virtual test dummy with 6-DOF at the pelvis.
• This allows the body to translate and rotate freely in response to the leg forces, exactly like a human.

Answer 2

[Michele]

Thank you very much for your detailed and insightful explanation.

Following your suggestions, I have modified the setup in the following way:

• I added a Prismatic Joint along the Z axis between the World frame and the hip/base frame, so that the leg can move vertically during stance.
• I also added an Inertia/Mass block to the hip/base to represent upper body inertia and avoid an unrealistically massless pelvis.

Despite this change, the foot–ground contact still does not behave as expected. During stance, the interaction remains unstable/disturbed and the joint tracking degrades significantly compared to the no-contact case. I am attaching a short video that shows the current behavior.

To further investigate, I also tried:

• Replacing the single prismatic joint with a Cartesian Joint (allowing motion in X and Z),
• Modulating the Spatial Contact Force parameters (normal stiffness, damping, friction) over a wide range.

While these changes affect the behavior, the contact still seems problematic and does not yet lead to stable, physically plausible stance dynamics.

At this point, I suspect there may still be something subtle in the constraint/DOF setup or in the way the contact forces interact with the joint-level control, and I would really appreciate any further insight you might have.

Thanks again for taking the time to answer.

[Jan Janse van Rensburg]

Thanks for the video. Based on the behavior, there are three main areas to investigate:

1. Solver Settings (Most Likely Cause)

If you are using a Fixed-Step Solver, this is likely the culprit. Contact is a discrete event. The Physics: At time step n-1, there is no contact. At time step n, the foot might have penetrated 2mm into the ground. The Result: This sudden penetration creates a massive force spike because the solver missed the exact moment of impact. The object tries to accelerate away instantly, but your PID controller fights it, causing oscillations. Recommendation: Switch to a Variable-Step Solver (like ode15s or ode23t). These solvers automatically reduce the time step to catch the exact moment of contact.

2. Friction & Horizontal Movement

The instability might be coming from horizontal "sticking" rather than just vertical impact. If the foot hits the ground with any forward velocity and friction is active, it creates a horizontal shock.

Test A: Set the contact Friction to 0. If the simulation becomes stable, the issue is the horizontal impact forces.

Test B: Mount the floor on a Planar Joint (allowing X/Y movement). This allows the floor to "slide away" upon impact, reducing the shock while letting you keep friction enabled to test traction.

3. Mass & Inertia Checks

Check the rigid body transforms and inertia parameters imported from your CAD geometry. Ensure the mass and inertia are not zero or unrealistically small. If inertia is too low, the calculated accelerations from contact forces will be huge, leading to instability.

4. Troubleshooting Strategy:

Isolate the Problem

You are tuning PID gains, contact stiffness, and solver settings while the robot is trying to walk. This is too difficult.

Try this process:

Stand Still First: Change your reference signals to keep the joints stationary.

Tune Contact: Tune parameters until the "standing" phase is stable. Start Walking: Only once static contact is stable, apply the gait trajectory.

Use an Operating Point: Look into using a Simscape Operating Point to start the simulation from a steady state (already balanced) rather than dropping it at t=0.