flybody: The Fruit Fly Body Model DeepMind Built for MuJoCo

Update — September 26, 2026: Google reposted the complete male fruit fly CNS connectome (166k+ neurons, nerve cord included) — the wiring map that simulation projects like flybody eventually need to close the loop from neurons to movement.

Most reinforcement learning benchmarks for legged locomotion use bodies that don't exist in nature — MuJoCo's Ant and Humanoid are convenient abstractions, not biology. flybody takes the opposite approach: it's an anatomically detailed simulation of an actual animal, the fruit fly Drosophila melanogaster, built so researchers can train real control policies on a real (simulated) nervous system's worth of joints and muscles.

The project comes from a collaboration between Google DeepMind and HHMI Janelia Research Campus, and the underlying science was published in Nature in 2025 as "Whole-body physics simulation of fruit fly locomotion" by Roman Vaxenburg and 12 co-authors. The repository has drawn 675 GitHub stars and 86 forks — modest by AI-tooling standards, but notable for a computational neuroscience release, and a signal that the sim-to-behavior approach is resonating past its original lab.

TL;DR

What flybody actually models

The fly body in this repo isn't a stylized six-legged robot — it's built from the Drosophila's real exoskeleton geometry, joint arrangement, and muscle-actuator dynamics, rendered as a MuJoCo XML model (fruitfly.xml, plus a floor.xml variant) you can drag straight into MuJoCo's simulate viewer with no code at all. The included fly-white.png and the paper's figures show collision geometry down to individual leg segments, something a generic legged-robot MuJoCo model never bothers with because it doesn't need to match a real animal's mechanics.

That level of fidelity is the whole point. A world model trained to predict pixels doesn't have to get muscle torques right; a body model built to test hypotheses about how a fly's nervous system controls its own body does. flybody sits closer to physical simulators like NVIDIA's Cosmos physical-AI world models in spirit — physics-grounded, not just visually plausible — but scoped to one specific, extremely well-studied organism instead of general robot embodiments.

Getting started

Installation follows a standard conda + pip pattern, with three install tiers depending on how much of the stack you need:

git clone https://github.com/TuragaLab/flybody.git
cd flybody
conda create --name flybody -c conda-forge python=3.10 pip ipython cudatoolkit=11.8.0
conda activate flybody

Drop the -e flag for a non-editable install, or install directly from the remote repo (pip install git+https://github.com/TuragaLab/flybody.git) without cloning first.

Once installed, interacting with the fly is a few lines of Python:

import numpy as np
import mediapy

from flybody.fly_envs import walk_imitation

# Create walking imitation environment.
env = walk_imitation()

# Run environment loop with random actions for a bit.
for _ in range(100):
   action = np.random.normal(size=59)  # 59 is the walking action dimension.
   timestep = env.step(action)

# Generate a pretty image.
pixels = env.physics.render(camera_id=1)
mediapy.show_image(pixels)

That 59-dimensional action space is worth pausing on — it's a rough proxy for how many independently actuated degrees of freedom the fly's legs require just to walk, versus the handful of joints a typical legged-robot RL benchmark uses. The repo also ships a Colab tutorial notebook covering the walking, flight, and vision-guided flight task environments, and a Ray-based distributed training script that runs DeepMind Acme's DMPO agent across parallel workers for anyone training a policy from scratch rather than just poking at random actions.

Why a fruit fly body model matters for AI research

Embodied neuroscience, tested in simulation. The core research question isn't "can an agent walk" — plenty of MuJoCo benchmarks already answer that — it's whether a biologically accurate control policy, trained the way a real fly's motor system might operate, reproduces real fly behavior. That's a much harder and more interesting bar than clearing a locomotion benchmark, and it's only answerable if the simulated body's mechanics actually match the organism's.

A testbed for sensorimotor control, not just locomotion. flybody ships flight and vision-guided flight environments alongside walking, which means the same body model supports multiple sensorimotor modalities — a fly deciding how to fly based on what it "sees" is a different, harder RL problem than a legged robot walking on flat terrain, and it's the kind of embodied, multi-sensor control loop that shows up again in robot data-collection pipelines and humanoid robot training stacks more broadly.

Distributed RL at insect scale. The Ray + DMPO training path is the same general shape used across modern RL infrastructure — rollout workers generating experience in parallel, a learner updating a policy from batches, weights synced back out — just applied to a fly instead of a humanoid or a chat model. If you've read how open-source RL-as-a-service stacks decompose into rollout engines, trainers, and environment layers for LLM post-training, flybody's Ray script is the same architecture pattern one level down, running against a physics simulator instead of a language model.

What people are asking

Is this a real robot? No — flybody is purely a simulation. Nothing here builds or controls physical hardware; it's a MuJoCo XML model plus Python environments and training code.

Why a fly specifically, and not a more "useful" robot body? Drosophila is one of the most extensively studied model organisms in neuroscience, with decades of connectome, behavior, and muscle-physiology data available to validate a simulated body against. That existing ground truth is what makes a biophysically accurate model tractable and scientifically checkable — you can't easily do the same validation for an arbitrary robot morphology invented for a paper.

How mature is the project? The repo has a single tagged release (v0.1.0, from two years ago) and one primary contributor (Roman Vaxenburg) alongside the collaboration credited in the paper. It's stable enough to have shipped a Nature publication built on it, but it isn't under active feature development at the pace of a general-purpose robotics framework — expect a focused, research-grade codebase rather than a growing product.

What are the honest limitations? The core install deliberately excludes Tensorflow and Acme, so out of the box you get the body and environments but not turnkey policy training — you need the [tf] or [ray] extras, plus MUJOCO_GL/CUDNN_PATH environment configuration the README calls out explicitly, before training or even GPU-accelerated rendering works. It's also scoped tightly to the fly body itself; there's no built-in path to transfer a trained policy to other simulated organisms or to physical insect-scale robots.

Does it compare to standard MuJoCo RL benchmarks? Not directly — Ant, Humanoid, and Walker2d exist to benchmark control algorithms against each other on a fixed body, while flybody exists to test whether a specific real animal's behavior can be reproduced. Comparing sample efficiency across them tells you more about task difficulty than about which RL algorithm is "better."

Citing the work

If you use flybody in research, the maintainers ask for the Nature citation directly, not just a repo link:

@article{flybody,
  title = {Whole-body physics simulation of fruit fly locomotion},
  author = {Roman Vaxenburg and Igor Siwanowicz and Josh Merel and Alice A Robie and
            Carmen Morrow and Guido Novati and Zinovia Stefanidi and Gert-Jan Both and
            Gwyneth M Card and Michael B Reiser and Matthew M Botvinick and
            Kristin M Branson and Yuval Tassa and Srinivas C Turaga},
  journal = {Nature},
  volume = {643},
  pages = {1312--1320},
  year = {2025},
  doi = {https://doi.org/10.1038/s41586-025-09029-4},
}

The takeaway

flybody is a narrow but well-built example of a broader trend: physics engines like MuJoCo are becoming the shared substrate for both robotics RL and computational biology, because a policy that has to obey real muscle-actuator constraints is forced to learn something closer to how the real system actually works. Whether you're training a humanoid to walk or testing a hypothesis about how a fly's nervous system flies, the tooling — distributed rollouts, a physics-accurate body, an RL agent updating from batched experience — looks the same underneath.

Separate a rendering check from a control experiment

First load the body and render a short sequence to confirm that the environment works. Then test a policy or action sequence with a defined goal. Random actions are an installation exercise; they do not establish walking performance or a biologically plausible controller.

Use the environment's reported action specification rather than carrying a hardcoded dimension into a different task. Record the task configuration, simulation settings, seed, and checkpoint with each experiment. The flybody repository is the reference for the supported environments and dependencies.

For a research comparison, evaluate more than a visually convincing clip. Define the behavior, reference data, and metric before tuning the policy. Include failures and variations across trials, and explain which aspects of the simulated body the experiment assumes are accurate. An anatomically detailed body model supports better questions about control, but it does not by itself prove that the learned policy matches a living fly's nervous system.

Keep exploratory modifications separate from the original model. A changed actuator or contact parameter can materially alter a result even when the rendered fly looks identical. Preserving those changes makes an experiment reviewable and distinguishes a faithful baseline from your proposed extension.

Related on explainx.ai

• What are world models? Complete guide
• Open-source RL-as-a-service: what that phrase actually buys you
• NVIDIA Cosmos 3: open physical AI world model guide
• 500 humanoid robots, Unitree, and the BitRobot dataset
• Figure Helix-02: collaborative humanoid robots
• Official flybody repository
• Nature paper: Whole-body physics simulation of fruit fly locomotion

Repository details, star/fork counts, and version specs in this post are accurate as of the publication date above — check the flybody GitHub repo for the latest release.