Sim-to-real transfer of reinforcement learning policies for contact-rich manipulation fails in zero-shot deployment because physics engines mismodel friction, contact stiffness, and deformation

Reinforcement learning policies trained in simulation (MuJoCo, Isaac Sim, PyBullet) for contact-rich robotic tasks -- in-hand manipulation, peg insertion, cable routing, food handling -- consistently fail when deployed zero-shot on real hardware because simulator contact models use simplified penalty-based or complementarity-based solvers that misrepresent real-world friction cone geometry, surface compliance, material deformation, and contact patch dynamics. Even small mismatches in contact stiffness or friction coefficients cause trained policies to apply incorrect forces, producing dropped objects, jammed insertions, or damaged parts. Why it matters: simulation-based RL was supposed to eliminate the need for expensive and slow real-robot data collection by generating millions of training episodes in simulation, so robotics companies invested heavily in simulation infrastructure (NVIDIA Isaac, Google DeepMind), so when zero-shot transfer fails, teams must collect real-world fine-tuning data anyway, so the cost and time savings of sim-to-real RL largely evaporate for contact-rich tasks, so the most economically valuable manipulation tasks (assembly, food processing, electronics handling) remain resistant to learned control policies. The structural root cause is that rigid-body physics engines solve contact as a discontinuous event using simplified models (e.g., Coulomb friction cones, spring-damper penetration penalties) that are computationally tractable but physically inaccurate for the soft, distributed, hysteretic contact mechanics of real materials, and increasing simulator fidelity (FEM deformation, measured material properties) makes simulation too slow for the millions-of-episodes throughput that RL algorithms require, creating a fundamental tradeoff between sim speed and sim fidelity that no current engine resolves.