The mobile manipulator vendor RFP: questions and red flags

Why standard robot RFPs miss the compound failure modes

A standard industrial robot RFP asks about arm payload, reach, cycle time, repeatability, and software interfaces. Those questions are necessary — but for a mobile manipulator, they are insufficient. A mobile manipulator is a system of systems. The arm's performance figures mean little without knowing how they degrade when the arm is mounted on a navigating base. The base's navigation spec means little without knowing how it translates to end-effector accuracy at the task location.

An RFP that treats the arm and base as independent systems will produce a technically accurate but practically misleading proposal. This article provides the full question set that addresses the compound performance, the integration architecture, the safety validation, and the commercial terms that determine whether a mobile manipulation platform performs as promised.

Questions are organised into six categories. For each question, representative red-flag responses are noted — answers that, taken alone or in combination, are reasons to ask deeper follow-up questions or reconsider the vendor.

Category 1: Positioning repeatability after navigation

These are the most important questions in the RFP and the area where the largest gap exists between vendor datasheets and production reality.

Q1.1. What is the arm's mechanical repeatability, and under what conditions is it measured? Expected: a specific value (e.g. ±0.05 mm), tested per ISO 9283, on a stable pedestal in a controlled lab.

Red flag: The vendor quotes repeatability from a general spec sheet without specifying test conditions, or conflates repeatability with accuracy.

Q1.2. What is the base navigation positioning accuracy at your programmed goal poses in a representative production environment? Expected: a specific range (e.g. ±8 mm lateral, ±0.5° heading) measured in a factory-floor environment with typical obstacles, not in a clean lab.

Red flag: The vendor quotes only the navigation stack's theoretical performance without field validation data. Navigation accuracy in lab demos is typically better than production by 2–5×.

Q1.3. What is the end-effector positioning repeatability after navigation, measured at a representative station with your re-localisation system active? Expected: a tested value (e.g. ±1.5 mm) achieved in their demo environment, with documentation of the test methodology — number of trials, floor surface, ambient lighting, fixture configuration.

This is the most important single question in the RFP. It is also the question that the largest number of vendors cannot answer with real data. The inability to answer it is itself a significant red flag.

Red flags:

• Vendor provides the arm's mechanical repeatability in response to this question (conflation)
• Vendor provides a theoretical calculation rather than measured data
• Vendor says "it depends on the application" without providing a baseline measurement
• Vendor is unable to demonstrate the re-localisation system live on request

Q1.4. What re-localisation method is standard, and is it included in the base platform price? Expected: a clear description of the method (vision fiducials, structured light, precision docking, or combination) and confirmation of whether it is included or an add-on.

Red flag: Re-localisation is an add-on quoted separately, or the standard offering is navigation-only (no end-effector compensation), with re-localisation positioned as a "custom integration" project.

Q1.5. What happens when the re-localisation fails? How does the robot report the failure and what is the recovery sequence? Expected: a defined fault state, operator notification via fleet management software, a manual or semi-automatic recovery procedure, and logging of the event for analysis.

Red flag: Re-localisation failure causes a silent task failure (the robot proceeds with an uncorrected position), or failure handling is not yet implemented in the production firmware.

Category 2: Arm payload and reach at the base

Q2.1. Provide the payload-reach curve for the arm in its configuration on your mobile base. What is the effective payload at 600 mm and 800 mm TCP reach? Expected: a payload diagram that shows capacity degrading with reach distance. Verified figures, not the nominal flange-rating.

Red flag: The vendor provides only the nominal payload at the flange and cannot produce a payload-reach curve. This is standard documentation for any industrial cobot.

Q2.2. Does base motion impose any restrictions on the arm's operating mode? Can the arm operate while the base is in motion? Expected: a clear answer — most platforms require the arm to be in a transport/folded pose during navigation and only operate the arm when stationary. If operation during motion is claimed, ask for the dynamic load analysis that supports it.

Red flag: The vendor is unclear about whether arm operation during transit is supported, or claims it is supported without documentation of the dynamic load validation.

Q2.3. What are the joint speed limits in the collaborative operating mode at each station, and how do they affect task cycle time? Expected: ISO/TS 15066 defines maximum contact forces that determine safe arm speed given the payload and end-effector geometry. The vendor should be able to calculate or provide representative cycle times at compliant speeds.

Red flag: The vendor quotes unreduced speed in cycle time estimates, or claims "it depends on your safety assessment" without providing any baseline.

Category 3: Dual safety architecture

Q3.1. Which safety standard governs the mobile base — ISO 3691-4, ANSI B56.5, or both? Has the platform received third-party certification or declaration of conformity for both standards? Expected: clear identification of applicable standards and documentation of conformity assessment. CE marking in Europe, UL or equivalent in North America.

Red flag: The vendor says the platform "can be configured to meet" standards without certification. In-process certification is acceptable for newer platforms; verify the timeline.

Q3.2. How does the safety system handle the transition between mobile (transit) and stationary (task) operating modes? Is the transition governed by a safety-rated PLC or by general-purpose software? Expected: the transition should be managed by a safety-rated controller (SIL 2 or PLd/e) — not application-layer software. A mode transition that depends on correct execution of user-written code is not a safety function.

Red flag: The vendor describes mode transitions as a software-configurable feature without identifying the safety controller that governs it.

Q3.3. Is the cobot arm's power-and-force limiting (PFL) function type-tested and certified, or is it a customer-implemented configuration? Expected: PFL is a Category 3, PLd safety function per ISO 13849 for most certified cobots. The vendor should be able to provide the arm's safety function documentation.

Red flag: PFL is described as something the integrator configures, without a certified safety function behind it.

Q3.4. Provide the safety architecture block diagram showing how the E-stop, protective stop, and restart functions connect across the mobile base, the arm, and any safety I/O. Expected: a formal block diagram or functional safety architecture document. Any vendor with a production-ready platform has this.

Red flag: The vendor does not have a safety architecture document, or provides a conceptual block diagram rather than one showing actual component connections. This indicates the platform's safety architecture has not been formally documented — a significant concern for compliance with the Machinery Directive (EU) or equivalent regulation.

Q3.5. What is the risk assessment process and what does the vendor provide versus what must the system integrator produce? Expected: the vendor provides a base risk assessment for the platform operating in defined operating modes. The system integrator is responsible for the application-specific risk assessment that covers the specific task, environment, and station configurations.

Red flag: The vendor claims the platform's certification covers the full application risk assessment. It does not — platform certification covers the platform, not the application.

Category 4: SDK, integration, and fleet management

Q4.1. What is the API for task programming — a proprietary teach-pendant interface, a ROS (Robot Operating System) interface, a web API, or a combination? Expected: a clear description of the programming interface. ROS-compatible platforms provide the broadest ecosystem of integrators and community support. Proprietary-only interfaces are not a disqualifier but raise integration risk if the vendor's support is limited.

Red flag: The vendor's programming interface is poorly documented, requires dedicated training that is available only as a paid engagement, or is described as "in development" for the integration layer you need.

Q4.2. How does the platform integrate with external systems — ERP, MES, SCADA, safety PLCs? Provide an integration architecture document or reference customer integration. Expected: documented integration interfaces (MQTT, OPC-UA, REST API, or similar) with a reference customer who has used them in production.

Red flag: Integration is described as a custom project for each customer without standard interfaces. This is common in early-stage platforms and predictive of high integration costs.

Q4.3. What is the fleet management software's architecture — on-premise, cloud, or hybrid? What happens to the fleet when internet connectivity is unavailable? Expected: a clear answer about connectivity dependency. For manufacturing environments with restricted internet access, the fleet management software must be deployable on-premise or operate fully autonomously when cloud connectivity is interrupted.

Red flag: The fleet management software requires continuous cloud connectivity and the robot cannot operate (or safety degrades) when the connection drops.

Q4.4. How are navigation map updates distributed to the fleet, and what is the procedure for a map update that affects active missions? Expected: a documented map update procedure that includes validation, staged rollout, and rollback capability. A fleet management change that breaks active missions without recovery procedure is a production risk.

Category 5: Charging, uptime, and maintenance

Q5.1. What is the battery runtime at typical duty cycle, and how is charging choreographed in a multi-station mission? Expected: runtime at specified payload and speed (typically 6–10 hours), plus documentation of how the fleet management software schedules charging to avoid mission interruption.

Red flag: The vendor quotes maximum battery runtime (no payload, low speed) rather than duty-cycle runtime. Or charging choreography is not implemented — the robot simply stops when the battery is low, regardless of mission state.

Q5.2. What is the time to recharge from minimum safe level to operational capacity? Expected: 1–3 hours for most commercial platforms with standard charging, 30–60 minutes for fast-charge options. Verify this against shift patterns — if recharge time exceeds break duration, the robot cannot be reliably topped up during production pauses.

Q5.3. What is the expected MTBF (mean time between failures) for the platform, and what is the basis for that claim? Expected: data from deployed platforms in production, not MTBF calculations from component spec sheets. Vendors with production deployments can quote field data; vendors without cannot.

Red flag: MTBF is quoted from theoretical calculation or lab test, not field data. For a first-generation or recently introduced platform, this is common and not disqualifying — but the buyer should adjust the downtime contingency accordingly.

Q5.4. What on-site maintenance is required, and what must be performed by a factory-trained technician? Expected: a tiered maintenance schedule distinguishing operator-level maintenance (cleaning, battery check, scanner inspection) from qualified-technician maintenance (arm joint calibration, safety function revalidation) from factory-service-only maintenance (firmware updates, major repairs).

Red flag: All maintenance requires factory-trained technicians, with significant travel or lead time for service visits. This creates unacceptable downtime risk for production applications.

Category 6: Commercial terms and support

Q6.1. What is included in the standard warranty, and what are the escalation paths for a fault that stops production? Expected: at minimum 12 months on hardware, 90 days on software. Clear escalation path — phone support, remote access, on-site response within defined SLA.

Red flag: Support is email-only, with no defined SLA for production-stopping faults.

Q6.2. What is the process for a software update that breaks an existing deployment? Expected: a change control process with documented release notes, a staging environment for customer validation before production rollout, and a rollback procedure.

Red flag: Software updates are pushed automatically without change notification or customer approval. This has stopped production deployments in the field.

Q6.3. Is the vendor willing to commit to a performance guarantee — specified task success rate and uptime — in the purchase contract? Expected: most mature vendors will offer a conditional performance guarantee tied to specified operating conditions. The willingness to commit is itself a signal of vendor confidence in production readiness.

Red flag: The vendor declines any performance commitment, or conditions the guarantee so broadly (e.g. "in a controlled environment") that it covers no real production scenario.

The red flags summary checklist

The following combination of answers is a strong signal to pause and conduct deeper due diligence before committing:

• Cannot provide measured end-effector positioning repeatability after navigation (Q1.3)
• Re-localisation is not included in base price or not fully implemented (Q1.4)
• Safety architecture is not formally documented (Q3.4)
• No reference customer with production deployment (Q4.2 / Q5.3)
• Fleet management requires continuous cloud connectivity (Q4.3)
• Software updates pushed without customer approval or rollback procedure (Q6.2)
• No performance guarantee offered under any conditions (Q6.3)

Any single red flag warrants a follow-up question. Three or more red flags on a platform that is otherwise technically attractive suggests a platform that is not yet production-ready for a first unassisted deployment — and may be appropriate for a supervised pilot with a research or innovation budget rather than a production capital appropriation.

What to read next

This RFP series has covered the full buyer journey: the economic case, the cost model, use-case payback, the decision framework, deployment execution, and now vendor selection. Return to the first article in the series — When a mobile manipulator beats a fixed arm — and when it doesn't — for the foundational positioning-accuracy framework that should anchor every evaluation.