One set of legs, ten different robots

I'm building a walking robot that I can take apart and reconfigure. There are six identical leg modules and a body plate with eight places to attach them. Four legs makes a quadruped; six makes a hexapod; other arrangements give me different body shapes to test. The goal is for the robot to detect which legs are attached and use the same learned controller across all those configurations.

I started the semester planning to make a vacuum testbed, but switched to this project in week 4. It fits the class and gives me hardware I can use in my research afterward.

Some recent work suggests that a controller trained on a larger variety of simulated robot bodies can generalize better to new ones. That's exciting, but the physical validation so far has been limited. I want to find out whether the same trend holds when you test on more real robots. The catch is that most robots aren't easy to rebuild, and modular research platforms can be expensive. So I'm trying to make one that's relatively cheap and quick to reconfigure. If the hardware works, I'd like to run the experiment between December and February and aim for an IROS 2027 submission.

More broadly, this is the question I want to work on: how do we make controllers that can adapt when the robot's body changes?

The robot brings together most of the things we cover in class: 2D and 3D design, machining, 3D printing, circuit design, firmware, sensors and system integration. Here's how I'm planning to tackle the pieces across the semester.

I'm developing the simulation in parallel with the hardware rather than waiting for the robot to be finished. I started that part in week 4 using MuJoCo MJX and JAX. For now it runs on my laptop CPU; the same code should be able to run on a GPU for larger training runs.

One awkward part of MJX is that environments in a batch need to share a model structure. I'm getting around that by using a six-legged base model for every robot and changing its parameters. For example, a missing leg becomes almost massless, sits tucked inside the body and has its actuator disabled. That lets one batch contain many different configurations. The controller also gets a compact description of the body: which ports have legs, where those legs are and their link lengths. Eventually I'd like the physical robot to generate that description itself.

generator.py   module graph + parameters -> MJCF; the 10-body test set; random body sampler
env.py         MJX environment, one batched model, a different body per environment
train.py       PPO (brax) over a population of bodies; the 1 / 10 / 100 / 1000-body sweep
evaluate.py    run a checkpoint on all 10 test bodies -> the simulation side of the scaling curve

pip install mujoco mujoco-mjx brax           # GPU: pip install -U "jax[cuda12]"
python3 generator.py                         # the 10 test bodies stand under PD control
python3 train.py --smoke                     # CPU pipeline check, a few minutes
python3 train.py --mode scaling --n_bodies 10   --steps 100_000_000 --tag n10
python3 train.py --mode scaling --n_bodies 1000 --steps 100_000_000 --tag n1000
python3 evaluate.py runs/n1000.pkl           # writes n1000_eval.json

The pipeline currently runs end to end on CPU: I've done a small 256-step training test and evaluated the policy on a tripod configuration. Proper training is the next step and will need a GPU. The actuator dynamics, foot friction and communication delays are still placeholders. I'll replace them with measurements as I build and test the hardware.

The experiment is to train four controllers, each exposed to a different number of simulated bodies: 1, 10, 100 and roughly 1,000. Then I'll test each controller, without fine-tuning, on the ten physical configurations shown above. I want to compare success rate and velocity error in simulation and on hardware. Does performance keep improving as training diversity increases, or does the real-world curve level off? Either outcome would tell me something useful about transferring controllers across morphologies.

I'm keeping the measurement setup fairly simple. An overhead webcam will track an AprilTag on the robot to estimate velocity, and I'll use servo current and voltage to estimate electrical energy use. I'll count a 30-second run as successful if the robot neither falls nor stalls. With five trials per condition, the main comparison comes to 200 runs. I'm budgeting about two days for testing and swapping configurations.

Final orders close on December 4, so I need to order anything for the January experiments, including spares, before then.

Papers I'm using as references include Whitman, Travers and Choset on modular robot policies (T-RO 2023), URMA (CoRL 2024), Ai et al. on embodiment scaling (CoRL 2025), UniLegs (IROS 2025), DyRET (Nature Machine Intelligence 2021), and the BAM actuator identification work. I used AI assistants to help find and organize papers and to work on the simulation code. The research question, design choices and criteria for evaluating the result are my own.