Insights · 2026-10-29

How to Evaluate a Dexterous Hand Sample: A 7-Day Protocol

A dexterous hand sample has arrived. The next seven days decide whether it earns a place on your platform or goes back in the box. Most teams evaluate by playing with it for a few days and going with gut feel — which is exactly how costly late-stage surprises happen.

The point of a sample evaluation is not to prove the hand works. It is to find out how it fails, and whether those failure modes are acceptable for your application. Here is the protocol we use when qualifying hands, with a gate at the end of every day. Fail a gate and you stop.

Day 1 — Unboxing and physical inspection

Before you connect power or a bus, inspect the hardware. Mechanical problems found here save hours of debugging later.

CheckPassFail = stop
Weight vs datasheetWithin ±5%>10% deviation suggests the wrong configuration was shipped
Joint free movement (power off)Every joint moves smoothly by handAny joint that binds or grinds is a mechanical defect
ConnectorsClean, no bent pins, locks positivelyBent pins or a loose fit means an unreliable link
DocumentationQuick-start guide with a clear wiring diagramNo documentation means painful integration
AccessoriesPower supply, cables, adapter, mounting bracket presentMissing parts — contact the supplier before powering on

Photograph all sides before you start. That is your baseline if you ever need to claim warranty. And do not power on a visibly damaged hand.

Day 2 — Communication and basic control

Goal: bidirectional comms and one joint moving. If you cannot talk to the hand by end of day two, integration will be a long fight.

  1. Identify the protocol — CAN, CAN FD, EtherCAT, RS485 or serial — from the datasheet and pinout.
  2. Set up the bus interface: USB-to-CAN adapter, EtherCAT master, or serial converter.
  3. Install drivers and SDK. Flag it if the only instructions are in Chinese — that is a support risk worth knowing about before you order production units.
  4. Power on at the specified voltage (commonly 24 V) and watch the indicators.
  5. Send a heartbeat, read all joint positions, then command one joint to move 10°.
  6. Test emergency stop — you need to be able to halt motion instantly.
SymptomLikely causeFirst thing to try
No response at allWrong baud rate or node IDCheck datasheet defaults; try 1000 kbps then 500 kbps
Some joints respond, some don'tAddress conflict or broken daisy chainCheck wiring continuity, verify node IDs
Jittery motionGains untuned or bus noiseCheck grounding, lower PD gains
SDK examples crashLibrary or OS mismatchAsk the supplier for a known-good version
Warm at idleFirmware bug or wiring faultStop immediately — hardware risk

Day 3 — Motion characterisation and calibration

Now measure how it actually moves. Everything downstream depends on these numbers.

ParameterHow to measureGood result
Range of motionCommand min to max, measure the real angleMatches datasheet ROM
Position accuracyFive target angles per joint, commanded vs actual±0.5°
RepeatabilitySame angle ten times, measure spread±0.1° on precision hands
Maximum speedTime a full flex–extend cycleMeets datasheet speed
Step responseStep input, time to 90% of targetUnder 100 ms
BacklashApproach one position from both directions<0.5° direct drive, <2° tendon

Accuracy more than 2° off spec is either a calibration problem (fixable) or an encoder problem (not fixable). Ask the supplier which before you proceed. If your application needs grasp planning, also map joint angles to fingertip position: command the hand to touch known reference points on a grid, record the angles, fit a kinematic model, then verify at five points you did not use for fitting.

Day 4 — Grasp testing and force measurement

This is where the spec sheet meets reality. Build one standard object set and use it for every hand you evaluate, so scores are comparable.

Grasp typeTest objectsWhat it tells you
Power (cylindrical)Bottle, can, 50–80 mm cylinderMaximum grip force and wrap-around
Precision (pinch)Pen, 5–15 mm cylinderFingertip dexterity and fine force control
Lateral pinchCard, thin book, phoneThumb-to-finger lateral force
TripodPen in writing position, small ballThree-finger coordination
HookBag handle, ropeLoad-bearing capacity, finger strength
DelicateEgg, ripe fruit, paper cupForce regulation and tactile feedback

With a force gauge or even a kitchen scale: measure maximum fingertip force, force resolution across five commanded levels, force repeatability over ten trials, and — if the hand has tactile sensing — whether slip is actually detected when you load a grasped object until it moves.

Day 5 — Durability and thermal

A hand that works for five minutes and drifts after thirty is useless. Program a repetitive open–grasp–release cycle and run it at least two hours, logging joint temperature every fifteen minutes.

MetricGoodAcceptableFailing
Motor temperature after 1 h<45 °C45–60 °C>60 °C — thermal shutdown risk
Grasp success rate, start vs 1 hNo change<10% drop>10% drop
Position drift<0.5°0.5–1°>1° — thermal growth or encoder drift
Audible noiseNo changeSlight changeNew grinding or clicking = wear

Then run 1,000 grasp cycles. Stable at 1,000 usually means 10,000–50,000 before meaningful wear. Degradation before 1,000 means you should plan for frequent maintenance.

Day 6 — Integration with your platform

The hand stops being a bench device today, and this is the day that exposes integration problems.

  • Mount it — check the wrist flange pattern, that the weight sits inside arm payload, and that nothing collides at the extremes of wrist rotation.
  • Route the cable through the arm's internal channel and check for pinching at joint extremes.
  • Power it from the robot bus and verify voltage stability under load.
  • Write the driver into your control framework (ROS 2 or otherwise) and calibrate the tool centre point.
  • Run an end-to-end test: move the arm to a target, grasp, move away.

The most common failure here is cable management: a cable that behaves perfectly on the bench pinches or fatigues once the arm sweeps its full range. Test every configuration, not just the home pose. Also verify your safety watchdog opens the hand on comms loss rather than freezing it closed, and that one e-stop halts arm and hand together.

Day 7 — Score it and decide

CategoryWeightScore 1–5
Mechanical quality20% 
Motion performance20% 
Communication reliability15% 
Grasp capability15% 
Durability10% 
Documentation quality10% 
Integration effort10% 

Weighted total then maps to a decision: 4.0–5.0 go — order production units and spares. 3.0–3.9 conditional — acceptable with named caveats to fix before scaling. 2.0–2.9 hold — request manufacturer fixes or evaluate alternatives. Below 2.0 no-go — return it.

Run the protocol on a real sample

Tell us the grasp types you care about, the payload and the protocol, and we will shortlist hands across our partner factories and quote the sample and the production price together. Start from the Linker Hand range; if teleoperation or demonstration data is part of your plan, evaluate a motion capture glove in the same window — same SDK, same ROS packages.

Request an evaluation sample

Specs quoted from manufacturer datasheets; final figures confirmed at quotation.

FAQ

How long should a dexterous hand evaluation take?

About a week of structured testing—enough to cover six grasp types, a thermal run and a repeatability check. Anything shorter and you are judging the unboxing, not the hand.

What fails first in a hand sample?

Thermal behaviour under repeated grasp cycles and fingertip repeatability after a few thousand cycles. Both are easy to miss in a demo and obvious by day five.

Should the evaluation include teleoperation?

If that is the target use, yes. Latency and mapping quality only show up when a human is in the loop, and they are usually the reason a technically capable hand gets rejected.