DEV Community: Drift

Install MuJoCo and Run Your First Simulation With One Prompt

Aditi Sharma — Fri, 26 Jun 2026 19:17:19 +0000

MuJoCo powers some of the most famous robotics and reinforcement learning benchmarks. The catch is getting it installed and configured before you can touch any of them.

MuJoCo powers some of the most widely used robotics and reinforcement learning benchmarks. But before you can run any of them, you need to install MuJoCo and configure your environment correctly. This walkthrough goes from a fresh environment to a first MuJoCo simulation by letting Drift handle the entire setup in one go.

Why installing MuJoCo isn't always quick

On paper, installing MuJoCo is a one-line job: pip install mujoco. In practice, the setup that surrounds it is where time disappears. You still need a clean Python environment, the right supporting packages for rendering and for the benchmark suite, and a quick check that everything actually launches rather than failing on a missing dependency.

For a lot of people, that first hour goes to chasing packages and fixing environment issues instead of running a single simulation. It's a small tax, but you pay it every time you set up a new machine or project.

Installing MuJoCo from a clean environment with one prompt

Instead of doing that by hand, we start from a clean environment and let Drift take the whole task. The prompt asks it to install MuJoCo, verify the installation, and launch a benchmark environment.

Here's what it handles, in order:

It installs MuJoCo and pulls in the dependencies: As MuJoCo installs, Drift automatically brings in the supporting packages it needs to run, so there's no separate round of hunting down missing requirements.
It configures the environment: Drift sets up the environment so the simulator and its rendering work together, rather than leaving you to debug configuration after the fact.
It verifies the installation: Before declaring success, it confirms MuJoCo is actually working, which is the step people most often skip and then regret.
It launches a benchmark environment: Finally, it brings up a benchmark so you can see the physics running, not just a "package installed" message.

Exploring your first MuJoCo simulation

Once the simulator is up, you can interact with the model, tweak the controls, and watch how MuJoCo handles physics in real time. It's a simple benchmark, but it's also the first real step toward building more advanced robotics and reinforcement learning simulations.

At this point MuJoCo is installed, verified, and ready to use. The setup that usually eats your first hour is done, and you got there from a single prompt against an empty environment.

Where to go after installing MuJoCo

From here, the interesting work begins. You can explore the built-in benchmark environments like Hopper, HalfCheetah, and Ant, experiment with your own models, or start building more advanced robotics and reinforcement learning projects, all without spending your first hour wrestling with the setup.

If you're still deciding whether MuJoCo is the right tool, our guides on what makes MuJoCo special and how the major robot simulators compare are good next reads. Otherwise, install it, launch a benchmark, and start experimenting today.

FAQ

How do you install MuJoCo?
The core install is pip install mujoco into a Python environment. Beyond that you typically need supporting packages for rendering and for the benchmark suite, plus a quick verification step. In this walkthrough, Drift handles the install, dependencies, configuration, and verification from a single prompt.

Is MuJoCo hard to install?
The base package is straightforward, but getting a clean environment, rendering, and benchmark dependencies all working together is where people lose time. Automating the setup removes most of that friction.

Do you need a GPU to run MuJoCo?
No. MuJoCo runs on a standard CPU for most simulation and benchmark use. A GPU mainly helps with the MJX branch, which runs many simulations in parallel for large-scale reinforcement learning.

How do you verify a MuJoCo installation?
You confirm the package imports correctly and that a model and viewer launch without errors, usually by running a simple model or a benchmark environment. Skipping this is a common cause of confusing failures later.

How do you run a MuJoCo benchmark environment?
The standard benchmark environments such as Hopper, HalfCheetah, and Ant are available through Gymnasium. Once MuJoCo and the benchmark packages are installed, you can load one of these environments and watch the physics run.

What does Drift do for MuJoCo setup?
Drift installs MuJoCo, pulls in the required dependencies, configures the environment, verifies the installation, and launches a benchmark, all from a natural-language prompt, so you reach a working simulation without manual setup.

Swarm Robotics: Why a Thousand Simple Robots Beat One Smart One

Aditi Sharma — Thu, 25 Jun 2026 18:11:12 +0000

One ant isn't much. Thousands of ants build colonies and solve hard problems. Swarm robotics asks what happens when robots work the same way.

A single ant isn't particularly impressive. But thousands of ants working together can build colonies, find food, and solve surprisingly complex problems. Swarm robotics asks a simple question: what if robots worked the same way? Instead of one highly capable machine, you coordinate many simple ones, and capability comes from the group.

What is swarm robotics?

Swarm robotics is an approach to robotics where many simple robots coordinate to accomplish tasks that a single robot would struggle with. Traditional robotics usually focuses on making one robot smarter and more capable, the kind of single mobile robot you stand up from scratch. Swarm robotics takes the opposite approach: deploy lots of inexpensive, simple robots that each follow a few basic rules.

Individually, those robots aren't very intelligent. Together, they can look surprisingly smart. The intelligence lives in the group, not in any one machine.

How swarm robotics works

Here's the part that surprises people. Most swarm robots don't have a leader. No single robot is in charge, and no robot holds the master plan. Each one follows a few simple rules and reacts to what's happening immediately around it, using only local information from its nearest neighbours.

That decentralisation is the point. Because no robot is essential, the swarm keeps working even if individuals fail, and it scales from a handful of robots to thousands without redesigning the system. Each robot is still running its own small sense, think, act loop; the swarm just runs thousands of them at once.

Emergent behaviour: how a swarm gets smart without a plan

When hundreds or thousands of robots follow those simple rules at the same time, something interesting happens. Complex, coordinated behavior starts to emerge that no single robot was programmed to produce. No robot knows the full plan, yet the swarm as a whole behaves as if it does. This is called emergent behavior.

A famous demonstration came from Harvard, where researchers built a swarm of more than a thousand tiny robots called Kilobots that could self-assemble into shapes like a star or a letter with no central control. Each Kilobot followed the same simple program and only talked to its neighbors, and the shapes appeared from the group, mistakes self-correcting along the way.

Swarm robotics examples: drones, warehouses, and search and rescue

The idea is already in use:

Drone swarms can coordinate massive aerial formations, the kind you see in light shows, without a central pilot steering each drone.
Warehouse robots move inventory around a facility while avoiding each other, keeping goods flowing without constant traffic jams.
Search-and-rescue swarms spread out to explore large or dangerous areas at the same time, covering far more ground than a single robot could.

Simulating these systems is its own challenge, since you need a simulator that handles many robots at once. If you're curious how the tools compare, see our robot simulators guide.

Inspired by nature: ants, bees, and termites

None of this is new. Nature has been doing it for millions of years. Ants, bees, and termites have no master plan and no manager, yet together they achieve things far beyond any individual: bridges built from bodies, hives run with precision, mounds engineered for airflow. It's the same instinct that gives us soft robots: when biology has already solved a problem, it's often easier to borrow the answer than invent a new one.

Swarm robotics is built on the same principle. Sometimes the smartest system isn't a single brilliant machine at all. It's a thousand simple robots, each following easy rules, adding up to something none of them could do alone.

FAQ

What is swarm robotics?
Swarm robotics is an approach where many simple robots coordinate to perform tasks collectively. Rather than building one highly capable robot, you deploy lots of basic ones that follow simple rules, and useful group behavior emerges from their interactions.

How does swarm robotics work?
Each robot follows a few simple rules and reacts to its nearby neighbors using local information. There's usually no leader and no central plan. Because control is decentralized, the swarm scales easily and keeps working even if some individual robots fail.

What are examples of swarm robotics?
Common examples include drone swarms that fly in coordinated formations, warehouse robots that move inventory while avoiding collisions, and search-and-rescue swarms that spread out to explore large areas. Harvard's thousand-robot Kilobot swarm is a well-known research example.

What is emergent behavior in swarm robotics?
Emergent behavior is complex, coordinated group behavior that arises from many robots following simple individual rules. No single robot is programmed with the overall outcome, yet the swarm as a whole produces it.

What is swarm robotics inspired by?
It's inspired by social insects and other collective systems in nature, especially ants, bees, and termites, which accomplish complex tasks through the simple, local actions of many individuals rather than central control.

Can Drift build swarm robotics simulations?
Drift generates simulation workspaces for individual robots in ROS 2, including the robot description, sensors, controllers, and world. Swarm behavior, where many robots coordinate through shared rules, is a separate layer built on top of those single-robot simulations, so Drift handles the per-robot foundation rather than the swarm coordination itself.

MuJoCo: The Physics Engine Robotics Research Quietly Runs On

Aditi Sharma — Tue, 23 Jun 2026 19:31:19 +0000

The physics engine behind robot hands, walking machines, and much of today's reinforcement learning research, and why it took off once DeepMind made it free.

MuJoCo, short for Multi-Joint dynamics with Contact, is a physics engine built for the fast, accurate simulation of robots and other articulated systems. It was first developed at the University of Washington in 2012 and later commercialized, which for years kept it mostly in the hands of academics and well-funded labs. That changed in 2021, when DeepMind acquired it, made it free, and went on to open-source the entire codebase. The price tag was the only thing that had been holding it back, and once it dropped, the wider robotics world got its hands on the simulator researchers had relied on for years. If you're moving into robotics or reinforcement learning, it's one of the most important tools to understand, so here's what actually sets it apart.

How MuJoCo went from paid software to free and open source?

For years MuJoCo sat behind a commercial license, which kept it mostly in the hands of academics and well-funded labs. That changed when DeepMind acquired it in October 2021 and made it free, then released the full source under an open license in 2022.

The acquisition did more than drop the price. It turned a quietly respected tool into something anyone could install with pip install mujoco and build on, which is a big part of why it shows up everywhere now.

What makes MuJoCo's physics different: contact as a constraint?

Here's the part that actually matters. Most simulators treat contact as a collision to detect and resolve after the fact. MuJoCo treats contact as a constraint problem, solving for the forces continuously as part of the equations of motion.

The payoff is realism where it's hardest to get. Friction, slipping, and soft contacts all behave much closer to the real world. That's why anything involving hands, fingers, or legged robots, where contact is essentially the whole problem, tends to end up in MuJoCo.

Why MuJoCo is fast enough for reinforcement learning?

MuJoCo can run hundreds of times faster than real time. For reinforcement learning, where training even a basic policy can take millions of simulation steps, that speed is the difference between a project that's feasible and one that isn't.

It goes further than that. The MJX branch, written in JAX, runs thousands of simulations in parallel on GPUs and TPUs, which is exactly what large-scale RL training needs. Speed here isn't a nice-to-have. It's the whole reason the field gravitated to it.

The benchmark environments that made MuJoCo a research standard

Open a robotics or RL paper and there's a good chance MuJoCo produced the results. Standard benchmark environments like Hopper, HalfCheetah, and Ant, available through Gymnasium, are so common they've become the MNIST of robotics: the baseline everyone tests against.

If you want to see how it stacks up against the alternatives, it sits alongside Gazebo, Isaac Sim, and others in our robot simulators comparison. It's also the kind of engine that powers research libraries like the one we explored in the LeRobot codebase.

MuJoCo's trade-offs: speed over photorealism

MuJoCo won't win a beauty contest. Its rendering is plain and it isn't photorealistic, which matters if your work depends on camera realism for perception. For that, a simulator like Isaac Sim fits better.

What MuJoCo offers instead is speed and physically accurate contact where it counts, which is exactly what serious robotics and reinforcement learning research needs. And if you'd rather not hand-write MJCF files, Drift can scaffold a MuJoCo workspace from a single prompt, so you can skip the setup and get to the experiment.

Should you use MuJoCo?

If you're moving into reinforcement learning or contact-heavy robotics like manipulation and legged locomotion, MuJoCo is worth installing today. Grab it with pip install mujoco, try one of the benchmark environments, and you'll quickly see why it became the default.

Watch the full breakdown in the video above, and tell us which simulator you want a deeper walkthrough of next.

FAQ

What is MuJoCo? MuJoCo, short for Multi-Joint dynamics with Contact, is a physics engine for fast, accurate simulation of robots and other articulated systems. It's widely used in robotics, reinforcement learning, and biomechanics research, and is especially strong at simulating contact.
Is MuJoCo free? Yes. MuJoCo was a commercial product until DeepMind acquired it in 2021 and made it free, then released it as open source under the Apache 2.0 license in 2022. You can install it with pip install mujoco.
What is MuJoCo used for? It's used to simulate contact-rich robotics tasks such as robotic hands, manipulation, and legged locomotion, to train reinforcement learning policies, and for research in biomechanics and control. Its standard benchmark environments are a fixture in RL papers.
Why is MuJoCo good for reinforcement learning? Two reasons: it runs hundreds of times faster than real time, which RL needs because training takes millions of steps, and its accurate contact model means policies trained in simulation behave sensibly. The MJX branch also runs many simulations in parallel on GPUs.
What's the difference between MuJoCo and Gazebo? MuJoCo is optimized for fast, accurate contact simulation and reinforcement learning research. Gazebo is the general-purpose ROS 2 simulator built around sensors, robot libraries, and full robotics workflows. Many researchers use MuJoCo for RL and Gazebo for ROS 2 system development.
Does Drift support MuJoCo? Yes. Drift generates simulation workspaces for ROS 2 across Gazebo, MuJoCo, and Isaac Sim, producing the matching description and world files (including MJCF for MuJoCo) from a single natural-language prompt.

Soft Robots: Why the Best Robot for the Job Might Be the Squishy One

Aditi Sharma — Sat, 20 Jun 2026 19:10:30 +0000

A silicone gripper picking up a raw egg, cleanly and effortlessly. What if the best robot for the job is the squishy one?

It sounds like a joke, but soft robots are a real and fast-growing field, and they're solving problems that rigid machines have struggled with for decades. The whole premise is to swap metal and motors for silicone, rubber, and other flexible materials, so the robot can bend, deform, and adapt to the world instead of fighting it.

What are soft robots?

A soft robot is a machine built partly or entirely from soft, flexible materials. Rather than rigid links driven by precise motors, it uses compliant structures that change shape, often powered by air pressure, fluids, or flexible actuators.

That one change has a big consequence. Because the body can deform, the robot adapts to whatever it's interacting with. No precise positioning, no complex gripping algorithm. It just conforms. They're still robots running the same sense, think, act loop as any rigid machine; they simply solve the "act" part with a body that gives.

Why a soft gripper beats a rigid one

Picture the difference in grasping. A rigid gripper needs to know exactly where an object is, how big it is, and how much force to apply, or it crushes or drops it. A soft gripper wraps around the object and lets the material do the work.

That's why soft grippers handle things rigid robots find hard: fruit, fragile materials, oddly shaped parts. Instead of relying on perfect positioning and tight control, they adapt to whatever lands in their grip. For messy, unpredictable real-world objects, that adaptability is a genuine advantage.

Where soft robots shine

The same flexibility opens up environments rigid machines can't easily handle.

Soft robots can squeeze through complex, confined spaces, move over uneven terrain, and interact gently with delicate things. One of the most striking applications is medicine: soft devices can operate inside the human body, where a rigid mechanism would be dangerous. Harvard's Soft Robotics Toolkit documents many of these designs, from wearable assistive devices to surgical tools.

Anywhere the world is irregular, fragile, or hard to reach, a body that conforms has the edge.

The catch: soft robots are hard to control

The same property that makes soft robots adaptable makes them difficult to engineer.

Control is the big one. When a robot is flexible by nature, predicting exactly where it ends up takes serious modeling, because the body has effectively infinite ways to bend. Speed and force are limited compared with rigid actuators. And sensing is still an open research problem: figuring out what a soft robot is actually doing, in real time, is much harder when there are no fixed joints to measure.

That difficulty is also the appeal. The field is young enough that the fundamentals, from materials to control theory, are still being worked out.

Why soft robotics is just getting started

Biology settled this question a long time ago. Octopuses, elephant trunks, and human hands all show that in most real-world situations, soft and adaptable beats rigid and precise. Robotics is only now catching up.

As materials, actuators, and control methods mature, expect soft robots to show up in more places where gentleness and adaptability matter more than raw speed or strength. It's one of the most open frontiers in robotics, and a great area to watch if you're deciding where the field is heading.

FAQ

What are soft robots?
Soft robots are machines built partly or entirely from flexible materials like silicone and rubber, rather than rigid metal links and motors. Their bodies bend and deform, which lets them conform to objects and environments instead of relying on precise positioning.
What are soft robots made of?
They're typically made from elastomers such as silicone and rubber, along with flexible fabrics and compliant actuators. Many are powered by air pressure or fluids that inflate chambers to make the structure bend or grip.
What are soft robots used for?
Common uses include gripping delicate or irregular objects such as fruit, moving through tight or complex spaces, and medical applications where a device needs to operate safely inside or against the human body.
Why are soft robots hard to control?
A flexible body can deform in countless ways, so predicting its exact position requires complex modeling. Their speed and force are also limited, and sensing what a soft robot is doing in real time remains an active research challenge.
How are soft robots different from traditional robots?
Traditional robots use rigid links and motors and depend on precise positioning and control. Soft robots use flexible materials that conform to objects and surroundings, trading precision and speed for adaptability and gentleness.
Can you simulate soft robots?
Yes, but soft-body simulation is harder than rigid-body simulation, because flexible materials deform in complex ways that usually require specialized methods like finite element modeling. General ROS 2 simulators and agents like Drift, which generate rigid-body robot simulations from a single prompt, are built for conventional robots, while soft robotics simulation remains a more specialized, research-heavy area.

Which Robot Simulator Should You Actually Use?

Aditi Sharma — Wed, 17 Jun 2026 18:47:08 +0000

Before you burn out a motor, crash a drone, or launch your robot off a table, there's a safer way to test your code.

There are a lot of robot simulators out there, they all claim to do everything, and half the tutorials you'll find are three ROS versions out of date. If you're working with ROS 2, picking the right simulator early saves you a lot of wasted effort. This is a plain-English tour of the six robot simulators worth knowing, and which one actually fits your project.

Why simulate at all?

Hardware is expensive, slow, and fragile. A simulator lets you test faster, break things safely, and iterate in minutes instead of hours. You can crash a robot a thousand times in sim and the only cost is a restart.

If you're learning ROS 2, starting in simulation is the smarter path. You get the full sense, think, act loop working in software first, which is the same idea we broke down in What Even Is a Robot?. Here's how the main options stack up.

Gazebo: the ROS 2 default

Gazebo is the one everyone mentions first, for good reason. It's effectively the default for ROS robotics, with solid physics, sensor modeling, and a huge library of robot models. If you're on ROS 2, you're most likely using Gazebo Sim, the modern version (Harmonic is the current long-term release, formerly known as Ignition).

The downside is that setup can be rough, and the first hour often goes to wiring things together rather than building. But for mobile robots, manipulators, and most ROS workflows, Gazebo is still the baseline. It's what we used to build a mobile robot simulation from a single prompt and then add a LiDAR sensor.

Webots: the easiest place to start

Webots is what you reach for when Gazebo feels overwhelming. It's open source, cross-platform, and much easier to get running. No ROS is required, though ROS 2 support is there through the webots_ros2 package if you want it, and it ships with a large library of ready-made robot models.

The physics aren't as advanced as Gazebo's, but for education, quick prototypes, and most beginner projects, that honestly won't matter. If your goal is to learn and move fast, Webots gets you to a running robot with the least friction.

Isaac Sim: the choice for AI and perception

If Gazebo is the workhorse, NVIDIA's Isaac Sim is the cinematic universe. Built on NVIDIA Omniverse, it's photorealistic, physically accurate, and deeply tied to AI workflows: synthetic data generation, domain randomization, and sim-to-real transfer.

The catch is that you'll need a strong NVIDIA GPU, and the learning curve is steeper. But for perception and AI-heavy robotics, where visual fidelity directly affects whether your trained models work in the real world, nothing else comes close.

CoppeliaSim: dependable for arms and academia

Previously called V-REP, CoppeliaSim has been quietly reliable for years. It's especially strong for robotic arms and multi-robot simulations, with built-in scripting, ROS support, and the ability to swap between physics engines. It also runs surprisingly well on modest hardware.

It's dependable rather than flashy: stable, flexible, and widely used across academia for exactly that reason.

Reinforcement learning simulators: PyBullet and MuJoCo

These two come up constantly in reinforcement learning and robotics research.

PyBullet:

It is lightweight, Python-friendly, and easy to set up. If you want to train RL agents without spending hours configuring a simulator, PyBullet is a great place to start. It has no official ROS 2 bridge, so it's better suited to pure learning experiments than full-stack testing.

MuJoCo:

It sits at the other end of the spectrum. MuJoCo is the simulator behind a huge amount of modern robotics research, especially humanoids, robotic manipulation, and legged locomotion. If you've seen a robot hand solving a Rubik's Cube, a humanoid learning to walk, or an arm trained to follow a human hand, there's a good chance MuJoCo was somewhere in the pipeline. It's fast, accurate, now open source, and trusted enough that it became the go-to for many RL researchers.

How to choose the right robot simulator

Match the tool to the job. For full-stack ROS 2 work like navigation and SLAM, start with Gazebo. If you're new and want momentum, Webots. For AI, vision, and synthetic data, Isaac Sim. For robotic arms and reproducible academic work, CoppeliaSim. For reinforcement learning, PyBullet to learn and MuJoCo for serious research.

Whichever you pick among the ROS 2 options, the slow part is usually the same: standing up the workspace, the robot description, and the sensor and controller configuration before you can run anything. That setup tax is exactly what Drift is built to remove. It generates production-grade simulation workspaces for ROS 2 across Gazebo, MuJoCo, and Isaac Sim from a single prompt, so you spend your time on the robotics instead of the plumbing.

The bottom line

There's no single best robot simulator, only the best one for what you're building. Gazebo for ROS 2 by default, Webots to learn, Isaac Sim for AI and perception, CoppeliaSim for arms, and PyBullet or MuJoCo for reinforcement learning.

Pick one, get a robot running in it this week, and start breaking things safely. Watch the full rundown in the video above, and tell me which simulator you want a deeper walkthrough of next.

FAQ

What is the best robot simulator for ROS 2?
For most ROS 2 work, Gazebo is the default choice because of its native integration with the ROS 2 navigation and control stack. Webots is the easiest to start with, and Isaac Sim is preferred for AI and perception tasks that need photorealism.

Which robot simulator is best for beginners?
Webots and PyBullet are the most beginner-friendly. Webots is open source, cross-platform, and quick to set up with built-in robot models, while PyBullet is lightweight and Python-friendly, which makes it easy to start with for learning and reinforcement learning experiments.

Which simulator is best for reinforcement learning?
PyBullet and MuJoCo are the most popular for reinforcement learning. PyBullet is lightweight and easy to configure, and MuJoCo is fast and accurate enough to be the standard in research on manipulation, humanoids, and legged locomotion.

Is Gazebo or Isaac Sim better?
They serve different goals. Gazebo is better for general ROS 2 development and runs on modest hardware, while Isaac Sim is better for AI, perception, and synthetic data generation, but it requires a strong NVIDIA GPU and has a steeper learning curve.

Does Drift work with these simulators?
Drift generates simulation workspaces for ROS 2 across Gazebo, MuJoCo, and Isaac Sim (Isaac Sim coming soon) from natural-language prompts, including the robot description, world files, controllers, and plugin configuration.

I Gave My Robot a LiDAR With One Prompt. Now It Can See

Aditi Sharma — Mon, 15 Jun 2026 19:30:51 +0000

A robot that drives is fine. A robot that can sense the world around it is where things get interesting.

A robot that can't sense its environment is really just a machine that moves. Getting that first sensor online, properly online, is where a lot of robotics projects stall. This post picks up the mobile robot simulation from the last build and adds a LiDAR sensor to it in ROS 2 and Gazebo, turning a robot that drives into one that can actually perceive what's around it.

The problem: a robot that drives but senses nothing

From the last build we have a working mobile robot simulation. It drives, and Gazebo is running. But there's no sensor data coming out of it. No /scan topic, nothing for a mapping or navigation algorithm to consume.

That gap matters more than it looks. Sensing is the first step of the sense, think, act loop that nearly every robot runs on. Without it, the "think" and "act" steps have nothing real to work with. So the next move is clear: give the robot a LiDAR.

How to add a LiDAR sensor to the robot in one prompt

Wiring a LiDAR into an existing robot usually means hand-editing the URDF to add a sensor link and joint, dropping in a Gazebo sensor plugin, and making sure the frame names and topic remappings all line up. Miss one and the sim launches but publishes nothing. If you want the full manual version, the Nav2 sensor setup guide walks through it step by step.

Instead of doing that by hand, I asked Drift to integrate the sensor into the existing workspace:

"Integrate a LiDAR sensor into the existing robot simulation."

Here's what it did, in order:

It read the existing setup first: Drift went through the current URDF and package structure before changing anything, so the additions matched the robot already defined.
It added the LiDAR link, joint, and Gazebo ray sensor plugin: That's the trio you need: a link representing the sensor, a joint attaching it to the robot, and the ray sensor plugin that makes Gazebo actually produce scan data.
The frame names and topic stayed consistent: The new sensor frame matched the rest of the transform tree, and the scan topic was mapped correctly. That alignment is exactly where hand-wiring usually breaks, and getting it wrong is why a sim can run while RViz shows nothing.

Why this is the moment robotics gets real

Robotics starts to feel real the moment a robot senses the world around it. Movement alone never quite gets there. Once the LiDAR is publishing, the robot stops being a thing that drives in the dark and becomes something that can react to what's actually in front of it.

And once sensor data is flowing, the rest of the stack opens up. Mapping. Navigation. Autonomy. All of it depends on a clean stream of sensor data and a transform tree that lines up, which is the part we just put in place. Instead of fighting URDFs, frame names, and plugins for an hour, the integration happened in context, against the workspace that already existed.

What's next: from sensing to navigation

The robot can finally see. That's the foundation everything else is built on.

The next step is teaching it to use that sensor stream to find its way around, which means moving into mapping and the navigation stack. If you're building your own simulation, this is the point to get your sensor data clean and your frames consistent before you layer navigation on top.

Watch the full integration in the video above, and follow along to the next build where we teach this robot to navigate.

FAQ

Why does my robot simulation have no /scan topic or sensor data?
Usually because the robot has a body and can move, but no sensor has been added to the URDF, or the sensor plugin and topic remapping aren't configured. A robot that drives in Gazebo will still publish nothing until a LiDAR or other sensor is wired in with a matching frame and topic.
How do you add a LiDAR sensor to a robot in ROS 2 and Gazebo?
With Drift, you describe it in a single prompt and it edits your existing workspace in context: adding the LiDAR link and joint to the URDF, attaching the Gazebo ray sensor plugin, and mapping the output to a topic such as /scan with a consistent frame name. Those are the same edits you would otherwise make by hand before rebuilding and checking the scan data in RViz, which is where mismatched frames or topics usually trip people up.
What is the Gazebo ray sensor plugin?
It's the Gazebo plugin that simulates a laser range sensor by casting rays in the simulated world and publishing the results as a LaserScan message, the same message type a real LiDAR would produce. It's what turns a static sensor link into a working data source.
Can Drift add a sensor to an existing URDF or use custom plugins?
Yes. Drift accepts existing URDF and SDF files and extends them in place, and it configures standard Gazebo plugins like LiDAR, cameras, IMUs, and depth sensors automatically. For custom or third-party plugins, you name them in the prompt and Drift adds the plugin block, though you may still need to verify build paths and parameters.
What is Drift?
Drift is an end-to-end robotics simulation engineering agent. It turns natural-language prompts into simulation workspaces for ROS2, Gazebo, MuJoCo, and Isaac Sim, generating URDF, SDF, and world files, configuring plugins and controllers, and scaffolding colcon workspaces.

What Even Is a Robot? (It's Messier Than You Think)

Aditi Sharma — Fri, 12 Jun 2026 19:03:29 +0000

A Roomba, a robotic arm, a self-driving car, a drone. Where's the line between a machine and a robot? Blurrier than you'd think, but they all share one thing.

When does a machine become a robot?

Picture a few things in a row. A robot vacuum. An industrial arm on a factory line. A self-driving car. A drone. Then a vending machine. An elevator. A smart speaker.

The first few feel obviously robotic. Somewhere around the vending machine and the elevator, your confidence starts to wobble. Both sense input and act on it, so what disqualifies them?

At what point does something stop being a machine and start being a robot?

The further right you go, the less sure anyone is. That fuzzy middle is the whole problem.

Why there's no single definition of a robot

If you go looking for one crisp definition, you won't find it. Ask a room of engineers and you'll get a room of arguments.

The disagreements tend to circle the same questions. Does a robot have to be autonomous, or does a remote-controlled machine count? Does it need to be reprogrammable? Must it physically move something in the world, or can a piece of software be a robot? Every definition that sounds tidy ends up either letting in a dishwasher or shutting out something most people would call a robot.

Underneath all the arguing, there's a pattern almost everyone's examples share.

The sense, think, act loop every robot shares

Popular explainers call it sense-think-act. In robotics textbooks it's the sense-plan-act paradigm. Same idea.

Strip away the shape and the branding, and most robots run the same three-step cycle, over and over.

Sense: First, the robot takes in the world. Cameras, LiDAR and other sensors, microphones, GPS. This is perception: turning physical reality into data the machine can work with. Without sensing, a robot is basically improvising reality.
Think: Next, it processes what it took in. Is there an obstacle? Where should I move? What object am I looking at? Sometimes this is simple pre-programmed logic, like stopping before a wall. Sometimes it's AI weighing options and predicting outcomes. Either way, this is where a decision gets made.
Act: Finally, the robot does something. Wheels turn. An arm moves. A drone adjusts its flight. The moment it acts, it changes the world around it, which gives the sensors something new to perceive, and the loop starts over.

Sense feeds think, think feeds act, and acting changes what gets sensed next.

Sense, think, act in action: how a robot vacuum works

The clearest everyday example is the robot vacuum bumping around your floor. It senses walls and furniture using its onboard sensors. It thinks about where the obstacles are and what that means for its path. Then it acts by changing direction and driving on.

It runs that cycle hundreds of times every minute, which is why a cheap disc on wheels can cross a cluttered room without help.

So, what is a robot? Different shapes, same loop

How human a robot looks turns out to be a poor guide. The better test is the loop. A robot is a machine that can sense the world, process that information, and act on it, then do it again. By that test, the industrial arm, the self-driving car, and the floor vacuum are all clearly robots, even though they share almost nothing in appearance.

Different shapes. Same loop.

Where this goes next

Once you start seeing robots as a sense-think-act loop, the interesting question shifts from "what is a robot" to "how do you build one." That's where simulation comes in: you can test the whole loop in software before any hardware exists.

If you want to see that in practice, I wrote about building a mobile robot simulation in ROS 2 from a single prompt and using an AI agent to map the LeRobot codebase. Both pick up roughly where this loop leaves off.

FAQ

What is a robot? There's no single universally accepted definition, but a practical one is: a machine that can sense its environment, process that information to make a decision, and act on the physical world, repeating that cycle. The form it takes can vary widely.

What is the sense, think, act loop? It's the basic cycle most robots follow. The robot senses the world through sensors, processes that data to decide what to do, then acts through motors or actuators. Acting changes the environment, which the robot senses again, closing the loop.

What's the difference between sense-think-act and sense-plan-act? They describe the same core idea. "Sense, think, act" is the common plain-language version, while "sense-plan-act" is the term used in robotics literature for the classic deliberative paradigm. Reactive and hybrid paradigms are variations on how the thinking step is handled.

Do all robots use AI? No. The "think" step can be simple pre-programmed logic, like stopping before a wall, or it can be AI that evaluates options and predicts outcomes. Many useful robots use little or no machine learning.

Is a self-driving car a robot? By the sense-think-act test, yes. It senses with cameras, LiDAR, and radar, processes that data to plan a path, and acts by steering, accelerating, and braking, continuously and on its own.

I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)

Aditi Sharma — Thu, 11 Jun 2026 14:06:59 +0000

New to robot learning? Here's how to map a huge open-source robotics repo in minutes instead of clicking through folders for an hour.

Why big open-source robotics repos feel intimidating at first

If you're getting into robotics and wondering how people actually train robots, work with datasets, or run policies, the best open-source tools are where you start. They're also where a lot of people get stuck.

The reason is simple. The most capable repositories are big. You open one up and immediately see a wall of folders, modules, and config files, with no obvious place to begin. The learning you came for is in there somewhere, sitting under layers of structure you have to decode first.

What's inside LeRobot, Hugging Face's open-source robot learning library

Datasets, policies, training code, robot interfaces, and simulation tools, all in one place.

For this one I opened LeRobot from Hugging Face, one of the most popular open-source robotics projects out there. People sometimes describe it as the "Transformers for robotics," and the scope lives up to that. It bundles datasets, policies, training code, robot interfaces, and simulation tools into a single library.

That breadth is exactly what makes it powerful, and exactly what makes a fresh clone feel like a lot to take in.

Mapping the LeRobot codebase with an AI agent in one prompt

The prompt, the fresh workspace, and what Drift returned.

The starting point was bare. A fresh workspace, just the cloned repository, nothing else set up.

One prompt did the inspection. Instead of clicking through folders and trying to piece things together by hand, I opened Drift and asked it to read the repo:

"Inspect the lerobot directory and give summary of the repo."

It mapped the top-level structure first. Within a moment the layout came back clean. The top-level structure was laid out plainly, so the shape of the project was readable at a glance.

Then it surfaced the core modules. Underneath, it pulled out the pieces that matter for actually using the library: policies, datasets, robot interfaces, and simulation environments. That's the map you normally build in your head over an hour of digging.

From folder archaeology to actually learning robotics

What understanding the architecture quickly does for your learning and building.

This is the part I enjoy most: the moment a giant robotics repo stops feeling intimidating.

The best open-source tools are often buried under layers of complexity, and the time you spend excavating them is time you're not spending on the thing you opened the repo to learn. Getting the architecture handed to you up front means you skip the folder archaeology and go straight to reading the policies, loading a dataset, or running something in simulation.

For anyone learning robot learning from open-source code, that shift from "where is everything" to "now I can start" is the whole game.

Try it on any robotics repo

Next time a big repository feels like a wall, point Drift at the directory and ask it to summarize the structure before you start clicking. Clone the repo, open Drift, and ask it to map the codebase.

Watch the full walkthrough in the video above, and tell me which repo I should have it map next.

FAQ

What is LeRobot?
LeRobot is Hugging Face's open-source robotics library for robot learning. It provides datasets, pretrained policies, robot interfaces, and simulation environments in PyTorch, aiming to lower the barrier to entry for working with real-world robots.

What is Drift?
Drift is an end-to-end robotics simulation engineering agent. It turns natural-language prompts into production-grade simulation workspaces for ROS2, Gazebo, MuJoCo, and Isaac Sim, generating URDF, SDF, MJCF, and USD files, configuring plugins and controllers, and scaffolding colcon workspaces. Beyond setup, it runs scenario variations, captures synthetic data for training, and (coming soon) trains policies on managed cloud compute.

How is Drift different from general-purpose coding agents like Cursor, Claude Code, or GitHub Copilot?
General-purpose coding agents don't understand ROS2 plumbing, URDF and SDF semantics, simulator physics, or colcon build conventions. Drift is purpose-built for robotics, reasoning about TF trees, joint controllers, plugin compatibility, mass and inertia validity, and Gazebo, MuJoCo, and Isaac Sim configuration as first-class concepts. The result is working simulations on the first run, not code that compiles but won't launch.

Which simulators and ROS version does Drift support?
Drift supports ROS2 and three major simulators: Gazebo, MuJoCo, and Isaac Sim (coming soon). It generates the matching world and robot description files (SDF for Gazebo, MJCF for MuJoCo, USD for Isaac Sim), along with the launch files, controllers, and plugin configuration needed to run them end to end.

What data does Drift send to the cloud? Is my code private?
Drift runs locally on your machine. Your workspace, URDF and SDF files, mesh assets, and ROS code never leave your environment. Only the text of your prompts and the diffs Drift proposes are sent to its API, which makes it safe to use on internal robot designs and IP-sensitive workspaces.

What operating systems does Drift run on?
Drift runs on Ubuntu. macOS and Windows are not officially supported today; engineers on those platforms typically run Drift inside an Ubuntu VM, a container, or a remote dev box.

From an Empty Workspace to a Running Robot in One Prompt

Aditi Sharma — Wed, 10 Jun 2026 18:46:57 +0000

The hard parts of robotics are supposed to be perception, planning, and control. So why does so much of the day go to everything that comes before them?

The hidden setup tax in every robotics simulation project

Ask anyone what's hard about robotics and you'll get the same list: perception, planning, control, navigation. The genuinely interesting problems.

If you track where your hours actually go, though, a strange thing shows up. A big chunk of the day disappears before you reach any of that. You're not solving hard problems yet. You're just getting to the starting line: wiring up a workspace, writing description files, stitching together launch files, and coaxing a simulator into opening without errors.

It's the unglamorous tax on every project, and most of us have quietly accepted it as the cost of doing business.

Building a differential drive robot simulation in ROS 2 and Gazebo from scratch

A diff drive base, a LiDAR, and Gazebo, set up from one prompt instead of an afternoon of boilerplate.

A few days ago I wanted a simple mobile robot simulation. Nothing exotic:

a differential drive base (two driven wheels, the classic mobile-robot setup),
a LiDAR for sensing,
running in Gazebo.

This is the kind of thing that should be straightforward. In practice it's an afternoon of boilerplate before the robot so much as twitches.

So instead of wiring it up by hand, I wanted to see how far Drift could get from a single prompt. To make it a fair test, I stripped the workspace down to nothing. No packages, no URDF, no launch files. A blank slate.

Then I typed one line:

"Create a mobile simulation from scratch."

From XACRO to URDF: how the robot description gets generated in ROS 2

What the tool wrote first, and what XACRO and URDF actually do for your robot.

It checked the workspace first: The opening move was sensible: it looked at the current directory to understand what it was working with.
It generated a XACRO file for the robot's dimensions: XACRO is the macro-based format that expands into a URDF, the file that tells the rest of the ROS 2 stack what your robot physically is: its links, joints, and geometry. Writing this by hand is one of the slower parts of standing up any new robot.
The package layout came out organized: The packages, description, and launch pieces sat roughly where you'd expect them instead of landing in one messy folder.
A running simulation in a few minutes: An empty workspace had become a running mobile robot simulation in Gazebo.

What one-prompt simulation setup means for robotics engineers

The real win is where your starting line sits. File generation is the smaller part of the story.

A running robot in a running simulator is exactly where I'd normally want to start working. The robot exists. The world is loaded. The plumbing is done. That's the point where the real robotics begins, and I got there without spending the first half of my day connecting things together.

What changed is where the starting line sits. If you spin up simulation environments constantly, that setup time isn't a one-off cost. You pay it again on every project. Getting it back means more of your day goes into the work that actually moves a project forward.

Try building a mobile robot simulation from a single prompt

If setup time is eating into your robotics work, that's the gap this is built to close. Start from an empty workspace, describe what you want, and see how close you get to a running simulation before you touch a single config file.

Watch the full run in the video above, and tell me what you'd point a single prompt at next.

FAQ

Can you set up a ROS 2 robot simulation from a single prompt?
Yes. In this walkthrough, the prompt "Create a mobile simulation from scratch" produced the packages, robot description, and launch setup for a running mobile robot simulation, starting from an empty workspace.

What is a differential drive robot simulation?
A differential drive robot moves using two independently driven wheels, steering by turning them at different speeds. Simulating one in Gazebo lets you test movement and sensors like LiDAR before deploying to hardware.

What is the difference between XACRO and URDF?
URDF is the XML file that describes a robot's links, joints, and geometry. XACRO is a macro language that expands into a URDF, letting you reuse and parameterize parts instead of writing repetitive XML by hand.

How long does it take to set up a mobile robot simulation in ROS 2 and Gazebo?
Done manually it's often an afternoon of boilerplate. In this walkthrough the working simulation came together in a few minutes from a single prompt.

What is Drift?
Drift is the AI tool used in this walkthrough. Given a prompt, it generates the workspace structure, robot description, and launch files needed for a working ROS 2 simulation.

DEV Community: Drift

Install MuJoCo and Run Your First Simulation With One Prompt

Why installing MuJoCo isn't always quick

Installing MuJoCo from a clean environment with one prompt

Exploring your first MuJoCo simulation

Where to go after installing MuJoCo

FAQ

Related reading

Swarm Robotics: Why a Thousand Simple Robots Beat One Smart One

What is swarm robotics?

How swarm robotics works

Emergent behaviour: how a swarm gets smart without a plan

Swarm robotics examples: drones, warehouses, and search and rescue

Inspired by nature: ants, bees, and termites

FAQ

Related reading

MuJoCo: The Physics Engine Robotics Research Quietly Runs On

How MuJoCo went from paid software to free and open source?

What makes MuJoCo's physics different: contact as a constraint?

Why MuJoCo is fast enough for reinforcement learning?

The benchmark environments that made MuJoCo a research standard

MuJoCo's trade-offs: speed over photorealism

Should you use MuJoCo?

FAQ

Related reading

Soft Robots: Why the Best Robot for the Job Might Be the Squishy One

What are soft robots?

Why a soft gripper beats a rigid one

Where soft robots shine

The catch: soft robots are hard to control

Why soft robotics is just getting started

FAQ

Related reading

Which Robot Simulator Should You Actually Use?

Why simulate at all?

Gazebo: the ROS 2 default

Webots: the easiest place to start

Isaac Sim: the choice for AI and perception

CoppeliaSim: dependable for arms and academia

Reinforcement learning simulators: PyBullet and MuJoCo

PyBullet:

MuJoCo:

How to choose the right robot simulator

The bottom line

FAQ

Related reading

I Gave My Robot a LiDAR With One Prompt. Now It Can See

The problem: a robot that drives but senses nothing

How to add a LiDAR sensor to the robot in one prompt

Why this is the moment robotics gets real

What's next: from sensing to navigation

FAQ

What Even Is a Robot? (It's Messier Than You Think)

When does a machine become a robot?

Why there's no single definition of a robot

The sense, think, act loop every robot shares

Sense, think, act in action: how a robot vacuum works

So, what is a robot? Different shapes, same loop

Where this goes next

FAQ

I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)

Why big open-source robotics repos feel intimidating at first

What's inside LeRobot, Hugging Face's open-source robot learning library

Mapping the LeRobot codebase with an AI agent in one prompt

From folder archaeology to actually learning robotics

Try it on any robotics repo

FAQ

From an Empty Workspace to a Running Robot in One Prompt

The hidden setup tax in every robotics simulation project

Building a differential drive robot simulation in ROS 2 and Gazebo from scratch

From XACRO to URDF: how the robot description gets generated in ROS 2

What one-prompt simulation setup means for robotics engineers

Try building a mobile robot simulation from a single prompt

FAQ