Introduction

Drift is your AI copilot for robotics engineering. Building, testing, and debugging robot simulations has always required deep expertise across ROS2, Gazebo, MuJoCo, URDF, MJCF, and more — Drift removes that barrier. Describe what you want in plain English, and Drift handles the complexity. From scaffolding a workspace to launching a full simulation, you just come with prompts, for example:

• set up a Unitree Go2 from mujoco_menagerie on a stairs scene and run a hold-pose PD controller
• set up an Aloha bimanual rig from menagerie on a tabletop and reach both arms toward the cubes
• set up a Unitree H1 humanoid standing balanced on flat ground with PD on all 19 joints
• launch my robot with the custom world file
• add a lidar sensor to my robot and rebuild
• why isn't my camera publishing images?

Browse the Robot Showcase for full walkthroughs of each.

​

Why Drift?

Tools like Cursor or Claude are excellent for general coding, but they miss the context that robotics needs — the running ROS2 graph, the live Gazebo or MuJoCo state, your team’s URDF conventions, your build system’s quirks. That’s the gap Drift fills. In the video below, we asked Claude and Drift to fix the same Gazebo error:

• Claude looks at the surface and concludes Gazebo isn’t installed. It was.
• Drift inspects the actual ROS2 environment — running processes, topic connections, launch file output, system state — finds the real cause, and fixes it without you interpreting the error.

​

How It Works

Drift runs as an interactive CLI agent on your local machine. Type a prompt; the agent interprets your request, generates the ROS2 packages, URDF / MJCF / SDF files, launch configs, and Gazebo or MuJoCo scenes; runs the builds and the simulator; and manages every background process — without you touching a config file.

1. You describe what you want at the drift> prompt.
2. Drift plans the steps: workspace layout, robot description, world or scene, launch configuration.
3. Drift executes — builds, fixes errors, launches the simulator, runs verification.
4. You iterate — add sensors, change configs, debug issues by asking follow-up questions.

Your files and simulation state stay on your machine.

​

Key Capabilities

​

Project context you write once

Drop a DRIFT.md (or CLAUDE.md) at your workspace root with your robot’s specs, topic names, frame IDs, build conventions, naming rules. Drift reads it before every step. Stop re-explaining your project to the agent on call #2. Run /init and Drift will scan your workspace and write a starter DRIFT.md for you.

​

Your own skills, written by your team

A skill is a markdown file describing how your team tunes EKFs, calibrates IMUs, writes Gazebo plugins, names ROS2 packages, structures a launch hierarchy. Drop it in .claude/skills/<name>/SKILL.md (per-workspace) or ~/.claude/skills/<name>/SKILL.md (everywhere). Drift picks it up automatically. Or add one inline: /skill add ./team-skills/ekf-tuning.md. Your team’s expertise becomes the agent’s.

​

Native MuJoCo and Gazebo Harmonic, end-to-end

Author URDFs, MJCF scenes, SDF worlds, sensor plugins, controllers. Launch headless or interactive. Debug contact failures, wheel-spin, transform mismatches, NaN-in-qacc, plugin load errors. Not “AI can write some XML” — actually runs the sim and reads the result back.

​

Multi-step builds that hold context

Workspace → robot → controllers → world → sim → tuning → docs, one prompt. Drift remembers what it built steps ago, doesn’t hallucinate file paths, and updates URDF + bridge + launch as one coordinated change.

​

Live ROS2 inspection and debugging

Describe the symptom; Drift does the detective work. Inspects running nodes, checks topic connections and QoS compatibility, validates URDF inertia tensors, traces the command chain from publisher to controller to joint. All ROS2 introspection tools available through natural language.

​

Build error recovery

Drift reads colcon output, finds the root cause, and fixes it — whether that’s CMakeLists.txt, package.xml, setup.py, or a missing dependency. Changes stay consistent across files.

​

You stay in control

Every command is shown before it runs. Press ESC to pause mid-execution and step through one command at a time, or let Drift run uninterrupted. Use drift -c for CI pipelines and scripted workflows.

​

Who is Drift for?

• Students — learn robotics concepts without getting stuck on setup
• Researchers — iterate faster on algorithms; simulation setup stops being the bottleneck
• Engineers — prototype and test production systems in a fraction of the time
• Hobbyists — bring robot ideas to life without deep expertise across the stack

​

Known Limitations

Drift is in active beta. Worth knowing up front:

• Prompt sensitivity — clear, specific prompts produce better results. “make a robot” gives generic output; describe the chassis, joints, sensors, world.
• Complex multi-robot setups — coordination and shared worlds are experimental.
• Architecture — Drift’s binary targets x86_64 (amd64). Apple Silicon (M1/M2/M3) users run Drift via a VMware Fusion x86_64 Ubuntu image. Raspberry Pi is not supported.
• Internet connectivity — Drift requires internet to process prompts. Your files stay local.

If you hit an issue, describe it at the drift> prompt — the agent will attempt to diagnose and recover. For persistent problems, open an issue on GitHub.

​

Next Steps