DEV Community: Aditi Sharma

Adding an IMU to a Quadruped in MuJoCo

Aditi Sharma — Sat, 18 Jul 2026 19:13:41 +0000

How does a robot know if it's leaning, turning, or about to lose its balance? That sense comes from one small sensor, called IMU.

An IMU, or Inertial Measurement Unit, tracks a robot's motion and orientation in real time, giving it a constant sense of how it's moving. This walkthrough adds an IMU to a quadruped in MuJoCo and rather than editing the model by hand, we let Drift wire the sensor into our existing simulation from a single prompt.

What an IMU does and why a quadruped needs one

An IMU measures two things continuously: acceleration and orientation. Together those tell a robot how fast it's moving, which way it's tilted, and how it's rotating, moment to moment.

For a legged robot, that feedback is essential. A walking quadruped is balancing on a small base of contact points, and without a sense of its own tilt and motion it has no way to tell that it's starting to fall until it already has. The IMU is what gives a balance controller something to react to.

Adding the IMU to the quadruped with Drift

Starting from the existing quadruped scene, we give Drift a simple prompt: add an IMU sensor to the quadruped and launch it in MuJoCo.

Drift updates the robot description to include the IMU, wires the sensor into the simulation, and reports back a summary of what it changed. What would normally mean hand-editing the model and its sensor configuration is handled in one step. If you're starting earlier in the process, here's how to build the quadruped simulation first.

Relaunching the walking controller with the IMU in place

With the sensor added, we relaunch the walking controller and the simulation comes back up. The quadruped starts jogging in place, and this time the IMU is part of the loop.

As the robot moves, the IMU continuously tracks its motion in real time. Nothing about the gait looks different on the surface, but the robot now has a live stream of data about its own orientation that it didn't have before.

Reading the live IMU data as the quadruped moves

The clearest payoff is in the terminal, where the live IMU readings scroll past as the quadruped jogs. The sensor reports the robot's acceleration and orientation continuously, updating many times a second.

That stream is what a balance or locomotion controller consumes to keep the robot stable. Seeing the raw numbers change as the robot moves is a good way to build intuition for what the controller is actually working with, and it's the foundation for more advanced behaviors like recovering from a push or adapting to uneven ground.

How an IMU fits into a robot's sensor suite

Adding an IMU is a small step with a big role. Real legged robots rely on this exact sensor to stay upright, and it's one piece of the sensor suite behind stable, autonomous movement, alongside things like the LiDAR we added to a mobile robot for navigation.

With Drift handling the integration, you get from "no orientation data" to "live IMU stream" in a single prompt, so you can spend your time on what the robot does with that data. Add the sensor, relaunch, and watch the readings. The full walkthrough is in the video above.

FAQ

What is an IMU in robotics?
An IMU, or Inertial Measurement Unit, is a sensor that measures a robot's acceleration and orientation in real time. It gives the robot a continuous sense of how it's moving and which way it's tilted, which is essential for balance and stable motion.

Why does a quadruped robot need an IMU?
A legged robot balances on a small set of contact points and can tip over easily. The IMU tells it how it's tilting and accelerating moment to moment, giving a balance controller the feedback it needs to keep the robot upright and moving stably.

What does an IMU measure?
An IMU typically measures linear acceleration and angular orientation, and often angular velocity. Combined, these describe how the robot is moving and rotating in space at any instant.

How do you add an IMU to a robot in MuJoCo?
You add the IMU to the robot's description and configure it to publish acceleration and orientation data in the simulation, using MuJoCo's built-in sensor definitions. In this walkthrough, Drift makes those changes to an existing quadruped and relaunches it in MuJoCo from a single prompt.

What does Drift do when adding an IMU?
Drift updates the quadruped's model to include the IMU sensor, wires it into the simulation, and launches it, all from a natural-language prompt, so the sensor is streaming live data without manual editing.

5 AI Models Changing Robotics Right Now

Aditi Sharma — Sat, 18 Jul 2026 08:38:08 +0000

Programming a robot used to mean scripting every single step. These five models are why that's changing fast.

Not long ago, getting a robot to perform a task meant programming every single step. Today, robots are beginning to understand language, recognize objects, and learn new skills. The AI models for robotics behind that shift are mostly a new class called vision-language-action (VLA) models, which take in what a robot sees plus an instruction, and output the actions to carry it out. Here are five driving the transformation.

1. RT-2: the model that connected language to robot actions

First up is RT-2 from Google DeepMind. Released in 2023, it's the model that named the vision-language-action category.

Its core trick was representing robot actions as text tokens, which let a single model train on both web-scale image and text data and real robot data. The result was robots that could connect what they see with instructions written in natural language. Instead of following fixed commands, they could start to work out what a human actually meant, including for objects and phrasings they'd never seen in robot training data.

2. OpenVLA: bringing vision-language-action models to open source

Another major step came with OpenVLA, a 7-billion-parameter model from Stanford and Toyota Research Institute.

Its contribution was access. It brought powerful vision-language-action models into the open-source world, so any lab or developer could download the weights, fine-tune on their own robot, and experiment with modern robotics AI. That turned VLAs from something a handful of large teams could explore into something the whole field could build on.

3. NVIDIA GR00T: a foundation model for humanoid robots

NVIDIA is taking a different approach with GR00T. Rather than targeting one task, GR00T N1 is designed as an open foundation model to help humanoid robots perform a wide range of everyday activities.

It uses a dual-system design: a vision-language model handles the reasoning about what it sees and hears, while a separate action module generates the actual motor commands. From one set of weights it can drive single-arm, bimanual, and humanoid bodies, which is exactly the kind of generality that humanoid robots need to be practical.

4. LeRobot: an open platform for AI-powered robots

Then there's LeRobot from Hugging Face. Calling it a model undersells it. It's an open robotics platform with datasets, pre-trained models, simulation environments, and tools that help developers build AI-powered robots faster.

The idea mirrors what Hugging Face did for language models: gather the data, the models, and the tooling in one place so people can start from proven work instead of scratch. We took a closer look at how the LeRobot codebase is structured if you want to explore it yourself.

5. Pi-Zero: one model across many robots and tasks

Finally, Pi-Zero, written as π0, from Physical Intelligence. Its goal is ambitious: a single AI model that adapts across different robots and different tasks.

It pairs a pre-trained vision-language model with a flow-based action expert, and trains across data from many robot types rather than one. That cross-embodiment approach, one brain for many bodies, is a real step toward general-purpose robotics, and it's shown up in demos doing everyday work like folding laundry and clearing tables.

What these AI models mean for the future of robotics

These five take different approaches, but they're aimed at the same future. Robots are moving past following instructions and toward learning, adapting, and interacting with the world around them, which is the core promise of embodied AI.

One thread runs through all of them: scale. Each depends on huge amounts of training data, and much of it comes from simulation, where a model can practice millions of times before it touches real hardware.

FAQ

What are vision-language-action (VLA) models?
VLA models take in what a robot sees along with a language instruction, and output the robot's actions directly. They let a robot follow natural-language commands and generalize to objects and situations it wasn't explicitly trained on, rather than executing hard-coded steps.

What is RT-2?
RT-2 is a vision-language-action model from Google DeepMind, released in 2023. It represents robot actions as text tokens so a single model can learn from both web data and robot data, which lets it apply general knowledge from the internet to physical control.

What is the best open-source robotics AI model?
OpenVLA is a common starting point, since its weights are openly available and it can be fine-tuned on a new robot with limited data. Hugging Face's LeRobot is the go-to open platform, providing datasets, pretrained models, and tooling around models like these.

What is NVIDIA GR00T?
GR00T is NVIDIA's open foundation model for generalist humanoid robots. It combines a vision-language model for reasoning with an action module for motor control, and a single set of weights can operate single-arm, bimanual, and humanoid robots.

What is Pi-Zero (π0)?
Pi-Zero is a vision-language-action model from Physical Intelligence built for general robot control. It's trained across data from many different robots, with the goal of one model that adapts to different bodies and different tasks.

How are these robotics AI models trained and tested?
Largely in simulation, where a policy can be trained and evaluated at massive scale before it runs on expensive hardware. Tools like Drift generate the simulated robots and environments used for that testing, while the models themselves are trained on top of those simulations.

Watch a Robot Solve a Maze on Its Own in MuJoCo

Aditi Sharma — Fri, 17 Jul 2026 13:31:22 +0000

Driving from A to B sounds simple. Add walls, obstacles, and dead ends and the robot has to figure it out for itself.

Getting a robot from one point to another sounds simple until walls, obstacles, and dead ends get in the way. This walkthrough builds autonomous maze navigation in MuJoCo, where a mobile robot has to work out its own route to the goal, and we let Drift generate the maze, the robot and the navigation logic from one prompt.

Why a maze is a good test of autonomous navigation

A maze strips navigation down to its essentials. There's no clear line to the goal, the robot can't see the whole layout at once, and a wrong turn leads to a dead end. To get through, it has to perceive what's immediately around it and make decisions as it goes.

That makes it a compact version of the real challenge. The robot needs to detect walls, avoid hitting them, and keep updating its path based on what it discovers, which is the core of how robots navigate anywhere.

Generating the maze and navigation logic with Drift

Rather than building the maze and writing the navigation code separately, we give Drift a single prompt: generate a maze, spawn a mobile robot and implement autonomous navigation that avoids collisions while finding its way to the goal.

Here's what it produces:

The maze environment: Drift creates the scene in MuJoCo, laying out the walls and pathways that define the challenge.
The robot at the start: A mobile robot is placed at the maze entrance, ready to run.
The navigation logic: The decision-making that lets the robot sense its surroundings, steer clear of walls, and work toward the goal is generated and wired in. If you're starting fresh, here's how to install MuJoCo in one prompt first.

Watching the robot find its way to the goal

Here's the robot at the entrance of the maze. The simulation starts, and it goes to work.

It detects the surrounding walls, avoids collisions, and continuously adjusts its path toward the goal. No one is steering it. Every turn is the robot reading its immediate surroundings and deciding what to do next, which is what makes watching it worthwhile: you're seeing the decision loop play out in real time.

What maze navigation teaches you about real robots

This is a simple maze, but the same idea scales up. Real robots navigating warehouses, offices, and other unfamiliar spaces work exactly this way: they constantly perceive their surroundings, make decisions, and update their path as they move.

An office environment full of desks and chairs is a messier version of the same problem. The maze just makes the logic easy to see, because every wall forces a visible decision.

Testing how robots make decisions in motion

Reaching the destination is only part of the goal. Reaching it safely, without clipping a wall or getting stuck, is what autonomous navigation is really about, and a maze makes any failure obvious immediately.

With Drift generating the environment and the navigation setup, the setup work is out of the way and you can focus on the interesting part: how the robot makes decisions while it's moving. Generate a maze, change the layout, and watch how the behavior holds up. The full run is in the video above.

FAQ

How does a robot navigate a maze autonomously?
It senses the walls around it, avoids collisions, and continuously re-plans its route toward the goal as it discovers the layout. Instead of following a fixed path, it makes decisions based on what it perceives at each step.

How do you build a maze simulation in MuJoCo?
You need a MuJoCo scene with walls and pathways, a mobile robot placed at the start, and navigation logic that drives it toward the goal. In this walkthrough, Drift generates all three from a single prompt and launches it in MuJoCo.

Why use a maze to test robot navigation?
A maze forces the robot to handle the hardest parts of navigation in a small space: no direct line to the goal, limited visibility, dead ends, and constant obstacle avoidance. Failures are immediately visible, which makes it a useful way to study navigation behavior.

How does this compare to real-world robot navigation?
The principle is the same. Robots in warehouses and offices perceive their surroundings, decide where to go, and update their path as they move. Real environments add moving people, uneven floors, and imperfect sensors, but the underlying loop matches.

What does Drift generate for maze navigation?
Drift generates the maze environment, spawns the mobile robot at the start, and implements the autonomous navigation logic, all from a natural-language prompt, so the scene and the navigation setup are ready to run.

Why Humanoid Robots Are Still So Hard to Build

Aditi Sharma — Wed, 15 Jul 2026 15:39:32 +0000

Humanoid robots look incredible. So why, after all the progress in robotics, is building one still so difficult?

Humanoid robots like Atlas, Optimus, and Figure look incredible in demos. But despite all the progress in robotics, building one that works reliably is still incredibly difficult. Here are the three main reasons why humanoid robots are so hard.

1. Balance: why two-legged walking is so hard

Bipedal walking is deceptively difficult. A two-legged robot is inherently unstable, so every single step requires it to actively balance and react to tiny changes underfoot.

Humans do this without thinking, using a lifetime of finely tuned reflexes. A robot has to compute that balance in real time, correcting constantly to avoid tipping over. Get the timing slightly wrong and it falls.

2. Coordination: keeping dozens of joints in sync

Then there's the body itself. A humanoid has dozens of joints, motors, and sensors that all have to work together in near-perfect sync.

Every motion is a coordination problem across all of them at once. One small error in one joint can cascade into a loss of stability for the whole robot. The more human-like the range of motion, the more moving parts there are to keep in agreement.

3. The real world: stairs, clutter and moving people

A factory floor is controlled and predictable. The real world is neither. Stairs, uneven ground, clutter, and moving people mean a humanoid can't rely on a fixed script.

Instead it has to continuously perceive its surroundings, plan a response, and adapt, the same sense, think, act loop every robot runs, but under far harder conditions and with much less room for error. This is closely tied to how robots navigate and understand a space, which is its own deep challenge.

Why humanoids combine every hard problem into one robot

Here's the real reason humanoids are so difficult. They aren't defined by a single hard problem. They pull together nearly every challenge in robotics, balance, coordination, perception, planning, and control, and demand that all of it work at once in one machine.

That's also what makes them exciting. A humanoid is a kind of grand challenge for the whole field, and progress on one pushes robotics forward everywhere. Much of that progress happens first in simulation, where researchers can train and test humanoid behaviours safely before building expensive hardware.

FAQ

Why are humanoid robots so hard to build?
Humanoid robots combine several of the hardest problems in robotics at once: balancing on two legs, coordinating dozens of joints and sensors, and adapting to an unpredictable real world. Each is difficult on its own, and a humanoid has to solve all of them together.

Why is balancing so difficult for humanoid robots?
A two-legged robot is inherently unstable, so it has to actively correct its balance on every step and react in real time to small changes in the ground and its own motion. A brief lapse in that control can cause it to fall.

What makes bipedal walking harder than wheeled movement?
Wheels are stable by default, while two legs are not. Walking requires constant dynamic balancing, precise timing, and coordination of many joints, whereas a wheeled robot can move without continuously fighting to stay upright.

How are humanoid robots tested and trained?
Much of the work happens in simulation first. Physics engines like MuJoCo let researchers train balance and locomotion behaviors, including with reinforcement learning, before risking real hardware. The Humanoid benchmark in Gymnasium's MuJoCo environments is a common starting point.

Can you simulate a humanoid robot?
Yes. Humanoids are commonly simulated in physics engines like MuJoCo, though their many degrees of freedom and balance requirements make them among the more demanding robots to model accurately.

Can Drift help with humanoid robot simulation?
Drift generates simulation workspaces from a prompt, including the robot description, scene, and setup, across ROS 2, Gazebo, and MuJoCo. That covers the foundation a humanoid simulation needs. The genuinely hard parts of humanoids, such as balancing controllers and learned locomotion, are advanced behaviors you build and train on top of that simulation rather than generate outright.

What Is Embodied AI?

Aditi Sharma — Wed, 15 Jul 2026 14:27:45 +0000

A chatbot can answer almost anything you type. Ask it to pick up a cup, open a door, or walk across a room, and it hits a wall. It has no body.

That gap is exactly what embodied AI closes. Embodied AI is artificial intelligence connected to a physical body, so it can move through and act on the real world rather than only processing text and images on a server.

What is embodied AI?

Embodied AI is more or less what it sounds like: AI that's attached to a physical body. That body might be a robot arm, a mobile robot, a drone, or a humanoid.

The key shift is from understanding to doing. A language model processes information. An embodied AI senses the world through cameras and other sensors, makes decisions based on what it perceives, and then interacts with its surroundings physically. Intelligence stops being something that lives only on a screen and starts affecting real objects in real space.

How embodied AI works: the sense, think, act loop

Just like a person, an embodied AI follows a simple loop. It perceives the environment, interprets what's happening, and then decides what to do next, over and over.

That's the same sense, think, act loop that underpins nearly every robot. What's new is how capable each step has become. Modern AI makes the "sense" and "think" parts far stronger, so an embodied system can recognize objects, understand a spoken instruction, and plan an action with a flexibility that older robots never had.

Why embodied AI is exploding right now

Recent advances in AI have made robots dramatically better at understanding language, recognising objects, and learning new tasks. A big driver is a new class of models called vision-language-action (VLA) models, which take in what a robot sees along with a language instruction and output the actual motor commands to carry it out.

That's why companies like NVIDIA, Google DeepMind, Figure, and Tesla are investing so heavily in embodied AI, and why NVIDIA's leadership has called this the "ChatGPT moment" for physical AI. Much of the progress comes from training these systems in simulation at massive scale before they ever touch real hardware, using platforms like NVIDIA Isaac. A lot of that ambition is aimed at humanoid robots, which are among the hardest and most visible targets for embodied AI.

What embodied AI means for the future of robotics

Chatbots changed how we interact with computers. Embodied AI could change how we interact with the physical world, putting capable, adaptable machines into warehouses, factories, hospitals, and eventually homes.

It's still early, and reliable real-world performance remains a hard problem. But the direction is clear, and the pace is fast. Embodied AI is where a lot of the most exciting work in robotics is heading, and we're only just getting started.

FAQ

What is embodied AI?
Embodied AI is artificial intelligence connected to a physical body, such as a robot. It can sense its environment, make decisions, and physically act on its surroundings, rather than only processing text or images on a server.

How is embodied AI different from ChatGPT?
A model like ChatGPT works with information: text, and sometimes images. Embodied AI is connected to a physical body with sensors and actuators, so it perceives the real world and takes physical action in it. The reasoning is similar in spirit, but embodied AI has to deal with the messiness of the physical world.

How does embodied AI work?
It follows a continuous loop: sense the environment through cameras and sensors, decide what to do based on what it perceives, then act on the world. Modern AI has made the perception and decision-making steps far more capable, which is what makes today's embodied AI so powerful.

Why is embodied AI a big deal right now?
Advances in AI, especially vision-language-action models that turn what a robot sees and hears into physical actions, have made robots far more capable. Combined with large-scale training in simulation and heavy investment from companies like NVIDIA, Google DeepMind, Figure, and Tesla, embodied AI has become one of the hottest areas in technology.

How is embodied AI trained and tested?
Much of the training happens in simulation, where a system can practice millions of times safely and cheaply before moving to real hardware. Tools like Drift generate the simulated robots and environments used for that kind of testing, while the AI models themselves are trained on top of those simulations.

How Mars Rovers Drive Themselves?

Aditi Sharma — Mon, 13 Jul 2026 12:51:28 +0000

You can't drive a Mars rover with a joystick. By the time your signal reaches Mars, minutes have already passed. So how does a rover explore a whole planet on its own?

Understanding how Mars rovers drive themselves comes down to one idea: the rover has to make its own moment-to-moment decisions, because Earth is simply too far away to help in real time.

Why you can't drive a Mars rover in real time?

The distance between Earth and Mars is enormous and always changing. Depending on where the two planets are in their orbits, a radio command can take anywhere from a few minutes to more than twenty minutes to arrive, and just as long for a response to come back.

That round trip makes real-time control impossible. If a rover waited for a joystick command before every move, it would spend almost all of its time sitting still. So the driving has to happen onboard.

How engineers actually command a Mars rover?

Instead of steering the rover directly, engineers give it a destination and let it work out the route. A team of specialists studies satellite imagery, maps out a general path, and sends the rover a goal to reach.

From there, the rover takes over the fine details of getting there. This split, humans planning the strategy and the rover handling the driving, is what makes exploration possible across such a huge communication gap.

How a Mars rover plans its own path?

To drive itself, the rover leans on its cameras and onboard computing. NASA's Perseverance rover uses a self-driving system called AutoNav that builds 3D maps of the terrain ahead, identifies hazards, and plans a route around obstacles without waiting for instructions from Earth.

In other words, the rover studies the ground in front of it, works out what's safe and what isn't, and chooses a path. Engineers describe this as "thinking while driving", the rover plans its next moves while its wheels are still turning. It's the same sense, think, act loop every robot runs, carried out millions of miles from any human.

How the rover avoids hazards without waiting for Earth?

As it moves, the rover continuously checks its surroundings. If it spots a rock, a steep slope, or another hazard, it adjusts its path on its own rather than pausing to ask Earth what to do.

This is autonomous navigation in its purest form, and it's what lets a rover cross a boulder field or rough terrain far faster than it could if every step needed human review. The same core challenge, figuring out where you are and how to move safely, is exactly how robots navigate here on Earth, just under much harsher conditions on Mars.

Humans decide where, the rover decides how

That's the heart of it. Human operators decide where the rover should go. The rover decides how to get there.

This division of labor is why autonomous navigation is one of the most important technologies behind every Mars mission. As the systems improve, rovers can drive farther on their own, cover more ground, and spend more time doing science instead of waiting on Earth.

FAQ

How do Mars rovers navigate without a driver?
Engineers give the rover a destination, and the rover drives itself there. Using onboard cameras and computing, it maps the terrain, identifies hazards, and plans a safe path on its own, adjusting the route as it encounters obstacles.

How long does it take to send a command to Mars?
Depending on the planets' positions, a one-way radio signal between Earth and Mars takes from a few minutes to more than twenty. That delay, in both directions, is why a rover can't be driven in real time and must navigate autonomously.

What is AutoNav?
AutoNav is the self-driving autonomous navigation system on NASA's Perseverance rover. It builds 3D maps of the terrain ahead, identifies hazards like rocks and slopes, and re-plans the rover's route around them without direction from Earth.

Do humans still control Mars rovers?
Yes, but at a higher level. Human planners study imagery, set the destination, and map a general route, while the rover handles the moment-to-moment driving and obstacle avoidance on its own.

How is a rover's autonomous navigation developed and tested?
Autonomous navigation is developed and tested extensively in simulation before it runs on real hardware, using navigation frameworks and simulated environments. Tools like Drift can generate the simulated robots and worlds used to test navigation, though a flight system like a Mars rover's is a highly specialised version built by mission teams.

Build a Pick-and-Place Scene in MuJoCo in One Prompt

Aditi Sharma — Thu, 09 Jul 2026 07:04:41 +0000

Before a robot can pick up an object, it first needs something to interact with. That means building the scene before you build the behavior.

This walkthrough builds a complete pick-and-place scene in MuJoCo, and rather than assembling every object by hand, we let Drift generate the whole manipulation scene from one prompt.

Why manipulation starts with the right scene

Manipulation is about a robot physically interacting with the world, which means the world has to exist first. An arm on its own has nothing to grasp, nowhere to place it, and no layout to plan around.

A proper pick-and-place setup needs a few things working together: a robot arm, a surface to work on, an object to pick, and a destination to place it. Get that environment right and every task built on top of it, from grasping to motion planning, has something real to work with.

What goes into a pick-and-place scene

The goal is simple. We want a Franka Panda robot arm mounted beside a table, a cube ready to be picked up, and a target location to place it. The Franka Panda is a popular seven-jointed research arm, which makes it a natural choice for a manipulation scene.

That's four pieces that have to be positioned sensibly relative to each other: the arm within reach of the cube, the cube on the table, and the target pad somewhere the arm can also reach.

Generating the manipulation scene in MuJoCo with Drift

Instead of placing each object manually, we ask Drift to generate the entire scene, from the robot and table to the cube and target pad, and launch it directly in MuJoCo. If you're just getting set up, here's how to install MuJoCo in one prompt.

In a few moments everything comes together. The Franka Panda is positioned at the table, the cube is placed within reach of the gripper, and the target pad marks where the object should eventually be moved. What would normally be a fiddly bit of scene authoring is done and running.

Exploring the Franka Panda arm before adding control

Before jumping into autonomous control, it's worth exploring the robot manually. Rotate the camera around the scene, then adjust the joints yourself and watch how the arm responds.

Moving the arm by hand gives you a real feel for how it reaches, how the gripper lines up with the cube, and how a robotic manipulator behaves in general. That intuition is valuable before you move on to harder tasks like motion planning and pick-and-place, because you already understand what the arm can and can't reach.

Adding motion planning and grasping to the scene

A finished scene is the launch point for the actual manipulation work. From here you can plan grasps, add a motion planner to move the arm to the cube, and build up a full pick-and-place routine that lifts the cube and sets it on the target pad.

Before you can teach a robot to manipulate objects, you need the right environment, and with Drift, creating that environment is as simple as describing what you want. Generate a scene, explore the arm, and start building your first grasp. The full walkthrough is in the video above.

FAQ

What is a pick-and-place task in robotics?
Pick-and-place is a common manipulation task where a robot grasps an object at one location and places it at another. It's a building block for many applications, from assembly and packaging to sorting, and it combines perception, grasping, and motion planning.

How do you build a manipulation scene in MuJoCo?
You define the arm, a work surface, an object to manipulate, and a target, all positioned so the arm can reach them, in a MuJoCo scene file. In this walkthrough, Drift generates that entire pick-and-place scene and launches it from a single prompt instead of placing each object by hand.

What is the Franka Panda robot arm?
The Franka Emika Panda is a seven-joint collaborative robot arm widely used in research and education. Its dexterity and available simulation models make it a common choice for manipulation and pick-and-place experiments.

Why explore a robot arm manually before autonomous control?
Moving the joints by hand builds intuition for how the arm reaches, how the gripper aligns with objects, and where its limits are. That understanding makes later work like motion planning and grasping much easier to reason about.

What does Drift generate for a manipulation scene?
Drift generates the full scene, the robot arm, table, object, and target, positions everything sensibly, and launches it in MuJoCo, all from a natural-language prompt, so you get a ready-to-use manipulation environment without building it manually.

Watch a Quadruped Take Its First Steps in MuJoCo

Aditi Sharma — Thu, 09 Jul 2026 06:49:14 +0000

We already have a quadruped standing in simulation. Standing still isn't much fun. The next step is getting it to walk.

In the last build we created a quadruped simulation in MuJoCo. A four-legged robot standing in an empty scene is a good start, but it isn't doing anything yet. This walkthrough adds a quadruped walking controller, and rather than writing the gait logic from scratch, we ask Drift to generate it from a single prompt.

Why getting a quadruped to walk is hard

Getting a legged robot to walk is one of the classic hard problems in robotics. A gait has to coordinate many joints in the right sequence, keep the robot balanced, and stay stable as it moves. Writing that controller by hand takes real effort before you see a single step.

That's the gap this closes. We use the existing quadruped simulation and let Drift produce a basic walking controller, then we run it and see how it performs.

Generating a quadruped walking controller with Drift

Starting from the quadruped scene, we give Drift a simple prompt: generate a basic walking controller for the robot. From there it produces the gait logic and wires it into the simulation, ready to launch. If you're just getting started with the simulator, here's how to install MuJoCo and build the quadruped scene first.

Watching the quadruped take its first steps

With everything generated, we launch the simulation. And there it is: the quadruped taking its first steps.

Seeing the robot actually move is the payoff, but it's also just the beginning. A working first gait is the foundation you build on, not the finish line.

Inspecting the generated walking controller code

Getting the robot to walk is one thing. Understanding how it walks is another, and that's where the generated code matters.

Drift also produces the controller code, so you can open it in your editor and see exactly how the walking sequence is implemented. Instead of a black box that happens to work, you get readable logic you can follow, learn from, and modify.

Tuning gait parameters like step timing and joint motion

Once you can see the code, you can experiment. Dive in and adjust parameters like step timing or the range of joint motion, then rerun the simulation and watch how the walk changes.

This is one of the best ways to build intuition for legged locomotion. Small changes in timing or stride can noticeably change how the robot moves, and being able to tweak and re-test quickly is how you develop a feel for what each value does.

Where to go after your first quadruped gait

Getting a quadruped walking is the start. The real value is understanding how the controller works and building on it. From a first gait you can refine stability, try different walking styles, or move toward training reinforcement learning policies for more robust locomotion.

With Drift generating the initial framework and the code behind it, you're free to explore, experiment, and keep improving from there. Load your quadruped, generate a gait, and start tuning. The full walkthrough is in the video above.

FAQ

How do you make a quadruped walk in simulation?
You need a walking controller that coordinates the robot's joints into a stable gait. In this walkthrough, Drift generates a basic walking controller for an existing quadruped simulation from a single prompt, then launches MuJoCo so you can watch it walk.

What is a walking controller or gait controller?
It's the logic that tells a legged robot how to move its joints over time to produce a walk. A good controller sequences the legs, keeps the robot balanced, and maintains stability as it moves forward.

What parameters affect a quadruped's walking behavior?
Common ones include step timing, stride length, and the range of joint motion. Adjusting these changes the rhythm and style of the gait, and experimenting with them is a good way to understand how each value influences the robot's movement.

Can you train a quadruped to walk with reinforcement learning?
Yes. Beyond a hand-designed gait, reinforcement learning is widely used to train more robust quadruped locomotion in simulators like MuJoCo, often using Gymnasium's quadruped environments, and many of those learned policies transfer to real hardware.

What does Drift generate for a walking quadruped?
Drift generates the walking controller and the underlying code, and launches the simulation. Because you get readable controller code alongside a working demo, you can inspect how the gait is implemented and tune it yourself.

Build a Realistic Office Environment in MuJoCo in One Prompt

Aditi Sharma — Mon, 06 Jul 2026 06:00:27 +0000

Liquid syntax error: Tag '{% https://youtu.be/oRHFoVwM6a0?si=yFXTT3EE_cGrNyHA %}' was not properly terminated with regexp: /\%\}/

The 5 Most Common Ways Robots Navigate

Aditi Sharma — Wed, 01 Jul 2026 18:10:36 +0000

Getting a robot from point A to point B sounds simple. The hard part is that a robot has no built-in sense of where it is.

Understanding how robots navigate comes down to two questions: where am I, and how do I get to my goal? Here are the five most common methods robots use to answer them.

Why navigation is hard for robots

A person walks into a room and instantly knows roughly where they are. A robot starts with none of that. It only has sensor readings, and it has to turn those raw numbers into an estimate of its own position, a model of its surroundings, and a plan to move. Below are the five most common ways robots navigate. Each tackles part of that problem, and each comes with its own trade-off.

1. Wheel odometry: estimating distance from wheel rotation

The simplest method is wheel odometry. By measuring how far its wheels have turned, a robot estimates how far it has traveled and how its position has changed.

It's simple, inexpensive, and works well over short distances. The catch is drift: if the wheels slip even slightly, the small errors accumulate over time, and the robot's estimate of where it is slowly diverges from reality.

2. GPS: knowing your position outdoors

What if the robot could know its actual position instead of estimating it? Outdoors, that's what GPS provides. It gives an absolute fix on location, which makes it a natural fit for drones, delivery robots, and autonomous vehicles.

The limits are well known. GPS struggles or fails indoors and near tall buildings, and even outdoors it often isn't accurate enough on its own for precise movement, so it's usually fused with other sensors.

3. Visual odometry: tracking movement with cameras

Cameras offer another approach. Instead of counting wheel rotations, visual odometry tracks features in the environment from frame to frame and uses how they shift to estimate the robot's own movement.

It's especially useful for drones and for robots operating where GPS isn't available. On its own, though, it estimates motion rather than giving the robot a full understanding of its surroundings, which is where mapping comes in.

4. SLAM: mapping and localising at the same time

What if the robot could build a map as it explores? That's exactly what SLAM does, short for Simultaneous Localization and Mapping. The robot creates a map of its environment while continuously working out where it is within that map.

Doing both at once is what makes SLAM powerful, and it's one of the most widely used techniques in mobile robotics. It usually runs on sensor data from a LiDAR or camera, which is why adding a sensor like a LiDAR is the step that unlocks mapping and navigation in the first place.

5. Navigation stacks: planning the actual path with Nav2

Once a robot knows where it is, one question remains: how does it actually get to its destination? That's the job of a navigation framework like Nav2, the navigation stack for ROS 2.

These frameworks plan a path to the goal, avoid obstacles along the way, and continuously update the route as the environment changes. In other words, they turn localization into real navigation, the difference between knowing where you are and actually moving there.

How robots combine these methods

Modern robots rarely rely on just one of these. A mobile robot might fuse wheel odometry with a LiDAR running SLAM, correct its position with GPS outdoors, and hand the result to a navigation stack for path planning. Each method covers another's blind spots.

That's the real takeaway. In robotics, knowing where you are is only half the challenge. Knowing how to get where you're going is the other half, and reliable navigation comes from combining sensing, mapping, localization, and planning into one system.

FAQ

How do robots navigate? Robots navigate by estimating their position and then planning a path to a goal. They use methods like wheel odometry, GPS, visual odometry, and SLAM to figure out where they are, and a navigation stack to plan and follow a route. Most robots combine several of these.

What is wheel odometry? Wheel odometry estimates how far a robot has moved by measuring how much its wheels have rotated. It's cheap and works over short distances, but wheel slip causes small errors that accumulate over time.

What is SLAM in robotics? SLAM stands for Simultaneous Localization and Mapping. It lets a robot build a map of an unknown environment while continuously tracking its own position within that map, and it's one of the most widely used techniques in mobile robotics.

What is the difference between odometry and SLAM? Odometry only estimates how the robot has moved, so its errors build up over time. SLAM also builds a map and uses it to correct the robot's position, which keeps localization accurate over longer distances.

What is a navigation stack like Nav2? A navigation stack is the software that turns localization into movement. Nav2, the navigation framework for ROS 2, plans a path to a destination, avoids obstacles, and updates the route as the environment changes.

Can Drift set up navigation for my robot? Drift builds the simulation foundation that navigation depends on, including the robot description, sensors like LiDAR, and the simulated world. Navigation stacks such as Nav2 then run on top of that setup to handle mapping, localization, and path planning.

Build a Quadruped Simulation in MuJoCo in One Prompt

Aditi Sharma — Wed, 01 Jul 2026 06:52:20 +0000

Testing controllers and training gaits on a four-legged robot all starts in the same place: a working simulation.

Quadruped robots, the four-legged machines made famous by Boston Dynamics and Unitree, are everywhere in robotics right now. But before you can train one or test a new controller, you need a working simulation to build on. This walkthrough creates a quadruped simulation in MuJoCo, and rather than wiring it together by hand, we hand the setup to Drift and start from one simple prompt.

Why a quadruped project starts with simulation

A four-legged robot is a complicated machine: many joints, many actuators, and contact with the ground at every step. Testing controllers or training gaits directly on hardware is slow, expensive, and risky. A simulation lets you iterate safely and quickly, which is why nearly every quadruped project, from research labs to companies like Boston Dynamics and Unitree, begins in a physics engine like MuJoCo.

The friction is the setup. Getting a quadruped model, its dependencies, and a launchable scene working together is the kind of task that eats your first session before any real work starts.

Generating a quadruped simulation in MuJoCo with Drift

Instead of assembling all of that manually, we initialize Drift and keep the prompt simple. The goal is a quadruped simulation we can launch and explore in MuJoCo. If you don't have MuJoCo set up yet, here's how to install MuJoCo in one prompt first.

Here's what Drift handles, in order:

It sets up the project: Drift scaffolds the project structure for the simulation, so the model and scene files sit where they belong.
It installs the required dependencies: The supporting packages get pulled in automatically, so there's no separate round of chasing missing requirements.
It prepares the simulation files: The robot description and scene are generated and wired together into something launchable.
It launches MuJoCo: Once everything is ready, the simulator opens with the quadruped loaded.

Exploring the quadruped model in MuJoCo

And there it is: the quadruped, loaded inside MuJoCo. From here you can inspect the robot, rotate the camera, and see how the different joints and actuators are configured.

MuJoCo also lets you interact with the model in real time. You can grab and move parts, test joints, try the controls, and get a feel for the overall robot structure before you write a single line of control code.

Where to take your quadruped simulation next

A loaded, working simulation is a solid starting point for more advanced quadruped behaviors. From here you can add controllers, experiment with different gaits, or train reinforcement learning policies for locomotion, the same path used to teach real four-legged robots to walk and recover.

If you want ready-made four-legged models to drop in, the MuJoCo Menagerie collection includes high-quality quadrupeds like the Unitree Go1 and Go2, ANYmal, and Boston Dynamics Spot. And for reinforcement learning, these models are commonly trained using Gymnasium's quadruped environment setup.

A single prompt took this from an empty project to a quadruped you can inspect and control. From here, load a model from Menagerie, try a gait, or start a training run. The full build is in the video above.

FAQ

How do you create a quadruped simulation in MuJoCo?
You need a quadruped model, its dependencies, and a launchable scene configured together. In this walkthrough, Drift handles all of that from a single prompt, setting up the project, installing dependencies, preparing the simulation files, and launching MuJoCo with the robot loaded.

What is a quadruped robot?
A quadruped is a four-legged robot, with each leg typically having multiple joints and actuators. Well-known examples include Boston Dynamics Spot and Unitree's Go1, Go2, and A1, which are widely used in research and increasingly in industry.

Where can I find quadruped models for MuJoCo?
The MuJoCo Menagerie, curated by Google DeepMind, provides high-quality quadruped models in MJCF format, including the Unitree Go1, Go2, and A1, ANYmal B and C, and Boston Dynamics Spot, all ready to load in MuJoCo.

Can you train reinforcement learning policies on a quadruped in MuJoCo?
Yes. MuJoCo is a popular choice for training quadruped locomotion policies. Using Gymnasium's Ant-v5 framework with a quadruped model, you can train gaits and behaviors, and many of these policies transfer to real hardware.

What does Drift do for a quadruped simulation?
Drift initializes the project, installs the required dependencies, prepares the simulation files, and launches MuJoCo with the quadruped loaded, all from a natural-language prompt, so you skip the setup and get straight to developing behaviors.

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.