Section 11.7: Drake, SAPIEN, ROS 2, and Gazebo

"A simulator that cannot talk to the rest of the robot is a very convincing island."

A Systems-Minded Embodied AI Agent

Drake: Model-Based Design And Verification

Drake is strongest when you need dynamics, planning, control, optimization, and verification in one systems framework. It is not primarily a massive RL environment factory. It is the tool you reach for when the question sounds like "can we formulate this controller, planner, or stability condition precisely?" rather than "how many randomized episodes can we run this hour?"

That distinction matters when a learned policy needs a model-based guardrail. Drake can help analyze contact modes, constraints, trajectories, or controller stability around a small scenario. It complements GPU training rather than replacing it.

SAPIEN And ManiSkill: Manipulation At Scale

SAPIEN provides physical simulation for robots, rigid bodies, and articulated objects. It is especially visible through ManiSkill, a manipulation and robot-learning benchmark framework powered by SAPIEN. ManiSkill3 emphasizes GPU-parallel simulation and rendering for manipulation tasks, which makes it a natural bridge from this chapter to the benchmark chapter that follows.

The benchmark strength is asset and task consistency. If the research question is manipulation generalization, a shared task suite can be more valuable than a hand-built simulator scene because other groups can reproduce the same objects, initial states, observations, and success metrics.

ROS 2 And Gazebo: Systems Integration

ROS 2 is not a physics simulator, and Gazebo is not a learning library. Together, they often form the systems-integration path for robot projects. Modern Gazebo connects simulation with sensors, controllers, robot descriptions, and ROS 2 nodes. Gazebo Classic reached end of life in January 2025, so new projects should use current Gazebo releases and compatible ROS 2 distributions.

The integration test is different from the training test. Instead of asking how many episodes per second you can run, ask whether clocks, transforms, messages, controllers, sensor topics, reset behavior, and logs match the robot software stack closely enough to reveal deployment failures before hardware time.

A System Boundary Check

Code Fragment 1 gives a small classifier for simulator needs. The useful part is not the code itself, but the habit: decide whether the primary risk is physics, learning throughput, control design, or systems integration.

# Classify a simulator need by the risk that dominates the project.
# This helps separate physics choice from systems-integration choice.
# Add your own project risks before making a tool recommendation.
def recommend_tool(primary_risk: str) -> str:
    options = {
        "control_verification": "Drake",
        "manipulation_benchmark": "SAPIEN or ManiSkill",
        "ros2_integration": "ROS 2 with modern Gazebo",
        "gpu_policy_training": "Isaac Lab, MJX, or MuJoCo Warp",
    }
    return options.get(primary_risk, "Run a simulator audit before choosing")

for risk in ["control_verification", "ros2_integration", "unknown"]:
    print(f"{risk}: {recommend_tool(risk)}")

control_verification: Drake
ros2_integration: ROS 2 with modern Gazebo
unknown: Run a simulator audit before choosing

Expected output: A multi-tool simulator plan should list each project phase, the tool assigned to that phase, the interface between tools, the shared robot model or conversion step, and the metric that proves the phase did its job.