robot-simulation

name	robot-simulation
description	Robot simulation — rigid body dynamics engines (ODE, Bullet, MuJoCo, Drake), kinematic simulation (ROS/Gazebo, URDF/SDF), physics fidelity (contacts, friction, deformable bodies), sim-to-real transfer (domain randomization, domain adaptation), simulation for reinforcement learning (OpenAI Gym, Isaac Gym), offline programming (OLP) simulation for industrial robots, cycle time verification, reach analysis, and robot simulation tools (RobotStudio, KUKA SimPro, FANUC ROBOGUIDE, Tecnomatix).
metadata	{"priority":7,"promptSignals":{"phrases":["robot simulation","Gazebo simulation","MuJoCo","robot digital twin","offline programming","Isaac Gym"],"minScore":3}}

Robot Simulation — Complete Skill

Physics Engines

Rigid Body Dynamics Engines

ODE (Open Dynamics Engine): Open-source; constraint-based; LCP (Linear Complementarity Problem) for contact Features: joint constraints, collision detection (OBB, cylinder, sphere); fast for kinematic chains Limitations: soft/deformable body limited; contact instabilities at high stiffness Used in: Gazebo classic, early robotics simulation

Bullet Physics: Open-source; GPU-accelerated (Bullet3); discrete collision detection + impulse-based contact Features: deformable bodies (FEM cloth, soft body); continuous collision detection (CCD) Used in: Gazebo, PyBullet (RL), Blender physics; widely deployed

MuJoCo (Multi-Joint dynamics with Contact): Proprietary → now open-source (DeepMind, 2022); generalized coordinates; implicit constraint formulation Optimized for robotic contact dynamics; best contact accuracy among free engines Stable at high stiffness; soft contact model; fast (10,000–1,000,000 fps for simple systems) Used in: OpenAI Gym, robotics RL research, DeepMind Control Suite

Drake (MIT/TRI): Modern C++/Python; model-based control + simulation; rigid + deformable bodies MultibodyPlant: Drake's physics engine; articulated body algorithm (Featherstone) Contact: LCP or compliant contact models; System diagram (blocks with ports) abstraction Used in: research, Atlas (Boston Dynamics historically), ROS integration

Webots: Open-source (Cyberbotics/EPFL); complete simulation environment; C, C++, Python, ROS APIs Physics: ODE-based; good for educational and research; includes device models

Physics Fidelity Concerns

Contact modeling: Real contact: asperity-level; simulation: penalty method (spring-damper) or LCP (hard contact) Friction: Coulomb (μ_s, μ_k) in simulation; real: complex anisotropic, rate-dependent Instability: high gear ratio transmissions with high-stiffness contacts → numerical stiffness → small timestep required

Integration: Explicit (Runge-Kutta): fast per step; small dt (0.01–1 ms); may diverge at stiff contact Implicit (backward Euler, Variational): stable for large dt; more computation per step; MuJoCo uses semi-implicit

Timestep recommendations: ODE/Bullet: 1–10 ms; MuJoCo: 0.1–1 ms; Drake: 0.01–1 ms RL training: need 1,000+ simulated steps per second → MuJoCo/IsaacGym for speed

ROS/Gazebo Simulation Stack

ROS 2 + Gazebo (Fortress/Harmonic)

URDF (Unified Robot Description Format): XML description: links (geometry + inertia), joints (type, axis, limits, dynamics) Inertia matrix: must be computed from CAD or measured; wrong inertia = inaccurate dynamics SDF (Simulation Description Format): Gazebo-native; more complete; supports worlds, plugins

ROS 2 Control (ros2_control): Hardware abstraction layer: connects real hardware or simulation via hardware_interface Controllers: JointTrajectoryController, ForwardCommandController, etc. Simulation: mock_hardware or gazebo_ros2_control plugin → same controllers for real/sim

Launch sequence:

1. robot_description → URDF → parameter server
2. Gazebo spawns robot (spawn_entity)
3. ros2_control starts controllers
4. MoveIt! or custom nodes plan and execute trajectories

Sensor Simulation in Gazebo

Camera plugin: generates sensor_msgs/Image; configurable resolution, FOV, frame rate, noise model Depth camera plugin: generates PointCloud2; RGBD simulation (Kinect, RealSense-style) Lidar (GPU ray plugin): 360° scan; configurable beams, range, noise; sensor_msgs/LaserScan IMU plugin: noise model for accelerometer + gyroscope; configurable bias Force-torque plugin: measures wrench at joint; comparable to real ATI/Schunk sensor

Sensor noise models: Gaussian noise added to perfect simulation: σ_noise from real sensor spec Gazebo camera: Gaussian pixel noise; blur (lens blur simulation optional)

Offline Programming (OLP) for Industrial Robots

OLP Workflow

Tools: RobotStudio (ABB), KUKA.Sim, FANUC ROBOGUIDE, Tecnomatix Process Simulate:

1. Import CAD models of robot, fixtures, part
2. Define work processes (weld paths, spray paths, pick-and-place sequences)
3. Program robot motions; check reachability; verify reach in all poses
4. Simulate cycle time; detect collisions
5. Export robot program (RAPID/SPTP/FANUC TP) → upload to real robot
6. Fine-tune on real robot (small offsets from fixture tolerances)

Reach analysis: Workspace envelope from kinematic simulation; check all programmed TCP poses within reach Identify out-of-reach poses → adjust fixture position or add robot offset

Cycle time analysis: Simulate motion with realistic velocity/acceleration limits; calculate total cycle time Optimize: minimize unproductive moves; use synchronization of positioner + robot Target accuracy of OLP cycle time prediction: ±5–10% vs. real robot

Accuracy of OLP programs: Position accuracy after OLP: typically ±1–5 mm without calibration (fixture placement uncertainty) With robot calibration + fixture scanning: ±0.3–1.0 mm Best practice: frame calibration (teach 3 points on real fixture → correct coordinate frame in program)

Sim-to-Real Transfer

Domain Randomization

Idea: randomize simulation parameters (friction, mass, stiffness) during training → policy robust to parameter uncertainty Randomize: joint friction (±50%), link mass (±20%), actuator noise, initial conditions, payload RL policy trained on distribution of environments → generalizes to real (which is one sample from distribution) Applications: dexterous manipulation (OpenAI Dactyl), legged locomotion (Unitree A1 RL policies)

Domain adaptation: Alternatively: minimize distribution gap between sim and real via adaptive algorithms or fine-tuning with real data System identification: measure real robot → update simulation parameters to match GRRL (Guided DRRL): start with sim policy → few real rollouts → adapt

Differentiable Simulation

Gradient of simulation output w.r.t. parameters → efficient model-based RL: Drake, DiffTaichi: compute ∂loss/∂θ through physics simulation → use gradient descent Applications: robot learning from demonstration; contact-rich manipulation; trajectory optimization

Isaac Gym / Isaac Sim (NVIDIA)

Isaac Gym (legacy) / Isaac Lab: GPU-accelerated parallel simulation: run 1,000–10,000 environments simultaneously on GPU PhysX 5 engine (NVIDIA); tight integration with reinforcement learning frameworks (RL-Games, RSL-RL) Training speed: 10,000× real-time for simple legged robots; 1,000× for manipulation Applications: bipedal locomotion, dexterous manipulation, agile robotics (ETH Zürich, UCB AMR Lab)

Isaac Sim: Full visualization + physics; USD (Universal Scene Description) format for assets ROS 2 bridge: same ROS 2 topics as physical robot; supports sensor simulation Photorealistic rendering: ray tracing → photo-real camera images for perception training

Standards and References

Standard	Scope
ISO 9283	Robot performance (measured on real system; simulation used to predict before fabrication)
URDF specification (ROS wiki)	Robot description format standard
SDF specification (Open Robotics)	Gazebo simulation description format
NVIDIA Isaac documentation	Isaac Gym/Sim reference
ABB RobotStudio documentation	OLP reference for ABB robots

Output

Provide: simulation purpose (physics verification / RL training / OLP / visualization / digital twin), physics engine selected (MuJoCo/Drake/Gazebo-Bullet/Isaac; justification: speed, contact fidelity, ROS integration, GPU), robot model (URDF/SDF: joints count; inertia accuracy: from CAD or estimated; collision meshes), simulation timestep Δt [ms] and expected real-time factor (RTF = sim_speed/wall_clock), sensor simulation (camera: resolution, noise model; LiDAR: beams, noise; F/T: Gaussian noise [N, Nm]; IMU: gyro noise [°/s/√Hz]), contact model (compliant/LCP; friction μ; penetration tolerance [mm]), OLP summary (robot model; work cell; programmed poses N; reachable [%]; estimated cycle time [s]; collision-free: yes/no), sim-to-real gap (if RL: randomization parameters and ranges; validation metric on real hardware), and applicable tool/standard (RobotStudio/ROBOGUIDE/Gazebo/Isaac, URDF spec, ISO 9283).