IR-SIM: Lightweight Intelligent Robot Simulator

• IR-SIM is a lightweight navigation simulator that uses YAML for scenario specification to enable rapid prototyping and systematic benchmarking.
• It features a modular design, separating robot kinematics, collision detection, and LiDAR sensing, which facilitates integration with high-fidelity simulation bridges.
• The simulator provides discrete agent skills for LLM-driven automation, supporting scenario generation, performance evaluation, and smooth transition to real-world testing.

Searching arXiv for IR-SIM and closely related simulator papers to ground the article in current literature. Intelligent Robot Simulator (IR-SIM) is a lightweight skill-native navigation simulator designed for rapid scenario construction, benchmarking, and robot learning. In IR-SIM, scenarios are entirely defined by YAML configuration files that specify mobile robot kinematics, geometric collision checking, LiDAR sensing, visualization, and behavior modules. The resulting scenarios can be used for automated benchmarking of navigation algorithms and for automated generation of training data for learning methods, and IR-SIM provides bridges to high fidelity simulators and real world deployment for validation after prototyping without extra coding (Han et al., 7 Jun 2026).

1. Definition and design rationale

IR-SIM is presented as a response to a recurrent systems problem in automated robotics research supported by LLMs: existing simulators often require custom code or complex interfaces, creating a barrier to rapid prototyping and automated algorithm development. Its central design decision is a fully modular, Python-based architecture in which every core component—world map, robot kinematics, collision checker, sensors, behaviors, rendering, and high-level “agent skills”—is cleanly separated but interoperable through a common, YAML-driven data model (Han et al., 7 Jun 2026).

At runtime, a minimal Python runner calls irsim.make(yaml_path) to construct the world, robots, obstacles, sensors, and behavior modules by parsing the YAML config; env.step(action) to advance kinematics, execute behavior modules, run collision-detection via Shapely, and update sensor readings; and env.render() to draw the current state using Matplotlib or emit ROS/Gazebo messages for bridges. The rationale for this skill-native design is stated in three parts: scenarios are authored entirely in YAML; agent skills expose discrete, composable operations such as “write this scenario,” “run these 100 episodes,” and “export to CARLA”; and seeded randomization plus explicit YAML parameters guarantee that a scenario can be shared, versioned, and re-run deterministically. In context, this means that IR-SIM treats simulation configuration not as auxiliary code but as the primary experimental artifact.

2. YAML-first scenario specification

A typical IR-SIM YAML scenario is divided into top-level blocks: world, robots, obstacles, sensors, behaviors, collision, and viz. These blocks encode map or geometry for static obstacles, robot definitions including kinematics and initial pose, static or dynamic agents, LiDAR or FOV sensing, behavior modules such as ORCA and SFM, minimum-distance and safety-margin parameters, and Matplotlib visualization settings including headless or animation flags (Han et al., 7 Jun 2026).

The paper’s concrete YAML example defines a 10.0 × 10.0 arena, a differential-drive robot with wheel_radius: 0.05, wheel_base: 0.3, circular geometry of radius 0.2, an ORCA behavior with safety_distance: 0.3, a dynamic agent using SFM with speed 1.2, a LiDAR sensor with 36 beams and max_range: 5.0, a collision.safety_margin of 0.05, and interactive visualization with animation saving enabled. The documented semantics of parameter changes are direct: modifying wheel_base or wheel_radius immediately alters the robot’s kinematic Jacobian and turning radius; adding a new obstacle under world.obstacles instantly places a static shape in the scene; and changing sensors[0].beams reconfigures the number of LiDAR rays in the next run. This makes the YAML file both a scenario description and an executable specification.

3. Kinematics, sensing, and collision models

For the differential-drive case, IR-SIM describes robot motion through the standard kinematic relations

$$\dot x = v \cos(\theta),\qquad \dot y = v \sin(\theta),\qquad \dot \theta = \omega .$$

Geometric collision checking uses Shapely’s distance queries. For robot geometry $R$ and obstacle geometry $O$, collision is signaled if

$\mathrm{dist}(R,O) \le d_{\min},$

where $d_{\min}$ is the configured safety margin plus the two radii if both shapes are circles. The LiDAR sensor model is defined beamwise: each beam is a ray cast from the robot pose $(x,y,\theta)$ at angle $\alpha_i$, and the measured range $r_i$ is the minimum distance to an intersection point between the ray and world geometries plus additive Gaussian noise $$\varepsilon_i \sim \mathcal N(0,\sigma_{\mathrm range}^2)$$ (Han et al., 7 Jun 2026).

These models delimit the simulator’s scope. The implementation is expressly 2D kinematics only, rather than full dynamics or contact physics. A plausible implication is that IR-SIM is optimized for navigation, policy training, and controlled benchmarking in planar environments, while more physically rich tasks are intended to be reached through its bridge mechanisms rather than through a heavier native physics stack.

4. Agent skills and LLM-oriented automation

IR-SIM defines a family of “agent skills” that wrap its underlying Python functions. The major skills named in the paper are irsim-scenario, irsim-runner, irsim-benchmark, and irsim-dev (Han et al., 7 Jun 2026).

Skill	Function
irsim-scenario	parse natural language or patch existing YAML to author/validate scenario descriptors
irsim-runner	generate the minimal Python loop to call env.reset(), env.step(), env.render(), and save animations or logs
irsim-benchmark	orchestrate multiple runs, collect metrics such as success rate, collisions, path length, and time to goal
irsim-dev	test, lint, document, and release

The LLM integration workflow is specified as a sequence. A text prompt such as “Create a 10×10 map with two differential-drive robots avoiding a wandering crowd” is processed by irsim-scenario, which extracts key parameters, selects the appropriate YAML template, and fills in fields; the skill then returns a complete YAML file plus a runner stub; the user reviews or adds minor edits and executes the runner. The significance of this mechanism is not that the simulator embeds an LLM, but that it exposes simulation actions as discrete, composable operations suited to automated orchestration.

5. Benchmarking, learning, and deployment bridges

For benchmarking, the irsim-benchmark skill runs scenarios under different controllers—examples given are ORCA, AVOCADO, SARL, or custom RL policies—and reports summary tables with Success (%), Collision (%), Timeout (%), Mean time to goal (s), Average speed (m/s), and Path length (m). For learning, IR-SIM exposes a Gymnasium-compatible API: wrappers written as GymEnv = irsim.make_gym(yaml_path) allow calls to obs = env.reset() and obs, reward, done, info = env.step(action), and a PPO pipeline can be launched via Stable-Baselines3 or TorchRL. Generated rollouts comprising states, LiDAR scans, and actions are automatically logged and can be saved as demonstration files for imitation learning or offline RL (Han et al., 7 Jun 2026).

The same paper emphasizes that prototyping is not intended to terminate inside the lightweight simulator. Without rewriting scenario logic, IR-SIM can export or synchronize to Gazebo/ROS, CARLA, Habitat-Sim, and real robots. The Gazebo/ROS bridge publishes map and robot_state, subscribes to cmd_vel, and publishes obstacle trajectories on /obstacles topics. The CARLA bridge converts pedestrian trajectories into actor spawn and motion scripts, triggered by a YAML block with bridge: type: carla. The Habitat-Sim bridge ingests the IR-SIM occupancy grid as a floor plan and reuses HM3D assets for vision testing. For real robots, IR-SIM publishes ROS 2 topics such as /irsim/robot1/pose and /irsim/robot1/ref_trajectory, which the on-robot controller can follow directly. In methodological terms, this places IR-SIM at the front end of a workflow that begins with rapid YAML-defined prototyping and extends to higher-fidelity validation and real-world execution.

6. Limitations, future directions, and naming ambiguity

The limitations explicitly noted are threefold: 2D kinematics only (no full dynamics, contact physics, manipulators, or legged locomotion); No built-in photorealistic camera model (vision tasks require bridging); and LLM-generated YAML may need human inspection for safety-critical settings. The future directions listed by the authors are Automatic semantic validation of scenarios to catch incoherent prompts, Richer, learned behavior modules (e.g., human motion from neural models), and Tighter, lower-latency bridges for real-time closed-loop sim2real (Han et al., 7 Jun 2026).

A separate source introduces a multi-scenario adaptable intelligent robot simulation platform based on LIDAR-inertial fusion and states, “which we will refer to here as ‘IR-SIM’.” That platform is organized into two ROS-centric subsystems—Robot-System Simulation in Gazebo and SLAM Evaluation & Benchmarking in ROS nodes and tools—and emphasizes URDF/XACRO robot models, Gazebo .world environments, LIDAR and IMU simulation, libgazebo_ros_p3d.so ground truth at 200 Hz, and evaluation with APE and RPE through evo (Li et al., 2024). This suggests a nomenclature ambiguity: in current usage, “IR-SIM” may denote either the lightweight skill-native YAML-first navigation simulator of (Han et al., 7 Jun 2026) or, in a different descriptive context, a ROS/Gazebo-centered LIDAR-inertial SLAM evaluation platform associated with MSSP. The two systems occupy adjacent but non-identical positions in the simulator landscape: one centers on YAML-defined navigation, learning, benchmarking, and bridge-based deployment; the other centers on Gazebo-based sensor simulation and SLAM evaluation workflows.