The Ghost, The Anchor, and The Exploding Robot

The Issue: The robot spawned in Isaac Sim but was completely static — it refused to fall due to gravity, respond to forces, or move at all. It was essentially a static prop glued to the origin.

The Diagnosis: The USD file exported from the CAD pipeline contained a fixed root_joint connecting the robot's base to the world frame. This is standard in URDF exports intended for static analysis (e.g., ROS visualization) but completely fatal for dynamic mobile robot simulation. The physics engine treated the robot as a world-fixed object.

The Fix: fix_lekiwi_usd.py opens the USD file, programmatically calls prim.SetActive(False) on the root_joint prim, and applies UsdPhysics.ArticulationRootAPI to the actual chassis body (/LeKiwi/base_plate_layer1_v5). The result is saved as lekiwi_floating.usd — a true floating-base articulation.

Lesson: Always inspect the articulation tree with inspect_joints.py before attempting to simulate a new USD robot. Look for any FixedJoint connecting the robot base to the world.

The Issue: With the articulation root fixed, the robot could now fall. But the wheels fell straight through the floor. When motors were commanded at 20 rad/s, logs confirmed the joints were spinning at the requested velocity — yet the robot didn't translate by a single millimeter.

The Diagnosis: A deep USD inspection via inspect_usd.py revealed that the visual meshes had zero collision geometry. The physics engine's broad-phase collision detection found no physics shapes, so the wheels were "ghost" objects — they could rotate, but had no surface to push against the ground.

The Fix: add_wheel_collisions.py procedurally injects collision primitives:

• For each of the three wheel bodies: creates a child prim (/wheel_collision) under the wheel's prim path
• Front two drive wheels → UsdGeom.Cylinder (radius = wheel radius × 0.95, axis = Y)
• Applies UsdPhysics.CollisionAPI + PhysxSchema.PhysxCollisionAPI
• Sets contactOffset = 0.002, restOffset = 0.001 to prevent interpenetration
• Marks colliders as invisible so they don't affect rendering

Lesson: Run find_collisions.py on any new robot USD. If the count of UsdPhysics.CollisionAPI prims is zero, the robot is a ghost.

The Issue: As soon as the collision shapes were added, the simulation exploded. The console was flooded with NaN (Not a Number) errors. The robot's world position would become [NaN, NaN, NaN] within milliseconds of spawning, crashing the entire simulation loop.

The Diagnosis: Two compounding failure modes:

• Self-Collisions: The injected collision cylinders overlapped with the body's existing geometry. The physics solver attempted to resolve two rigid bodies occupying the same space, generating effectively infinite separation forces which propagated as NaN through all downstream calculations.
• Actuator Instability: The default PID gains (copied from Dingo) were too aggressive for LeKiwi's smaller, lighter body. The wheels spasmed violently, causing the observation processing code to fail — specifically, a torch.inverse() call on a nearly-singular matrix.

The Fix (multi-pronged):

• PhysxArticulationAPI.CreateEnabledSelfCollisionsAttr().Set(False) — disabled self-collisions at the articulation level
• Reduced wheel collision cylinder radius by 5% (WHEEL_RADIUS * 0.95) to prevent ground interpenetration at spawn
• Replaced torch.inverse with torch.linalg.pinv (pseudo-inverse) for numerical robustness
• Wrapped MPC solver and visualization in try/except blocks to catch NaN before it propagates

Lesson: Always disable self-collisions when procedurally adding collision shapes. Any shape that overlaps with existing geometry at spawn will cause immediate NaN. Prefer torch.linalg.pinv over torch.inverse in robotics code.

The Issue: The robot was finally stable — no NaN, correct physics, correct spawn height. But it refused to move correctly. The front wheels would spin and the robot would inch forward 2–3 cm before stopping, as if dragging an invisible anchor. Turning in place was completely impossible.

The Diagnosis: LeKiwi is kinematically an omni-directional robot. The third wheel at the rear is designed as a caster — it should roll freely in any direction to allow lateral motion. However, we had assigned all three wheels Cylinder collision shapes. A cylinder naturally resists motion perpendicular to its rolling axis. With the rear caster acting as a fixed-axis cylinder, any attempt to turn or strafe was blocked by an enormous lateral friction force.

The Fix: Changed the rear caster's collision shape from Cylinder to Sphere. A sphere contacts the ground at a single point and has no preferred rolling axis, offering near-zero resistance to lateral motion. The collision script uses is_caster = (i == 2) to select the appropriate shape per wheel index.

# add_wheel_collisions.py
for i, wheel_path in enumerate(WHEEL_BODIES):
    is_caster = (i == 2)   # 3rd wheel is the passive caster
    add_cylinder_collision(stage, wheel_path, WHEEL_RADIUS, WHEEL_WIDTH, is_caster=is_caster)
# is_caster=True → Sphere; is_caster=False → Cylinder

Lesson: Understand the kinematic role of each wheel before assigning collision geometry. Casters require shapes that allow omnidirectional contact (sphere, disk with no axle friction), not shapes that enforce a preferred rolling direction.

Current State: The robot spawns correctly, sits at the correct ground height (z ≈ 0.033m = wheel radius), does not explode, and the drive wheels physically rotate. However, the robot's base velocity remains zero — it is effectively doing a burnout on frictionless ice.

Evidence:

• Root position locked at: [-6.64, 14.05, 0.033] — correct height, zero translation
• MPC generates valid commands: Action: [14.0, 16.0]
• Joint velocities confirm wheels are spinning physically
• Base velocity: [0, 0, 0]

Hypothesis: The procedurally-injected collision cylinders are using Isaac Sim's default material, which appears to have near-zero friction coefficients. In PhysX, a collision shape without an explicit PhysicsMaterial binding sometimes defaults to frictionless behavior — the equivalent of polished ice. The wheels are spinning, but generating no traction force.

Next Steps:

• Create a PhysicsMaterial with staticFriction=0.8, dynamicFriction=0.6 and bind it to the drive wheel collision shapes
• Use UsdShade.MaterialBindingAPI to programmatically apply the material in the collision injection script
• Alternatively, investigate if PhysxSchema.PhysxMaterialAPI can be applied directly to the collision prim