Robotics for research and controlled pilots

This page is for people planning to buy quadruped robots, robotic arms or similar platforms for university labs, research institutes or corporate innovation teams. Public SDKs and demonstration videos make robotics research look more accessible, but procurement has to state the exact edition, developer access, accessories, training and who provides local support.

CNPS helps prepare the configuration and support checklist and verifies supply and destination terms. Public materials such as Unitree SDK2 and the UFACTORY xArm SDK are evaluation starting points; they do not mean every product edition has the same access, and they are not CNPS customer orders. Site safety and integration need qualified owners.

Where this fits

Locomotion control and perception research

Labs need to validate algorithms on a real platform. Evaluate whether the chosen edition opens low-level control interfaces and whether the operating system and SDK versions are compatible.

Controlled grasping and assembly pilots

Use an arm to pick, place or assemble a limited set of workpieces. Evaluate the workpiece, gripper, payload, reach and camera arrangement, and record repeatable success rates.

Teaching and talent development

Several students share one platform in turns. Evaluate training, spare parts, emergency procedures and supervised operating rules, not only the robot body.

The expected output

A configuration and support checklist

What to share

Research task, exact platform, payload, workspace, developer access, destination and trained operator.

What to evaluate

Confirm the SKU and developer permissions in writing.
Check operating system and SDK compatibility.
Include tools, fixtures, spare parts and training.
Define supervised testing and emergency procedures.

How the evaluation runs, step by step

Write down the research task and the exact platform
Derive requirements from the task: payload, workspace, sensors, developer access and destination. Robots with the same name can have different access by edition, so name the exact model.
Confirm SDK access and compatibility in writing
Ask the supplier for written confirmation of developer access, supported operating systems and SDK versions for the selected edition, and check them against the lab’s existing software environment.
Start with simulation and supervised tests
Validate the workflow in simulation first, then run supervised tests inside a bounded workspace. Record successful attempts and every failure, and agree emergency stops and procedures.
Put the full configuration into the procurement request
Use the robotics procurement resource to list tools, fixtures, spares, training, shipping and local support, name the owners for safety and maintenance, then request a quotation.

Common mistakes

Assuming a public SDK applies to every edition
Education, standard and developer editions may open different interfaces. Obtain written confirmation for the exact edition before purchasing.
Buying only the robot body
Grippers, fixtures, cameras, spares, training and shipping often decide whether the project can start. Missing any one of them can leave equipment idle for months.
Inferring autonomy from demonstration videos
International demonstration videos show possibilities, not proof of autonomous productivity. Whether your research task succeeds depends on your algorithms, scenario and operating skills.

What to record during the pilot

Write these down before the test starts, so the decision rests on numbers you collected rather than on impressions.

Written confirmations received
Track which items the supplier has confirmed in writing for the exact edition: developer access, supported operating systems, SDK versions, warranty and destination terms.
Compatibility results
Record whether the SDK installs and runs on the lab’s existing machines, which versions were needed and how long setup took before the first command was sent.
Task success rate and failure log
Count successful and failed attempts under the same conditions, with the cause of each failure, so autonomy is judged on repeated runs rather than a demonstration.
Safety incidents and near-misses
Log every emergency stop, boundary breach and unplanned movement during supervised tests, and what changed in the procedure afterwards.
Time and cost to first experiment
Measure the calendar time and full cost from order to the first completed experiment, including accessories, training, shipping, customs and any idle weeks waiting for parts.

Key terms on this page

These terms are used in the same sense on this page, in the linked resource and in our quotations.

Exact edition: The precise product variant, such as education, standard or developer, named on the quotation. Editions with the same body can expose different interfaces.
Developer access / low-level control: Whether the edition lets your code command joints, motors or gait directly, rather than only through a high-level app or teach pendant.
SDK version compatibility: The operating system, ROS distribution, Python and library versions the platform supports, checked against what the lab already runs.
Payload and reach: The mass the arm or robot can carry and the workspace it can cover, stated for the exact configuration including gripper and camera.
End effector / gripper: The tool mounted on the arm for the task. It is usually ordered separately and decides whether the workpieces in your study can be handled at all.
Bounded workspace: The physical area where the robot may operate during tests, with guarding, emergency stops and clear rules for who may be inside it.
Repeatable success rate: The share of attempts that complete the task across many runs under the same conditions, recorded with every failure rather than the best demonstration.
Local support and spares: Who repairs the platform in your country, how long parts take to arrive and which consumables should be stocked before the first test.

What to confirm

References to SDKs do not mean every product edition has the same access. Site safety and integration require qualified owners.

Common questions

Which robotics platforms can CNPS provide?

CNPS verifies the exact editions, accessories and destination terms that can be supplied for your requirement and prepares the configuration list. Supply and access for any platform are subject to written confirmation from the supplier.

What site conditions should we prepare in advance?

A bounded workspace, emergency stops and guarding, qualified operators and a maintenance owner. Put these in place before the equipment arrives rather than afterwards.

Can we rent or trial a platform first?

Trial and rental options depend on the platform and region. State the research task and timeline in your inquiry so feasible evaluation options can be verified together.

Should we start with a robotic arm or a quadruped?

It follows from the research task. Grasping, assembly and workpiece studies point to an arm; locomotion, perception and outdoor navigation point to a legged platform. Write the task down first and let the platform follow.

What does a typical robotics quotation include?

The exact edition, developer access, accessories such as grippers and cameras, spares, training, shipping and destination terms, each as a separate line. Anything missing from the quotation should be assumed not included.

How do we plan for maintenance after delivery?

Name a maintenance owner, stock the consumables the supplier recommends, confirm who repairs the platform in your country and how long parts take, and keep a log of every fault from the first week.

Continue exploring

Industry references are not presented as CNPS customer deliveries.