Why research robot purchases get stranded

The robot in the corner

Picture a university robotics lab in year three of a five-year NSF grant. On a workbench near the window sits a mobile manipulation platform that cost roughly $85,000 two years ago. It powers on. The arm moves. The demo that closed the purchase still runs. But the postdoc who integrated it with the lab's ROS (Robot Operating System) environment graduated in December, and nobody else can replicate his workspace. The vendor's SDK is Windows-only. The ROS 1 driver the postdoc wrote lives in a private repo that wasn't handed off. The vendor's support contract expired, and the replacement part for the wrist encoder—the one component that failed during last month's experiment—has a 14-week lead time.

No paper has come out of this platform in eight months. The PI is staring at a budget line that calls itself infrastructure.

This is not a rare story. Lab managers and research engineers across academia and corporate R&D encounter it regularly, because the procurement process for research robots borrows too heavily from the procurement process for equipment—centrifuges, oscilloscopes, 3D printers—where "does it work as described?" is a sufficient test. For research robot platforms, that test misses the harder questions: Can a rotating cast of grad students and postdocs keep working on this? Can I reproduce my experiments in two years? Will this platform still have a community when my next grant cycle starts?

This article lays out a framework for answering those questions before the purchase order goes out. The remaining articles in this series cover the full three-year TCO, the buy-vs-build-vs-simulate decision, matching platforms to specific research domains, a 90-day lab stand-up playbook, and a procurement RFP with red-flag checklist.

Why research robots fail differently than lab equipment

Standard scientific equipment is a tool with a narrow interface: you supply power, consumables, and trained operators, and it produces data. A research robot is a programmable platform with a software ecosystem, a hardware supply chain, a community of practitioners, and a moving target of compatible middleware. Four failure modes show up repeatedly.

Failure mode 1: Closed or proprietary SDK lock-in. A vendor ships a Python API or a graphical programming environment that works in their demo environment and nowhere else. ROS 2 (Robot Operating System 2, the current community standard for open research robotics middleware) is not supported, or is supported only through an unmaintained third-party wrapper. When the lab wants to run a custom controller or integrate a new sensor, the vendor's API does not expose the necessary hardware interfaces. The lab is stuck in the vendor's walled garden.

Failure mode 2: ROS/ROS 2 ecosystem mismatch. ROS 2 is the de facto research middleware as of 2024–2025, with the Humble Hawksbill (2022, LTS) and Iron Irwini/Jazzy Jalisco (2023–2024) distributions in active use. Many platforms still ship with ROS 1 Noetic support only, which reached end-of-life in May 2025. If a lab's pipeline is built on ROS 2 and the vendor's robot driver is ROS 1, someone is writing a bridge or a new driver from scratch—an unbudgeted month of engineering.

Failure mode 3: Human key-person dependency. A single lab member integrates the platform and carries the institutional knowledge. When they leave—and in academic labs, they always leave—the knowledge leaves too. This is partly a lab process problem, but it is also a platform problem: if the platform requires deep, non-transferable expertise to operate, the risk scales with lab turnover. Platforms with clean URDF (Unified Robot Description Format) models, well-documented APIs, and active community forums flatten the ramp for the next person.

Failure mode 4: Spare parts and obsolescence deserts. A research robot is not a consumer product with a mass market behind it. Some platforms are sold in dozens of units per year, not thousands. When a component fails, "order from stock" is sometimes not an option. Labs that did not negotiate a spares arrangement upfront—or did not ask how long the vendor commits to stocking parts—find themselves with a platform that cannot be repaired in time for the next conference deadline.

The framework: four buying criteria that matter for research

The goal of the framework is to shift the evaluation from "does it perform the task?" to "can this lab build a research program on it?" These are four distinct questions.

1. Software openness and middleware fit

The minimum viable bar for a research platform is source-accessible drivers in a language the lab already uses, and either native ROS 2 support or a vendor-maintained ROS 2 package in the public ROS index (index.ros.org). The difference between a vendor-maintained package and a community-contributed wrapper is significant: vendor-maintained packages tend to get updated when the robot's firmware changes; community wrappers go stale when the contributor moves on.

Questions to ask: Is the robot's full sensor/actuator API accessible without the vendor's client library? Does the vendor contribute to or maintain a ros2 package? Is the software open-source or source-available (the distinction matters—source-available lets you read and modify; open-source lets you redistribute)?

2. Reproducibility infrastructure

Research papers require reproducibility. A platform that makes reproducibility easy—published URDF/MJCF simulation models, deterministic state logging, version-pinned firmware releases—is a research asset. One without these shifts the burden of reproducibility entirely to the lab.

Clearpath Robotics platforms like the Husky have been widely used in mobile navigation and SLAM (Simultaneous Localization and Mapping) research partly because the ROS packages and URDF models are publicly maintained and have a long commit history. This makes it straightforward to check out the exact environment a previous experiment used.

The ANYmal series from ANYbotics has a published simulation model and a legged locomotion community that has contributed benchmark datasets. That community infrastructure is a reproducibility asset independent of the hardware.

3. Supply chain and lifecycle commitment

Ask the vendor two specific questions: How long will you commit to stocking spare parts for this platform? What is your end-of-life policy—will you provide hardware schematics or repair documentation when the product is discontinued?

A five-year parts commitment with a published end-of-life notice is meaningfully better than "we'll try to keep parts available." Labs running multi-year grants need that commitment in writing, ideally in the purchase agreement.

For university labs with limited technical staff, also ask about repair turnaround and whether the lab can perform field repairs with vendor-supplied documentation. A platform that requires depot return for every actuator swap is a liability on a tight experimental schedule.

4. Community and ecosystem health

The longevity of a platform's usefulness correlates with the size and activity of its user community. This is measurable: GitHub commit frequency on the vendor's ROS package repo, Stack Overflow / ROS Answers activity, paper citations that name the platform, and whether the vendor runs or participates in a user forum or annual workshop.

This is not a vanity metric. A healthy community means the lab is not alone when it encounters an edge case. It means there are papers to cite that used the same platform. It means graduate students entering the field already know how the platform works.

Applying the framework before the purchase

A practical pre-purchase evaluation takes two to four weeks and requires access to a demo unit or detailed technical documentation. The four-criteria check maps to concrete activities:

If the vendor cannot or will not provide a URDF, won't commit to a support window in writing, and has a ROS package last updated two years ago, those are not minor concerns—they are signals about what the lab's experience will be in year two.

What the stranded-platform scenario usually has in common

Looking across the failure mode patterns, stranded research robots tend to share a cluster of traits: they were evaluated on hardware performance specs rather than software ecosystem; the procurement was driven by a single lab member who later left; no spares were purchased at time of acquisition; and the lab did not pilot the platform in its actual software environment before committing.

The inverse is also true. Platforms that stay productive across multiple students and multiple papers tend to be ones where the lab spent a month on a proper pilot, purchased a two-year spares kit, and specifically evaluated ROS 2 driver quality before signing.

The hardware performance gap between modern research platforms in a given category—legged locomotion, mobile manipulation, underwater—is often smaller than it looks in spec sheets. The software ecosystem gap is usually larger.

What comes next

The next article in this series—"The real cost of a research platform"—breaks down the three-year TCO including sensor/payload additions, ROS integration engineering time, student labor, and obsolescence costs, using planning ranges grounded in what labs actually spend rather than sticker prices.