Buy vs build vs simulate: the research robot decision

The three-fork decision that most labs skip

A research group with a new grant and a robotics problem to solve often moves directly to "which platform should we buy?" without pausing at the prior question: "should we buy a platform at all right now?"

In practice, every new robotics research program faces a three-way fork. The first option is purchasing a commercial platform—a robot built and sold by a vendor, with a defined software ecosystem. The second is building custom hardware from components—actuators, frames, compute, sensors assembled and integrated in-house. The third is staying in simulation—using physics engines like MuJoCo, Gazebo, or Nvidia Isaac Sim to develop, test, and publish algorithms before committing to hardware.

Each fork is correct under specific conditions. Choosing the wrong one early is expensive: buying hardware for a research question that simulation would have answered sets you back $80,000 and six months. Building custom hardware for a domain where commercial platforms already exist wastes engineering talent. Staying in simulation too long for problems that require physical contact dynamics leads to a publication record that cannot claim hardware validation.

This article gives a framework for making this choice deliberately, and examines the economics of each option.

Option A: Buy a commercial platform

When buying is right

Commercial platform purchases make economic sense when at least three of the following conditions hold:

1. The hardware form factor is settled science for your domain. Mobile navigation research on a differential-drive platform, for example, benefits from a known-quantity platform—the algorithms are the research, not the hardware. A platform like the Clearpath Husky (husky-observer) or Dingo-O (dingo-o) lets a lab run locomotion-agnostic experiments without spending engineering budget on chassis design.

2. The vendor ecosystem already supports the lab's software stack. If the platform has an active ROS 2 community, published simulation models, and maintained drivers, the integration cost is bounded and predictable.

3. The lab needs to make physical contact with the world in ways simulation cannot replicate. Manipulation research involving real deformable objects, HRI (human-robot interaction) involving real humans, and sensor fusion research with real sensor noise all have a physical-reality requirement that simulation cannot satisfy without significant modeling overhead.

4. The platform will be shared across multiple research projects or student cohorts. A commercial platform with a large user community distributes the per-user learning curve. A custom platform that only one student understands becomes a liability when that student graduates.

5. Time-to-research matters more than cost. A lab with a three-year grant and a deadline-driven publication schedule often cannot afford the 12–18 months a quality custom build takes. A commercial platform that is "good enough" and available now is often the right economic choice.

Commercial platform economics

The full three-year TCO for commercial platforms is addressed in detail in "The real cost of a research platform." The headline number is that hardware sticker price typically represents 30–50% of three-year actual spend once sensors, integration, and maintenance are included. The economic case for buying improves when:

• The platform has strong community documentation that reduces per-student integration time
• The vendor commits to parts availability for the duration of the grant
• Simulation models are available for pre-deployment testing

Option B: Build from components

When building is right

Custom hardware is genuinely justified in a narrower set of circumstances than most labs believe at the start of a research program. The legitimate cases are:

1. No commercial platform exists in your target form factor or capability range. Novel locomotion research—bipedal morphologies, soft robots, bio-inspired systems—often requires custom hardware because the commercial market has not reached that configuration. MIT's Mini Cheetah (mini-cheetah) was a custom research build because no commercial quadruped with its specific torque-density and open-source control architecture existed when the project started. DLR's Agile Justin (agile-justin) is custom because the dual-arm manipulation capability it embodies at that integration level has no commercial equivalent.

2. The mechanical design is itself the research contribution. If the paper is about a new actuator, a new structural design, or a new morphology, you need to build the hardware. If the paper is about a planning algorithm, you probably do not.

3. The lab has the mechanical and electrical engineering talent to execute a build to research-quality standards. This is a harder constraint than it looks. A quality custom platform that is mechanically robust, electrically clean, and maintainable across student generations requires a dedicated mechanical engineer, an electrical engineer, and a software engineer working in close coordination. At many universities, that talent does not sit inside the robotics lab.

4. Long-term total cost favors building. For platforms that will be maintained and evolved over a decade, a custom build with modular components and an open software architecture may have a lower cost per experiment-year than successive commercial platform purchases.

Build economics

The honest economics of a custom research platform: a quality build from components capable of matching a mid-range commercial platform's performance takes 12–24 months of engineering time and $30,000–$100,000 in components, depending on actuator selection and sensor suite. The first year is almost entirely engineering time, not research output.

The leverage question is: "Will this platform enable research that a commercial platform cannot, or enable it significantly cheaper over a 10-year horizon?" If the answer is no, building is optimization at the wrong level.

Option C: Start in simulation

When simulation is right

Simulation is not a fallback for labs that cannot afford hardware. For a significant class of robotics research problems, simulation is the correct first environment—and sometimes the correct permanent environment.

MuJoCo (Multi-Joint dynamics with Contact) is the dominant physics engine for contact-rich manipulation and locomotion research. Its differentiable physics and efficient contact modeling make it the standard environment for reinforcement learning (RL) research in robotics. A large fraction of recent RL-for-locomotion and RL-for-manipulation papers were developed primarily or entirely in MuJoCo. The 2021 transfer to Google DeepMind and subsequent open-source release made it freely available.

Gazebo (now subdivided into the Classic and Ignition/Gz Gazebo variants) is the standard simulator in the ROS ecosystem. Gazebo Classic is what the majority of existing ROS tutorials and robot models target. Ignition/Gz Gazebo (now rebranded Gazebo Sim) is the current development target for ROS 2 integration. For mobile navigation, SLAM, and multi-robot coordination research, Gazebo provides sensor simulation (LiDAR, cameras, IMUs) that is sufficient for algorithm development.

Nvidia Isaac Sim is a high-fidelity photorealistic simulator built on the Omniverse platform. It renders photo-accurate environments, supports GPU-accelerated physics, and is well-suited for sim-to-real transfer research in manipulation and navigation. It requires an Nvidia GPU and has a steeper setup curve than Gazebo or MuJoCo, but the photorealism makes it the right choice for perception-heavy work where synthetic training data quality matters.

When simulation is not enough

Simulation has three well-known limitations that make hardware necessary at some point in a research program:

1. Sim-to-real gap on contact dynamics. Manipulation tasks involving deformable objects, textured surfaces, and complex friction are poorly modeled by current physics engines. An algorithm that works in simulation may fail completely on hardware due to unmodeled contact phenomena.

2. Sensor noise and calibration. Simulated sensors are cleaner than real sensors. Research that depends on sensor fusion across modalities—LiDAR + camera + IMU—needs hardware validation because the correlation structure of real sensor noise does not match simulation.

3. Human presence in HRI research. Human behavior in the presence of a real robot differs from behavior in virtual or Wizard-of-Oz settings. HRI research that makes claims about real human response requires a real robot.

The decision matrix

The staged approach

Many successful research programs follow a staged sequence: begin in simulation, validate algorithms on commercial hardware, then (if justified) design custom hardware for the capability gap the commercial platform cannot address.

This is not a compromise—it is a rational allocation of risk. The simulation phase validates that the algorithm works in principle and is publishable. The commercial hardware phase validates real-world robustness and extends the publication record. The custom hardware phase, if it happens at all, is funded by publications that demonstrated the research direction is productive.

ANYbotics' ANYmal (anymal-d) exists as a commercial platform today partly because the ANYmal research lineage at ETH Zurich followed this arc: legged locomotion algorithms developed in simulation were validated on custom hardware, which matured into a commercial product. For labs working in legged locomotion research, the existence of ANYmal means the custom-build justification bar is higher than it was before 2016.

Similarly, the existence of Nauticus Robotics' Aquanaut (aquanaut) and Independent Robotics' Aqua2 (aqua2) in the underwater space means labs studying underwater manipulation and navigation have commercial starting points that would have required custom builds a decade ago.

A practical decision checklist

Before committing to a path, a lab manager or PI should be able to answer:

For simulation-first:

• Is the research question answerable without physical contact dynamics?
• Does an existing simulation model exist for the target morphology?
• Is sim-to-real transfer validation required for publication in our target venues?

For commercial purchase:

• Does a platform exist with the needed capability and an active ROS 2 community?
• Is the three-year TCO within budget (see "The real cost of a research platform")?
• Can a new grad student be productive on this platform within four to eight weeks?

For custom build:

• Does the lab have dedicated mechanical and electrical engineering staff?
• Is the hardware design itself a research contribution?
• Is the build timeline acceptable given the grant's publication milestones?

What comes next

The decision of what to buy is addressed in the next article: "Decision framework: matching platform to research goal" maps specific platform types to research domains—manipulation, legged locomotion, mobile navigation/SLAM, HRI, multi-robot/swarm, and underwater/aerial—and evaluates ecosystem fit for each.