# Drift - full blog corpus

> Every published post on godrift.ai/blogs, concatenated, machine-readable.
> See <https://godrift.ai/llms.txt> for the curated index.

Generated 2026-08-28. 43 posts.

---

# Peg Insertion in MuJoCo, the Classic Contact-Rich Task

*2026-08-27 · Drift Team · Product · 5 min*

> Peg-in-hole insertion is a benchmark contact-rich manipulation task. Drift builds a MuJoCo scene where a robot arm aligns and inserts a peg, from one prompt.

<https://godrift.ai/blogs/peg-insertion-mujoco>

---
Peg-in-hole insertion is the "hello world" of contact-rich manipulation. It looks trivial and is one of the most studied hard problems in robotic assembly.

&nbsp;

\<video\>

&nbsp;

Today we test a simple but surprisingly important robot skill: insertion. We build a MuJoCo scene where a robot arm aligns a cylindrical peg and inserts it into a matching hole, with [Drift](https://link.godrift.ai/peg-1) generating the task from one prompt. Peg insertion in MuJoCo is worth doing deliberately, because peg-in-hole is the canonical contact-rich manipulation benchmark, and almost everything hard about robotic assembly shows up in it.

## Why peg insertion is a decades-old benchmark?

&nbsp;

Peg-in-hole has been a standard manipulation benchmark for decades, and for good reason. It isolates the part of assembly that's genuinely hard: precise, contact-rich alignment where tolerances are tight and the margin for error is small.

&nbsp;

The difficulty scales with clearance. A loose fit is forgiving; a tight-clearance peg demands sub-millimeter positioning and precise orientation, and once the peg contacts the hole edge, the problem becomes about managing contact forces rather than just following a trajectory. Get the alignment slightly wrong and the peg jams, binds, or misses entirely. That combination, precision plus contact reasoning, is why insertion generalizes to real assembly and why it's a workhorse task for both classical force control and learned policies. It's a more constrained cousin of the [pick-and-place](https://www.godrift.ai/blogs/pick-and-place-mujoco) work, with the difficulty concentrated at the point of contact.

## Why the peg starts pre-attached to the gripper?

&nbsp;

We deliberately start with the peg already attached to the robot's end-effector, and focus entirely on the insertion itself. That scoping is intentional, and it's worth understanding why.

&nbsp;

Grasping the peg and inserting it are two separate hard problems. By fixing the peg to the gripper, we remove grasp uncertainty from the picture, no variation in how the peg sits in the hand, so the whole difficulty of the demo lives in the approach, alignment, and insertion. It isolates the contact-rich phase, which is the part actually being studied here. In a full assembly pipeline you'd chain a grasp before this, but for testing insertion behavior, removing the grasp variable gives you a cleaner signal.

## What we asked Drift to build?

&nbsp;

The task we give [Drift](https://link.godrift.ai/peg-1) is specific: with the peg pre-attached to the end-effector, the arm needs to smoothly approach the target, align the cylindrical peg with the hole, and lower it into place.

&nbsp;

That describes an insertion behaviour in three phases, approach, align, insert, without hand-specifying the waypoints or control gains. [Drift](https://link.godrift.ai/peg-1) generates the MuJoCo scene with the peg, the hole, and the arm, along with the motion that carries out the insertion. New to the simulator? Here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco) first.

## Running the insertion

&nbsp;

We run the simulation and watch the sequence. The arm starts above the target and moves into position over the hole. Once the peg is aligned, it slowly lowers and completes the insertion, seating the peg in the hole.

&nbsp;

The deliberate, slow descent is the point. Insertion rewards controlled, careful motion over speed, because the alignment has to hold all the way down as the peg enters the hole. Watching where the arm slows and how precisely it aligns before committing to the descent is watching the actual difficulty of the task play out.

## Why insertion is a foundation for assembly?

&nbsp;

It looks simple, but insertion comes down to precision. A small error in position or orientation is the difference between a clean insertion and a jam or a miss, and that sensitivity is exactly why the task is valuable. It stress-tests the alignment and contact handling that real assembly depends on.

&nbsp;

That's what makes insertion a foundation for more complex robotic assembly. Fastening, connector mating, part fitting, and most assembly steps are insertion problems at their core, so a robot that inserts reliably has the primitive that assembly is built from. It's also a natural target for [reinforcement learning](https://www.godrift.ai/blogs/franka-push-cube-ppo-mujoco), since a policy can learn the fine contact adjustments that are hard to script by hand, and it appears as a standard task in robot-learning benchmark suites like [robosuite](https://robosuite.ai/). Tighten the clearance, offset the hole, or add a policy on top, and you have a benchmark you can push as far as you want. The full walkthrough is in the video above.

## FAQ

1. **What is peg-in-hole insertion in robotics?** Peg-in-hole insertion is a benchmark manipulation task where a robot aligns a peg with a matching hole and inserts it. It's widely used to study contact-rich manipulation because success depends on precise position and orientation control and on managing contact forces once the peg touches the hole.
2. **Why is peg insertion considered difficult?** Because it demands high precision and contact reasoning. With tight clearances, sub-millimeter position and orientation errors cause the peg to jam or miss, and once contact begins the robot must handle contact forces rather than just follow a path. That mix of precision and contact is what makes it hard.
3. **Why start with the peg already attached to the gripper?** Grasping and inserting are separate hard problems. Fixing the peg to the end-effector removes grasp uncertainty so the demo isolates the approach, alignment, and insertion, which is the contact-rich phase actually being tested. A full pipeline would add a grasp step before insertion.
4. **Why is insertion important for robotic assembly?** Most assembly operations, fastening, connector mating, and part fitting, are insertion problems at their core. A robot that can insert reliably has the fundamental skill that assembly is built on, which is why peg-in-hole is a foundational benchmark for assembly automation.
5. **How does Drift build the insertion task?** From a single natural-language prompt, [Drift](https://link.godrift.ai/peg-1) generates the MuJoCo scene with the peg, hole, and arm, and the motion to approach, align, and insert the peg, so you get a runnable insertion task without hand-authoring the scene or tuning the trajectory yourself.

## Related reading

- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [Training a Franka Panda to Push a Cube With Reinforcement Learning](https://www.godrift.ai/blogs/franka-push-cube-ppo-mujoco)
- [Why Robot Hands Are So Hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# How DHL Uses Robots Across Its Warehouses?

*2026-08-27 · Drift Team · Research · 5 min*

> DHL runs 7,500+ robots across its network. Here's how mobile robots, picking arms, and Boston Dynamics Stretch handle moving, sorting, and unloading parcels.

<https://godrift.ai/blogs/how-dhl-uses-robots>

---
Moving a parcel from a warehouse to your door sounds like a solved problem. Inside a DHL facility, it's a coordination problem being handed, stage by stage, to different classes of robot.

&nbsp;

\<video\>

&nbsp;

When you order something online, getting it from a warehouse to your door sounds simple. Inside a DHL facility, understanding how DHL uses robots means following a parcel through several handoffs, each to a robot class built for that specific job: mobile robots move it, arms pick and sort it, and a heavy-duty manipulator unloads it from the trailer in the first place. Here's how those stages fit together at scale.

## 1. Autonomous mobile robots that move the goods

&nbsp;

It usually starts with autonomous mobile robots (AMRs). Instead of workers walking miles across a facility to fetch items, the robots navigate between shelves and bring products to the people picking orders, a goods-to-person model rather than person-to-goods.

&nbsp;

DHL runs these at serious scale. It has logged more than 500 million picks with Locus Robotics' LocusBots across its network, a milestone it reached in 2024, with the AMRs deployed across dozens of sites worldwide. The relevant engineering detail is that these are free-navigating AMRs, using onboard sensing to plot paths and avoid obstacles dynamically, rather than following fixed guide markers, which is what lets DHL flex fleet size and even move robots between facilities as demand shifts. It's the goods-movement layer described in [how warehouse robots work](https://www.godrift.ai/blogs/how-warehouse-robots-work) in general, running in production.

## 2. Robotic arms for picking and sorting

&nbsp;

Once an item is moving, robotic arms take on the repetitive manipulation: picking, placing, and sorting parcels. DHL has deployed AI-powered sorting robots that handle upwards of a thousand small parcels per hour.

&nbsp;

This is the hardest part to automate reliably, because it's real [pick-and-place manipulation](https://www.godrift.ai/blogs/pick-and-place-mujoco) on a mixed stream of items: the arm has to identify each parcel with vision, choose a grasp, and route it correctly, at rate. Throughput numbers like a thousand parcels per hour only hold if the perception and grasping are robust to the variety of a real parcel mix, which is exactly where the difficulty lives.

## 3. Boston Dynamics Stretch for unloading trailers

&nbsp;

One of the toughest jobs happens before a parcel even enters the warehouse: unloading the trailer. It's hot, cramped, physically punishing work, and a hard manipulation problem, densely packed boxes of varying size and weight, no fixed positions, in a confined space.

&nbsp;

DHL uses Boston Dynamics' Stretch robot for this. Stretch is a mobile base with a long-reach arm and a smart vacuum gripper that perceives the box wall, plans which case to pull next, and stacks onto a conveyor. Depending on the operation, DHL has reported unloading rates up to around 700 cases per hour. This is the same [deformable-and-cluttered manipulation](https://www.godrift.ai/blogs/why-robot-hands-are-hard) challenge that makes real-world grasping hard, solved well enough for a specific, high-value task.

## 4. The scale, and what it signals

&nbsp;

This isn't a pilot with a handful of demo units. DHL uses more than 7,500 robots across its global network, sourced from multiple partners including Locus Robotics, Geek+, and AutoStore, and in 2025 it signed a [memorandum of understanding with Boston Dynamics](https://bostondynamics.com/news/dhl-signs-mou-for-additional-1000-robot-deployment/) for the deployment of more than 1,000 additional Stretch robots.

&nbsp;

Numbers at that scale change what matters. The hard problem stops being any single robot and becomes fleet orchestration, sequencing thousands of machines from different vendors, routing work between them, and keeping throughput up through demand peaks. That coordination layer is the real system, and it's where a lot of the engineering effort in modern logistics automation actually goes.

## How the work gets divided?

&nbsp;

DHL's warehouses still run with people in the loop. The model is a division of labor: people, mobile robots, and manipulators each take the portion of the work they're best suited to, with robots absorbing the walking, lifting, and repetitive sorting while people handle exceptions, judgment, and the cases automation can't yet manage reliably.

&nbsp;

The net result is that a parcel can move through an entire warehouse with robots involved at nearly every stage, from trailer to shelf to pick to sort. Almost all of the perception, grasping, and navigation behind that is developed and validated in [simulation](https://www.godrift.ai/blogs/why-robots-train-in-simulation) before it runs on a warehouse floor, which is what makes deploying at this scale feasible at all.

## FAQ

1. **How many robots does DHL use?** DHL uses more than 7,500 robots across its global network, sourced from partners including Locus Robotics, Geek+, and AutoStore. In 2025 it also signed an MOU with Boston Dynamics for over 1,000 additional Stretch robots, alongside more than 200,000 smart handheld devices and hundreds of thousands of IoT sensors.
2. **What robots does DHL use for order picking?** DHL primarily uses Locus Robotics' autonomous mobile robots (LocusBots) in a goods-to-person model, bringing items to human pickers. It has logged more than 500 million picks with these AMRs across its network, a milestone reached in 2024.
3. **What does DHL use the Boston Dynamics Stretch robot for?** DHL uses Stretch to unload trailers and containers, an unstructured, physically demanding task. Stretch is a mobile robot with a long-reach arm and a vacuum gripper that identifies and pulls cases from a densely packed trailer wall, with DHL reporting rates up to around 700 cases per hour depending on the operation.
4. **Are DHL's warehouses fully automated?** No. DHL uses a mixed human-and-robot model where robots handle repetitive movement, lifting, and sorting while people manage exceptions and judgment-heavy tasks. More than 90% of DHL warehouses have at least one automation or digitalization solution, but they still operate with people in the loop.
5. **How is warehouse robotics like DHL's developed and tested?** The perception, grasping, and navigation are developed and validated largely in simulation before deployment, where behaviors can be tested at scale without disrupting live operations. Tools like [Drift](https://link.godrift.ai/dhl-1) generate the simulated robots and environments used for that kind of development work.

## Related reading

- [How Warehouse Robots Actually Work](https://www.godrift.ai/blogs/how-warehouse-robots-work)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [How Robots Are Reshaping 5 Everyday Industries](https://www.godrift.ai/blogs/industries-changed-by-robotics)
- [Why Robot Hands Are So Hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard)


# Generating Uneven Terrain for the Spot Robot in MuJoCo

*2026-08-26 · Drift Team · Product · 5 min*

> Testing a quadruped means getting it off flat ground. Drift generates an uneven, traversable MuJoCo terrain scene around a Boston Dynamics Spot in one prompt.

<https://godrift.ai/blogs/uneven-terrain-spot-mujoco>

---
A flat floor is a fine place to bring a quadruped up, and a useless place to test one. Real locomotion research starts the moment the ground stops being flat.

&nbsp;

\<!-- VIDEO EMBED GOES HERE --\>

&nbsp;

Today we take the Boston Dynamics Spot robot off flat ground. A quadruped's whole reason for existing is handling terrain a wheeled robot can't, so a flat plane is the one surface that tests none of what matters. This walkthrough generates uneven terrain in MuJoCo around an existing Spot model, letting [Drift](https://link.godrift.ai/terrain-1) build the environment while leaving the robot exactly as it is.

## Why flat ground is a dead end for quadruped testing?

&nbsp;

A perfectly flat floor removes the entire problem a legged robot is built to solve. On a plane, foot placement is trivial, the body stays level, and balance is barely exercised. None of that survives contact with real ground.

&nbsp;

Uneven terrain is where the interesting failure modes live: varying foot-contact heights, slopes that shift the center of mass, and obstacles that force the gait to adapt step to step. If you want to develop or stress-test locomotion, whether a hand-tuned controller or a learned policy, you need a surface that actually provokes those behaviors. Generating that terrain is the prerequisite for everything that follows, and it builds directly on the [quadruped simulation](https://www.godrift.ai/blogs/quadruped-simulation-mujoco) work from earlier.

## The prompt, and the constraint that matters

&nbsp;

The instruction to [Drift](https://link.godrift.ai/terrain-1) is deliberately scoped: keep the existing Spot robot exactly as it is, and build the environment around it. We want terrain that is uneven but traversable, gentle slopes and obstacles, and the scene has to load cleanly without touching the robot model itself.

&nbsp;

That "don't modify the robot" constraint is the important part for anyone working this way. In a real project, the robot model, its collision geometry, joints, actuators, and any controller wired to it, is something you've already validated and don't want silently altered when you change the world around it. Scoping the generation to the environment only keeps the robot as a fixed, known quantity and avoids introducing regressions in the part you already trust.

## How Drift builds the terrain scene?

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/terrain-1) generates the terrain and drops the untouched Spot model into it, wiring everything into a scene that launches cleanly. In MuJoCo terms, uneven ground like this is typically expressed as a [heightfield](https://mujoco.readthedocs.io/en/stable/XMLreference.html#asset-hfield) or a set of mesh and primitive geoms with appropriate collision properties, positioned so the robot spawns on solid contact rather than clipping into a slope.

&nbsp;

The useful part is that the generation targets only the world. The robot's model stays byte-for-byte what it was, and the new geometry is added around it, which is exactly the separation you want between a validated robot and an experimental environment. The result is a runnable scene without hand-editing MJCF, placing geoms, and tuning contact parameters yourself.

## What the generated terrain looks like?

&nbsp;

Launching the scene gives a complete uneven environment: rolling slopes and scattered obstacles, with Spot placed directly on the surface. The terrain is deliberately uneven but still traversable, which is the balance that makes it useful.

&nbsp;

That balance matters. Terrain that's too tame tests nothing; terrain that's impassable just produces failed runs with no signal. Something uneven but crossable is much closer to the surfaces a quadruped actually has to deal with, and it gives a locomotion controller a meaningful challenge without setting it up to fail outright. It's a far better proving ground than a plane, and a more honest one.

## From terrain to traversal

&nbsp;

The robot is standing on the terrain, not yet crossing it. That's the honest state of this step: we've moved beyond a flat simulation environment, and the next stage is giving Spot the ability to actually traverse the surface.

&nbsp;

That next stage is where the real locomotion problem lives, adapting foot placement to the height changes, keeping balance on the slopes, and planning a path around the obstacles, which connects to [how robots navigate](https://www.godrift.ai/blogs/how-robots-navigate) unstructured space in general. With [Drift](https://link.godrift.ai/terrain-1) handling the environment generation, the terrain side is done, so the work ahead is the controller, not the scene. Regenerate with rougher terrain, add harder obstacles, and you have a ready-made curriculum to test against. The full walkthrough is in the video above.

## FAQ

1. **How do you create uneven terrain in MuJoCo?** Uneven terrain in MuJoCo is usually built with a heightfield (hfield) or a combination of mesh and primitive geoms with defined collision properties, arranged into slopes and obstacles. In this walkthrough, Drift generates that terrain scene around an existing robot from a single prompt, so you get a clean, runnable environment without hand-authoring the MJCF.
2. **Why test a quadruped on uneven terrain instead of flat ground?** Flat ground doesn't exercise the capabilities a legged robot exists for. Uneven terrain introduces varying foot-contact heights, slopes, and obstacles that stress balance, foot placement, and gait adaptation, which is what you need in order to develop or validate real locomotion.
3. **Why generate the terrain without modifying the robot model?** The robot model is typically already validated, its geometry, joints, actuators, and controller, and you don't want it changed when you alter the environment. Scoping generation to the world only keeps the robot a fixed, known quantity and avoids introducing regressions in the part you already trust.
4. **What does "traversable but uneven" mean here?** It means terrain rough enough to be a real challenge but still physically crossable. Terrain that's too flat provides no test signal, and terrain that's impassable only produces failures; something uneven but traversable gives a locomotion controller a meaningful but fair problem.
5. **How does Drift generate the terrain scene?** From a single natural-language prompt, [Drift](https://link.godrift.ai/terrain-1) builds the uneven terrain and places the untouched Spot model into it, producing a scene that loads cleanly in MuJoCo, without manually editing MJCF, placing geoms, or tuning contact parameters by hand.

## Related reading

- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [Watch a Quadruped Take Its First Steps in MuJoCo](https://www.godrift.ai/blogs/quadruped-walking-mujoco)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# This Robot Model Learns a Task After Watching Once

*2026-08-25 · Drift Team · Research · 6 min*

> GEN-1.5 is a new embodied AI model from Generalist that learns a robot task from a single short demo, no retraining. Here's how physical prompting works.

<https://godrift.ai/blogs/gen-1-5-robot-learns-from-one-demo>

---
What if you only had to show a robot a task once? Not train it for hours, not hand it thousands of demonstrations. Just show it what to do, and let it try.

<figure data-type="youtube-embed" data-yt-id="_ipViqQ8sXE" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/_ipViqQ8sXE?autoplay=1&mute=1&loop=1&playlist=_ipViqQ8sXE&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

What if you only had to show a robot a task once? That's the idea behind [GEN-1.5](https://generalistai.com/blog/gen-1.5), a new embodied AI model from the startup Generalist. Instead of training for hours on thousands of examples, the GEN-1.5 robot model can take a short demonstration, sometimes just a few seconds, and attempt the task right away. It's one of the more striking ideas in recent [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai), so here's what it does and why it matters.

## Learning from a single demonstration

&nbsp;

The core idea is one-shot learning: teaching the robot a task from a single example. A person performs the task, often using handheld grippers, or the robot itself does a rough attempt, and that short clip, between 3 and 12 seconds, becomes the input the model works from.

&nbsp;

Generalist calls this a "physical prompt." Rather than the thousands of demonstrations that [learning-from-demonstration methods](https://www.godrift.ai/blogs/how-robots-learn-without-programming) usually need, GEN-1.5 works from one. Show it what to do, and it tries to do it.

## What a "physical prompt" actually means?

&nbsp;

Here's the part that makes it unusual. The demonstration is not used to retrain the model. Its weights don't change at all. Instead, the demo is placed into the model's context window, its short-term memory, and stays there while the robot performs the task.

&nbsp;

It's in-context learning, the same mechanism behind few-shot prompting in LLMs, applied to sensorimotor data. You paste an example into the context to condition the output, except here the example is a few seconds of physical demonstration rather than text, and the output is a closed-loop action trajectory rather than tokens.

&nbsp;

Some specifics worth knowing. GEN-1.5 is a large multimodal model that ingests video, sensor, language, and proprioceptive inputs, holds roughly 30 seconds of context, and emits action trajectories at 100 Hz. The physical prompt is a 3 to 12 second demonstration dropped into that window, and inference runs with no gradient updates. Notably, Generalist reports no architectural changes to induce in-context learning, no meta-learning loop, and no auxiliary improvisation objective, the capability emerged from pretraining on physical interaction data at scale, which is the more interesting claim than any single demo.

## How it adjusts, recovers, and improvises?

&nbsp;

A robot that only mimicked the exact motion in the clip wouldn't be very useful, because the real world never lines up perfectly with the demo. GEN-1.5 goes further. When the situation changes, it can adjust its movements, recover from a mistake, and even improvise a different strategy to reach the same goal.

&nbsp;

Physical prompts also compose. Generalist placed two independently recorded demonstrations, unzipping a pencil pouch and retrieving money from it, into the context together, and GEN-1.5 chained them into one continuous skill, generating the connective motions (repositioning, regrasping, error recovery) that appeared in neither clip. That is closer to planning over a library of primitives than to trajectory playback, and it runs straight into the contact-rich dexterity problems behind [why robot hands are so hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard).

## Learning in simulation, acting in the real world

&nbsp;

One of the most interesting results is that the demonstration doesn't have to come from the real world at all. Generalist showed GEN-1.5 learning from a demonstration performed in simulation, then carrying out the task on a real robot, without being trained on that specific task in either place.

&nbsp;

The detail that makes this notable: Generalist says GEN-1.5's pretraining contains no simulation data, neither rendered video nor simulated dynamics, yet a rollout from the simulator still works as a valid physical prompt, and the prompted behavior transfers to the real scene. For tasks where that holds, demonstrations no longer have to be collected physically, they can come from whatever is cheapest to generate in [simulation](https://www.godrift.ai/blogs/why-robots-train-in-simulation), which is a materially more scalable data path.

## Why this matters, and where it falls short?

&nbsp;

It's worth being honest about the results, which the company is too. Across ten tasks like opening a jar or pulling money from a purse, one-shot prompting succeeded around 59% of the time, rising to roughly 83% with a few minutes of extra task data. The tasks are short and simple, and the reliability isn't there yet for real deployment.

&nbsp;

The significance lies elsewhere: a robot can now learn a new physical skill from a single example at all, across a broad range of tasks, which had largely been considered out of reach. It's the same shift toward general, promptable models seen in systems like [Gemini Robotics 2](https://www.godrift.ai/blogs/gemini-robotics-2-explained). Instead of programming robots task by task, the question GEN-1.5 raises is a bigger one: what if the next generation of robots could simply learn by watching?

## FAQ

1. **What is GEN-1.5?** GEN-1.5 is an embodied AI foundation model from the startup Generalist. It can learn a new physical task from a single short demonstration (3 to 12 seconds) placed into its context, without any retraining or fine-tuning, and then attempt the task on a robot immediately.
2. **What is a "physical prompt"?** A physical prompt is a short demonstration of a task, from a person using handheld grippers or from the robot itself, that's loaded into the model's context window as input. Like an example pasted into a chatbot prompt, it guides the model's behavior without changing its underlying weights.
3. **How is this different from normal robot learning?** Most robot learning retrains or fine-tunes a model on many demonstrations. GEN-1.5 instead keeps a single demonstration in context and acts on it directly, with no training step, which is why it's described as one-shot, in-context learning rather than conventional training.
4. **How well does GEN-1.5 actually work?** Generalist reports about 59% average success across ten short tasks from a single demonstration, rising to around 83% with a few minutes of additional task-specific data. The tasks are simple, and the company is clear that reliability is still early; the notable part is that one-shot learning works at all.
5. **Can GEN-1.5 learn from simulation?** Yes. Generalist showed the model being prompted with a demonstration performed in simulation and then carrying out the task on a real robot, without task-specific training in either environment, which suggests a cheaper, more scalable way to gather demonstrations.
6. **How would you experiment with an approach like this yourself?** In-context and demonstration-driven methods still depend on a simulation stack for collecting demonstrations, generating variations, and validating policies before real-robot rollouts. [Drift](https://link.godrift.ai/gen01) generates ROS 2 and MuJoCo simulation workspaces from a natural-language prompt, which removes the scene-and-harness setup so you can focus on the demonstrations and the policy rather than the boilerplate around them.

## Related reading

- [5 Ways Robots Learn Without Being Programmed](https://www.godrift.ai/blogs/how-robots-learn-without-programming)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Gemini Robotics 2 and Whole-Body Control for Humanoid Robots](https://www.godrift.ai/blogs/gemini-robotics-2-explained)
- [Why Robots Practice in Simulation Before the Real World](https://www.godrift.ai/blogs/why-robots-train-in-simulation)


# 5 Ways Robots Learn Without Being Programmed

*2026-08-21 · Drift Team · Research · 6 min*

> Robots no longer need every move coded by hand. Here are 5 ways robots learn instead, from demonstrations and reinforcement learning to human videos and VLAs.

<https://godrift.ai/blogs/how-robots-learn-without-programming>

---
You no longer have to script a robot's every movement. You can show it what to do, give it a goal, or just tell it what you want, and let it work out the rest.

<figure data-type="youtube-embed" data-yt-id="KKVSmrVfUYU" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/KKVSmrVfUYU?autoplay=1&mute=1&loop=1&playlist=KKVSmrVfUYU&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

You don't have to program a robot's every movement anymore. Understanding how robots learn without programming comes down to a shift in approach: instead of writing out each motion, engineers show the robot what to do, give it a goal, or describe the task in plain language. Here are five ways robots learn to act on their own.

## 1. Learning from demonstrations

&nbsp;

The most intuitive method is to simply show the robot. A person performs a task, often by teleoperating the robot directly, the robot records that demonstration, and a model learns how those actions produce the result. Do this enough times and the robot can reproduce the task on its own.

&nbsp;

This approach, sometimes called imitation learning, is behind a lot of recent manipulation progress. Low-cost platforms like [the ALOHA dual-arm system](https://www.godrift.ai/blogs/bimanual-manipulation-aloha-mujoco) exist largely to make collecting these human demonstrations easy. The appeal is obvious: showing a robot a task is far more natural than coding it.

## 2. Reinforcement learning

&nbsp;

But what if you don't show the robot the right answer? That's where reinforcement learning comes in. You give the robot a goal, let it try many different actions, and reward the ones that move it closer to success. Over enough attempts, it discovers a working behavior on its own, without ever being told the exact motions.

&nbsp;

This is how a lot of robot locomotion and control is learned. We walked through a hands-on example in [training a Franka Panda to push a cube with reinforcement learning](https://www.godrift.ai/blogs/franka-push-cube-ppo-mujoco), where the arm figures out the task purely from trial and reward.

## 3. Learning in simulation

&nbsp;

Those trial-and-error attempts don't have to happen on real hardware, and usually they shouldn't. In simulation, a robot can practice thousands of times without any risk to the machine. It can fail, reset, and try again in seconds, and many virtual copies can train in parallel, which makes learning dramatically faster and cheaper.

&nbsp;

This is why [almost every robot trains in simulation first](https://www.godrift.ai/blogs/why-robots-train-in-simulation). The catch is the sim-to-real gap, the small differences between simulation and reality that a learned behavior has to survive, but the speed and safety make it worth it for the bulk of training.

## 4. Learning from human videos

&nbsp;

Robots can learn from more than just robot data. They can also learn by watching us. Researchers are increasingly using ordinary human videos, people cooking, opening doors, picking things up, to extract information about objects, actions, and how tasks get done.

&nbsp;

The appeal here is scale. There is a vast amount of video of humans doing things, far more than anyone could ever collect on robots directly, which is why approaches like [learning manipulation from human video](https://arxiv.org/abs/2207.09450) have drawn so much attention. Tapping into it is a way to teach robots about the physical world without running a robot for every example, and it's a fast-moving area of [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai) research.

## 5. Vision-language-action models

&nbsp;

The newest approach combines much of the above with models that understand language. Vision-language-action (VLA) models connect three things: what a robot sees, what it's told, and what it should do. The model takes in the camera view and an instruction, and outputs the actions to carry it out.

&nbsp;

The result is that instead of writing a routine for every task, you can give the robot a plain-language instruction, like "pick up the red cup", and let the model translate it into motion. VLA models are among the most important [AI models changing robotics](https://www.godrift.ai/blogs/ai-models-changing-robotics) right now, and the basis of systems like Google DeepMind's [Gemini Robotics 2](https://www.godrift.ai/blogs/gemini-robotics-2-explained).

## Where all five approaches are heading?

&nbsp;

These five methods are different on the surface, but they point in the same direction. Whether a robot learns by being shown, by trial and error, by practicing in simulation, by watching human video, or by interpreting an instruction, the underlying shift is the same: away from telling a robot exactly how to move, and toward giving it ways to figure that out for itself.

&nbsp;

That shift is the heart of modern robot learning and a defining feature of [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai). It's what's taking robots from rigid machines that repeat pre-programmed motions to systems that can adapt to tasks and environments they were never explicitly coded for.

## FAQ

1. **How do robots learn without being programmed?** Instead of hand-coding every motion, engineers use machine learning. Robots learn from human demonstrations, through reinforcement learning (trial and error toward a reward), by practicing in simulation, by watching human videos, and through vision-language-action models that turn instructions into actions.
2. **What is imitation learning in robotics?** Imitation learning is when a robot learns a task by observing demonstrations, often from a human teleoperating it. A model learns the mapping from what the robot senses to the actions that achieve the task, so it can later perform the task on its own.
3. **What is the difference between reinforcement learning and learning from demonstrations?** In learning from demonstrations, the robot is shown the correct actions and imitates them. In reinforcement learning, the robot is not shown the answer, it tries different actions and learns from reward feedback which ones work, discovering the behavior itself.
4. **Can robots really learn from human videos?** Yes. Researchers use human video to extract information about objects, actions, and how tasks are performed, then transfer that knowledge to robots. Because there is far more human video than robot data available, it's a promising way to teach robots at scale.
5. **What are vision-language-action (VLA) models?** VLA models connect a robot's vision, a language instruction, and its actions in one system. They let you give a robot a plain-language command and have the model output the motor actions to carry it out, instead of programming a separate routine for each task.
6. **How are these learning methods developed and tested?** Most of them, especially reinforcement learning and simulation-based training, are developed in a simulator before running on real robots, where a policy can be trained and evaluated safely at scale. Tools like [Drift](https://link.godrift.ai/prelearn) generate the simulated robots and environments used for that work, while the learning algorithms are built on top.

## Related reading

- [Training a Franka Panda to Push a Cube With Reinforcement Learning](https://www.godrift.ai/blogs/franka-push-cube-ppo-mujoco)
- [Why Robots Practice in Simulation Before the Real World](https://www.godrift.ai/blogs/why-robots-train-in-simulation)
- [5 AI Models Changing Robotics Right Now](https://www.godrift.ai/blogs/ai-models-changing-robotics)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)


# Scripting Hand Gestures for the SharpaWave Hand in MuJoCo

*2026-08-19 · Drift Team · Product · 5 min*

> The SharpaWave is a dexterous five-finger robot hand. Drift scripts it through five poses in MuJoCo, from open hand to fist to thumbs up, from one prompt.

<https://godrift.ai/blogs/sharpa-wave-hand-gestures-mujoco>

---
What can you do with a five-finger robot hand and a few lines of instruction? Start simple: teach it to make a handful of recognizable gestures.

<figure data-type="youtube-embed" data-yt-id="s_3xeF9IJf8" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/s_3xeF9IJf8?autoplay=1&mute=1&loop=1&playlist=s_3xeF9IJf8&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough takes the SharpaWave hand into MuJoCo and gives it a scripted sequence of finger movements, with [Drift](https://link.godrift.ai/sharpa) setting up the scene and the motion from one prompt. It's a gentle entry point into controlling a dexterous hand, and a nice contrast to [why robot hands are so hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard) once you move past scripted poses into real manipulation.

## What the SharpaWave hand is?

&nbsp;

The [SharpaWave](https://www.sharpa.com/pages/wave), made by the robotics company Sharpa, is a dexterous five-fingered robot hand with 22 active degrees of freedom at human hand size, built to approach the range of motion of a real hand. It's the same hand that appears on Apptronik's Apollo humanoid in [Google DeepMind's Gemini Robotics 2 demos](https://www.godrift.ai/blogs/gemini-robotics-2-explained), where it handles delicate tasks like sealing bags and handling light bulbs.

&nbsp;

Here we're using it in a much simpler way, on its own, as a standalone hand rather than attached to an arm or a robot. That lets us focus entirely on the fingers and what it takes to move them into specific, coordinated shapes.

## What we asked [Drift](https://link.godrift.ai/sharpa) to build?

&nbsp;

We start from the existing SharpaWave model and give [Drift](https://link.godrift.ai/sharpa) one prompt: use the hand as a standalone end-effector, build a simple MuJoCo scene, and script a smooth finger sequence that runs through five poses, open hand, closed fist, a pointing index finger, a thumbs up, and back to open, keeping the hand fixed in place so the focus stays on the finger motion.

&nbsp;

Two choices in that prompt matter. Keeping the hand fixed removes arm movement from the picture, so nothing distracts from the fingers. And asking for a smooth sequence means the hand eases between poses rather than snapping, which is what makes the gestures read as natural. New to the simulator? Here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco) first.

## How Drift builds the scene and the sequence?

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/sharpa) sets up the MuJoCo scene with the hand fixed in position and generates the scripted motion that carries it through the five poses. It works out the joint targets for each gesture and the transitions between them, then packages it into a runnable file.

&nbsp;

Getting a specific gesture right means setting many finger joints to the correct angles at once, a fist needs every finger curled, a point needs the index extended while the rest close, a thumbs up flips that around. Generating those poses and the smooth motion between them from a prompt skips the manual work of hand-tuning each joint angle by trial and error.

## Watching the hand run through its gestures

&nbsp;

We launch the generated file and MuJoCo opens with the hand in its starting open position. Then the sequence plays out: the hand smoothly closes into a fist, opens into a pointing gesture with the index finger, switches to a thumbs up, and finally returns to the open hand it started from.

&nbsp;

Letting each pose hold for a moment makes the sequence easy to follow, and the smooth transitions between them are what sell the gestures as deliberate rather than mechanical. Each shape is just a particular combination of finger joint positions, but strung together they read as gestures anyone would recognize.

## Why coordinated finger motion matters?

&nbsp;

It's a simple sequence, but it makes a real point: recognizable gestures are just individual finger movements coordinated in the right way. A fist, a point, and a thumbs up come down to the same thing: different combinations of the same joints moving together.

&nbsp;

That coordination is the foundation everything harder is built on. Scripting fixed poses is the easy end of the spectrum, and real manipulation, grasping unfamiliar objects, adjusting grip by feel, reacting to contact, is far tougher, which is the whole reason [robot hands are so hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard) and a central challenge in [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai). But it starts here, with getting the fingers to move where you want them. Change the poses, add your own gestures, and see what the hand can express. The full walkthrough is in the video above.

## FAQ

1. **What is the SharpaWave hand?** The SharpaWave is a dexterous five-fingered robot hand with many independently controllable joints, designed to approach the range of motion of a human hand. It's used on humanoid robots, including Apptronik's Apollo in Google DeepMind's Gemini Robotics 2 demonstrations.
2. **How do you make a robot hand form a gesture?** A gesture is a specific combination of finger joint positions. To form one, you set each joint to the right angle, for example curling all fingers for a fist, or extending the index while closing the others to point. Smooth transitions between these joint targets create natural-looking gestures.
3. **Is scripting gestures the same as robot manipulation?** No. Scripting gestures moves the fingers through predefined poses, which is relatively straightforward. Real manipulation, like grasping unfamiliar objects and adjusting by touch, is much harder because the hand must react to contact and objects it wasn't pre-programmed for.
4. **Why keep the hand fixed in place for this demo?** Fixing the hand removes arm and body motion from the scene, so the focus stays entirely on finger movement. It isolates the coordination of the fingers, which is the point of the demonstration.
5. **How does ****[Drift](https://link.godrift.ai/sharpa)**** set up the gesture sequence?** From a single natural-language prompt, [Drift](https://link.godrift.ai/sharpa) builds the MuJoCo scene with the SharpaWave hand fixed in place and generates the scripted finger motion through all five poses, including the smooth transitions, so you can launch it and watch without hand-coding each joint angle.

## Related reading

- [Why Robot Hands Are So Hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard)
- [Gemini Robotics 2 and Whole-Body Control for Humanoid Robots](https://www.godrift.ai/blogs/gemini-robotics-2-explained)
- [Adding Vision to a Franka Panda Robot in MuJoCo](https://www.godrift.ai/blogs/add-camera-franka-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# Why Folding Laundry Is So Hard for Robots?

*2026-08-18 · Drift Team · Research · 5 min*

> Folding a T-shirt takes us seconds but stumps most robots. Here's why deformable fabric makes laundry one of the hardest manipulation tasks in robotics.

<https://godrift.ai/blogs/why-folding-laundry-is-hard-for-robots>

---
Folding a T-shirt takes you a few seconds without thinking. For a robot, it's one of the hardest manipulation problems there is.

<figure data-type="youtube-embed" data-yt-id="6Uqgzyg4UZk" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/6Uqgzyg4UZk?autoplay=1&mute=1&loop=1&playlist=6Uqgzyg4UZk&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

The short version: a robot is great at handling objects that hold their shape, and terrible at objects that don't. Laundry is the second kind.

## Fabric has no fixed shape

&nbsp;

The core problem is that a piece of clothing has no fixed shape. A rigid object like a cube or a mug looks essentially the same every time, so a robot can model it once and plan around it. Fabric refuses to cooperate.

&nbsp;

A shirt can wrinkle, stretch, drape, and fold over itself, and it looks completely different from one moment to the next. Drop it on a table twice and you get two entirely different shapes. This is what roboticists call a [deformable object](https://pmc.ncbi.nlm.nih.gov/articles/PMC10007406/), and it breaks the assumption most manipulation relies on, that the thing you're grasping has a predictable form. It's a whole tier harder than the rigid-object grasping behind [why robot hands are so hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard).

## Finding the edges, sleeves, and collar

&nbsp;

Because the shape is never the same twice, the robot's first job is perception. Before it can fold anything, it has to look at a crumpled heap of fabric and work out where the meaningful parts are: the edges, the sleeves, the collar, the hem.

&nbsp;

That's genuinely hard. A human glances at a shirt and instantly parses its structure, even bunched up. A robot has to infer all of that from camera data alone, on an object with no consistent appearance. This is the perception half of [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai)working at the edge of what current vision can do.

## Grasping the right spot without disturbing the rest

&nbsp;

Once the robot has identified a useful point, like a shoulder or a corner, it has to grab exactly that spot without disturbing everything else. Fabric moves in response to the lightest touch, so reaching in to pinch one sleeve can easily drag, bunch, or flip the rest of the shirt.

&nbsp;

A rigid object stays put while you position the gripper. Cloth reacts to contact before you've even grasped it, which means the robot has to account for how the whole garment will shift as it moves in. Precise, gentle grasping on something that keeps rearranging itself is a serious control challenge.

## Every fold changes the scene

&nbsp;

Here's the part that makes laundry especially brutal. Every fold changes the scene. The moment the robot completes one fold, the shirt is a different shape than the plan assumed, and the part it needs to grab next may now be hidden underneath a flap of fabric.

&nbsp;

So the robot can't compute one plan and execute it blindly. It has to perceive the garment again after every single action, re-locate the parts it needs, and adjust, over and over. This constant sense-plan-act loop on an object that transforms with each step is far harder than executing a fixed sequence on a rigid object that stays where you put it.

## Why laundry is a benchmark for household robots?

&nbsp;

All of this is exactly why laundry has become such a good test for household robots. It concentrates the hardest parts of real-world manipulation into one ordinary chore: unpredictable shape, delicate grasping, and a scene that changes with every move.

&nbsp;

If a robot can reliably fold a shirt, it's demonstrating the skills needed to handle the messy, deformable, ever-changing objects that fill a real home, from towels and bags to food and packaging. That's why leading robotics teams use tasks like folding and bag manipulation to show real progress, and why it connects to the broader push to build capable [household robots](https://www.godrift.ai/blogs/kitchen-simulation-stretch-3-mujoco). To us, it's just a T-shirt. To a robot, it's a constantly changing object, and mastering it is a real milestone.

## FAQ

1. **Why is folding laundry so hard for robots?** Because fabric has no fixed shape. A shirt wrinkles, stretches, and folds over itself, looking different every time, so a robot can't rely on a memorized model. It has to perceive the garment's structure, grasp delicate points without disturbing the rest, and re-plan after every fold, since the scene changes with each move.
2. **What is a deformable object in robotics?** A deformable object is one that changes shape when handled, like cloth, rope, food, or bags, as opposed to a rigid object like a cube that keeps its form. Deformable objects are much harder for robots because their shape is unpredictable and reacts to contact.
3. **Why is folding laundry considered a good test for household robots?** Laundry combines the hardest parts of home manipulation in one task: unpredictable shape, gentle and precise grasping, and a scene that changes after every action. A robot that can fold laundry reliably is showing it can handle the messy, deformable objects common in real homes.
4. **Why can't a robot just follow a fixed folding sequence?** Because every fold changes the shape of the garment, and the next part the robot needs may end up hidden or moved. It has to re-perceive the shirt and re-plan after each action rather than blindly executing a memorized set of motions.
5. **How do robots learn to handle fabric and other deformable objects?** Largely through learning from data and demonstrations, and through practice in simulation, where deformable-object handling can be attempted many times safely. Tools like [Drift](https://link.godrift.ai/folding) generate the simulated robots and environments used to develop and test manipulation before it runs on real hardware.

## Related reading

- [Why Robot Hands Are So Hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Building a Kitchen Simulation With the Hello Robot Stretch 3 in MuJoCo](https://www.godrift.ai/blogs/kitchen-simulation-stretch-3-mujoco)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)


# Adding SLAM to a Warehouse Robot With LiDAR in Gazebo

*2026-08-15 · Drift Team · Product · 5 min*

> SLAM lets a robot map an unknown space while tracking its own position. Drift adds LiDAR SLAM to a warehouse robot in Gazebo and ROS 2 from a single prompt.

<https://godrift.ai/blogs/slam-warehouse-robot-gazebo>

---
A robot can drive across a warehouse just fine. The harder question is how it knows where it is while doing it.

<figure data-type="youtube-embed" data-yt-id="kSC_c-B0hnM" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/kSC_c-B0hnM?autoplay=1&mute=1&loop=1&playlist=kSC_c-B0hnM&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough gives a robot a way to answer that, adding LiDAR SLAM to a warehouse robot so it can map its surroundings while it moves, with [Drift](https://link.godrift.ai/slam-1) setting up the whole stack from one prompt. It builds directly on [adding a LiDAR sensor](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2), which gave the robot the ability to see. SLAM is what turns those measurements into a map.

## What SLAM is and why a warehouse robot needs it?

&nbsp;

SLAM stands for Simultaneous Localization and Mapping, and the name captures the whole trick. The robot has to do two hard things at once: build a map of a space it has never seen, and figure out its own position within that map as it goes. Each depends on the other, which is what makes it a genuinely difficult problem, and one of the core methods behind [how robots navigate](https://www.godrift.ai/blogs/how-robots-navigate).

&nbsp;

A warehouse is a perfect case for it. The robot can't rely on GPS indoors, and the layout can change as shelves and inventory move. Rather than being handed a fixed map, the robot builds its own and keeps it updated, which is what lets it know where it is well enough to navigate reliably.

## The role of LiDAR in building the map

&nbsp;

SLAM needs measurements of the environment to work from, and that's what the LiDAR provides. The sensor sweeps the space with laser beams and reports the distance to whatever they hit, producing a precise outline of walls, shelves, and obstacles around the robot.

&nbsp;

Feed that stream of distance readings into SLAM, and the algorithm stitches successive scans together into a single consistent map, while using them to track how the robot has moved. Good sensor data is what makes the resulting map accurate, which is why LiDAR is such a common choice for indoor mapping.

## What we asked Drift to build?

&nbsp;

Starting from the existing robot setup, we gave [Drift](https://link.godrift.ai/slam-1) one prompt: add SLAM to the robot using LiDAR, and launch Gazebo, the SLAM stack, and RViz2 together so the robot builds a 2D map while it moves around the warehouse autonomously.

&nbsp;

That single instruction covers several moving parts, the simulator, the SLAM software, and the visualization, that normally have to be wired together by hand. A quick note on the tools: [Gazebo](https://gazebosim.org/) is the robot simulator running the warehouse and the robot, and RViz2 is the ROS 2 visualization tool where you actually see the map being drawn. Drift sets all of it up to launch together.

## How Drift assembles the SLAM stack?

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/slam-1) adds the SLAM stack around the robot you already have and configures everything to launch as one system. It connects the LiDAR output to the SLAM algorithm, sets up the mapping, and wires in RViz2 so the map is visualized live.

&nbsp;

Standing this up by hand normally means installing and configuring a SLAM package, matching it to your robot and sensor, and getting the launch files and visualization talking to each other. Generating it from a prompt skips the fiddly integration and gives you a working stack to run.

## Watching the map build in real time

&nbsp;

We launch everything together and let the robot drive. As it moves through the warehouse, its LiDAR continuously scans the surroundings, and SLAM uses those measurements to build the map live in RViz2.

&nbsp;

The map fills in as the robot explores. Areas it has already passed are mapped in detail, and each new corridor or aisle gets added as the robot reaches it. Watching the 2D map grow from nothing into a full floor plan is the clearest possible confirmation that the robot both sees its environment and understands where it sits inside it.

## Why mapping changes what the robot can do?

&nbsp;

With SLAM running, the robot is doing more than driving through the warehouse. It's building a map of the space around it and continuously working out its own position within that map. That combination, a map plus a reliable sense of location, is the foundation almost every higher-level behavior sits on.

&nbsp;

Once a robot can map and localize, it can plan efficient routes, avoid obstacles it discovers along the way, and navigate autonomously toward a goal, exactly the capabilities behind [how warehouse robots work](https://www.godrift.ai/blogs/how-warehouse-robots-work) at scale. With Drift handling the setup, you can move straight to those next steps. Launch the stack, drive the robot, and watch the map appear. The full walkthrough is in the video above.

## FAQ

1. **What is SLAM in robotics?** SLAM (Simultaneous Localization and Mapping) is a technique that lets a robot build a map of an unknown environment while tracking its own position within that map at the same time. It's a core capability for autonomous navigation, especially indoors where GPS is unavailable.
2. **How does LiDAR help with SLAM?** LiDAR measures the distance to surrounding surfaces by sweeping the space with laser beams. SLAM uses that precise distance data to construct an accurate map and to estimate how the robot has moved between scans, which is why LiDAR is a popular sensor for indoor mapping.
3. **Why do warehouse robots use SLAM?** Warehouses have no reliable GPS indoors, and their layouts change as inventory moves. SLAM lets a robot build and update its own map rather than depend on a fixed one, so it always knows where it is well enough to navigate safely and efficiently.
4. **What is the difference between Gazebo and RViz2?** Gazebo is a physics simulator that runs the virtual robot and environment. RViz2 is a ROS 2 visualization tool that displays data like the SLAM map, sensor readings, and the robot's estimated position. In this walkthrough, Gazebo runs the warehouse while RViz2 shows the map being built.
5. **How does Drift set up SLAM?** From a single natural-language prompt, [Drift](https://link.godrift.ai/slam-1) adds a LiDAR-based SLAM stack to an existing robot and launches the simulator, the SLAM algorithm, and RViz2 together, so the robot builds a live 2D map as it moves, without manually configuring and connecting each component.

## Related reading

- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [How Warehouse Robots Actually Work](https://www.godrift.ai/blogs/how-warehouse-robots-work)
- [Why Robots Practice in Simulation Before the Real World](https://www.godrift.ai/blogs/why-robots-train-in-simulation)


# 5 Robotics Research Labs Pushing the Field Forward

*2026-08-14 · Drift Team · Research · 5 min*

> Most robots you see online started in a research lab. Here are 5 robotics research labs pushing the field forward, from the RAI Institute to MIT and CMU.

<https://godrift.ai/blogs/top-robotics-research-labs>

---
Every robot you've seen go viral started somewhere. Usually not at a company, but in a research lab, years before the demo reel.

<figure data-type="youtube-embed" data-yt-id="Ftcb2uZP7eM" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/Ftcb2uZP7eM?autoplay=1&mute=1&loop=1&playlist=Ftcb2uZP7eM&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

These robotics research labs are where the hard problems get solved first, and where a lot of what you'll see robots doing next is being figured out right now. Here are five of them.

## 1. RAI Institute, the brains behind Atlas and Spot

&nbsp;

Let's start with one whose robots you'll recognize. If you've watched Atlas or Spot in action, you've already seen the hardware. The [Robotics and AI Institute](https://rai-inst.com/) (RAI Institute, formerly the Boston Dynamics AI Institute), led by Boston Dynamics founder Marc Raibert, works on the intelligence behind machines like these.

&nbsp;

Its focus is the harder, less visible half of robotics: helping robots move athletically, perceive their surroundings, and manipulate objects more naturally. It works closely with Boston Dynamics on things like a reinforcement-learning pipeline for the electric Atlas, which is exactly the kind of research that makes [humanoid robots](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard) practical rather than just impressive.

## 2. Google DeepMind Robotics and the push into language

&nbsp;

Making a robot move is one challenge. Getting it to understand what you're asking is a completely different one. That's the problem Google DeepMind's robotics team works on, most visibly through [Gemini Robotics](https://www.godrift.ai/blogs/gemini-robotics-2-explained).

&nbsp;

By combining large AI models with robotics, DeepMind is building systems that can interpret a plain-language instruction, plan the steps, and carry out real-world tasks like sorting objects or handling household items. It's some of the clearest work on giving robots general, flexible intelligence rather than a fixed set of pre-programmed skills, and a major force behind the vision-language-action models [reshaping robotics](https://www.godrift.ai/blogs/ai-models-changing-robotics).

## 3. Stanford Vision and Learning Lab and robot learning

&nbsp;

Robots need more than instructions. They also need experience. Stanford's Vision and Learning Lab (SVL) focuses on exactly that: robot learning, computer vision, and embodied AI, so robots can improve through data and demonstrations rather than hand-written rules.

&nbsp;

SVL is behind widely used work in this space, including [ALOHA](https://www.godrift.ai/blogs/bimanual-manipulation-aloha-mujoco), the low-cost dual-arm platform for bimanual manipulation, and research into learning manipulation from human demonstrations. It's a lot of the groundwork behind teaching robots skills by showing them, instead of coding every motion by hand.

## 4. MIT CSAIL and robots that work with people

&nbsp;

Once robots can learn, the question becomes where they can actually help. MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) is one of the largest computing research labs in the world, and its robotics work ranges widely, from [soft robotics](https://www.godrift.ai/blogs/soft-robots) to human-robot interaction.

&nbsp;

The through-line is building robots designed to operate alongside people, whether that means machines that bend and flex safely, assistive robots, or agile legged systems like the Mini Cheetah. It's research aimed at robots that fit into human environments rather than staying behind safety cages.

## 5. CMU Robotics Institute and robots for the real world

&nbsp;

Robotics doesn't stop indoors. Carnegie Mellon's Robotics Institute, one of the oldest and largest dedicated robotics research centers anywhere, builds machines for the messiest environments there are.

&nbsp;

Its work spans autonomous vehicles, drones, industrial robots, and field robots designed to operate in tough outdoor conditions, from farms to disaster sites to mines. This is the research pushing robots out of controlled labs and into the unpredictable real world, which is one of the hardest tests in the entire field.

## Why these labs matter for where robotics is going

&nbsp;

Each of these labs tackles a different piece of the puzzle: athletic intelligence, language understanding, learning from experience, working with people, and operating in the wild. Put them together and you get a fairly complete picture of where robotics is heading next.

&nbsp;

They also share a common thread in how the work gets done. Almost all of it relies on [simulation](https://www.godrift.ai/blogs/why-robots-train-in-simulation) to develop and test robots before building expensive hardware, which is increasingly the foundation of modern [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai) research across every one of these labs.

## FAQ

&nbsp;

1. **What are the top robotics research labs?** Among the most influential are the RAI Institute (formerly the Boston Dynamics AI Institute), Google DeepMind Robotics, Stanford's Vision and Learning Lab, MIT CSAIL, and Carnegie Mellon's Robotics Institute. Each leads in a different area, from humanoid intelligence to robot learning to field robotics.
2. **What is the RAI Institute?** The Robotics and AI Institute, formerly the Boston Dynamics AI Institute, is a research organization led by Boston Dynamics founder Marc Raibert. It develops the intelligence behind advanced robots, focusing on athletic movement, perception, and manipulation, and works with Boston Dynamics on robots like Atlas.
3. **What does Google DeepMind work on in robotics?** Google DeepMind's robotics research focuses on giving robots general intelligence, most visibly through Gemini Robotics. It combines large AI models with robot control so robots can understand plain-language instructions, plan multi-step tasks, and act in the real world.
4. **Which university has the best robotics research?** There's no single answer, but Stanford (Vision and Learning Lab), MIT (CSAIL), and Carnegie Mellon (Robotics Institute) are consistently among the leading university robotics programs, each with different strengths in learning, human-robot interaction, and field robotics.
5. **How do robotics labs test their robots?** Most rely heavily on simulation to develop and validate robots before building or risking real hardware, then transfer what works to physical machines. Tools like [Drift](https://link.godrift.ai/lab) generate the simulated robots and environments used for that kind of testing.

## Related reading

- [Gemini Robotics 2 and Whole-Body Control for Humanoid Robots](https://www.godrift.ai/blogs/gemini-robotics-2-explained)
- [5 AI Models Changing Robotics Right Now](https://www.godrift.ai/blogs/ai-models-changing-robotics)
- [Why Robots Practice in Simulation Before the Real World](https://www.godrift.ai/blogs/why-robots-train-in-simulation)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)


# Training a Franka Panda to Push a Cube With Reinforcement Learning

*2026-08-12 · Drift Team · Product · 7 min*

> Reinforcement learning lets a robot learn by trial and error. Drift sets up the Gymnasium environment to train a Franka Panda to push a cube with PPO in MuJoCo.

<https://godrift.ai/blogs/franka-push-cube-ppo-mujoco>

---
What happens when you stop telling a robot exactly how to move, and let it work the task out for itself? That's the whole idea behind reinforcement learning.

<figure data-type="youtube-embed" data-yt-id="z7_c3ANllR8" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/z7_c3ANllR8?autoplay=1&mute=1&loop=1&playlist=z7_c3ANllR8&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Our earlier Franka Panda demos told the arm exactly what to do, every grasp and placement scripted in advance. This one is different. We use reinforcement learning to train a Franka Panda to push a cube onto a target, which means we don't program the motion at all. We give the robot a goal and let it discover how to reach it through trial and error, with [Drift](https://link.godrift.ai/rele) generating the whole training setup from a prompt.

## What reinforcement learning actually means here?

&nbsp;

Reinforcement learning (RL) is a way for a robot to learn a task by trying it many times and getting feedback on how well it did. Rather than being told the exact motions, the robot takes an action, receives a reward score for how close it got to the goal and gradually adjusts its behaviour to earn more reward. Over thousands of attempts, it converges on a strategy that works.

### A few plain-language terms show up in this build:

1. **Policy:** The robot's learned strategy, its internal rule for what to do given what it currently sees.
2. **Reward:** A score the environment gives after each action, telling the robot how good or bad that action was. Pushing the cube toward the target earns more reward.
3. **PPO:** [Proximal Policy Optimization](https://stable-baselines3.readthedocs.io/en/master/modules/ppo.html), a popular and reliable RL algorithm. It's the method that actually improves the policy from all those attempts.
4. **Gymnasium environment:** The standard wrapper that defines the task, what the robot senses, what actions it can take, how reward is calculated, and when an episode ends, so an RL algorithm like PPO can train against it.

&nbsp;

This is the hands-on version of [why robots train in simulation](https://www.godrift.ai/blogs/why-robots-train-in-simulation): the robot needs thousands of attempts, and only a simulator can provide them safely and fast.

## Setting up the training environment

&nbsp;

We start from the existing Franka Panda scene in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco), the same one from the [pick-and-place walkthrough](https://www.godrift.ai/blogs/pick-and-place-mujoco), and create a separate Python virtual environment for the training code, so the RL setup stays isolated from the rest of the project. Then we launch Drift and initialize a new project for the task.

&nbsp;

Keeping the training setup in its own environment is good practice, since RL training pulls in specific libraries, and you don't want them tangled up with your simulation scene.

## The prompt that defines the whole RL task

&nbsp;

Rather than writing the RL code by hand, we give Drift the key constraints for the task: reuse the existing Franka scene, set up a Gymnasium environment, randomize the cube's starting position on each reset, and define the rewards and success detection needed to train and evaluate a PPO policy.

&nbsp;

That single prompt describes the whole training pipeline at a high level. Randomizing the cube position matters, because it forces the robot to learn to push a cube from anywhere, not just memorize one fixed motion. That's the difference between a policy that generalizes and one that only works in a single rehearsed case.

## The training pipeline Drift generates

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/rele) generates the full setup: the Gymnasium environment, randomized resets, the reward function, and success detection, along with two separate scripts, one to train the policy and one to evaluate it.

&nbsp;

Writing all of this by hand is fiddly and error-prone. The reward function alone usually takes careful tuning, since a poorly shaped reward can teach the robot the wrong thing entirely. Having the pipeline generated as a working starting point means you can go straight to training and iteration instead of debugging boilerplate.

## Training the PPO policy

&nbsp;

With the pipeline in place, we run the training script and let PPO go to work. The robot attempts the push over and over, and after each attempt PPO nudges the policy toward whatever earned more reward.

&nbsp;

In the training output you can watch the numbers tick up: steps, episodes, and the reward per episode climbing as the policy improves. Early on the arm flails and misses. As training continues, the reward trends upward, a sign the robot is genuinely learning the task rather than moving at random. This is the part that takes time and compute, which is exactly why it happens in simulation and not on a real arm.

## Watching the learned policy in action

&nbsp;

Once training finishes, we run the evaluation script and MuJoCo opens so we can see what the policy actually learned. Each episode starts with the cube in a new position, so the robot has to apply what it learned rather than repeat a memorised path.

&nbsp;

The arm moves in, tries to push the cube toward the target, and the script reports whether each attempt succeeded, a simple true or false per episode. It isn't perfect. You'll see some misses and clumsy attempts mixed with clean successes. But across the episodes you can watch the policy starting to genuinely figure out the task, which is the whole point: nobody told it how to push the cube, it worked that out on its own.

## Why this matters for robot learning?

&nbsp;

That's reinforcement learning in action. Instead of programming every movement, we gave the robot a goal, a reward, and a place to practice, and it learned how to reach the goal through trial and error.

&nbsp;

This is the same principle behind much of modern robot learning, from locomotion to manipulation, and it's a foundational technique in [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai). With Drift generating the training pipeline, the tedious setup is handled, so you can focus on the interesting parts: shaping better rewards, training longer, or trying harder tasks. Change the reward, retrain, and watch how the behavior shifts. The full walkthrough is in the video above.

## FAQ

1. **What is reinforcement learning in robotics?** Reinforcement learning is a method where a robot learns a task by trial and error. It takes an action, receives a reward score for how well it did, and gradually adjusts its strategy to earn more reward. Over many attempts it learns a behavior without being explicitly programmed with the motions.
2. **What is PPO?** PPO (Proximal Policy Optimization) is a widely used reinforcement learning algorithm. It's popular because it's relatively stable and reliable at improving a robot's policy from repeated attempts, which makes it a common default choice for training control tasks.
3. **What is a Gymnasium environment?** Gymnasium is a standard interface for reinforcement learning that defines a task: what the agent observes, what actions it can take, how reward is calculated, and when an episode ends. Wrapping a robot task in a Gymnasium environment lets standard RL algorithms like PPO train against it.
4. **Why randomize the cube's position during training?** Randomizing the starting position forces the robot to learn a general pushing skill instead of memorizing one fixed motion. A policy trained only on a single position would fail as soon as the cube moved, so randomization is what makes the learned behavior robust.
5. **How does ****[Drift](https://link.godrift.ai/rele)**** set up reinforcement learning?** From a single prompt, [Drift](https://link.godrift.ai/rele) generates the full RL pipeline: a Gymnasium environment, randomized resets, a reward function, success detection, and separate training and evaluation scripts, reusing the existing MuJoCo scene, so you can train a PPO policy without hand-coding the setup.

## Related reading

- [Why Robots Practice in Simulation Before the Real World](https://www.godrift.ai/blogs/why-robots-train-in-simulation)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# Why Robots Practice in Simulation Before the Real World?

*2026-08-11 · Drift Team · Research · 4 min*

> Almost every modern robot practices in simulation before real hardware. Here's why sim-to-real training makes robots faster, cheaper, and safer to build.

<https://godrift.ai/blogs/why-robots-train-in-simulation>

---
Before a robot ever enters the real world, it usually spends hundreds of hours somewhere else first: inside a simulation. There's a good reason for that.

<figure data-type="youtube-embed" data-yt-id="1KWj5qDkTW8" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/1KWj5qDkTW8?autoplay=1&mute=1&loop=1&playlist=1KWj5qDkTW8&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Understanding why robots train in simulation comes down to three things it gives them that reality can't: a safe place to fail, a way to practice far faster than real time, and a cheap way to iterate before touching costly hardware. Here's how each one works.

## A safe place to fail without breaking hardware

&nbsp;

Engineers start by building a virtual version of the robot, a model that behaves like the real machine under simulated physics. In that virtual copy, they can test new controllers, train AI models, and experiment freely.

&nbsp;

The key word is freely. A mistake in simulation costs nothing. The same mistake on a real robot might mean a damaged arm, a crashed drone, or weeks of repairs. Robot hardware is expensive and fragile, so being able to fail thousands of times with no consequences is what makes bold experimentation possible in the first place.

## Practicing thousands of times faster than real time

&nbsp;

Simulation also removes one of the biggest limits in robotics: time. On a real robot, every attempt happens in real time, and someone often has to reset the setup between tries. That makes large-scale learning painfully slow.

&nbsp;

In simulation, a robot can repeat the same task thousands of times, learning from every attempt without waiting for a human to reset anything. Better still, many simulators can run faster than real time and spin up many copies of the robot in parallel, so a task that would take months on hardware can be practiced in hours. This is what makes modern approaches like [reinforcement learning](https://www.godrift.ai/blogs/what-is-mujoco) for robots practical, often using training frameworks like [NVIDIA Isaac Lab](https://developer.nvidia.com/isaac/lab) to run thousands of robots at once.

## Crossing the sim-to-real gap

&nbsp;

Once the robot performs consistently in simulation, engineers move those trained controllers onto the real machine. This transfer step is known as sim-to-real, and it's where the practice pays off.

&nbsp;

Real-world testing doesn't go away. The purpose of simulation is to reach the real robot having already made most of the mistakes virtually, so the hardware phase starts far ahead instead of from zero. The one catch is that simulation is never a perfect match for reality, tiny differences in friction, contact, or timing can trip up a controller that looked flawless in sim, which is the core challenge sim-to-real work exists to close.

## Why almost every robot starts in simulation?

&nbsp;

Put it together and the pattern is clear. Simulation gives a robot a place to fail, learn, and improve before the real world is ever involved, safely, quickly, and cheaply.

&nbsp;

That's why almost every modern robot, from warehouse machines to [humanoids](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard) and self-driving systems, starts its journey in a simulator. It's the foundation underneath most of [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai), and the reason picking the [right simulator](https://www.godrift.ai/blogs/best-robot-simulators-ros2)matters so much for anyone building robots.

## FAQ

1. **Why do robots train in simulation first?** Simulation gives robots a safe, fast, and cheap place to practice. Engineers can test controllers and train AI without risking expensive hardware, and a robot can repeat a task thousands of times far faster than real time, so it arrives at real-world testing having already made most of its mistakes virtually.
2. **What is sim-to-real in robotics?** Sim-to-real is the process of transferring a controller or AI policy trained in simulation onto a real robot. The challenge is that simulation never perfectly matches reality, so behavior that works in sim has to hold up against real-world friction, contact, and sensor noise.
3. **Why not just train robots in the real world?** Real-world training is slow, expensive, and risky. Every attempt runs in real time and often needs a manual reset, and a mistake can damage costly hardware. Simulation removes those limits, so most development happens virtually before moving to real machines.
4. **What is the sim-to-real gap?** The sim-to-real gap is the difference between how a robot behaves in simulation versus reality. Small mismatches in physics, like friction or contact dynamics, can cause a controller that worked perfectly in simulation to fail on real hardware, and closing that gap is a major focus of robotics research.
5. **How do you build a robot simulation?** You create a virtual model of the robot and its environment in a physics simulator, then test and train on it before deploying to hardware. Tools like [Drift](https://link.godrift.ai/simreal) generate ready-to-run robot simulations from a natural-language prompt, which removes much of the manual setup that this kind of virtual practice normally requires.

## Related reading

- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# Simulating Autonomous Drone Flight With the Skydio X2 in MuJoCo

*2026-08-08 · Drift Team · Product · 5 min*

> Robots fly too. Drift builds a MuJoCo simulation where the Skydio X2 drone takes off, follows a set of waypoints, and lands autonomously, all from one prompt.

<https://godrift.ai/blogs/drone-flight-simulation-mujoco>

---
Robots don't have to stay on the ground. The same simulation tools that build ground robots can put a drone in the air and fly it on its own.

<figure data-type="youtube-embed" data-yt-id="9ZL9yxqk9kw" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/9ZL9yxqk9kw?autoplay=1&mute=1&loop=1&playlist=9ZL9yxqk9kw&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough moves into the air, building an autonomous drone flight in MuJoCo with the Skydio X2, a real quadcopter, and letting [Drift](https://link.godrift.ai/dro-ne) generate the whole takeoff-to-landing sequence from one prompt. It's the same simulation workflow used for [ground robots and manipulators](https://www.godrift.ai/blogs/quadruped-simulation-mujoco), pointed upward.

## Why drone flight belongs in a physics simulator?

&nbsp;

Flying a real drone to test new behaviour is risky and expensive. A crash can destroy the hardware, and every failed attempt costs time and battery. Simulation removes that cost, so you can try a flight path a hundred times, break it safely, and refine it before anything leaves the ground.

&nbsp;

Drones are also a natural fit for a physics engine, because flight is all about dynamics: thrust, gravity, momentum, and how the aircraft responds to its own control inputs. [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco) simulates exactly those physics, and it ships with community models for aerial vehicles, which is what makes a realistic drone simulation possible without building the aircraft from scratch.

## Meet the Skydio X2 drone

&nbsp;

The Skydio X2 is a compact autonomous quadcopter made by the American company Skydio, known for AI-driven flight and 360-degree obstacle avoidance that lets it navigate without GPS. It's used for enterprise inspection, public safety, and defense, exactly the kind of missions where a drone has to fly itself reliably.

&nbsp;

For simulation, the useful detail is that there's an official [Skydio X2 model in the MuJoCo Menagerie](https://github.com/google-deepmind/mujoco_menagerie/tree/main/skydio_x2), provided by Skydio itself. That means the flight in this walkthrough runs on a realistic, community-standard model of a real drone, not a rough stand-in.

## What we asked Drift to build?

&nbsp;

After creating a new [Drift](https://link.godrift.ai/dro-ne) project, we described the flight in a single prompt: create a MuJoCo simulation where the Skydio X2 autonomously flies through a sequence of predefined waypoints and returns to its starting position.

&nbsp;

The prompt describes the mission, take off, hit a series of waypoints, come home, rather than the low-level control math to achieve it. That's the point of task-level prompting: you specify the flight you want and let Drift generate the simulation and control to fly it. (New to the simulator? Here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco) first.)

## Watching the drone fly the waypoint course

&nbsp;

We launch the simulation by running the generated Python file, and the flight plays out on its own. The drone lifts off, climbs to its target height, and begins following the programmed path from waypoint to waypoint, then returns to its starting position for landing.

&nbsp;

Everything runs autonomously from takeoff to touchdown. There's no manual piloting: the drone holds its altitude, tracks each waypoint in sequence, and comes home without intervention. Watching a clean waypoint flight is the clearest way to confirm the basic control loop works before you add anything harder on top.

## Where autonomous drone flight goes from here?

&nbsp;

A waypoint loop is where autonomous flight begins. Everything more advanced builds on a drone that can already fly a known path reliably, so a clean trajectory like this one is the groundwork for the rest.

&nbsp;

From here you can work toward obstacle avoidance, so the drone reroutes around things in its way, visual navigation using its cameras instead of fixed coordinates, and fully autonomous missions that string many behaviors together. With Drift generating the simulation, you can move straight to those problems instead of setting up the aircraft and its controller by hand. Change the waypoints, raise the altitude, or tighten the path and see how the flight holds up. The full walkthrough is in the video above.

## FAQ

1. **Can you simulate a drone in MuJoCo?** Yes. MuJoCo simulates the flight dynamics of aerial vehicles, and its community model collection includes drones such as the Skydio X2. That makes it possible to build a realistic autonomous flight simulation, from takeoff through a waypoint path to landing, without modeling the aircraft from scratch.
2. **What is the Skydio X2?** The Skydio X2 is a compact autonomous quadcopter from Skydio, an American drone company. It's known for AI-driven flight and 360-degree obstacle avoidance that let it operate without GPS, and it's used for inspection, public safety, and defense. An official model of it is available in the MuJoCo Menagerie.
3. **What is waypoint navigation for a drone?** Waypoint navigation is flying through a predefined sequence of positions in order. The drone takes off, travels to each waypoint in turn, and can return to its start. It's the foundational form of autonomous flight and the basis for more complex missions.
4. **Why simulate drone flight instead of testing on real hardware?** Testing real drones is costly and risky, since a crash can destroy the aircraft. Simulation lets you develop and fail safely and cheaply, running a flight path many times and refining the control before flying real hardware.
5. **How does ****[Drift](https://link.godrift.ai/dro-ne)**** build the drone simulation?** Drift takes a single natural-language prompt describing the flight, then generates the MuJoCo simulation and the control needed for the Skydio X2 to take off, follow the waypoints, and land autonomously, so you can launch it and watch the full flight without hand-coding the setup.

## Related reading

- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [Autonomous Maze Navigation in MuJoCo](https://www.godrift.ai/blogs/maze-navigation-mujoco)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# How Robots Are Reshaping 5 Everyday Industries

*2026-08-06 · Drift Team · Research · 4 min*

> Robotics is already reshaping manufacturing, warehousing, healthcare, agriculture, and construction. Here's how robots are changing each of these industries.

<https://godrift.ai/blogs/industries-changed-by-robotics>

---
Say "robot" and most people picture a humanoid walking around. The biggest impact of robotics is already here, quietly running the industries you rely on every day.

<figure data-type="youtube-embed" data-yt-id="9rP15AHaY6g" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/9rP15AHaY6g?autoplay=1&mute=1&loop=1&playlist=9rP15AHaY6g&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

When you hear the word robot, you probably picture a humanoid walking around. The most important industries changed by robotics look nothing like that. The real impact is already happening behind the scenes, in the factories, warehouses, hospitals, farms, and building sites we depend on. Here are five of them.

## 1. Manufacturing, where industrial robots got their start

&nbsp;

It starts in manufacturing, the industry that has used robots the longest. Robotic arms weld, assemble, paint, and inspect products with a precision and consistency people can't match over a long shift.

&nbsp;

This is what keeps factories producing everything from cars to smartphones around the clock. There were about [4.66 million industrial robots](https://ifr.org/worldrobotics/report-2025) operating in factories worldwide in 2024, according to the International Federation of Robotics. The arms doing this work are the industrial cousins of the [pick-and-place manipulation](https://www.godrift.ai/blogs/pick-and-place-mujoco) you can build in simulation, running the same grasp-and-place fundamentals at high speed and scale.

## 2. Warehousing and the machines behind fast delivery

&nbsp;

Once products leave the factory, another set of robots takes over. In warehouses, autonomous robots move inventory, carry entire shelves to workers, and sort packages toward the right destination.

&nbsp;

This is what keeps millions of deliveries moving every single day, and it's one of the fastest-growing areas of robotics. We broke down the different machines involved in [how warehouse robots actually work](https://www.godrift.ai/blogs/how-warehouse-robots-work), from mobile robots to picking arms to sorting systems, if you want the full picture.

## 3. Healthcare, from the operating room to the ward

&nbsp;

Robotics is also transforming healthcare, in two quite different ways. Surgical robots help doctors perform delicate procedures with steadier, more precise movements than a human hand alone, often through smaller incisions.

&nbsp;

Away from the operating room, rehabilitation robots help patients recover mobility, and hospital service robots ferry supplies and medications around the building. Both reduce the physical workload on medical staff and free them to focus on care, which matters more as healthcare systems stretch to meet demand.

## 4. Agriculture and the robots working the fields

&nbsp;

Out on farms, robots are changing how food is grown. They can monitor crop health from the field, harvest produce, and automate the repetitive, labor-intensive tasks that farms have long struggled to staff.

&nbsp;

The payoff is efficiency and sustainability: targeting water and treatment only where crops need it, harvesting at the right moment, and working long hours in conditions that are hard on people. Navigating an open, uneven field is its own challenge, closely related to [how robots navigate](https://www.godrift.ai/blogs/how-robots-navigate) any unstructured space.

## 5. Construction and robots on the building site

&nbsp;

Even construction, one of the least automated industries, is starting to adopt robotics. Autonomous rovers survey sites and track progress, robotic arms lay bricks, and large-scale 3D printers extrude concrete structures layer by layer.

&nbsp;

On a job site full of hazards, that shift makes construction both safer and faster, taking people out of the most dangerous and repetitive work. It's an early frontier, but a fast-moving one.

## Why this matters more than the humanoid hype

&nbsp;

From building our products to delivering them, supporting our doctors, growing our food, and constructing our cities, robotics is already reshaping the world around us. It just doesn't look like the humanoid in the headlines, at least not yet.

&nbsp;

What all five industries share is a common toolkit underneath: perception, navigation, and manipulation, developed and tested in [simulation](https://www.godrift.ai/blogs/best-robot-simulators-ros2) before robots are trusted with real work. As that toolkit improves, robotics reaches further into everyday life, and we're only getting started.

## FAQ

1. **Which industries are most affected by robotics?** Manufacturing, warehousing and logistics, healthcare, agriculture, and construction are among the most affected. Manufacturing has used robots the longest, while warehousing is one of the fastest-growing, and healthcare, agriculture, and construction are adopting robotics rapidly.
2. **How is robotics used in manufacturing?** Robotic arms handle welding, assembly, painting, and inspection with high precision and consistency, operating around the clock. This lets factories mass-produce goods from cars to electronics at a scale and reliability that manual labor alone can't sustain.
3. **How are robots used in healthcare?** In two main ways: surgical robots help doctors perform precise, minimally invasive procedures, while service and rehabilitation robots move supplies, support patient recovery, and reduce the physical workload on medical staff.
4. **How is robotics used in agriculture?** Agricultural robots monitor crop health, harvest produce, and automate repetitive field tasks. They improve efficiency and sustainability by targeting resources like water and treatment precisely and by handling labor-intensive work that is hard to staff.
5. **How are these industrial robots developed and tested?** Most are developed and validated in simulation first, where their perception, navigation, and manipulation can be tested safely and cheaply before deployment. Tools like [Drift](https://link.godrift.ai/h-care) generate the simulated robots and environments used for that testing, while the control software is built on top.

## Related reading

- [How Warehouse Robots Actually Work](https://www.godrift.ai/blogs/how-warehouse-robots-work)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)


# Building a Bimanual Manipulation Scene With ALOHA in MuJoCo

*2026-08-05 · Drift Team · Product · 5 min*

> Bimanual manipulation means using two arms together. Drift builds a MuJoCo tabletop scene with the ALOHA dual-arm robot, a lunchbox, and food from one prompt.

<https://godrift.ai/blogs/bimanual-manipulation-aloha-mujoco>

---
Most everyday tasks need two hands. Packing a lunchbox, opening a jar, folding a shirt. That's why a lot of household robotics starts with two arms.

<figure data-type="youtube-embed" data-yt-id="EqzBZxkfZ8k" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/EqzBZxkfZ8k?autoplay=1&mute=1&loop=1&playlist=EqzBZxkfZ8k&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Most household robots need two arms to handle everyday tasks. A single arm can pick something up, but packing a lunchbox or steadying an object while working on it takes two limbs cooperating. This walkthrough builds a bimanual manipulation scene with the ALOHA robot in MuJoCo, using [Drift](https://link.godrift.ai/manual-bi) to generate the whole tabletop setup from one prompt.

## Why everyday tasks need two arms?

&nbsp;

Watch how you pack a lunchbox and you'll notice your hands rarely work in isolation. One holds the box open while the other places food inside. One steadies, the other acts. That coordination between two arms is called bimanual manipulation, and it's what a huge share of real household and workshop tasks actually require.

&nbsp;

A single arm hits a wall fast on these jobs. It can't hold and place at the same time, so the moment a task needs one hand to stabilize while the other manipulates, you need a second arm. That's a real step up in difficulty from the [single-arm pick-and-place](https://www.godrift.ai/blogs/pick-and-place-mujoco) we built earlier, because now the two arms have to coordinate without colliding or working against each other.

## Meet the ALOHA dual-arm robot

&nbsp;

[ALOHA](https://aloha-2.github.io/) (A Low-cost Open-source Hardware System for Bimanual Teleoperation) is an open-source two-armed robot platform from Stanford, built to make bimanual manipulation research accessible. It pairs two arms over a shared workspace so a robot, or a human teleoperating it, can perform tasks that need both hands.

&nbsp;

It's become a standard testbed for two-armed manipulation, and there's an official MuJoCo model of the ALOHA 2 version, which is exactly why it's a natural choice for a simulated bimanual scene. If a robot can learn to coordinate both ALOHA arms in simulation, that skill points straight at practical household tasks.

## What we asked [Drift](https://link.godrift.ai/manual-bi) to build?

&nbsp;

After creating a new [Drift](https://link.godrift.ai/manual-bi) project, we described the whole scene in a single prompt: generate a workbench with an open lunchbox and food items, and place the ALOHA robot ready for future bimanual manipulation.

&nbsp;

The prompt describes the finished setup, a workbench, an open lunchbox, food to pack, and the dual-arm robot positioned to work, rather than listing coordinates for each object. That's the point of task-level prompting: you describe the scene you want and let [Drift](https://link.godrift.ai/manual-bi) arrange it. New to the simulator? Here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco) first.

## How Drift assembles the tabletop scene?

&nbsp;

From that single prompt, [Drift](https://link.godrift.ai/manual-bi) generates the simulation files and assembles them into a ready-to-run MuJoCo scene. The workbench, the open lunchbox, and the food items are placed on the table, with the ALOHA dual-arm robot positioned alongside them and set up for manipulation.

&nbsp;

What would normally be a session of scene authoring, importing the robot, placing the props, and configuring the world, is handled in one step. It's the same task-level scene generation behind [building an office environment](https://www.godrift.ai/blogs/office-environment-mujoco) and a [kitchen scene](https://www.godrift.ai/blogs/kitchen-simulation-stretch-3-mujoco), pointed at a two-armed tabletop task.

## What comes after the scene is built?

&nbsp;

The scene loads with the workbench, lunchbox, and food already in place, alongside the ALOHA dual-arm robot, ready to work. But building the task is only half the challenge.

&nbsp;

The harder half is next: teaching both arms to work together to actually pack the lunchbox, one arm holding it steady while the other places each item. That coordination, timing two arms so they cooperate instead of colliding, is where bimanual manipulation gets genuinely difficult, and it's the kind of behavior researchers train on platforms exactly like ALOHA. With the environment generated by Drift, you can move straight to that problem instead of spending your time building the table. The full walkthrough is in the video above.

## FAQ

1. **What is bimanual manipulation?** Bimanual manipulation is a robot using two arms together to perform a task, such as one arm holding an object steady while the other works on it. Many everyday tasks, like packing a container or opening a jar, require this two-armed coordination that a single arm can't do.
2. **What is the ALOHA robot?** ALOHA (A Low-cost Open-source Hardware System for Bimanual Teleoperation) is an open-source dual-arm robot platform from Stanford, designed to make two-armed manipulation research affordable. It's widely used to collect demonstrations and train manipulation policies, and the ALOHA 2 version has an official MuJoCo simulation model.
3. **Why is bimanual manipulation harder than using one arm?** Two arms have to coordinate in the same workspace without colliding, and often one arm must stabilize an object while the other manipulates it. That coordination, timing, and shared-space planning make it significantly more complex than single-arm pick-and-place.
4. **How do you build a bimanual scene in MuJoCo?** You define a scene with a work surface, the objects for the task, and a dual-arm robot model, positioned so both arms can reach the workspace. In this walkthrough, [Drift](https://link.godrift.ai/manual-bi) generates that entire tabletop scene with the ALOHA robot from a single prompt.
5. **How does ****[Drift](https://link.godrift.ai/manual-bi)**** build the ALOHA scene?** [Drift](https://link.godrift.ai/manual-bi) takes one natural-language prompt describing the workbench, objects, and robot, then generates the simulation files and assembles them into a ready-to-run MuJoCo scene with the ALOHA dual-arm robot in place, so you can launch it and move on to the manipulation task.

## Related reading

- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [Building a Kitchen Simulation With the Hello Robot Stretch 3 in MuJoCo](https://www.godrift.ai/blogs/kitchen-simulation-stretch-3-mujoco)
- [Build a Realistic Office Environment in MuJoCo in One Prompt](https://www.godrift.ai/blogs/office-environment-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# Gemini Robotics 2 and Whole-Body Control for Humanoid Robots

*2026-08-04 · Drift Team · Research · 5 min*

> Gemini Robotics 2 is Google DeepMind's new AI model suite giving humanoid robots whole-body control, five-finger dexterity, and multi-robot task planning.

<https://godrift.ai/blogs/gemini-robotics-2-explained>

---
Google DeepMind's first robotics model taught robots to manipulate objects on a table. Gemini Robotics 2 teaches them to use their whole body to get there.

<figure data-type="youtube-embed" data-yt-id="Z1p_MoycJtU" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/Z1p_MoycJtU?autoplay=1&mute=1&loop=1&playlist=Z1p_MoycJtU&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Google DeepMind has [unveiled Gemini Robotics 2](https://deepmind.google/blog/gemini-robotics-2-brings-whole-body-intelligence-to-robots/), and it's a notable jump for humanoid robots. The first version taught robots how to manipulate objects on a tabletop. This release extends that to the whole body, so a robot can move through a space and act on it as one continuous behavior. It's built on the vision-language-action approach that's [reshaping robotics](https://www.godrift.ai/blogs/ai-models-changing-robotics), now applied to entire humanoids rather than just arms.

## Whole-body control, from feet to fingertips

&nbsp;

Think about picking up a watering can from a low shelf. You don't just move your arm. You walk over, bend down, reach out, and grasp it, all as one fluid motion. Earlier Gemini Robotics models controlled only a robot's upper body for tabletop work. Gemini Robotics 2 plans that entire sequence, controlling the robot from its feet to its fingertips.

&nbsp;

In DeepMind's demo, Apptronik's Apollo 2 humanoid is told to "put the watering can into the green bin on the bottom shelf." The robot walks to the object, picks it up, steps over to the shelves, and places it, coordinating balance, locomotion, and manipulation together. That whole-body coordination is exactly [what makes humanoids so hard](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard), and getting it into a single model is the headline advance here.

## Five-finger dexterity and where it still falls short

&nbsp;

Movement is only part of the story. Once a robot reaches an object, it still has to interact with it, which is the harder half. Gemini Robotics 2 can drive a five-fingered, 22-degree-of-freedom hand (Apollo 2's SharpaWave hand) to do delicate tasks like tying a trash bag, sealing a ziplock bag, and handling a light bulb.

&nbsp;

It's worth being honest about the numbers, because they show how hard dexterity remains, which is a theme in [why robot hands are so hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard). In DeepMind's own reporting, the model unscrewed a bulb successfully about 92% of the time but managed only 36% when screwing one back in, with tying a trash bag around 44% and sealing a bag near 40%. It does noticeably better with simpler two-finger grippers on a Franka Duo, scoring roughly 74% on general pick-and-place and about 90% on precise insertion. Five-finger manipulation is progressing, but it's clearly the frontier.

## Longer tasks and multiple robots with Gemini Robotics ER 2

&nbsp;

Google also introduced Gemini Robotics ER 2, an embodied reasoning model that acts as the robot's high-level brain. Rather than thinking one step ahead, it plans longer tasks that can run for several minutes and hundreds of decisions, tracks progress through them, and knows when a task starts and ends.

&nbsp;

It also enables multi-robot collaboration, letting different types of robots communicate and coordinate on a workflow that a single machine couldn't finish alone, like a multi-step cleanup or organizing a garage. In practice, ER 2 plans and supervises while the vision-language-action model executes the motion, and it can self-correct partway through when a step fails.

## On-device models that run without the cloud

&nbsp;

DeepMind also released Gemini Robotics On-Device 2, a version optimized to run locally on the robot itself. That matters because many real-world settings can't rely on a constant cloud connection, and network latency can break a delicate, multi-step task.

&nbsp;

Running on-device makes the model easier to deploy across different robot platforms, and DeepMind says it can adapt to a completely new robot body with only a few hours of training data. The models have been shown across several embodiments, from the Apollo 2 humanoid to a Franka arm, using the same underlying approach.

## What Gemini Robotics 2 gets right and what it doesn't?

&nbsp;

Gemini Robotics 2 is more than a single model release. It brings movement, manipulation, and planning together in one system: the VLA handles motor control, ER 2 handles reasoning and coordination, and the on-device model handles deployment. DeepMind also paired it with a new safety benchmark, ASIMOV-Agentic, aimed at getting robots to refuse unsafe actions and stop safely when a person is nearby.

&nbsp;

The honest picture is a real step forward with clear limits, whole-body tasks and gripper work are solid, five-finger dexterity and movement speed still have a long way to go. But combining all three capabilities in one system moves robots closer to handling real-world tasks from start to finish, which is the whole promise of [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai).

## FAQ

1. **What is Gemini Robotics 2?** Gemini Robotics 2 is a suite of three AI models from Google DeepMind for controlling robots. It includes a core vision-language-action model for whole-body motor control, Gemini Robotics ER 2 for reasoning and multi-step planning, and Gemini Robotics On-Device 2 for running locally on robot hardware.
2. **What is new in Gemini Robotics 2 compared to the first version?** The original Gemini Robotics controlled a robot's upper body for tabletop manipulation. Gemini Robotics 2 adds whole-body control (walking, crouching, and reaching as one motion), stronger five-finger dexterity, longer multi-step task planning, multi-robot coordination, and on-device operation.
3. **What is Gemini Robotics ER 2?** Gemini Robotics ER 2 is an embodied reasoning model that acts as a robot's high-level brain. It plans multi-minute tasks involving hundreds of decisions, tracks task progress, communicates with people, and coordinates multiple robots working together. It's available in preview on Google AI Studio.
4. **How good is Gemini Robotics 2 at dexterous manipulation?** It's capable but uneven. On five-finger hands it does well at some tasks (around 92% unscrewing a bulb) and poorly at others (about 36% screwing one in). It performs more reliably with two-finger grippers, scoring roughly 74% on pick-and-place. Fine multi-finger dexterity remains the hardest part.
5. **Can you experiment with robotics AI like this in simulation?** Yes. Models like these are developed and validated heavily in simulation before running on real robots. Tools like [Drift](https://link.godrift.ai/gemini-1) generate the simulated robots and environments used for that testing, so you can prototype navigation and manipulation behaviours virtually before deploying to hardware.

## Related reading

- [5 AI Models Changing Robotics Right Now](https://www.godrift.ai/blogs/ai-models-changing-robotics)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [Why Robot Hands Are So Hard](https://www.godrift.ai/blogs/why-robot-hands-are-hard)


# Building a Kitchen Simulation With the Hello Robot Stretch 3 in MuJoCo

*2026-08-01 · Drift Team · Product · 5 min*

> A kitchen simulation gives a household robot a place to learn. Drift builds a MuJoCo kitchen scene with the Hello Robot Stretch 3 in it from one prompt.

<https://godrift.ai/blogs/kitchen-simulation-stretch-3-mujoco>

---
Household robots need more than smart software. They need realistic places to practice, and a kitchen is one of the hardest rooms in the house.

<figure data-type="youtube-embed" data-yt-id="j_Scw27NNqw" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/j_Scw27NNqw?autoplay=1&mute=1&loop=1&playlist=j_Scw27NNqw&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Smart software alone won't get a household robot very far. It also needs realistic environments to learn and operate in, and a home kitchen, full of counters, appliances, and clutter, is one of the most demanding. This walkthrough builds a kitchen simulation with the Hello Robot Stretch 3 in MuJoCo, using [Drift](https://link.godrift.ai/kit) to generate the whole scene and drop the robot in, from one prompt.

## Why household robots start in the kitchen?

&nbsp;

A kitchen is a genuinely hard environment for a robot. It's full of surfaces at different heights, tight gaps between counters and islands, objects of every shape, and tasks that mix moving around with reaching and grasping. If a robot can operate in a kitchen, it can handle a lot of the rest of a home.

&nbsp;

That's exactly why it's a good place to test in simulation first. A [realistic simulated environment](https://www.godrift.ai/blogs/office-environment-mujoco) lets you iterate on navigation and manipulation safely and cheaply, long before risking a real robot in a real room. Getting the environment right is the foundation everything else builds on.

## Meet the Hello Robot Stretch 3

&nbsp;

The [Hello Robot Stretch 3](https://hello-robot.com/stretch-3-whats-new) is an open-source mobile manipulator built specifically for human spaces like homes. It pairs a compact wheeled base with a distinctive telescoping arm and a gripper, so it can drive up to a counter, extend its arm out over it, and pick something up, all with a footprint small enough to fit through the clutter of a real kitchen.

&nbsp;

That combination of mobility and manipulation is what makes it interesting for household robotics, and what makes it worth simulating. To do anything useful, it has to both navigate the room and act on objects in it, the two halves of the problem this scene is set up to test.

## What we asked Drift to build?

&nbsp;

After initializing a new [Drift](https://link.godrift.ai/kit) project, we gave it one instruction: create a realistic kitchen environment in MuJoCo and place the Hello Robot Stretch 3 inside it, ready for future navigation and household manipulation tasks.

&nbsp;

The prompt describes the end state, a furnished kitchen with the robot positioned and ready, rather than spelling out where each counter and appliance goes. That's the point of working at the task level: you describe the scene you want and let [Drift](https://link.godrift.ai/kit) assemble it. New to the simulator? Here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco) first.

## How Drift assembles the scene?

&nbsp;

From that single prompt, [Drift](https://link.godrift.ai/kit) generates the simulation files and puts everything together into a ready-to-run MuJoCo scene. The kitchen layout, the objects in it, and the Stretch 3 are placed and wired into one launchable file, positioned so the robot is set up for navigation and manipulation from the start.

&nbsp;

What would normally be a long session of scene authoring, placing furniture, importing the robot model, and configuring the world, is handled in one step. It's the same task-level scene generation behind [building an office environment](https://www.godrift.ai/blogs/office-environment-mujoco), pointed at a harder, more cluttered room.

## Driving the Stretch 3 in the simulated kitchen

&nbsp;

We launch the simulation and the kitchen loads with the Stretch 3 standing inside it. From here, you can already explore what the robot can do.

&nbsp;

You can drive its mobile base around the room, extend the telescoping arm out toward a counter, and open and close the gripper, all inside a realistic household setting. Being able to move the base, arm, and gripper by hand first is how you build a feel for the robot's reach and limits before you write any autonomous behaviour. It's the same reason we [explored the Franka Panda arm manually](https://www.godrift.ai/blogs/pick-and-place-mujoco) before automating it.

## Where a household robot simulation leads next?

&nbsp;

A loaded kitchen with a working robot in it is the starting point for real household robotics. From here you can develop navigation around the counters, manipulation tasks like opening drawers or picking up items, and eventually full routines that combine both.

&nbsp;

Building realistic simulation environments is the first step toward capable household robots, because everything, the navigation, the grasping, the failures, can be worked out in simulation before moving to the real world. Drive the base, extend the arm, try reaching an object, and start building from there. The full walkthrough is in the video above.

## FAQ

1. **What is the Hello Robot Stretch 3?** The Stretch 3 is an open-source mobile manipulator from Hello Robot, designed for human environments like homes. It combines a compact wheeled base with a telescoping arm and gripper, letting it both navigate a room and reach and grasp objects, and it supports ROS 2 and Python.
2. **Why simulate a household robot in a kitchen?** A kitchen combines everything hard about home robotics: varied surface heights, tight spaces, many object types, and tasks that mix navigation with manipulation. Testing in a simulated kitchen lets you develop and fail safely and cheaply before running on a real, expensive robot.
3. **How do you build a kitchen simulation in MuJoCo?** You define a scene with the kitchen layout, furniture, and objects, then place a robot model inside it, in a MuJoCo scene file. In this walkthrough, [Drift](https://link.godrift.ai/kit) generates the full kitchen and positions the Stretch 3 inside it from a single prompt, producing a ready-to-run scene.
4. **What can you do with the Stretch 3 in simulation?** Once the scene loads, you can drive the mobile base, extend and retract the telescoping arm, and operate the gripper. This lets you explore the robot's reach and behavior, and build toward autonomous navigation and manipulation tasks.
5. **How does Drift build the kitchen scene?** [Drift](https://link.godrift.ai/kit) takes a single natural-language prompt describing the environment and robot, then generates the simulation files and assembles them into a ready-to-run MuJoCo scene with the Hello Robot Stretch 3 placed inside, so you can launch and interact with it right away.

## Related reading

- [Build a Realistic Office Environment in MuJoCo in One Prompt](https://www.godrift.ai/blogs/office-environment-mujoco)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# How Warehouse Robots Actually Work?

*2026-07-31 · Drift Team · Research · 5 min*

> Warehouse robots move shelves, pick items, sort packages, and track inventory as one coordinated system. Here's how each type works and why they run together.

<https://godrift.ai/blogs/how-warehouse-robots-work>

---
Ever wondered how a company like Amazon processes millions of packages a day? Behind the people is a coordinated team of robots, each doing one job well.

<figure data-type="youtube-embed" data-yt-id="Fm5ne_QLOwo" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/Fm5ne_QLOwo?autoplay=1&mute=1&loop=1&playlist=Fm5ne_QLOwo&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Understanding how warehouse robots work means seeing them as a team: several specialized machines, each handling one stage of the journey from shelf to shipping dock. Amazon [crossed one million deployed robots](https://www.aboutamazon.com/news/operations/amazon-million-robots-ai-foundation-model) in 2025, roughly one robot for every worker, which is the scale that makes same-day delivery possible. Here's what each type does, and why they only matter together.

## Mobile robots that bring the shelves to workers

&nbsp;

It starts with autonomous mobile robots. In a traditional warehouse, workers walk miles a day to fetch items. These robots flip that around: instead of people going to the shelves, the robots carry entire shelving units, called pods, directly to a picking station.

&nbsp;

That single change saves an enormous amount of time, cuts the walking, and keeps orders flowing continuously. The robots navigate the floor and coordinate through a central system that sequences their routes and stops them colliding, which is the same core problem behind [how any robot navigates](https://www.godrift.ai/blogs/how-robots-navigate) a shared space. Amazon's Proteus is one example of a fully autonomous version that moves among people rather than in a caged-off zone.

## Robotic arms that pick the right item

&nbsp;

Once a shelf arrives, the harder problem begins: actually picking the correct item out of a mixed bin. That's the job of robotic arms.

&nbsp;

Using cameras and AI, these arms identify a specific product, work out how to grasp it without damaging it, and place it into a bin for the next step. Amazon's Sparrow arm, for instance, uses computer vision and suction to handle a large share of its product catalog. This is genuine [pick-and-place manipulation](https://www.godrift.ai/blogs/pick-and-place-mujoco), the same challenge you can build and test in simulation, running at industrial scale and speed.

## Sorting systems that route every package

&nbsp;

Picking an item is only half the job. It still has to reach the right customer. Automated sorting systems handle that stage.

&nbsp;

As packages travel through the facility, sorters scan each one, read its destination, and route it toward the correct truck, chute, or delivery lane. At peak volume this happens thousands of times an hour, far faster and more consistently than manual sorting, and it's what keeps the right box heading to the right doorstep.

## Inspection robots that keep inventory accurate

&nbsp;

Meanwhile, another group of robots is quietly checking stock. Some move through the aisles scanning shelves, while others monitor inventory levels and flag missing or misplaced items before they turn into a delayed order.

&nbsp;

This is the unglamorous layer that keeps the rest honest. If the system thinks an item is in a location it isn't, every downstream step fails, so continuous inspection is what keeps the picking and sorting robots working against accurate data.

## Why the robots only work as a system?

&nbsp;

The interesting part is that none of these robots works alone. Navigation, picking, sorting, and inventory are separate jobs handled by separate machines, but a central coordination layer ties them into one flow. A shelf is delivered, an arm picks from it, a sorter routes the result, and inspection keeps the inventory it all relies on up to date.

&nbsp;

That orchestration is the real technology. As a fleet grows from dozens of robots to thousands, the hard problem shifts from any single robot to coordinating the whole fleet, deciding which robot goes where, how they avoid each other, and how work is sequenced so throughput holds through a holiday peak. It's the warehouse-scale version of the [sense, think, act loop](https://www.godrift.ai/blogs/what-is-a-robot) every robot runs, played out across a whole building.

## What warehouse automation actually changes?

&nbsp;

Warehouse robots don't target one worker's job. What they replace is the thousands of repetitive trips, scans, and movements that happen every hour, the walking, the lifting, the manual sorting, the stock counts. Humans increasingly handle the judgment calls and exceptions while robots absorb the repetition.

&nbsp;

That division is what lets a modern fulfillment center deliver millions of orders with speed that manual operations can't match. And nearly all of it, the navigation, the grasping, the coordination, is developed and tested in [simulation](https://www.godrift.ai/blogs/best-robot-simulators-ros2) long before a robot touches a real warehouse floor.

## FAQ

1. **How do warehouse robots work?** Warehouse robots divide fulfillment into stages handled by specialized machines. Mobile robots bring shelves to workers, robotic arms pick items using cameras and AI, automated sorters route packages to the right destination, and inspection robots track inventory. A central system coordinates them into one continuous flow.
2. **What types of robots are used in warehouses?** The main types are autonomous mobile robots (which move shelves or totes), robotic picking arms (which grasp individual items), automated sortation systems (which route packages), and inspection or inventory robots (which scan shelves and track stock). Some warehouses are also piloting humanoids.
3. **How many robots does Amazon use?** Amazon passed one million deployed robots across its fulfillment network in 2025, approaching roughly one robot per human worker. Its systems include Proteus mobile robots, Sparrow and Robin picking arms, and Cardinal sortation, among others.
4. **Do warehouse robots replace human workers?** They automate repetitive physical tasks, the trips, lifts, scans, and sorts, rather than replacing entire roles one for one. Workers increasingly focus on exceptions, judgment, and oversight, though the growing scale of automation is reshaping warehouse jobs significantly.
5. **How are warehouse robots developed and tested?** Their navigation, grasping, and coordination are developed largely in simulation, where behaviors can be tested safely and at scale before deployment. Tools like [Drift](https://link.godrift.ai/ware) generate the simulated robots and environments used for that testing, while the control and coordination software is built on top.

## Related reading

- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)


# Stacking Three Cubes With a Franka Panda in MuJoCo

*2026-07-29 · Drift Team · Product · 6 min*

> Cube stacking is a benchmark robot manipulation task. Drift generates an autonomous sequence that makes a Franka Panda stack three cubes into a tower in MuJoCo.

<https://godrift.ai/blogs/cube-stacking-franka-mujoco>

---
Picking up one cube is a good start. Getting an arm to stack three into a tower that doesn't fall over is a much better test of what it can really do.

<figure data-type="youtube-embed" data-yt-id="NsaPfdvnBw8" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/NsaPfdvnBw8?autoplay=1&mute=1&loop=1&playlist=NsaPfdvnBw8&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Cube stacking is one of the oldest and most useful tests in robotic manipulation. It looks simple, yet it packs in perception, precise grasping, and, above all, placement accuracy that compounds with every block. This walkthrough runs that test on a Franka Panda arm in MuJoCo, using [Drift](https://link.godrift.ai/cube) to generate the entire stacking sequence from one prompt instead of hand-coding it.

## Why cube stacking is a genuine test of precision?

&nbsp;

A single pick-and-place is forgiving. If the arm sets a cube down a few millimeters off target, it still lands flat on the table and the task counts as done. Nothing depends on it.

&nbsp;

Stacking removes that safety net. Each cube becomes the foundation for the next, so errors don't just occur, they accumulate. Place the first cube slightly crooked and the second sits crooked on top of it. Add a third and a small early error can topple the whole tower. To succeed, every placement has to be accurate enough that the next cube has a stable, level surface to rest on. That is why stacking is a standard benchmark for grasping precision and repeatability, and why it's a clear step up from the [single automated pick-and-place](https://www.godrift.ai/blogs/automate-pick-and-place-franka-mujoco) we built earlier in this series.

## What we asked Drift to build?

&nbsp;

Starting from the existing Franka Panda scene, we gave [Drift](https://link.godrift.ai/cube) one instruction: create a new script that makes the arm autonomously stack three cubes into a tower.

&nbsp;

Notice how little we had to specify. There's no list of grasp points, lift heights, or drop coordinates. The prompt describes the goal, a tower of three cubes, and leaves the sequence of operations to [Drift](https://link.godrift.ai/cube). That task-level prompting is the whole point of working this way: you say what you want, not how to move each joint. Starting fresh? Here's [how to build the pick-and-place scene](https://www.godrift.ai/blogs/pick-and-place-mujoco) with this arm, running in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco).

## How [Drift](https://link.godrift.ai/cube) turns one prompt into a stacking sequence?

&nbsp;

From that single prompt, [Drift](https://link.godrift.ai/cube) generates a new script and plans each pick-and-place operation the tower requires. It works out the order to move the cubes, where to grip each one, and where to release it so the stack grows cleanly rather than drifting off-center.

&nbsp;

Under the hood, this is three dependent pick-and-place routines chained together, the kind of thing that's tedious and error-prone to hand-tune, since a fix to one placement can throw off the next. [Drift](https://link.godrift.ai/cube) produces it as a ready-to-run script, which is the same task-level generation behind [automating a single pick-and-place](https://www.godrift.ai/blogs/automate-pick-and-place-franka-mujoco), now extended to a multi-step sequence.

## Watching the Franka Panda build the tower

&nbsp;

We run the new script and watch the arm work. It picks up each cube, carefully aligns it over the growing stack, and sets it down, one block at a time, until the tower stands complete.

&nbsp;

The alignment step is the part worth slowing down to watch. Before each release, the arm lines the cube up over the one beneath it, and that small correction is what keeps the tower stable as it climbs. What looks like the same motion repeated three times is really three precise, dependent placements, each one setting up the next.

## Where sequential manipulation shows up in the real world?

&nbsp;

Stacking three cubes is a small task with a big idea inside it: sequential manipulation, where a robot performs a series of steps and the success of each one depends on the accuracy of those before it.

&nbsp;

That pattern is everywhere in practical robotics. Assembling a product, packing a box, palletizing goods, and laying bricks on a construction site are all versions of the same challenge, perform precise operations in the right order, where each step builds on the last. A robot that can reliably stack cubes is demonstrating the core skill those jobs require. It's also a natural next step after giving an arm [vision through a camera](https://www.godrift.ai/blogs/add-camera-franka-mujoco), since real stacking eventually needs the robot to see where the blocks actually are.

## Push the tower higher and see where it breaks

&nbsp;

With Drift generating the sequence, you get a working stacking demo in one prompt, which frees you to experiment with the hard parts. Add a fourth and fifth cube and see where the tower starts to wobble. Tighten the spacing, change the cube sizes, or offset the target so the arm has to adapt. Each variation is a quick way to probe how much precision the sequence really has.

&nbsp;

Watch the full build in the video above, and if you're setting up from scratch, start with [installing MuJoCo](https://www.godrift.ai/blogs/install-mujoco) and [building the pick-and-place scene](https://www.godrift.ai/blogs/pick-and-place-mujoco).

## FAQ

1. **What is cube stacking in robotics?** Cube stacking is a benchmark manipulation task where a robot arm grasps several blocks and places them into a stable tower. It's widely used to test grasping precision and repeatability, because each placement has to be accurate enough to support the next block.
2. **Why is stacking harder than a single pick-and-place?** A single pick-and-place tolerates small errors, since the object only needs to land on a surface. Stacking chains placements together, so an error in one cube carries into the next and can topple the tower. Every step has to be precise enough to hold the one above it.
3. **What is sequential manipulation?** Sequential manipulation is performing a series of manipulation steps in a specific order, where the success of each step depends on the previous ones. Stacking, assembly, and packing are common examples, and they demand both precision and reliable repetition.
4. **Why is the Franka Panda used for stacking experiments?** The [Franka Emika Panda](https://github.com/google-deepmind/mujoco_menagerie) is a seven-joint collaborative arm widely used in research, with readily available simulation models. Its precision and popularity make it a common choice for pick-and-place and stacking tasks.
5. **How does ****[Drift](https://link.godrift.ai/cube)**** build the stacking sequence?** [Drift](https://link.godrift.ai/cube) takes a single natural-language prompt describing the goal, then generates a script that plans and executes each pick-and-place operation needed to build the tower, so the Franka Panda stacks the cubes autonomously without any hand-coded sequence.

## Related reading

- [Automating Pick and Place With the Franka Panda in MuJoCo](https://www.godrift.ai/blogs/automate-pick-and-place-franka-mujoco)
- [Adding Vision to a Franka Panda Robot in MuJoCo](https://www.godrift.ai/blogs/add-camera-franka-mujoco)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# The 5 Most Impressive Robot Dogs Right Now

*2026-07-28 · Drift Team · Research · 5 min*

> Robot dogs now inspect factories, patrol borders, and map mines. Here are 5 of the most impressive robot dogs, from Boston Dynamics Spot to the Unitree Go2.

<https://godrift.ai/blogs/most-impressive-robot-dogs>

---
Robot dogs have gone from research demos to real jobs. Some inspect factories, some cross dangerous terrain, and some are learning to work alongside people.

<figure data-type="youtube-embed" data-yt-id="PTwKsjmGHSU" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/PTwKsjmGHSU?autoplay=1&mute=1&loop=1&playlist=PTwKsjmGHSU&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

The legged-robot market topped $1.8 billion in 2025 and is projected to keep climbing, which is why these machines are showing up everywhere from power plants to construction sites. Here are five of the most impressive robot dogs you should know, counting down to the most popular of all.

## 1. Ghost Robotics Vision 60

&nbsp;

Let's start with the Vision 60 from Ghost Robotics. This one was built with defense and security in mind, which sets it apart from most quadrupeds.

&nbsp;

It's designed to patrol rough terrain, carry specialized equipment, and operate where it may be too dangerous to send a person. It's exceptionally rugged, can be submerged in water, and has even gained an optional arm for manipulation. Its whole purpose is to keep people out of harm's way by going where they can't safely follow.

## 2. Deep Robotics X30

&nbsp;

Where the Vision 60 focuses on security, the X30 from Deep Robotics is built for industry. It's a heavy, ruggedized quadruped, IP67-rated against dust and water, that inspects factories, power plants, and industrial sites.

&nbsp;

It climbs stairs, clears obstacles, and navigates complex environments while collecting inspection data, and it's already deployed in jobs like high-voltage station inspection and underground cable tunnels. The pitch is simple: rather than sending workers into hazardous areas, a company can send a robot first.

## 3. ANYbotics ANYmal

&nbsp;

Taking things further is ANYmal, developed out of ETH Zurich and commercialized by ANYbotics. This robot is known for its mobility in genuinely hard places.

&nbsp;

It can navigate mines, tunnels, and offshore facilities, creating detailed 3D maps of locations that are difficult or dangerous for humans to reach. It's also been engineered for hazardous industrial settings, including an explosion-proof version certified for use around flammable gases, which is why energy companies have been early adopters.

## 4. Boston Dynamics Spot

&nbsp;

Then there's Spot, the robot dog that introduced millions of people to modern robotics. Beyond the viral dance videos, Spot does serious work: construction, inspection, emergency response, and digital mapping.

&nbsp;

With well over a thousand units deployed across dozens of countries, [Spot](https://bostondynamics.com/products/spot/) is one of the most widely used quadrupeds in the world, and its mature software and sensor ecosystem have made it the benchmark others are measured against.

## 5. Unitree Go2

&nbsp;

Finally, the Unitree Go2. What makes it remarkable is access: it brings capable quadruped hardware, with AI features like obstacle avoidance and autonomous following, down to a price hobbyists and universities can actually afford.

&nbsp;

A built-in lidar and camera give it a 360-degree view, and an open SDK with ROS 2 support makes it a favourite for developers, researchers, and robotics enthusiasts. More than any other robot here, the Go2 is why so many people are now building with quadrupeds, and it's the same platform we've used to explore [building a quadruped simulation in MuJoCo](https://www.godrift.ai/blogs/quadruped-simulation-mujoco).

## What these robot dogs have in common?

&nbsp;

Each of these robot dogs was built for a different job, from border patrol to factory floors to a developer's workbench. Together, they show how quickly quadruped robots are becoming practical tools across research, industry, and beyond.

&nbsp;

They also share the same core challenge under the hood: staying balanced and moving reliably over unpredictable terrain, which is exactly [why getting a robot to walk](https://www.godrift.ai/blogs/quadruped-walking-mujoco) is so hard in the first place. If you want to experiment with the ideas behind these machines, the best place to start is [simulation](https://www.godrift.ai/blogs/best-robot-simulators-ros2).

## FAQ

1. **What is the most popular robot dog?** The Unitree Go2 is among the most popular by units in the field, thanks to its low price, capable AI features, and open SDK. Boston Dynamics Spot is the most widely deployed in enterprise settings, with well over a thousand commercial units across dozens of countries.
2. **What are robot dogs used for?** Common uses include industrial inspection of factories and power plants, security and defense patrols, mapping mines and tunnels, construction site monitoring, and emergency response. They excel at reaching stairs, rubble, and hazardous areas that are unsafe for people.
3. **How much does a robot dog cost?** It ranges enormously. Consumer and research models like the Unitree Go2 start in the low thousands of dollars, industrial platforms like the Deep Robotics X30 run into the tens of thousands, and premium or defense systems like Spot and the Vision 60 can reach well into six figures.
4. **Which robot dog is best for developers?** The Unitree Go2 is a top choice for developers and researchers because of its affordable price, onboard sensors, and open SDK with ROS 2 support. It's widely used for education, research, and prototyping robotics applications.
5. **Why are quadruped robots useful compared to wheeled robots?** Legs let quadrupeds handle stairs, ladders, rubble, and uneven or confined terrain that wheels can't, which is why they're valued for inspection and response in places built for humans rather than machines.
6. **Can you experiment with these robot dogs in simulation?** Yes. Platforms like the Unitree Go2 have widely available simulation models, so you can prototype behaviors virtually before touching hardware. Tools like [Drift](https://link.godrift.ai/dogs) generate quadruped simulations in MuJoCo from a natural-language prompt, which is a low-cost way to explore the locomotion and navigation ideas behind these commercial robots.

## Related reading

- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [Watch a Quadruped Take Its First Steps in MuJoCo](https://www.godrift.ai/blogs/quadruped-walking-mujoco)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)


# Adding Vision to a Franka Panda Robot in MuJoCo

*2026-07-25 · Drift Team · Product · 4 min*

> A robot arm moves with precision but sees nothing. See how Drift adds a wrist camera to a Franka Panda in MuJoCo and streams its live view, all from one prompt.

<https://godrift.ai/blogs/add-camera-franka-mujoco>

---
A robot arm can move with incredible precision. Without a camera, though, it has no idea what's actually in front of it.

<figure data-type="youtube-embed" data-yt-id="xK5WXM-J5Gk" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/xK5WXM-J5Gk?autoplay=1&mute=1&loop=1&playlist=xK5WXM-J5Gk&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough adds a camera to a Franka Panda in MuJoCo, giving the arm the ability to see, and rather than editing the model by hand, we let [Drift](https://link.godrift.ai/vis) attach the camera and wire up the live feed from a single prompt.

## Why a robot arm needs a camera?

&nbsp;

A Franka Panda knows its own joint positions with high accuracy, so it can repeat a memorised motion perfectly. What it can't do without vision is react to anything it wasn't told about in advance.

&nbsp;

Add a camera and that changes. The arm can locate an object that isn't in a fixed position, tell one item from another, and adjust to a scene that looks different from last time. For any task outside a rigidly structured setup, vision is what turns a precise-but-blind arm into one that can respond to the world in front of it. It's the same shift we saw when [adding a LiDAR to a mobile robot](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2), just aimed at manipulation instead of navigation.

## Adding a wrist camera with a single Drift prompt

&nbsp;

Starting from the existing scene, we give [Drift](https://link.godrift.ai/vis) a simple instruction: add a camera to the Franka Panda arm in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco) and display its camera feed.

&nbsp;

Mounting the camera on the gripper, a wrist camera, is a common choice for manipulation, because the camera looks out from roughly where the hand acts. That gives the arm a close, first-person view of whatever it's reaching for.

## How Drift attaches the camera and configures the feed?

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/vis) updates the simulation, attaches a camera to the robot, and configures the live camera stream. The sensor is added to the robot description and wired so its output can be displayed as the simulation runs.

&nbsp;

What would normally mean editing the model, placing the camera frame, and setting up the rendering by hand is handled in one step. If you're starting earlier, here's [how to build the pick-and-place scene](https://www.godrift.ai/blogs/pick-and-place-mujoco) with this arm first.

## Launching the live camera feed in MuJoCo

&nbsp;

Time to launch. With the camera attached, we run the simulation and bring up the feed.

&nbsp;

Now we can see exactly what the robot sees as it moves through the scene. The view shifts with the arm, tracking whatever the gripper is pointed at. That first-person perspective is the raw input every vision-based behavior builds on, and watching it move with the arm makes it clear what the robot has to work with.

## What vision unlocks for a robot arm?

&nbsp;

Giving a robot vision is a small addition with a large payoff. It's the first step toward tasks like object detection, visual servoing, where the arm uses the camera feed to guide its motion in real time, and autonomous manipulation.

&nbsp;

It's a simple change that opens up a whole new way for the robot to understand its environment. With vision in place, the next challenge shifts from moving accurately to deciding what to do with what it sees. That's where manipulation gets genuinely interesting. Add a camera, launch the feed, and start exploring what the arm can do once it can see. The full walkthrough is in the video above.

## FAQ

1. **How do you add a camera to a robot in MuJoCo?** You add a camera to the robot's description, position it, for example on the gripper, and configure the simulation to render its view. In this walkthrough, Drift attaches the camera to a Franka Panda arm and sets up the live feed from a single prompt.
2. **Why mount the camera on the gripper?** A gripper-mounted, or wrist, camera looks out from near where the hand acts, giving the arm a close first-person view of whatever it's manipulating. This is a common setup for manipulation because it keeps the target in view as the arm approaches it. The [Franka Panda model](https://github.com/google-deepmind/mujoco_menagerie) used here comes from the MuJoCo Menagerie collection.
3. **What can a robot arm do once it has a camera?** Vision enables tasks like object detection, visual servoing (using the camera feed to guide motion in real time), and autonomous manipulation. It lets the arm find and react to objects instead of only repeating pre-programmed motions.
4. **What is visual servoing?** Visual servoing is a technique where a robot uses live camera data to control its motion, continuously adjusting toward a visual target. It lets an arm home in on an object even if that object moves or wasn't in a fixed position.
5. **What does Drift do when adding a camera?** [Drift](https://link.godrift.ai/vis) updates the simulation, attaches the camera to the robot, and configures the live camera stream, all from a natural-language prompt, so you can see what the robot sees without manually editing the model or rendering setup.

## Related reading

- [Automating Pick and Place With the Franka Panda in MuJoCo](https://www.godrift.ai/blogs/automate-pick-and-place-franka-mujoco)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# Why Robot Hands Are So Hard?

*2026-07-24 · Drift Team · Research · 8 min*

> Robot hands look more human every year, yet nobody has really solved them. Here's why grasping is so hard, and why most robots still use simple grippers.

<https://godrift.ai/blogs/why-robot-hands-are-hard>

---
A new robot hand goes viral every few months for how human it looks. Look past the demo reel and the same thing is true: nobody has really solved the robot hand.

<figure data-type="youtube-embed" data-yt-id="uk3I0JPl_0E" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/uk3I0JPl_0E?autoplay=1&mute=1&loop=1&playlist=uk3I0JPl_0E&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

Impressive hardware, but understanding why robot hands are hard means looking at what happens after the demo ends. Despite decades of work, dexterous manipulation remains unsolved, and most working robots today don't have hands at all.

## Why most robots use grippers instead of hands?

&nbsp;

Walk onto almost any factory floor and you won't see hands. You'll see grippers: two-finger pincers, three-finger claws, and often just a suction cup.

&nbsp;

There's a good reason for that. The parallel-jaw gripper is one of the most successful pieces of hardware in automation history: one actuator, one degree of freedom, almost nothing to break, calibrate, or get wrong in software. A human hand has roughly 27 degrees of freedom. That gap is the entire engineering problem in miniature.

&nbsp;

Every actuated degree of freedom you add is a tax: another motor, another failure mode, another thing that slips out of calibration before a demo. And for a huge fraction of real tasks, the gripper is enough. If the object always arrives in the same place, you don't need fingers, you need a clamp that closes reliably ten million times. Most robots get by without many fingers because most robots work in worlds we built for them.

## What makes grasping so difficult in the real world?

&nbsp;

Outside a factory, that structure vanishes. Every object has a different shape, weight, and texture, and it rarely shows up where you expect.

&nbsp;

To pick something up, a robot has to perceive the object, choose where to grip it, and apply exactly the right amount of force. Too little and it slips. Too much and a paper cup or an egg is crushed. A person adjusts continuously without conscious thought, using a dense sense of touch that current robots don't come close to matching.

&nbsp;

The hardware fights back too. A dexterous hand is one of the worst real-estate problems in robotics: 20-plus degrees of freedom packed into a hand-sized volume, light enough not to wreck the arm's dynamics. That leaves two painful options. Put the motors in the hand and it gets heavy, and mass at the end of an arm is the enemy of everything carrying it. Or run tendons from the forearm, the way a human hand does, and take on cables that stretch, wear, and snap. Add cost on top: research-grade hands have run as much as a car, and a single controller hiccup into a table can turn one into a paperweight.

## The tactile sensing gap in robot hands

&nbsp;

The deeper technical gap is touch. Available dexterous hands still fall well short of human hands, and tactile ability is where the shortfall is largest. A robot may see an object clearly and still have almost no sense of how it feels in its grip, whether it's slipping, or how the contact is changing as it moves.

&nbsp;

There's also a data problem. Learning-based approaches need enormous amounts of high-quality manipulation data, and capturing how a human hand actually moves and touches things at that scale is difficult in itself. Much of this research happens in simulators like [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco), where contact-rich tasks such as reorienting a cube in-hand can be practiced at scale, as covered in this [survey of learning-based in-hand manipulation](https://pmc.ncbi.nlm.nih.gov/articles/PMC11573780/).

&nbsp;

Simulation carries its own version of the problem. Contact dynamics, friction, deformation, and the exact moment a fingertip slips are where simulation and reality disagree most. The sim-to-real gap is a challenge everywhere in robotics, and in the hand it's at its worst.

## Underactuation, the middle path between two fingers and five

&nbsp;

Framing this as two fingers versus five is a false choice, and some of the most interesting work sits in between.

&nbsp;

The key idea is underactuation: mechanical design that produces dexterity-like behavior without a motor for every joint. An adaptive gripper that passively conforms to whatever it touches gets you a large share of human grasping with a fraction of the actuators. You put the intelligence in the mechanism rather than the motors. Evolution did something similar, since a lot of human grasping is mechanically coupled rather than independently controlled. You may not need to actuate everything in order to do everything.

## Redesign the world, or build robots that fit it?

&nbsp;

That raises a bigger question than finger count. There are two paths forward, and the industry is pursuing both.

&nbsp;

One is to redesign the world for robots: structured warehouses, fixtures, conveyors, and packaging standardised so simple grippers suffice. That approach works, and it's why deployed robotics succeeds today. You've moved the complexity into the environment.

&nbsp;

The other is to build robots dexterous enough to fit the world we've already built. Door handles, drills, light switches, knives, zippers, jar lids. None of it was designed for a claw, and all of it was designed implicitly around five fingers and a thumb. In human spaces, the human hand is the universal adapter. There's a quieter argument for it too: the internet is full of footage of human hands doing things, so the closer a robot's hand is to ours, the better that demonstration data transfers and the easier teleoperation becomes. The anthropomorphic form factor stops being vanity and becomes a data decision.

&nbsp;

The catch is that you can only redesign the places you control. You can rebuild a warehouse. You can't rebuild every home, hospital, and messy human space built up over decades around human hands. This is what [humanoid robots](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard) are betting on, and it depends on solving the hand.

## Why hands are the frontier of physical AI?

&nbsp;

AI is getting smarter every day, and models are getting far better at understanding instructions and recognizing objects. The gap now sits at the point of contact, in the moment a robot has to physically touch the world and get the force right. As our founder [put it in a longer piece on this question](https://x.com/nikhilkr/status/2074194530363142577), intelligence with nothing to act through is just text in a box. The hand is where physical AI becomes physical.

&nbsp;

Until robots master their hands, [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai) still has one of its biggest challenges ahead. It's also one of the most interesting places to work right now, because progress on hands unlocks a huge share of what people imagine robots doing.

If you want the longer argument behind this, read our founder's full piece on [how many fingers a robot actually needs](https://x.com/nikhilkr/status/2074194530363142577). And if you'd rather get hands-on, most of this research starts in simulation: try [building a pick-and-place scene in MuJoCo](https://www.godrift.ai/blogs/pick-and-place-mujoco)and see how quickly grasping stops feeling simple.

## FAQ

1. **Why are robot hands so hard to build?** Because grasping requires perceiving an object's shape, weight, and texture, then applying exactly the right force to avoid dropping or crushing it. Robot hands also lack the dense sense of touch human hands have, and the training data needed to learn dexterous manipulation is scarce and difficult to collect.
2. **Why do most robots use grippers instead of hands?** Grippers are cheaper, more reliable, and easier to control. In structured settings like factories, where the same object arrives in the same orientation repeatedly, a simple gripper handles the task perfectly without the cost and complexity of a multi-fingered hand.
3. **What is dexterous manipulation?** Dexterous manipulation is a robot's ability to handle and reorient objects skillfully, typically with a multi-fingered hand. It covers tasks like adjusting an object within the grip, using tools, and handling unfamiliar shapes, and it remains an active area of research.
4. **Why is tactile sensing important for robot hands?** Touch tells a robot whether an object is slipping, how much force it's applying, and how contact is changing as it moves. Vision alone can't provide that, which is why tactile sensing is considered one of the key missing pieces in dexterous manipulation.
5. **What is underactuation in robot hands?** Underactuation means a hand has fewer actuators than joints, using mechanical design so fingers passively conform to an object instead of driving each joint independently. It delivers much of the benefit of a dexterous hand with far fewer motors, less weight, and fewer failure points.
6. **How many fingers does a robot actually need?** It depends on where the robot works. In structured settings like warehouses, a one-degree-of-freedom gripper is often the correct answer. In homes, hospitals, and other spaces built around human hands, more dexterity becomes necessary, which is why the question is really about whether you redesign the world for robots or build robots to fit the world.
7. **How are robot hands researched and tested?** A great deal of the work happens in simulation, where contact-rich tasks can be repeated at enormous scale without wearing out expensive hardware. Physics engines like MuJoCo are widely used for this, and tools like [Drift](https://link.godrift.ai/rob-hand) generate the simulated robots and environments that experiments run in, while the manipulation policies themselves are trained on top.

## Related reading

- [How many fingers does a robot actually need?](https://x.com/nikhilkr/status/2074194530363142577) 
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [Soft Robots: Why Some of the Best Machines Are Squishy](https://www.godrift.ai/blogs/soft-robots)
- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)


# Automating Pick and Place With the Franka Panda in MuJoCo

*2026-07-22 · Drift Team · Product · 4 min*

> Building the scene was step one. See how Drift automates a pick-and-place sequence for the Franka Panda arm in MuJoCo, grasp, lift, and place, from one prompt.

<https://godrift.ai/blogs/automate-pick-and-place-franka-mujoco>

---
We already built the scene: a Franka Panda arm, a cube and a target. Moving the arm by hand is one thing. Can it run the whole sequence on its own?

<figure data-type="youtube-embed" data-yt-id="W8fgfcH0hQk" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/W8fgfcH0hQk?autoplay=1&mute=1&loop=1&playlist=W8fgfcH0hQk&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough automates pick and place with the Franka Panda in MuJoCo, asking [Drift](https://link.godrift.ai/franka-1) to generate the full sequence so the arm grasps, lifts, and places the object without any manual control.

## From a manual arm to an automated pick-and-place task

&nbsp;

Picking things up and putting them down sounds trivial, but it's one of the foundational skills in robotics. A full pick-and-place sequence has to move the arm to the object, align the gripper, close it at the right moment, lift without dropping, travel to the target, and release, each step depending on the one before.

&nbsp;

Writing that motion logic by hand is fiddly. Getting the timing and positions right is exactly the kind of work that eats an afternoon, which is why automating the generation of it is useful.

## The prompt: automate the sequence with [Drift](https://link.godrift.ai/franka-1)

&nbsp;

Starting from the existing scene, we give [Drift](https://link.godrift.ai/franka-1) a simple prompt: create an automatic pick-and-place sequence for the existing Franka Panda arm in MuJoCo, and save it as a named script.

&nbsp;

That's the whole instruction. There's no need to specify every waypoint or gripper command, since the goal is described at the task level and [Drift](https://link.godrift.ai/franka-1) works out the sequence to achieve it.

## How Drift generates and integrates the motion sequence?

&nbsp;

From that prompt, [Drift](https://link.godrift.ai/franka-1) updates the controller, generates the required motion sequence, and integrates it into the existing simulation. The pick-and-place logic is written into a script and wired into the scene we already had, rather than replacing it.

What would normally be careful, hand-tuned motion code is produced in one step and left ready to run. If you're starting earlier, here's [how to build the pick-and-place scene](https://www.godrift.ai/blogs/pick-and-place-mujoco) and [how to install MuJoCo](https://www.godrift.ai/blogs/install-mujoco) first.

## Watching the Franka Panda pick and place on its own

&nbsp;

Time for the real test. We launch the simulation and let it run.

&nbsp;

The Panda arm moves toward the cube, grasps it, lifts it clear of the table, carries it across, and places it on the target location, all automatically. No manual joint adjustments, no step-by-step control. The task the scene was built for now runs end to end on its own.

## Why pick and place is a foundational robotics skill?

&nbsp;

This is a simple pick-and-place task, but it's one of the most fundamental skills in robotics. Almost every practical manipulation job is some version of it: move to an object, grasp it, and put it somewhere useful.

&nbsp;

Once a robot can reliably pick, move, and place objects, that skill scales toward real applications, from warehouse automation and order fulfillment to industrial assembly. With [Drift](https://link.godrift.ai/franka-1) generating the sequence, you get a working automated task quickly and can spend your time refining the grasp, testing new objects, or building toward more complex behaviors. The full run is in the video above.

## FAQ

1. **How do you automate a pick-and-place task in simulation?** You need a motion sequence that moves the arm to the object, grasps it, lifts and transports it, and releases it at the target. In this walkthrough, [Drift](https://link.godrift.ai/franka-1) generates that full sequence for a Franka Panda arm and integrates it into an existing MuJoCo scene from a single prompt.
2. **What is a pick-and-place task in robotics?** Pick and place is a manipulation task where a robot grasps an object at one location and places it at another. It's a foundational skill behind many real applications, including assembly, packaging, sorting, and warehouse automation.
3. **What is the Franka Panda used for?** The [Franka Emika Panda](https://github.com/google-deepmind/mujoco_menagerie) is a seven-joint collaborative robot arm widely used in research and education. Its dexterity and readily available simulation models make it a common choice for manipulation and pick-and-place experiments.
4. **Why is pick and place considered a fundamental robotics skill?** Because most practical manipulation reduces to it: reach an object, grasp it, and move it somewhere. Once a robot can do this reliably, the same capability underpins tasks from industrial assembly to logistics.
5. **What does ****[Drift](https://link.godrift.ai/franka-1)**** generate for an automated pick-and-place task?** [Drift](https://link.godrift.ai/franka-1) updates the controller, generates the motion sequence for the pick-and-place task, and integrates it into the existing MuJoCo simulation as a script, all from a natural-language prompt, so the arm runs the full task automatically.

## Related reading

- [Build a Pick-and-Place Scene in MuJoCo in One Prompt](https://www.godrift.ai/blogs/pick-and-place-mujoco)
- [Watch a Quadruped Take Its First Steps in MuJoCo](https://www.godrift.ai/blogs/quadruped-walking-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)


# Why NVIDIA Cares So Much About Robots?

*2026-07-21 · Drift Team · Research · 4 min*

> NVIDIA is famous for graphics cards, so why pour billions into robotics? Because it builds the AI, simulation, and computing platform that powers the robots.

<https://godrift.ai/blogs/why-nvidia-cares-about-robots>

---
Say NVIDIA and most people think graphics cards. So why is one of the world's biggest AI companies pouring billions into robotics?

<figure data-type="youtube-embed" data-yt-id="jP5vFWSH2V8" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/jP5vFWSH2V8?autoplay=1&mute=1&loop=1&playlist=jP5vFWSH2V8&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

The short answer to why NVIDIA cares about robotics is that it sees the same opportunity it captured in AI: not the flashy end product, but the platform everyone else builds on.

## What NVIDIA actually builds for robotics?

&nbsp;

While companies like Figure and Tesla build the physical robots, NVIDIA is building the AI, simulation tools, and computing platform that power many of them. It's a supplier-to-everyone strategy rather than a compete-with-everyone one.

&nbsp;

NVIDIA frames this as **"three computers"**: one to train a robot's AI, one to simulate and test it, and one to run it inside the robot itself. Own all three layers, and you power robots regardless of which company ends up building the winning hardware.

## Isaac Sim and training robots in simulation

&nbsp;

The middle layer is where a lot of the action is. Tools like NVIDIA's Isaac Sim let developers train and test robots in [simulation](https://www.godrift.ai/blogs/best-robot-simulators-ros2) before they ever touch real hardware, with a companion framework, Isaac Lab, focused on training robot policies at scale.

&nbsp;

This matters because training robots in the real world is slow, expensive, and risky. A physical robot can only practice one attempt at a time, and mistakes can break it. In simulation, thousands of virtual robots can practice in parallel, safely, at a speed no physical setup can match. That sim-to-real approach is central to modern robot learning.

## GR00T and foundation models for robots

&nbsp;

The AI layer is [GR00T](https://developer.nvidia.com/isaac/gr00t), NVIDIA's open foundation model for humanoid robots. Rather than programming one task at a time, the goal is a general model that helps robots perform a wide range of real-world activities, and that developers can fine-tune for their own machines.

&nbsp;

It's the same foundation-model idea that reshaped language and images, now aimed at physical robots, and it's one of several [AI models changing robotics](https://www.godrift.ai/blogs/ai-models-changing-robotics) right now. Paired with NVIDIA's Jetson Thor chips for on-robot computing, it completes the loop from training to deployment.

## Why NVIDIA's platform-first bet could pay off?

&nbsp;

Put the pieces together and the strategy is clear. Simulation makes robot learning faster and safer. Foundation models make robots smarter and more general. And NVIDIA's chips run underneath both. Together, these tools help robots learn faster, more safely, and at a much larger scale than real-world training alone allows.

&nbsp;

The future of robotics depends on more than better hardware. It depends on better software, better simulation, and better AI, the layer that turns a machine into a capable robot. That's exactly where NVIDIA is placing its biggest bets, and why a company known for graphics cards is now one of the most important names in [embodied AI](https://www.godrift.ai/blogs/what-is-embodied-ai).

## FAQ

1. **Why is NVIDIA investing in robotics?** NVIDIA sees robotics as the next major platform opportunity. Rather than building robots to compete with companies like Figure and Tesla, it builds the AI models, simulation software, and chips that many robots rely on, aiming to be the platform underneath the whole industry.
2. **Does NVIDIA build robots?** Not the physical robots themselves, for the most part. NVIDIA focuses on the enabling layers: training and simulation software like Isaac Sim and Isaac Lab, foundation models like GR00T, and computing hardware like Jetson Thor that runs inside robots built by other companies.
3. **What is NVIDIA Isaac Sim?** Isaac Sim is NVIDIA's simulation platform for robotics. It lets developers train, test, and validate robot AI in a realistic virtual environment before deploying to real hardware, which is faster, cheaper, and safer than training on physical robots.
4. **What is NVIDIA GR00T?** GR00T is NVIDIA's open foundation model for generalist humanoid robots. It's designed to help robots understand and perform a wide range of tasks, and to be fine-tuned by developers, as part of a broader Isaac platform that spans data, simulation, and deployment.
5. **Why is simulation so important for training robots?** Training in the real world is slow, expensive, and risky, since a physical robot practices one attempt at a time and can be damaged. Simulation lets many virtual robots train in parallel at high speed and zero physical risk, then transfer what they learn to real hardware.
6. **Where do tools like ****[Drift](https://link.godrift.ai/nvi)**** fit into this robotics stack?** NVIDIA supplies the underlying platform: simulators like Isaac Sim, foundation models, and chips. [Drift](https://link.godrift.ai/nvi) works one layer up, generating the simulation workspaces developers actually run from a natural-language prompt, across simulators like Gazebo and MuJoCo, with Isaac Sim support on the way. NVIDIA provides the engine; Drift helps you build what runs inside it.

## Related reading

- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [5 AI Models Changing Robotics Right Now](https://www.godrift.ai/blogs/ai-models-changing-robotics)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)


# Adding an IMU to a Quadruped in MuJoCo

*2026-07-18 · Drift Team · Product · 4 min*

> How does a robot know it's about to tip over? See how Drift adds an IMU sensor to a quadruped in MuJoCo from one prompt, streaming live orientation data.

<https://godrift.ai/blogs/add-imu-quadruped-mujoco>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="vut2_PGBfks" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/vut2_PGBfks?autoplay=1&mute=1&loop=1&playlist=vut2_PGBfks&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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](https://link.godrift.ai/imu-quad) wire the sensor into our existing simulation from a single prompt.

## What an IMU does and why a quadruped needs one?

&nbsp;

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.

&nbsp;

For a legged robot, that feedback is essential. A [walking quadruped](https://www.godrift.ai/blogs/quadruped-walking-mujoco) 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

&nbsp;

Starting from the existing quadruped scene, we give [Drift](https://link.godrift.ai/imu-quad) a simple prompt: add an IMU sensor to the quadruped and launch it in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco).

&nbsp;

[Drift](https://link.godrift.ai/imu-quad) 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](https://www.godrift.ai/blogs/quadruped-simulation-mujoco) first.

## Relaunching the walking controller with the IMU in place

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2) for navigation.

&nbsp;

With [Drift](https://link.godrift.ai/imu-quad) 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

1. **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.
2. **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.
3. **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.
4. **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](https://mujoco.readthedocs.io/en/stable/XMLreference.html#sensor). In this walkthrough, Drift makes those changes to an existing quadruped and relaunches it in MuJoCo from a single prompt.
5. **What does ****[Drift](https://link.godrift.ai/imu-quad)**** do when adding an IMU?** [Drift](https://link.godrift.ai/imu-quad) 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.

## Related reading

- [Watch a Quadruped Take Its First Steps in MuJoCo](https://www.godrift.ai/blogs/quadruped-walking-mujoco)
- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# 5 AI Models Changing Robotics Right Now

*2026-07-17 · Drift Team · Research · 5 min*

> The 5 AI models teaching robots to understand language and learn new skills: RT-2, OpenVLA, NVIDIA GR00T, LeRobot, and Pi-Zero, explained simply.

<https://godrift.ai/blogs/ai-models-changing-robotics>

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

<figure data-type="youtube-embed" data-yt-id="m_kgr6_diXQ" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/m_kgr6_diXQ?autoplay=1&mute=1&loop=1&playlist=m_kgr6_diXQ&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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

&nbsp;

First up is [RT-2](https://robotics-transformer2.github.io/) from Google DeepMind. Released in 2023, it's the model that named the vision-language-action category.

&nbsp;

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

&nbsp;

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

&nbsp;

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

&nbsp;

NVIDIA is taking a different approach with [GR00T](https://arxiv.org/abs/2503.14734). 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.

&nbsp;

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](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard) need to be practical.

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

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/lerobot-codebase-explained) if you want to explore it yourself.

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

&nbsp;

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.

&nbsp;

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?

&nbsp;

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](https://www.godrift.ai/blogs/what-is-embodied-ai).

&nbsp;

One thread runs through all of them: scale. Each depends on huge amounts of training data, and much of it comes from [simulation](https://www.godrift.ai/blogs/best-robot-simulators-ros2), where a model can practice millions of times before it touches real hardware.

## FAQ

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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](https://link.godrift.ai/ai-mod) generate the simulated robots and environments used for that testing, while the models themselves are trained on top of those simulations.

## Related reading

- [What Is Embodied AI?](https://www.godrift.ai/blogs/what-is-embodied-ai)
- [I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)](https://www.godrift.ai/blogs/lerobot-codebase-explained)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)


# Watch a Robot Solve a Maze on Its Own in MuJoCo

*2026-07-15 · Drift Team · Product · 4 min*

> Walls, dead ends, and no map. See how Drift builds a maze in MuJoCo and gives a robot autonomous navigation to reach the goal, all from a single prompt.

<https://godrift.ai/blogs/maze-navigation-mujoco>

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

<figure data-type="youtube-embed" data-yt-id="2RKSXR88gGA" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/2RKSXR88gGA?autoplay=1&mute=1&loop=1&playlist=2RKSXR88gGA&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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](https://link.godrift.ai/maze-01) generate the maze, the robot and the navigation logic from one prompt.

## Why a maze is a good test of autonomous navigation

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/how-robots-navigate) anywhere.

## Generating the maze and navigation logic with Drift

&nbsp;

Rather than building the maze and writing the navigation code separately, we give [Drift](https://link.godrift.ai/maze-01) a single prompt: generate a maze, spawn a mobile robot and implement autonomous navigation that avoids collisions while finding its way to the goal.

&nbsp;

Here's what it produces:

- **The maze environment**:** **[Drift](https://link.godrift.ai/maze-01) creates the scene in [MuJoCo](https://www.godrift.ai/blogs/what-is-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](https://www.godrift.ai/blogs/install-mujoco) first.

## Watching the robot find its way to the goal

&nbsp;

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

&nbsp;

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

&nbsp;

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.

&nbsp;

An [office environment full of desks and chairs](https://www.godrift.ai/blogs/office-environment-mujoco) 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

&nbsp;

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.

&nbsp;

With [Drift](https://link.godrift.ai/maze-01) 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

1. **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.
2. **How do you build a maze simulation in MuJoCo?** You need a [MuJoCo scene](https://mujoco.readthedocs.io/) with walls and pathways, a mobile robot placed at the start, and navigation logic that drives it toward the goal. In this walkthrough, [Drift](https://link.godrift.ai/maze-01) generates all three from a single prompt and launches it in MuJoCo.
3. **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.
4. **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.
5. **What does ****[Drift](https://link.godrift.ai/maze-01)**** generate for maze navigation?** [Drift](https://link.godrift.ai/maze-01) 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.

## Related reading

- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [Build a Realistic Office Environment in MuJoCo in One Prompt](https://www.godrift.ai/blogs/office-environment-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)


# What Is Embodied AI?

*2026-07-14 · Drift Team · Research · 4 min*

> Embodied AI is AI connected to a physical body that can sense, decide, and act in the real world. Here's what embodied AI is, how it works, and why it matters.

<https://godrift.ai/blogs/what-is-embodied-ai>

---
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.

<figure data-type="youtube-embed" data-yt-id="eNkxU_Vp_YM" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/eNkxU_Vp_YM?autoplay=1&mute=1&loop=1&playlist=eNkxU_Vp_YM&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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?

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

That's the same [sense, think, act loop](https://www.godrift.ai/blogs/what-is-a-robot) 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?

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/best-robot-simulators-ros2) at massive scale before they ever touch real hardware, using platforms like [NVIDIA Isaac](https://developer.nvidia.com/isaac). A lot of that ambition is aimed at [humanoid robots](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard), which are among the hardest and most visible targets for embodied AI.

## What embodied AI means for the future of robotics?

&nbsp;

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.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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](https://link.godrift.ai/emb-ai) generate the simulated robots and environments used for that kind of testing, while the AI models themselves are trained on top of those simulations.

## Related reading

- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# How Mars Rovers Drive Themselves?

*2026-07-11 · Drift Team · Research · 4 min*

> How do Mars rovers drive themselves across a planet? They map the terrain with onboard cameras, spot hazards like rocks and slopes and plan a safe path alone.

<https://godrift.ai/blogs/how-mars-rovers-drive-themselves>

---
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?

&nbsp;

<figure data-type="youtube-embed" data-yt-id="0I5WEdB7KyQ" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/0I5WEdB7KyQ?autoplay=1&mute=1&loop=1&playlist=0I5WEdB7KyQ&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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?

&nbsp;

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.

&nbsp;

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?

&nbsp;

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.

&nbsp;

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?

&nbsp;

To drive itself, the rover leans on its cameras and onboard computing. NASA's Perseverance rover uses a self-driving system called [AutoNav](https://www.nasa.gov/solar-system/nasas-self-driving-perseverance-mars-rover-takes-the-wheel/) that builds 3D maps of the terrain ahead, identifies hazards, and plans a route around obstacles without waiting for instructions from Earth.

&nbsp;

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](https://www.godrift.ai/blogs/what-is-a-robot) every robot runs, carried out millions of miles from any human.

## How the rover avoids hazards without waiting for Earth?

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/how-robots-navigate) here on Earth, just under much harsher conditions on Mars.

## Humans decide where, the rover decides how

&nbsp;

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

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **How is autonomous navigation like a rover's 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](https://link.godrift.ai/mars) 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.

## Related reading

- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [Why Humanoid Robots Are Still So Hard to Build](https://www.godrift.ai/blogs/why-humanoid-robots-are-hard)


# Why Humanoid Robots Are Still So Hard to Build?

*2026-07-10 · Drift Team · Research · 4 min*

> Humanoid robots look effortless in demos, but building one is brutally hard. Here are the 3 reasons why, from balancing on two legs to a chaotic real world.

<https://godrift.ai/blogs/why-humanoid-robots-are-hard>

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

<figure data-type="youtube-embed" data-yt-id="DbP6guigzcY" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/DbP6guigzcY?autoplay=1&mute=1&loop=1&playlist=DbP6guigzcY&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

Instead it has to continuously perceive its surroundings, plan a response, and adapt, the same [sense, think, act loop](https://www.godrift.ai/blogs/what-is-a-robot) 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](https://www.godrift.ai/blogs/how-robots-navigate), which is its own deep challenge.

## Why humanoids combine every hard problem into one robot

&nbsp;

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.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **How are humanoid robots tested and trained?** Much of the work happens in simulation first. Physics engines like [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco) let researchers train balance and locomotion behaviors, including with reinforcement learning, before risking real hardware. The Humanoid benchmark in [Gymnasium's MuJoCo environments](https://gymnasium.farama.org/environments/mujoco/) is a common starting point.
5. **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.
6. **Can ****[Drift](https://link.godrift.ai/human)**** help with humanoid robot simulation?** [Drift](https://link.godrift.ai/human) 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.

## Related reading

- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Soft Robots: Why Some of the Best Machines Are Squishy](https://www.godrift.ai/blogs/soft-robots)


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

*2026-07-08 · Drift Team · Product · 4 min*

> A robot arm needs a scene before it can grasp anything. See how to build a pick-and-place scene in MuJoCo, arm, cube, and target, in one prompt with Drift.

<https://godrift.ai/blogs/pick-and-place-mujoco>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="3yXeWnU2SkI" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/3yXeWnU2SkI?autoplay=1&mute=1&loop=1&playlist=3yXeWnU2SkI&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

This walkthrough builds a complete pick-and-place scene in MuJoCo and rather than assembling every object by hand, we let [Drift](https://link.godrift.ai/place) generate the whole manipulation scene from one prompt.

## Why manipulation starts with the right scene

&nbsp;

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.

&nbsp;

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

&nbsp;

The goal is simple. We want a [Franka Panda](https://github.com/google-deepmind/mujoco_menagerie) 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

&nbsp;

Instead of placing each object manually, we ask [Drift](https://link.godrift.ai/place) to generate the entire scene, from the robot and table to the cube and target pad, and launch it directly in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco). If you're just getting set up, here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco).

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

Before you can teach a robot to manipulate objects, you need the right environment, and with [Drift](https://link.godrift.ai/place), 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **What does Drift generate for a manipulation scene?** [Drift](https://link.godrift.ai/place) 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.

## Related reading

- [Build a Realistic Office Environment in MuJoCo in One Prompt](https://www.godrift.ai/blogs/office-environment-mujoco)
- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)


# Watch a Quadruped Take Its First Steps in MuJoCo

*2026-07-07 · Drift Team · Product · 4 min*

> You have a quadruped standing in simulation. Now it needs to walk. See how Drift generates a quadruped walking controller in MuJoCo from a single prompt.

<https://godrift.ai/blogs/quadruped-walking-mujoco>

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

&nbsp;

<figure data-type="youtube-embed" data-yt-id="wY8lJ3rXctA" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/wY8lJ3rXctA?autoplay=1&mute=1&loop=1&playlist=wY8lJ3rXctA&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

In the last build we created a [quadruped simulation in MuJoCo](https://www.godrift.ai/blogs/quadruped-simulation-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](https://link.godrift.ai/quad-walk) to generate it from a single prompt.

## Why getting a quadruped to walk is hard

&nbsp;

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.

&nbsp;

That's the gap this closes. We use the existing quadruped simulation and let [Drift](https://link.godrift.ai/quad-walk) produce a basic walking controller, then we run it and see how it performs.

## Generating a quadruped walking controller with Drift

&nbsp;

Starting from the quadruped scene, we give [Drift](https://link.godrift.ai/quad-walk) 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](https://www.godrift.ai/blogs/install-mujoco) and [build the quadruped scene](https://www.godrift.ai/blogs/quadruped-simulation-mujoco) first.

## Watching the quadruped take its first steps

&nbsp;

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

&nbsp;

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

&nbsp;

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

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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 ](https://www.godrift.ai/blogs/what-is-mujoco)policies for more robust locomotion.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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](https://gymnasium.farama.org/tutorials/gymnasium_basics/load_quadruped_model/), and many of those learned policies transfer to real hardware.
5. **What does Drift generate for a walking quadruped?** [Drift](https://link.godrift.ai/quad-walk) 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.

## Related reading

- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)
- [Build a Realistic Office Environment in MuJoCo in One Prompt](https://www.godrift.ai/blogs/office-environment-mujoco)


# Build a Realistic Office Environment in MuJoCo in One Prompt

*2026-07-02 · Drift Team · Product · 4 min*

> A robot is only as good as the world you test it in. See how Drift builds a realistic office environment in MuJoCo, furniture and all, from a single prompt.

<https://godrift.ai/blogs/office-environment-mujoco>

---
A robot is only as good as the environment you test it in. Before it ever reaches the real world, it has to prove itself in a realistic one.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="oRHFoVwM6a0" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/oRHFoVwM6a0?autoplay=1&mute=1&loop=1&playlist=oRHFoVwM6a0&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

&nbsp;

This walkthrough builds a realistic office environment in MuJoCo, and rather than placing every desk and chair by hand, we let [Drift](https://link.godrift.ai/off-env) generate the whole scene from one prompt.

## Why your test environment matters as much as your robot

&nbsp;

You can have a perfectly tuned robot and still learn nothing useful if you test it in an empty room. Real spaces are cluttered, and that clutter is the point.

&nbsp;

Offices in particular are full of obstacles: tables, chairs, desks, and narrow pathways between them. That makes them a strong environment for testing navigation, perception, and how a robot interacts with the things around it. A furnished scene forces the robot to deal with the same kinds of constraints it will face once it's deployed.

## Generating an office environment in MuJoCo with Drift

&nbsp;

Instead of building the scene object by object, we initialize [Drift](https://link.godrift.ai/off-env) in the terminal and describe what we want. The goal is a realistic office scene, complete with furniture, launched directly in [MuJoCo](https://www.godrift.ai/blogs/what-is-mujoco). If you don't have it set up yet, here's [how to install MuJoCo in one prompt](https://www.godrift.ai/blogs/install-mujoco).

&nbsp;

Here's what [Drift](https://link.godrift.ai/off-env) handles from that single prompt:

- **It generates the office scene:** [Drift](https://link.godrift.ai/off-env) builds a complete office environment rather than an empty room, laying out the space as a usable workspace.
- **It places the furniture:** Desks, chairs, tables, and other objects are positioned throughout the scene, turning a blank floor into a realistic, cluttered environment.
- **It launches MuJoCo:** In a few moments the empty scene becomes a full office loaded and running in the simulator, ready to explore.

## Exploring the office scene in MuJoCo

&nbsp;

One advantage of simulation is that you can freely inspect the environment before adding any robots or controllers. Rotate the camera, move around the space, and look at how everything is arranged.

&nbsp;

This is your chance to verify the layout, identify the obstacles a robot will need to handle, and prepare the scene for future robotics tasks. Getting the world right before you introduce a robot saves you from debugging the environment and the robot at the same time later.

## What to do with your simulated office environment

&nbsp;

A finished office scene is the foundation for the interesting work. From here you can drop in a robot and start testing [how it navigates](https://www.godrift.ai/blogs/how-robots-navigate) around the furniture, experiment with perception in a cluttered space, or set up manipulation and autonomous-behaviour tasks.

&nbsp;

Building realistic environments is a core part of robotics simulation. Whether you're testing navigation, manipulation, or autonomous behavior, it starts with a world worth testing in. With [Drift](https://link.godrift.ai/off-env), generating that world takes a single prompt, so you can spend your time on the robot instead of the room. Spin up a scene, load a robot, and start testing. The full build is in the video above.

## FAQ

1. **How do you create a simulation environment in MuJoCo?** A MuJoCo environment is defined in an [MJCF scene file](https://mujoco.readthedocs.io/)that describes the world, its objects, and their placement. In this walkthrough, [Drift](https://link.godrift.ai/off-env) generates a complete office scene with furniture and launches it in MuJoCo from a single natural-language prompt, instead of writing the scene by hand.
2. **Why test robots in an office environment?** Offices are full of realistic obstacles like desks, chairs, tables, and narrow pathways. That makes them a strong setting for testing navigation, perception, and robot interaction, because the robot faces the same kinds of constraints it will meet in a real deployment.
3. **What is a scene or environment in MuJoCo?** It's the simulated world a robot operates in, including the floor, walls, furniture, and other objects, along with their positions and physical properties. A good environment lets you test a robot under realistic conditions before using real hardware.
4. **Can you add a robot to a MuJoCo office environment?** Yes. Once the environment is built, you can place a robot model into the scene and begin testing navigation, perception, or manipulation. Inspecting and verifying the environment first makes adding the robot much smoother.
5. **What does Drift do for building environments?** [Drift](https://link.godrift.ai/off-env) generates a complete, furnished simulation environment and launches it in MuJoCo from a single prompt, handling the scene layout and object placement, so you get a realistic world to test in without building it manually.

## Related reading

- [Build a Quadruped Simulation in MuJoCo in One Prompt](https://www.godrift.ai/blogs/quadruped-simulation-mujoco)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [The 5 Most Common Ways Robots Navigate](https://www.godrift.ai/blogs/how-robots-navigate)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)


# The 5 Most Common Ways Robots Navigate

*2026-06-30 · Drift Team · Research · 5 min*

> Robots don't naturally know where they are. Here are the five most common ways robots navigate, from wheel odometry and GPS to visual odometry, SLAM, and Nav2.

<https://godrift.ai/blogs/how-robots-navigate>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="ShMj79ksdkE" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/ShMj79ksdkE?autoplay=1&mute=1&loop=1&playlist=ShMj79ksdkE&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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

&nbsp;

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

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2) is the step that unlocks mapping and navigation in the first place.

### 5. Navigation stacks: planning the actual path with Nav2

&nbsp;

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](https://docs.nav2.org/), the navigation stack for ROS 2.

&nbsp;

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

&nbsp;

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.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **Can Drift set up navigation for my robot?** [Drift](https://link.godrift.ai/navigate) 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.

## Related reading

- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [Building a Mobile Robot Simulation in ROS 2 From a Single Prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2)
- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)


# Build a Quadruped Simulation in MuJoCo in One Prompt

*2026-06-30 · Drift Team · Product · 4 min*

> A quadruped has dozens of joints to configure before it can stand in a sim. See how Drift builds a quadruped simulation in MuJoCo from a single prompt.

<https://godrift.ai/blogs/quadruped-simulation-mujoco>

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

<figure data-type="youtube-embed" data-yt-id="GLe3oGbrnUI" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/GLe3oGbrnUI?autoplay=1&mute=1&loop=1&playlist=GLe3oGbrnUI&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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](https://link.godrift.ai/quad-sim) and start from one simple prompt.

## Why a quadruped project starts with simulation

&nbsp;

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](https://www.godrift.ai/blogs/what-is-mujoco).

&nbsp;

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

&nbsp;

Instead of assembling all of that manually, we initialize [Drift](https://link.godrift.ai/quad-sim) 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](https://www.godrift.ai/blogs/install-mujoco) first.

&nbsp;

Here's what Drift handles, in order:

- **It sets up the project:** [Drift](https://link.godrift.ai/quad-sim) 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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

If you want ready-made four-legged models to drop in, the [MuJoCo Menagerie](https://github.com/google-deepmind/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](https://gymnasium.farama.org/tutorials/gymnasium_basics/load_quadruped_model/).

&nbsp;

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

1. **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](https://link.godrift.ai/quad-sim) 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.
2. **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.
3. **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.
4. **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.
5. **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.

## Related reading

- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Install MuJoCo and Run Your First Simulation Without the Setup Grind](https://www.godrift.ai/blogs/install-mujoco)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [Swarm Robotics: Why a Thousand Simple Robots Beat One Smart One](https://www.godrift.ai/blogs/swarm-robotics)


# Install MuJoCo and Run Your First Simulation With One Prompt

*2026-06-26 · Drift Team · Product · 4 min*

> Installing MuJoCo means chasing dependencies and configuring your environment. Here's how to install MuJoCo and launch a benchmark in one prompt with Drift.

<https://godrift.ai/blogs/install-mujoco>

---
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.

<figure data-type="youtube-embed" data-yt-id="IuRrAckB6jA" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/IuRrAckB6jA?autoplay=1&mute=1&loop=1&playlist=IuRrAckB6jA&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

[MuJoCo](https://www.godrift.ai/blogs/what-is-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](https://link.godrift.ai/muj-set) handle the entire setup in one go.

## Why installing MuJoCo isn't always quick

&nbsp;

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.

&nbsp;

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

&nbsp;

Instead of doing that by hand, we start from a clean environment and let [Drift](https://link.godrift.ai/muj-set) take the whole task. The prompt asks it to install MuJoCo, verify the installation, and launch a benchmark environment.

&nbsp;

Here's what it handles, in order:

- **It installs MuJoCo and pulls in the dependencies: **As MuJoCo installs, [Drift](https://link.godrift.ai/muj-set) 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](https://link.godrift.ai/muj-set) 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

&nbsp;

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.

&nbsp;

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

&nbsp;

From here, the interesting work begins. You can explore the [built-in benchmark environments](https://gymnasium.farama.org/environments/mujoco/) 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.

&nbsp;

If you're still deciding whether MuJoCo is the right tool, our guides on [what makes MuJoCo special](https://www.godrift.ai/blogs/what-is-mujoco) and [how the major robot simulators compare](https://www.godrift.ai/blogs/best-robot-simulators-ros2) are good next reads. Otherwise, install it, launch a benchmark, and start experimenting today.

## FAQ

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **What does Drift do for MuJoCo setup?** [Drift](https://link.godrift.ai/muj-set) 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.

## Related reading

- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [Building a Mobile Robot Simulation in ROS 2 From a Single Prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2)
- [I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)](https://www.godrift.ai/blogs/lerobot-codebase-explained)


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

*2026-06-24 · Drift Team · Research · 5 min*

> Swarm robotics deploys many simple robots that follow basic rules with no leader. Together they produce complex, emergent behavior, like ants, bees, and drones.

<https://godrift.ai/blogs/swarm-robotics>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="kjz-UIkrY5c" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/kjz-UIkrY5c?autoplay=1&mute=1&loop=1&playlist=kjz-UIkrY5c&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

&nbsp;

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?

&nbsp;

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](https://www.godrift.ai/blogs/mobile-robot-sim-ros2). Swarm robotics takes the opposite approach: deploy lots of inexpensive, simple robots that each follow a few basic rules.

&nbsp;

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?

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/what-is-a-robot); the swarm just runs thousands of them at once.

## Emergent behaviour: how a swarm gets smart without a plan

&nbsp;

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.

&nbsp;

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](https://wyss.harvard.edu/news/a-self-organizing-thousand-robot-swarm/) 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

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/best-robot-simulators-ros2).

## Inspired by nature: ants, bees, and termites

&nbsp;

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](https://www.godrift.ai/blogs/soft-robots): when biology has already solved a problem, it's often easier to borrow the answer than invent a new one.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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](https://link.godrift.ai/s-rob) handles the per-robot foundation rather than the swarm coordination itself.

## Related reading

- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [Soft Robots: Why Some of the Best Machines Are Squishy](https://www.godrift.ai/blogs/soft-robots)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [MuJoCo: The Physics Engine Robotics Research Quietly Runs On](https://www.godrift.ai/blogs/what-is-mujoco)


# MuJoCo: The Physics Engine Robotics Research Quietly Runs On

*2026-06-23 · Drift Team · Research · 5 min*

> MuJoCo went from a paid, academic-only physics engine to free and open source under DeepMind. Here's why it became the simulator behind modern robotics and RL.

<https://godrift.ai/blogs/what-is-mujoco>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="cDLapb32ktg" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/cDLapb32ktg?autoplay=1&mute=1&loop=1&playlist=cDLapb32ktg&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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?

&nbsp;

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](https://deepmind.google/blog/open-sourcing-mujoco/) acquired it in October 2021 and made it free, then released the full source under an open license in 2022.

&nbsp;

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?

&nbsp;

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.

&nbsp;

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?

&nbsp;

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.

&nbsp;

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

&nbsp;

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](https://gymnasium.farama.org/environments/mujoco/), are so common they've become the MNIST of robotics: the baseline everyone tests against.

&nbsp;

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](https://www.godrift.ai/blogs/best-robot-simulators-ros2). It's also the kind of engine that powers research libraries like the one we explored in [the LeRobot codebase](https://www.godrift.ai/blogs/lerobot-codebase-explained).

## MuJoCo's trade-offs: speed over photorealism

&nbsp;

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.

&nbsp;

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](https://link.godrift.ai/mjc) can scaffold a MuJoCo workspace from a single prompt, so you can skip the setup and get to the experiment.

## Should you use MuJoCo?

&nbsp;

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.

&nbsp;

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

## FAQ

1. **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.
2. **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`.
3. **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.
4. **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.
5. **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.
6. **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.

## Related reading

- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)](https://www.godrift.ai/blogs/lerobot-codebase-explained)
- [Building a Mobile Robot Simulation in ROS 2 From a Single Prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2)
- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)


# Soft Robots: Why Some of the Best Machines Are Squishy

*2026-06-20 · Drift Team · Research · 5 min*

> Soft robots made of silicone and rubber can grab an egg, squeeze through tight spaces, and even work inside the body. A look at robotics' squishy frontier.

<https://godrift.ai/blogs/soft-robots>

---
---

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

<figure data-type="youtube-embed" data-yt-id="7Ct84LsPTbQ" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/7Ct84LsPTbQ?autoplay=1&mute=1&loop=1&playlist=7Ct84LsPTbQ&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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?

&nbsp;

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.

&nbsp;

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](https://www.godrift.ai/blogs/what-is-a-robot) as any rigid machine; they simply solve the "act" part with a body that gives.

## Why a soft gripper beats a rigid one?

&nbsp;

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.

&nbsp;

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

&nbsp;

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](https://softroboticstoolkit.com/) documents many of these designs, from wearable assistive devices to surgical tools.

&nbsp;

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

&nbsp;

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.

&nbsp;

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?

&nbsp;

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.

&nbsp;

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

&nbsp;

- **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](https://link.godrift.ai/sr), 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.

## Related reading

- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)
- [Robot Simulators, Compared: Which One Should You Actually Use?](https://www.godrift.ai/blogs/best-robot-simulators-ros2)
- [Building a Mobile Robot Simulation in ROS 2 From a Single Prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2)
- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)](https://www.godrift.ai/blogs/lerobot-codebase-explained)


# Which Robot Simulator Should You Actually Use?

*2026-06-17 · Drift Team · Research · 6 min*

> Gazebo, Webots, Isaac Sim, CoppeliaSim, PyBullet, MuJoCo: Guide to the best robot simulators for ROS 2 and which one to pick for your project.

<https://godrift.ai/blogs/best-robot-simulators-ros2>

---
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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="IY4QS0BSq48" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/IY4QS0BSq48?autoplay=1&mute=1&loop=1&playlist=IY4QS0BSq48&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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 guide of the six robot simulators worth knowing, and which one actually fits your project.

## Why simulate at all?

&nbsp;

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.

&nbsp;

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?](https://www.godrift.ai/blogs/what-is-a-robot). Here's how the main options stack up.

## Gazebo: the ROS 2 default

&nbsp;

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](https://gazebosim.org), the modern version (Harmonic is the current long-term release, formerly known as Ignition).

&nbsp;

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](https://www.godrift.ai/blogs/mobile-robot-sim-ros2) and then [add a LiDAR sensor](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2).

## Webots: the easiest place to start

&nbsp;

[Webots](https://cyberbotics.com) 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.

&nbsp;

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

&nbsp;

If Gazebo is the workhorse, NVIDIA's [Isaac Sim](https://developer.nvidia.com/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.

&nbsp;

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

&nbsp;

Previously called V-REP, [CoppeliaSim](https://www.coppeliarobotics.com) 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.

&nbsp;

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

## Reinforcement learning simulators: PyBullet and MuJoCo

&nbsp;

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

&nbsp;

### PyBullet:

&nbsp;

It is lightweight, Python-friendly, and easy to set up. If you want to train RL agents without spending hours configuring a simulator, [PyBullet](https://pybullet.org) 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.

&nbsp;

### **MuJoCo:**

&nbsp;

It sits at the other end of the spectrum. [MuJoCo](https://mujoco.org) 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

&nbsp;

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.

&nbsp;

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](https://link.godrift.ai/list) 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

&nbsp;

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.

&nbsp;

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **Does ****[Drift](https://link.godrift.ai/list)**** 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.

## Related reading

- [Building a Mobile Robot Simulation in ROS 2 From a Single Prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2)
- [Adding a LiDAR Sensor So Your Robot Can Finally See](https://www.godrift.ai/blogs/add-lidar-gazebo-ros2)
- [I Used an AI Agent to Explain the LeRobot Codebase (Hugging Face Robotics)](https://www.godrift.ai/blogs/lerobot-codebase-explained)
- [What Even Is a Robot? (It's Messier Than You Think)](https://www.godrift.ai/blogs/what-is-a-robot)


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

*2026-06-15 · Drift Team · Product · 5 min*

> Watch a mobile robot go from driving blind to sensing its world: adding a LiDAR in ROS 2 and Gazebo without fighting URDFs, frames, and plugins.

<https://godrift.ai/blogs/add-lidar-gazebo-ros2>

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

&nbsp;

<figure data-type="youtube-embed" data-yt-id="j2xQASA-PbA" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/j2xQASA-PbA?autoplay=1&mute=1&loop=1&playlist=j2xQASA-PbA&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

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](https://www.godrift.ai/blogs/mobile-robot-sim-ros2) 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

&nbsp;

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.

&nbsp;

That gap matters more than it looks. Sensing is the first step of the [sense, think, act loop](https://www.godrift.ai/blogs/what-is-a-robot) 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

&nbsp;

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.

&nbsp;

Miss one and the sim launches but publishes nothing. Instead of doing that by hand, I asked [Drift](https://link.godrift.ai/lidar) to integrate the sensor into the existing workspace:

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

Here's what it did, in order:

1. **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.
2. **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.
3. **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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

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 that turns natural language prompts into production-ready simulation workspaces. It supports ROS 2, Gazebo, MuJoCo, and Isaac Sim, automatically generating URDF, SDF, MJCF, and USD files, configuring plugins and controllers, and scaffolding complete colcon workspaces.


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

*2026-06-12 · Drift Team · Research · 4 min*

> A Roomba, an arm, a drone, a Tesla. What makes a machine a robot? The definition is messy, but almost every robot runs one loop: sense, think, act.

<https://godrift.ai/blogs/what-is-a-robot>

---
---

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.

&nbsp;

<figure data-type="youtube-embed" data-yt-id="h7IWta6JhmQ" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/h7IWta6JhmQ?autoplay=1&mute=1&loop=1&playlist=h7IWta6JhmQ&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
</figure>

&nbsp;

## When does a machine become a robot?

&nbsp;

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?

&nbsp;

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

<figure>
  <img src="https://uzakymai5lbn8o9r.public.blob.vercel-storage.com/robot-definition-confidence-spectrum-VFHZru4rV2IOPolIydQF09o5JWc6Za.png" alt="robot definition confidence spectrum" />
  <figcaption>The further right you go, the less sure anyone is. That fuzzy middle is the whole problem.</figcaption>
</figure>

## Why there's no single definition of a robot

&nbsp;

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.

&nbsp;

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.

&nbsp;

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

&nbsp;

<figure>
  <img src="https://uzakymai5lbn8o9r.public.blob.vercel-storage.com/what-is-a-robot-device-lineup-4t46ng6NWgdfo9kwhcAp6fwSwsKiNW.png" alt="what is a robot device lineup" />
</figure>

## The sense, think, act loop every robot shares

&nbsp;

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

&nbsp;

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.

&nbsp;

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

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

&nbsp;

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.

&nbsp;

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

&nbsp;

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.

&nbsp;

Curious how this loop plays out in real simulations? See how Drift builds a [mobile robot simulation in ROS 2 from a single prompt](https://www.godrift.ai/blogs/mobile-robot-sim-ros2).

## FAQ

1. **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.
2. **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.
3. **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.
4. **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.
5. **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)

*2026-06-11 · Drift Team · Product · 4 min*

> LeRobot from Hugging Face packs datasets, policies, and simulation tools into one big repo. See how Drift maps its whole structure from a single prompt.

<https://godrift.ai/blogs/lerobot-codebase-explained>

---
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.

<figure data-type="youtube-embed" data-yt-id="eM33nfy2uZs" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/eM33nfy2uZs?autoplay=1&mute=1&loop=1&playlist=eM33nfy2uZs&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
  <figcaption>Watch Drift map the entire LeRobot codebase from Hugging Face, datasets, policies, and simulation tools, from a single prompt.</figcaption>
</figure>

## 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 [Drift](https://link.godrift.ai/repo) in one prompt

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](https://link.godrift.ai/repo)** and asked it to read the repo:

> **"Inspect the lerobot directory and give a 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

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, don't start by clicking through folders. Clone the repo, open [Drift](https://link.godrift.ai/repo), and ask it to map the codebase for you.

## FAQ

1. **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.
2. **What is ****[Drift](https://link.godrift.ai/repo)****?** 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.
3. **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.
4. **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.
5. **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.
6. **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.


# Building a Mobile Robot Simulation in ROS 2 From a Single Prompt

*2026-06-10 · Drift Team · Product · 5 min*

> Building a mobile robot simulation in ROS 2 and Gazebo from a single prompt, starting from an empty workspace, no packages or URDF needed.

<https://godrift.ai/blogs/mobile-robot-sim-ros2>

---
Building a **mobile robot simulation in ROS 2** is supposed to be the easy part, the hard problems are perception, planning, and control. So why does so much of the day disappear *before* you reach any of them, just wiring up a workspace and coaxing Gazebo to open?

<figure data-type="youtube-embed" data-yt-id="yZP4p9y3_Zk" data-autoplay="1" data-loop="1">
  <iframe src="https://www.youtube.com/embed/yZP4p9y3_Zk?autoplay=1&mute=1&loop=1&playlist=yZP4p9y3_Zk&rel=0&playsinline=1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen loading="lazy"></iframe>
  <figcaption>Watch a full mobile robot simulation in ROS 2 and Gazebo , a differential drive robot with LiDAR, built from a single prompt, starting from an empty workspace</figcaption>
</figure>

## 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](https://link.godrift.ai/blog)** 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 gave this prompt:

> **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

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.

It's the same shift Drift brings to understanding existing code, like when I had one [explain the LeRobot codebase](https://www.godrift.ai/blogs/lerobot-codebase-explained) instead of reading it line by line.

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 watch a running ROS 2 + Gazebo simulation come together before you touch a single config file.

**[Build your first simulation with Drift →](https://link.godrift.ai/blog)**

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

### FAQ:

1. **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.
2. **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.
3. **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.
4. **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.
5. **What is Drift?** Drift is an end-to-end robotics simulation engineering agent that turns natural language prompts into production-ready simulation workspaces. It supports ROS 2, Gazebo, MuJoCo, and Isaac Sim, automatically generating URDF, SDF, MJCF, and USD files, configuring plugins and controllers, and scaffolding complete colcon workspaces.