The real cost of a research platform

The gap between the PO and the actual spend

When a research group budgets for a robot platform, the purchase order typically captures two items: the robot itself and perhaps an initial extended warranty. What the PO does not capture is the system around the robot—the sensor stack, the middleware engineering hours, the compute, the spare parts, the student and postdoc time, and the cost of repeating some of this work when the platform reaches the end of its useful research life.

For a typical research-grade mobile manipulation platform, the hardware sticker price often represents 30–50% of the three-year total cost. The rest is invisible at purchase time, allocated against other budget lines (student stipends, compute grants, sensor budgets), or simply not anticipated.

This article breaks down the full three-year total cost of ownership (TCO) using representative planning ranges drawn from the structure of what research labs typically spend—not vendor-specific prices, which vary by region, academic discount, and configuration. The goal is to give a PI or lab manager a template for building a realistic budget before the grant proposal goes out.

The six cost buckets

Bucket 1: Platform hardware

This is the number on the quote. It includes the robot base, any bundled sensors, a standard computing payload, and basic safety accessories. It does not include extended warranties or spares.

For planning purposes, research-grade platforms by category break roughly into:

These are wide ranges because configuration matters enormously. A Clearpath Husky base with no payload sits at the low end of mobile bases. A fully instrumented ANYmal with a manipulator arm and a 3D LiDAR payload sits at the high end of legged platforms. Use the quote for your specific configuration and treat this table as a check against implausible numbers.

Bucket 2: Sensor and payload additions

Very few research platforms arrive with all the sensors a research program actually needs. A SLAM (Simultaneous Localization and Mapping) study needs a 3D LiDAR. A manipulation study needs a depth camera and possibly a force-torque sensor at the wrist. An HRI (human-robot interaction) study needs a microphone array and perhaps an RGB-D sensor for person tracking. These are purchased separately, integrated separately, and calibrated separately.

A realistic sensor add-on budget for a first-year deployment is $8,000–$25,000, depending on the research domain. Build this into the grant budget as a separate line, not an afterthought.

Bucket 3: ROS integration and middleware engineering

This is the most frequently underestimated cost in research robot deployments. Getting a platform to the point where a graduate student can run reproducible experiments in a lab's ROS 2 environment requires: verifying or writing the ROS 2 driver, integrating the sensor stack, building a simulation model for pre-deployment testing, configuring a Docker or container environment for reproducibility, and writing the data-logging and experiment-replay infrastructure.

For a platform with good vendor ROS 2 support (published package, active maintenance, working URDF), this is a two-to-six week task for an experienced research engineer or a postdoc. For a platform with poor support or ROS 1-only drivers that need porting, it can stretch to three months—and the output may still be brittle.

At a postdoc/research engineer loaded labor rate of roughly $50–$80/hour (US academic, fully loaded), three months of integration work costs $25,000–$40,000 in salary-equivalent time that produces no publishable output.

Bucket 4: Maintenance, spares, and repairs

Research robots are not production floor robots. They run experiments, they fall, they are modified, they have sensors mounted and remounted. Over three years, a typical active-use research platform will need:

• Consumables: batteries ($500–$3,000 per cycle depending on platform), cables, connectors, 3D-printed mounts
• Wear components: wheels, grippers, actuator seals
• Unplanned repairs: one to three events per year in active use, ranging from $500 for a cable replacement to $15,000+ for an actuator overhaul

A conservative three-year maintenance budget is 8–15% of platform hardware cost per year. For a $90,000 platform, budget $7,200–$13,500 per year, or $21,600–$40,500 over the grant period. Labs that negotiate a spares kit at purchase time typically spend less per event.

Extended warranties from vendors typically run 10–15% of platform cost per year and often cover labor for depot repairs but not shipping or consumables. They are worth evaluating against the lab's in-house repair capability.

Bucket 5: Student and postdoc labor

Every hour a graduate student or postdoc spends fighting the robot stack is an hour not spent on research. This cost is real but diffuse—it rarely shows up as a discrete line item. It shows up as longer time-to-first-paper, more thesis revisions, and postdoc extensions.

A framework for estimating platform-maintenance labor: in a healthy deployment, a graduate student should spend no more than 10–20% of their time on platform upkeep after the first three months. In an unhealthy deployment—one with poor ROS support, fragile drivers, or high hardware fault rates—that share can exceed 50%.

Over a four-year PhD, 50% platform-maintenance overhead at a graduate student stipend of $30,000–$35,000/year (US STEM) represents $60,000–$70,000 in effectively non-research-productive labor. This is not a reason to avoid research robots; it is a reason to invest in platform selection and documentation.

Bucket 6: Obsolescence cycle

Research robot platforms have useful research lives. A platform purchased in 2020 running ROS 1 Noetic is, as of 2025, at the end of its supported software life. Labs that want to continue publishing will need to either port to ROS 2 (a significant engineering effort) or migrate to a new platform. The migration cost—hardware, integration, a new spares kit, new simulation model—is essentially the upfront cost of a new platform, compressed.

This cycle runs roughly every four to seven years for platforms in active development. Plan for it in grant renewals rather than being surprised by it.

Three-year TCO summary table

The following table assembles the buckets into a planning scenario for a mid-range mobile manipulation platform. Numbers are ranges, not vendor quotes.

Student/postdoc platform-maintenance labor is excluded from this table because it is embedded in existing stipend lines, but the 10–50% overhead range above should inform how you value good platform selection.

The practical implication: a $90,000 platform that requires $40,000 in ROS integration and $30,000 in sensor additions is a $160,000 first-year commitment. A $120,000 platform with excellent ROS 2 support and a bundled sensor payload may cost $140,000 in year one and half as much in year two. The sticker price comparison is not the right comparison.

Grant proposal implications

National funding agencies (NSF, NIH, DOE, DARPA) typically allow infrastructure purchases under direct costs. Most require a justification for equipment purchases above a threshold ($5,000–$25,000 depending on the program and institution). A well-structured equipment justification includes:

1. The research tasks the platform enables that cannot be accomplished another way
2. A brief equipment lifecycle estimate (four to seven years for most platforms)
3. Shared use potential—will other groups in the department use this platform?
4. Maintenance costs, typically as a percentage of hardware cost

Reviewers and grants officers familiar with robotics research are accustomed to platform costs in the ranges above. What they are not used to seeing—and what tends to strengthen a proposal—is an honest accounting of integration and maintenance costs, rather than treating the hardware cost as the entire infrastructure budget.

The hidden leverage point

If there is one place where careful pre-purchase evaluation pays the largest dividend, it is ROS 2 driver quality. The difference between a platform with a mature, vendor-maintained ROS 2 stack and one without is 40–80 hours of integration engineering time per new student who joins the project, multiplied over the life of the platform.

A platform with a Dingo-O (dingo-o) or Husky Observer (husky-observer) level of community documentation and maintained ROS packages—where a new graduate student can be running their first experiment in a week—has a lower effective cost than a technically superior platform that requires months of integration work to reach the same point.

What comes next

"Buy vs build vs simulate"—the next article in this series—examines when purchasing a commercial platform makes economic sense, when building from components is justified, and when simulation tools like Isaac Sim (Nvidia), Gazebo, or MuJoCo can replace or delay hardware entirely.