# Generating Uneven Terrain for the Spot Robot in MuJoCo
> 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.
**Author:** Drift Team
**Published:** 2026-08-26
**Tag:** Product
**Reading time:** 5 min
**Canonical URL:** 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.

 

\<!-- 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)