Is this checklist free to use?

Yes. The CSV and page are public so your team can use them for a procurement brief without an account.

Does checking every box certify the robot?

No. The worksheet records requirements and evidence. It does not establish compliance, safety or acceptance beyond the scope your team and supplier agree.

Can I send this to more than one supplier?

Yes. A consistent brief makes it easier to compare the same configuration, services and unresolved items across quotations.

What should I do when the supplier cannot answer a requirement?

Mark it unresolved, identify its effect on the project and decide whether further evidence, a sample or a different product is needed before approval.

Research Robot Procurement Checklist: A Shared Brief for Your Lab

Editorial worksheet · Version 2026-09-15 · Complete with your team's requirements and the supplier's evidence

Download the editable procurement checklist (CSV). No account is required. You can also print this page or save it as a PDF through your browser and share it with engineering, procurement and the person receiving the equipment.

1. Write the project brief

Field	What to enter
Project and owner	Project name, technical owner and purchasing contact
Research objective	The experiment or demonstrated task the equipment must enable
Required behavior	Motions, objects, operating conditions and acceptable failure criteria
Existing equipment	Arm or robot, gripper, cameras, host computer, interfaces and software versions
Quantity and budget	Sample quantity, planned follow-on quantity and budget currency
Destination and dates	Delivery address, required arrival date and commissioning deadline
Main constraints	Workspace, payload, power, permitted network access and operating procedure

Write the objective so a supplier can identify a mismatch. “Research robot” is broad; “record synchronized hand actions and two camera streams while manipulating these objects” gives them something concrete to evaluate.

2. Record the exact hardware configuration

Requirement	Evidence to request	Record in your comparison
Product identity	Complete model code and hardware revision	Model, revision and quotation line
Joint configuration	Body, arm, wrist and hand layout	Controlled axes separately from coupled or passive joints
Tool and payload	Tool mass, center of gravity and load limits	Required object load and relevant pose or motion conditions
Workspace	Dimensioned drawings and joint limits	The required approach poses and mounting position
Sensors	Full models and optional packages	Included devices, accessible data and calibration scope
Compute and control	Controller, onboard compute and host requirements	Included hardware versus customer-supplied equipment
Power and wiring	Supply ratings, connectors and cable list	Needed adapters and missing accessories
Mechanical integration	Flange, base and assembly drawings	Who supplies each adapter and fixture

For hand selection, compare candidates in the dexterous-hand table and use the buyer's guide to frame the interface questions. A family name does not identify the tactile package or a supported retrofit.

3. Define software access as a deliverable

Ask for the actual repository, manual or sample package and record its version. Separate what is publicly downloadable from what the purchased configuration permits you to use.

Required command modes: task commands, joint position, velocity, torque or another named interface.
Available observations: joint state, current, temperature, sensor data and timestamps.
Firmware and software compatibility: robot revision, host OS, ROS distribution where applicable and driver release.
Data access: sample export, format, units, synchronization and any licensing or sharing constraints.
Operation and recovery: supported stop procedure, error reporting, restart and reset instructions.
Access conditions: accounts, activation, network dependencies, included licenses and update policy.
Support deliverables: documentation language, installation assistance and any separately priced engineering work.

Have the supplier identify an example that exercises the required interface on the proposed configuration. A link to an SDK repository is useful evidence, but does not itself confirm hardware entitlement or successful integration.

4. Normalize the quotation

Use identical rows for every supplier. Mark each item included, optional, excluded or unresolved. Keep unresolved costs out of confirmed subtotals and visible to the person approving the budget.

Quotation line	Details needed
Core equipment	Model, revision, quantity and unit price
Options	Hands, sensors, compute, interfaces and upgrades
Accessories	Power supply, batteries, charger, cables, adapters and mounts
Software and services	Licenses, setup, training, integration and acceptance work
Spares	Proposed parts, quantities, prices and availability
Packing and delivery	Destination, delivery terms, dispatch estimate and transit assumptions
Taxes and import costs	What is included, who handles import formalities and what remains to be confirmed
Commercial terms	Quote expiry, currency, payment milestones and agreed change procedure
Repair and warranty	Scope, exclusions, repair location, freight responsibility and calibration after repair

Do not equate dispatch with arrival, a battery-runtime claim with a duty-cycle guarantee, or a warranty period with a complete service plan. Ask for the terms that matter to your project and have them written into the final scope.

5. Agree what acceptance will demonstrate

Create one row for each acceptance check. Define the equipment configuration, procedure, success criterion and evidence before the order is placed. Let the supplier propose a safe way to perform the check within the documented limits.

Check	Evidence to keep
Identity and contents	Serial numbers, revision details and packing list
Hardware configuration	Photos or inspection record of the agreed options and accessories
Software connection	Firmware and driver versions plus the agreed example output
Required task	Test conditions, unedited results and any failures or human assistance
Data collection	Sample observations and action log with units and timing information
Stop and recovery	Confirmation of the supported procedure and relevant instructions
Handover	Manuals, credentials or licenses where applicable, drawings and support contacts

A demonstration can support one acceptance item without proving durability, autonomy or safety for every future experiment. State what was tested and leave other questions open. Your institution should define the operating procedure and any additional safety or purchasing requirements for the assembled system.

6. Keep a decision log

For each unresolved issue, record an owner, evidence requested, the supplier's response and a decision date. Do not silently replace “unknown” with “yes.” Keep the accepted quotation and configuration attached to the final comparison so later substitutions are visible.

Before approving a larger quantity, review the sample's results against the original requirements. If the experiment, software or hardware revision changes, recheck the affected items rather than assuming the previous approval transfers.

Use the brief for a specific product

The G1 platform guide focuses on development access and humanoid configurations. The research-arm guide helps with workspace and tooling. The QDD actuator guide focuses on revision, drive electronics and load cases. The hand price guide shows how accessory and sensing scope changes a quotation.

Bring your completed brief or its key requirements to the Sourcebotics quotation form. Include the model shortlist, quantity, destination and questions you still need answered.

Method and reference notes

This is a Sourcebotics editorial template, dated 2026-09-15. It does not claim an independent test or a standards-based certification procedure. The linked product-selection guides provide the manufacturer references behind their specific examples; attach the current model documents and quotation when using this worksheet for a purchase.