The research-robot procurement RFP: questions and red flags

Why vendors need specific questions

A standard equipment procurement process—request a quote, evaluate specs, purchase—is insufficient for research robot platforms. The spec sheet tells you what the platform can do in the vendor's demo environment. It does not tell you what happens when your lab's ROS 2 pipeline talks to the hardware, what the lead time is on the servo that will fail in year two, or whether the platform is export-controlled in a way that prevents shipping it to an international collaborator's lab.

These questions require deliberate solicitation. Vendors who have thought carefully about research use cases will have clear answers. Vendors who have not—or who have made design decisions that create friction for researchers—will hedge, defer, or give answers that sound fine until they are tested in practice.

The questions in this RFP are organized into seven categories. Each category includes a set of specific questions and a description of answers that should give pause—the red flags. The overall 90-day deployment process that follows a successful procurement is covered in the previous article: "A 90-day playbook to stand up a new platform in a lab."

Category 1: SDK and API openness

The software interface to the hardware is a long-term research constraint. The questions in this category determine whether the platform is a tool the lab controls or a platform the vendor controls.

Questions to ask:

1. Is the full hardware API (all joints, all sensors, all actuators) accessible via a documented, versioned public interface, without requiring the vendor's client library?
2. What programming languages have officially supported interfaces? (Python and C++ are the minimum for ROS 2 work.)
3. Is the hardware API open-source, source-available, or binary-only?
4. Are the communication protocols between the onboard computer and actuators documented at the byte level?
5. Can the lab run a custom operating system or a custom ROS 2 environment on the onboard computer, or is the onboard compute locked to vendor-provided software?
6. What is the vendor's policy on API stability? Are breaking changes versioned and announced in advance?

Red flags:

• "The API is documented in our SDK reference guide, but the SDK is required for access." This means the lab is dependent on the vendor's binary library, which may not be updated for new ROS 2 distributions.
• "You can access most sensors through the API." The word "most" is load-bearing. Ask which sensors are excluded and why.
• "The onboard computer runs our proprietary OS and cannot be replaced." The lab cannot install software it controls, which is a long-term research constraint.
• No versioning policy for API changes. Breaking changes without notice is a common cause of lab research code going stale after a firmware update.

Category 2: ROS and ROS 2 support

This category is the most common source of post-purchase friction. The questions here should be asked of the vendor's engineering team, not just their sales team.

Questions to ask:

1. Does the vendor maintain a public ROS 2 package on the ROS index (index.ros.org)?
2. Which ROS 2 distribution(s) are currently supported, and what is the update policy when new LTS distributions are released?
3. Is a URDF model of the platform publicly available? Is a Gazebo or Isaac Sim model available?
4. Is the ROS 2 package open-source? Is the vendor the primary maintainer, or is it maintained by the community?
5. What is the typical latency between a ROS 2 command published to the control topic and actuator response? Is this documented?
6. Does the vendor support ros2_control (the standard hardware abstraction layer)? If so, which controller types are available?
7. Who should the lab contact for ROS 2 integration questions—a dedicated support engineer, a community forum, or sales?

Red flags:

• "We support ROS 1 and have a community-maintained ROS 2 bridge." A community-maintained bridge goes stale when the contributor moves on. This is not equivalent to vendor-supported ROS 2.
• "Our ROS 2 package was last updated 18 months ago." Check the GitHub commit history before the call. Stale packages are a flag for vendor investment in research use cases.
• "We don't have a URDF but can provide CAD files." STEP/IGES files require engineering work to convert to URDF. This is an integration cost, not a feature.
• No ros2_control interface. The ROS 2 ecosystem has converged on ros2_control as the hardware abstraction layer. Platforms without it require custom controller code that does not compose with standard ROS 2 tools.
• "Contact sales for technical questions." Research labs need access to engineers who can answer low-level API questions. A sales funnel for technical support is a red flag.

Category 3: Academic pricing and licensing

Research budgets are structured differently than corporate procurement budgets. Vendors who understand the research market offer pricing structures that reflect this.

Questions to ask:

1. Does the vendor offer an academic research discount? If so, what is the discount rate and what documentation is required (institutional affiliation letter, PI name)?
2. Does the academic price include a source-code license (for vendors with proprietary software)?
3. Are there usage restrictions in the academic license? Specifically: can research results be published without vendor approval? Can the platform be used in commercially-funded research projects (industry grants, corporate-sponsored research)?
4. Is a trial or demo loan program available before purchase?
5. Can the vendor provide a reference list of academic labs using the platform that can be contacted?

Red flags:

• "Academic pricing is the same as commercial." This suggests the vendor does not have a research-focused sales track. It is not necessarily a disqualifier, but it suggests research-support processes may be similarly underdeveloped.
• License terms that require vendor approval for publication. This is uncommon but has appeared in the field. Any publication approval clause is a hard disqualifier for academic research.
• No reference customers who can be contacted. A vendor who has been working with research labs should be willing to provide at least two lab contacts.

Category 4: Spare parts and repair

Hardware fails. The questions here determine whether that failure is a recoverable event or a research-stopping event.

Questions to ask:

1. What is the vendor's committed spare parts availability period for this platform? Is this commitment in writing?
2. What are the three most likely components to fail in the first three years, and what are their current lead times?
3. Can the lab purchase a recommended spares kit at time of initial purchase, at a discount?
4. What is the depot repair turnaround time? Can the lab perform field repairs? Is field repair documentation (schematics, disassembly procedures, torque specs) available?
5. What is the process when a component goes out of production before the end-of-life commitment date?
6. What is the vendor's end-of-life policy? Will mechanical drawings, electrical schematics, or source code be released when the platform is discontinued?

Red flags:

• "We'll try to keep parts available as long as there's demand." This is not a commitment. Demand can drop to near zero quickly for niche research platforms, and "as long as there's demand" can become "we're phasing out support" with very little notice.
• Lead times on critical components (actuators, compute modules) longer than eight weeks. Research experiments run on shorter cycles; a three-month wait for a failed servo blocks the lab.
• Field repair requires depot return. For a lab running continuous experiments, a two-week depot cycle per repair event is a significant throughput constraint.
• No end-of-life documentation commitment. When the platform is discontinued, hardware drawings and software source code become the lab's only path to continued operation or hardware maintenance. A vendor who will not commit to releasing this documentation at end-of-life is creating an obsolescence trap.

Category 5: Export control and ITAR considerations

Export control regulations apply to the transfer of certain controlled items and technologies to foreign nationals or foreign countries. For university research labs with international students, postdocs, and collaborators, this is a significant operational consideration that is often overlooked until it creates a compliance problem.

ITAR (International Traffic in Arms Regulations) is administered by the US State Department and covers defense articles and defense services. EAR (Export Administration Regulations) is administered by the US Department of Commerce and covers dual-use items. Both apply to physical hardware and to technical data (software, schematics, specifications).

Questions to ask:

1. Is this platform or any of its components controlled under ITAR? If so, under what USML (United States Munitions List) category?
2. Is this platform classified under EAR? What is the ECCN (Export Control Classification Number)?
3. Does the vendor provide documentation (a commodity jurisdiction letter or self-classification documentation) that the lab's export control office can review?
4. Are there end-user restrictions in the purchase agreement that would prevent the lab from allowing foreign national access to the platform?
5. If the platform includes controlled components (e.g., certain radiation sensors, high-precision GPS, specific frequency communication hardware), how are those components documented and classified?

Red flags:

• "We don't think it's controlled, but you should check with your legal team." This is an answer from a vendor who has not done the classification work. The correct answer is a documented commodity jurisdiction determination or an ECCN.
• A purchase agreement with end-user restrictions that were not disclosed during the sales process. Read the agreement before signing, not after.
• Platforms with defense applications (force projection, targeting, surveillance) that have not clearly segregated the research configuration from the defense configuration. University export control offices are cautious about platforms with ambiguous military applicability.

For non-US institutions: equivalent export control frameworks exist in the EU (dual-use regulation), UK (Export Control Order), and most developed countries. The vendor should be able to document classification under the relevant framework for your jurisdiction.

Category 6: Publication readiness

Research use requires that the lab can publish about the platform and its experimental results without vendor interference.

Questions to ask:

1. Is the lab free to publish research results, including negative results, without vendor review or approval?
2. If the vendor provides any proprietary control software that runs on the platform, can the lab describe that software's behavior in a publication without disclosing trade secrets?
3. Does the vendor provide benchmark datasets or standard test conditions that the lab can reference to make results comparable across groups?
4. Are there naming or attribution requirements—for example, must the vendor be acknowledged in publications?
5. Has the vendor published technical reports, academic papers, or whitepapers describing the platform's design that the lab can cite?

Red flags:

• Publication review requirements in the agreement. Non-negotiable disqualifier.
• Proprietary control software with no technical documentation. If the lab cannot describe how the platform's core functions work in a paper, reviewers cannot evaluate the experimental methodology.
• No vendor-published documentation at all. A platform that the vendor has not described technically makes citation and methodology description difficult. Reviewers who want to understand the experimental setup need a citable reference.

Category 7: End-of-life risk

Research programs run for five to ten years. Platforms need to survive that horizon.

Questions to ask:

1. How long has this platform been in production, and what is the current version/generation?
2. What is the expected production lifetime? Has an end-of-life date been announced or anticipated?
3. If the vendor's business changes (acquisition, product line discontinuation), what protections does the purchase agreement provide?
4. Is there a user community or user association that maintains platform knowledge independently of the vendor?
5. What fraction of the platform's software stack is open-source vs. proprietary? If the vendor stops supporting the platform, what can the lab continue to run from open-source components?

Red flags:

• The platform has been in production for less than two years. Early-production platforms have higher end-of-life risk and lower community depth.
• The platform is the only product from a venture-backed startup with no history of revenue. Research platforms require vendor longevity; early-stage startup platforms carry significant discontinuation risk.
• No user community independent of the vendor. A platform whose only support resource is the vendor's own support channel is one acquisition or bankruptcy away from zero support.

Consolidated red-flag checklist

The following checklist summarizes the conditions that should trigger either a vendor clarification conversation or a reconsideration of the platform:

Disqualifying (reconsider the platform):

• SDK requires vendor binary library; no direct hardware API access
• License requires vendor approval for publication
• ITAR/EAR classification undocumented; end-user restrictions not disclosed
• Onboard compute cannot run lab-controlled software

High concern (require written resolution before purchase):

• No ROS 2 package, or last update >12 months ago
• No URDF or simulation model available
• No spare parts commitment in writing
• Lead times on critical components >8 weeks
• No field repair documentation
• No end-of-life documentation commitment

Worth investigating (ask follow-up questions):

• ROS 2 package community-maintained rather than vendor-maintained
• No academic pricing program
• No reference lab contacts provided
• Vendor is early-stage (<2 years in production)
• No benchmark datasets or standard test conditions published
• Platform has defense applications without clear civilian/research segregation

One final note on the process

The questions above can feel adversarial in a sales conversation. They are not. Vendors who have built products for the research market will answer most of them confidently and specifically—because their research customers asked the same questions before them, and the vendor has already solved the problems the questions surface. A vendor whose answer to "what is your committed parts availability period?" is a hedge has, in most cases, simply never been asked the question seriously before. That tells you something important about their research customer base.

The best procurement conversations are ones where these questions are answered with specifics that then go into the purchase agreement. The purchase agreement is the place where verbal commitments become binding. Spare parts commitments, end-of-life documentation releases, and publication rights should all be reflected in the agreement, not just the sales call.

This article is the last in the Research & Lab Robots series. The full series covers procurement pitfalls, three-year TCO, the buy-vs-build-vs-simulate decision, domain-specific platform selection, the 90-day standup playbook, and this RFP. Each article stands alone, but the series is designed to be read in order by a PI or lab manager approaching a new platform decision.