roqsim — robots, quickly simulated (in MuJoCo) — is a plugin-driven simulation framework where a world and everything in it, robots, sensors, props and scene, is declared in a single YAML file.

sim:
  world: empty_room
components:
  - spawn_robot: {model: turtlebot4, pose: {position: {x: 0, y: 0}}}

That is a driving, sensing robot: the TurtleBot 4 brings its own differential drive, lidar and RGB-D camera, because a model's manifest names the plugins intrinsic to it. No C++, no scene graph to hand-assemble.

Features

• One YAML file per world. Robots, sensors, props and scene declared together; plugins hook a MuJoCo step loop at well-defined lifecycle points. Write your own in a file next to the world.
• 37 robot models across 6 families — 17 wheeled bases (TurtleBot 4 and 3 Waffle, Husky A200, Jackal, Ridgeback, Warthog, Panther, ROSbot, MP-400, MPO-500/700, ROX-Diff, LGDXRobot2, MakerSpet Mini, Raspimouse, OOMWOO ONE, PiRacer), 9 arms and 2 grippers (UR10e, UR5e, Panda, Gen3, xArm7, M1013, OpenManipulator-X, ViperX 300s, WidowX 250s; Robotiq 2F-85, Schunk PG+70), 2 mobile manipulators (TIAGo Pro, Frankie), 4 humanoids (Unitree G1, G1 + Dex1, LimX Oli, AgiBot G2), Boston Dynamics Spot, the Crazyflie 2 and an X500 — each vendored with pinned upstream provenance, the X500 authored from PX4's own airframe definition.
• Sensors, and where to put them. Lidar, RGB-D, IMU, force-torque and fiducial markers, with 19 bundled sensor device models. The IMU reports proper acceleration, true attitude (or none, marked as such) and covariances built from its declared noise, so a robot_localization stack has the input it expects; a segmentation camera adds per-pixel class and instance labels with tight 2D boxes, measured from the mask, so a perception experiment has ground truth to be scored against. Coverage analysis answers the question that actually blocks you: how many cameras, and where?
• Scenes from what you already have. Import Gazebo SDF, USD or CAD — or draw a floorplan in a window and get a world back.
• People as dynamic obstacles. Kinematic pedestrians with A* and behaviour-tree navigation, plus optional ORCA local avoidance, for the case your robot has to share a corridor.
• Runs where you need it. Viewer by default, headless for CI and containers; real-time, scaled, or as-fast-as-possible pacing.
• Speaks to your stack. A ROS 2 bridge exposing standard simulation_interfaces, a working nav2 example, and a SimulationInterface for scenario-execution. The core itself is ROS-free and pip-installable.
• Answers questions afterwards. Record a run, then pull poses, joints, contacts and sensor series out of it — or export the scene to the browser.
• Extensible without forking. Third-party packages register plugins, models, worlds and textures by entry point. The core never learns their names.

Quick start

make venv     # create .venv and install everything
make help     # list all targets

.venv/bin/roqsim sim roqsim_mobile:turtlebot4_demo      # a viewer opens

Ready-to-run worlds ship in the box, named by a <package>:<world> ref that roqsim sim takes. Every robot model also registers a <name>_demo world that shows that one robot in an empty room, which is how the commands above run. roqsim --help lists the core's commands and the command groups; roqsim <group> --help gives one line per tool.

Headless, as fast as the machine allows, with timings:

.venv/bin/roqsim sim roqsim_mobile:turtlebot4_demo --headless --pacing asap --steps 1000 --profile

Documentation

The documentation is published at https://cps-test-lab.github.io/roqsim/, rebuilt from main — read the model catalog there, where each model shows its preview. The sources: start with getting started, then:

Installation	packages, the venv, ROS 2
Quickstart · Plugins	writing a world; every built-in plugin
Models · Textures	the robot/prop catalog; surfaces and floors
Interfaces	ROS 2, scenario-execution, your own code
Scene builder · Coverage	building worlds; sensor placement
nav2 example · Ground truth	navigation; getting numbers out
Architecture	how it fits together, and the porting playbook

Build them locally with make doc (or make view-doc).

Licensing

roqsim's own code is Apache-2.0 (see LICENSE).

Vendored third-party assets keep their own terms, and some of those terms require attribution when you redistribute. The authoritative records are the THIRD_PARTY.md file in each package and the CREDITS.txt beside each asset; NOTICE summarises them.

license	assets
BSD-3-Clause	Spot, xArm 7 (© UFACTORY) and the Interbotix ViperX 300 / WidowX 250 (MuJoCo Menagerie; the last two © Trossen Robotics), Unitree G1 ×2, UR5e/UR10e/Robotiq (ROS-Industrial), Jackal, Husky, Ridgeback, Warthog (Clearpath)
Apache-2.0	LimX Oli, Panda, OpenManipulator-X, TurtleBot 3/4, Tiago Pro, Husarion ROSbot and Panther, Doosan M1013, Maker's Pet oomwoo! One and Mini
MPL-2.0	AgiBot G2 meshes — file-level copyleft, the notice travels with the files
MIT	Frankie, Crazyflie 2 (MuJoCo Menagerie), RT Corporation Raspberry Pi Mouse, LGDXRobot2, Neobotix MPO-700 / MPO-500 / MP-400
CC-BY-4.0	the warehouse scene (Gazebo Fuel), locomotion clips (CARLA)
CC0-1.0 or CC-BY-4.0	pedestrian characters (Gazebo Fuel), each as the CREDITS.txt beside it states

Props and surface textures in roqsim_assets carry their licence and attribution in the CREDITS.txt beside each, which ships with the package.

Nothing under a non-commercial (CC-*-NC) or no-derivatives (CC-*-ND) license is included.