Chapter 2: Choose the Arm and Hand — Four Purpose-Built Configurations

Overview

The most common way to choose a robot arm and hand is also the least useful: sort catalogs by payload, degrees of freedom, or tactile-point count. Real research schedules fail elsewhere. An adapter does not exist, the driver does not support the laboratory's ROS 2 distribution, the completed tool exceeds the wrist moment limit, a collision mesh is wrong, or the only hand is away for repair. The useful question is therefore not “Which robot is best?” It is “What is the least complex arm–hand pair that completes my first task while exposing the control, sensing, service, and safety interfaces I need to verify?”

There is no single answer. This chapter separates four purposes: a low-cost leader–follower and recording cell; a repeatable pick-and-place cell; a torque-aware compliant-manipulation cell; and a tactile, multi-finger research cell. These are not low-to-high product rankings. Each configuration buys a different class of failure. A simpler cell has less capability but usually makes failures easier to isolate. A dexterous cell has a larger action space but also adds coupling, calibration, model, cabling, and repair work.

Product and software status in this chapter is current to 2026-07-14. Prices vary rapidly with region, education discounts, options, tariffs, and support contracts, so this chapter does not repeat unverified prices. It instead specifies what to demand in a quotation, purchase review, and acceptance test. Detailed choices for cameras, VR controllers, gloves, trackers, GPU tiers, tables, and safety fixtures follow in (Chapter 3). The connection from ROS 2 to the real controller follows in (Chapter 4).

After reading this chapter... - You can turn task payload, reach, control, and sensing requirements into an arm–hand purchase specification. - You can compare a UR5e and Franka Research 3 as different control contracts rather than as a one-dimensional ranking. - You can decide when a parallel gripper makes the first experiment cheaper to debug and when five fingers justify their integration cost. - You can explain the BOM, achievable tasks, integration risk, mounting and safety needs, and “do not buy yet” list for four starter cells. - You can give Codex a bounded prompt to audit payload, driver, and simulator compatibility before requesting a quotation.

1. Calculate the arm and hand as one installed tool

An arm's advertised payload is not merely the object mass. The wrist carries the gripper or hand, flange adapter, fingers, wrist force/torque sensor, cable guide, tool camera, and object. Total mass is only the first constraint. Moving the center of mass away from the flange increases wrist moment, and rapid reversals create inertial loads that a static calculation misses. Do not ask a supplier only whether the robot “can lift 3 kg.” Ask whether the completed tool's mass m, center-of-mass vector r, and inertia satisfy the load diagram across the actual poses and accelerations.

Start with a conservative worksheet: tool mass = hand + adapter + fingers + wrist sensor + cable allowance + maximum object. If CAD or inertia data are unavailable, use the farthest credible component center of mass and mark the result as uncertain. Evaluate at least three representative poses: the folded home pose, an approach over the center of the table, and the farthest horizontal reach. Obtain the vendor's load-diagram calculation or written application confirmation. “Below rated payload” is necessary but not sufficient, especially for dexterous hands with long adapters and moving cables.

Repeatability must also be distinguished from accuracy. ISO 9283 defines measures such as pose accuracy and pose repeatability and requires controlled test conditions ^[4]. A small catalog repeatability value does not fix a wrong base–world transform, TCP, or camera extrinsic. Specifications in this chapter screen candidates; calibration and identification in (Chapter 9) make the installed cell trustworthy.

2. UR5e and FR3 are different control contracts, not interchangeable catalog rows

A more useful arm-selection axis than the label “industrial” or “research” is what the laboratory controls and what remains inside the vendor controller. The UR ecosystem emphasizes commissioning, teach-pendant operations, peripheral integration, and repeatable industrial workflows. The Franka Research ecosystem emphasizes seven-axis redundancy, joint torque sensing, a fast research interface, and impedance-control experiments. Neither is universally superior.

The current UR5e specification lists a 5 kg payload, 850 mm reach, ±0.03 mm ISO 9283 pose repeatability, a 500 Hz update rate, and 20.7 kg arm mass. ^[1] These values were checked on 2026-07-14 and do not approve an arbitrary completed tool. A 1 kg gripper, long fingers, wrist camera, and 2 kg object may fit the mass number while violating a pose-dependent wrist moment or leaving no collision margin.

The current FR3 evidence describes a 7-DoF arm with 3 kg rated payload, 855 mm reach, less than ±0.1 mm repeatability, and a 1 kHz control interface. ^{[2] [3]} The datasheet also publishes joint torque limits and Cartesian stiffness ranges. A configured stiffness is not guaranteed physical contact stiffness: pads, the object, table compliance, filters, and delay all influence the measured closed loop.

UR5e and FR3 are not interchangeable: UR5e evidence emphasizes payload and an industrial controller ecosystem, while FR3 emphasizes torque sensing and research control. ^{[1] [3]} This is a conditional capability comparison, not a universal ranking. For repeated pick-and-place and factory-like peripheral integration, UR5e may give the simpler contract. If joint torque or impedance is itself an experimental variable, FR3 exposes that question more directly.

Consider alternatives only when they solve a named constraint. Kinova Gen3 is credible for laboratories that value the Kortex API and an official Ubuntu/ROS support path, including mobile or accessibility-oriented research ^[7]. The xArm family is a candidate when a lower-cost commercial arm and Python/C++/ROS interfaces are priorities, but the name spans multiple models; reach, payload, and safety scope must be taken from the exact variant ^[8]. OpenArm is compelling when an open description, leader–follower workflow, and LeRobot integration are central. Its younger ecosystem, however, makes revision pinning, CAN configuration, regional parts supply, and local support more important ^{[10] [11]}.

SO-101 uses five arm joints plus one gripper motor (six motors total) and stores calibration by robot ID, making it a low-cost learning loop rather than an industrial substitute. ^[9] If the team accepts backlash, thermal limits, a small workspace, and the absence of a certified industrial cell ecosystem, the platform is valuable precisely because it teaches action, state, and timestamp semantics without expensive failures.

3. Decide whether to start with a parallel gripper or a multi-finger hand

A two-finger parallel gripper is the right first tool for most tabletop tasks. Its action space is usually one opening coordinate, the collision geometry and TCP are tractable, and custom fingers can adapt to object shape. Failures separate into understandable classes: wrong approach pose, insufficient opening, excessive grip, or inadequate friction. A multi-finger hand enables palm contact, finger gaiting, regrasping, and in-hand rotation, but buys new failure sources: joint coupling, tendon slack, tactile calibration, self-collision, retargeting, and maintenance ^[22].

Robotiq 2F-85 provides an 85 mm stroke and documented 20–235 N force range, while 2F-140 trades force for a 140 mm stroke. ^{[12] [13]} A force setting is not an accurate fingertip-force measurement. Usable force depends on finger geometry, contact position, object, acceleration, and manual assumptions. A common mistake is selecting the wider gripper for a large object and discovering that long fingers cannot deliver the required force at the actual contact.

The Franka Hand weighs 0.73 kg, provides 80 mm travel, and specifies 30–70 N continuous grasp force. ^[14] Its major benefit is not a claim of universal performance but fewer integration variables with FR3. The two fingers are not independently actuated, and a long custom finger can introduce tilting loads outside the tested geometry.

Custom fingers are often the cheapest useful performance upgrade. A V-groove aligns cylinders, a broad compliant pad reduces pressure on pouches and thin boxes, and a thin tip can retrieve small objects near a table. Every longer finger, however, changes the payload calculation, collision mesh, bending stiffness, and TCP uncertainty. A printed prototype is not automatically a production tool: evaluate sharp edges, layer separation, repeated cleaning, contamination, and loose fasteners.

A dexterous hand must not be classified by visible finger count. Inspect active actuator count, coupling, joint and torque state, tactile surface, control rate, hand mass, host interface, and simulator model. More DoF means more command axes; it does not guarantee accurate fingertip-force regulation or stable object rotation. Foundational grasp mechanics connect joint torque, contact force, and object wrench through contact Jacobians and grasp matrices. Using that relationship requires contact location, friction, and actuator semantics, not merely a hand-shaped URDF ^[21].

Shadow Dexterous Hand E has five fingers, 24 movements, and 20 actuated DoF, whereas Allegro V4 has four fingers and 16 active DoF. ^{[15] [16]} Allegro must not be mislabeled as a five-finger hand, although it remains valuable as an in-hand research benchmark. Shadow provides human-like morphology and high independence, but its full system mass is about 4.3 kg. It is unsuitable for a 3 kg-rated FR3 before adapter and object are added, and leaves little margin on a 5 kg-rated UR5e. It requires an arm with validated wrist payload and moment, a short adapter, and a specialist integration review.

Inspire RH56DFX is a five-finger but six-controlled-DoF family, so finger count is not a proxy for independent fingertip authority. ^{[17] [24]} Coupling is not simply a defect. It can provide simple power grasps with fewer commands and lower integration burden. It is a limitation when the task requires arbitrary joint configurations or fine finger gaiting.

Unitree Dex5-1P specifies 94 pressure sensors, while the base Dex5-1 row lists no tactile array; PSYONIC Ability Hand exposes six motors and 30 touch sensors, so their sensing and service workflows differ. ^{[18] [19] [20]} They can appear in the same “five-finger tactile hand” table despite that difference. Manufacturer sensor counts do not establish calibrated force accuracy, bandwidth, drift, or task success. Obtain raw packet schemas, timestamps, saturation behavior, replacement procedures, and calibration tools before purchase.

A dexterous-hand purchase is incomplete without flange adaptation, payload and inertia checks, cables, collision geometry, spares, zero calibration, controller access, and simulator assets. ^{[15] [19] [21]} Request a quotation for the complete installed tool, not “one hand.”

4. The four recommended configurations at a glance

The configurations below order learning goals and integration risk, not prestige. Configuration A teaches an episode schema reusable in B–D, but its servo and safety assumptions must not be copied to an industrial cobot. Configuration B can establish a planning and pick/place baseline for C, but position success does not prove safe contact behavior. Configuration D should be attempted by a team that can already commission A–C.

“Load-qualified UR5e-class arm” does not mean attaching products by name. Add the Dex5-1, adapter, cable, optional wrist sensor, and object; pass pose-dependent UR5e load requirements; and obtain confirmation of the mechanical and electrical interfaces from both suppliers. If it fails, select a higher-capability wrist or a lighter hand. A Shadow-class system needs a larger payload and moment margin than default FR3/UR5e combinations provide because the hand system itself is around 4.3 kg ^[15].

5. Configuration A — the cheapest complete learning loop

What it achieves

Configuration A is not a miniature industrial robot. Its purpose is to complete one transparent loop: operator action → follower command → joint state → camera frame → episode file → replay. Start with an SO-101 leader and follower, stock gripper, fixed tabletop mat, one or two modest cameras, and short reliable USB connections. The computer only needs to assemble, teleoperate, and record reliably. Defer a large training GPU until the action schema and task definition are stable.

Reasonable tasks include moving lightweight blocks, placing a cup in a marked region, repeating two poses, and recording and replaying 20–50 human-operated episodes. Precision connector insertion, heavy objects, fast cycles, and force-control research are out of scope. More useful KPIs than headline success include whether calibration reloads under the same robot ID, timestamps increase monotonically, dropped frames are detected, and a failed episode can be replayed ^[9].

Minimum BOM and acceptance gate

Do not buy an expensive glove, VR headset, tactile hand, or workstation GPU for this configuration. The matching leader is the most transparent teleoperator because leader and follower share joint semantics and minimize retargeting. Finalize cameras and compute after reading the VLA-ready logging requirements in (Chapter 3).

6. Configuration B — robust pick-and-place and ROS 2 integration

Why UR5e with 2F-85

Configuration B is a cell the laboratory can power every day and repeat. Mount a Robotiq 2F-85 on the UR5e with a short official or validated coupling and begin with stock fingers. Use the supported UR integration, controller state, teach pendant, and peripheral ecosystem to separate arm failures from perception failures ^{[1] [13]}. If an object exceeds 85 mm, do not automatically order a 2F-140. Test the required opening, grasp depth, force, and finger collision across the real object set.

Appropriate tasks include table or bin pick/place, tray loading, simple machine tending, tag- or depth-based pose grasps, MoveIt 2 planning, and real trajectory execution. Contact-rich in-hand motion and delicate force control are not its first objectives. Ninety-five percent position-controlled pick success says nothing by itself about safe insertion or sustained surface contact.

Mounting and safety

Bolt the base to a calculated structure or reinforced bench, not a thin mobile table. Check overturning moment at maximum reach, bolt pattern, table resonance, and the heaviest completed tool. Provide a service loop near the tool flange without allowing wrist rotation to wind the cable. Add removable strain relief for gripper and camera cables. The workspace includes the base, table, fixture, camera mast, dropped-object zone, and operator—not merely the arm's advertised reach sphere.

ISO 10218-1:2025 addresses safety requirements for industrial robots, while ISO 10218-2:2025 addresses applications and cells ^{[5] [6]}. Purchasing a “collaborative robot” does not replace an application risk assessment. Sharp custom fingers, pinch points, dropped objects, camera masts, and automatic restart introduce hazards outside the arm's built-in functions. Apply local law, institutional EHS review, and qualified integration practice.

Purchase and acceptance checklist

1. Fix the exact controller generation, PolyScope/firmware, ROS 2 driver branch, OS, and supported ROS 2 distribution in an attachment to the quotation.
2. Confirm inclusion of arm, controller, pendant, E-stop, power cables, tool I/O, gripper, coupling, fingertips, licenses, and training.
3. Replace the vendor's unloaded air motion with your representative adapter and object across three poses.
4. Demonstrate protective stop, network loss, gripper communication loss, stale command, and application restart behavior.
5. Obtain URDF/xacro, collision geometry, TCP procedure, payload/CoM configuration, gripper state, and fault-code logging.
6. Approve spare fingertips, coupling fasteners, gripper cable, and expected repair turnaround.

Do not buy a tactile hand or long custom fingers at the outset. Establish a stock-finger and simple-fixture baseline, then design fingers for the observed failure objects. If perception is unstable, changing to five fingers adds grasp candidates, hand posture, and sensing failures simultaneously.

7. Configuration C — make torque and compliance experimental variables

Configuration C begins with FR3 and Franka Hand. A same-vendor pair reduces uncertainty in flange, power, software objects, and the default model. The target output is not merely “the robot picked up an object.” It is an explanation of how Cartesian stiffness, collision thresholds, approach velocity, contact-force proxy, controller rate, and faults alter the outcome ^{[3] [14]}.

Suitable first tasks include grasping a foam block, low-speed peg approach, tracing a compliant surface with a small force, and a controlled handover that remains below validated thresholds. High-speed force control, sharp tools, and unsupervised experiments near people are excluded initially. A host using Franka Control Interface must satisfy the vendor's network and real-time requirements. Do not mix a low-level loop with an unpredictable learning workload on an unqualified scheduler.

Do not attach a heavy five-finger hand immediately. Learn the control contract with Franka Hand, adapter, and object inside the 3 kg rated payload. A lighter research hand such as Allegro may be considered, but it has four fingers and adds an adapter, CAN/host, collision model, and simulator-integration project ^[16]. Shadow Hand E is not a default FR3 end effector because of its mass ^[15].

If force-bearing demonstrations are a long-term objective, the hardware determines the action representation. DexForce shows tasks in which force-informed actions outperform actions that ignore force, but the evidence is tied to one platform and per-task gain tuning ^[25]. Terry's related note is available in Korean and English. Before imitating the study, decide which force, torque, stiffness, and contact proxies can actually be synchronized in the FR3 log.

8. Configuration D — a high-risk cell for tactile multi-finger manipulation

The purpose of Configuration D is not to own a human-looking hand. It is to study palm and multi-fingertip regrasping, slip observation, object rotation, and teleoperation data reproducibly. A defensible starting candidate is a load-qualified UR5e-class arm with a relatively lightweight five-finger tactile hand such as Unitree Dex5-1. Public product pages do not fully establish ROS 2 packages, calibrated tactile units, loaded control rate, collision-model quality, or long-term support. Order only after the audit below passes ^{[18] [19]}.

If the task needs simple power grasps and human-like form, coupled hands such as Inspire RH56DFX or PSYONIC Ability Hand can reduce command and integration burden ^{[17] [20]}. If independent fingertip trajectories, research baselines, and a mature paper ecosystem matter more, accept Allegro's four-finger morphology or the greater mass and maintenance of Shadow. A requirement for “five fingers” is not the same as a requirement for independent finger control.

Evidence required from the supplier before ordering

The first-month task is not cube rotation. Progress through: verify every joint sign and zero; command one finger at a time; measure unloaded tactile baseline and drift; hold one object statically; repeat the same grasp 100 times; then attempt one-step regrasping. Record joint error, tactile saturation, missed packets, temperature, calibration ID, interventions, and pad damage alongside task success.

Do not buy the hand first and match a glove afterward. DexUMI uses a human hand as a dexterous manipulation interface and demonstrates learning on two robot-hand platforms, but relies on a hand-specific exoskeleton and a rigid camera relationship ^[26]. Terry's related note is available in Korean and English. Do not copy a human joint vector directly into robot joint angles. Decide whether retargeting preserves fingertip poses, grasp aperture, or contact intent; (Chapter 8) develops that design.

Buying one hand first is also a technical strategy. Validate adapter, driver, zero, tactile log, simulator, and spares on one side before justifying a second hand. Bimanual hardware adds not just a second device but paired calibration, paired collision, twice the cabling, time synchronization, and operator mapping.

9. Audit driver and simulator ecosystems before hardware purchase

This is not the software-installation chapter, but hardware purchase fixes a software contract. “ROS 2 support” may mean binary packages, source-only compilation, a ros2_control hardware interface, or only vendor topics. “Isaac Sim support” may mean an official articulation asset, a community URDF import, or a visual-only model. “MuJoCo model included” is incomplete unless actuator semantics, joint limits, contact, and tendon parameters are described and validated.

A platform such as OpenArm that documents descriptions, fake-hardware switches, and namespace structures is useful for learning custom integration ^[10]. Good documentation does not establish long field history. Conversely, an established arm is not automatically supported on every new ROS 2 distribution or current SDK. Record hardware revision, controller firmware, OS image, compiler, SDK, and ROS package commit as one compatibility tuple.

10. Bounded pre-purchase audit prompts for Codex

Codex is useful for comparing vendor manuals, repositories, and the local workspace and exposing missing evidence. It must not declare a safety rating, connect to and authorize real motion, or invent unavailable driver support. The prompts below constrain output to a read-only audit report. A human reviews that report before code generation or purchase approval.

Prompt A — arm–hand BOM and payload audit

Act as a pre-purchase compatibility auditor for a robot cell. Do not write code or
connect to hardware. Read only the materials I provide: (1) exact arm model/manual,
(2) hand/gripper manual, (3) adapter drawing, (4) wrist sensor/camera data, and
(5) maximum object and representative pose list.

Create a table with component, mass, CoM, inertia/source, flange/interface, power,
communication, cable constraint, and uncertainty. Include hand, adapter, fingers,
sensor, cable allowance, and object in total tool mass. If the manufacturer's load
diagram or wrist-moment evidence is absent, label the result UNKNOWN, never PASS.
List the document needed for each representative pose, plus reach, collision, TCP,
and spare-part gaps.

Output: (a) verified facts with URL/page, (b) assumptions, (c) blockers,
(d) at most 15 supplier questions, and (e) conditions under which not to purchase.
Do not guess price or declare safety certification.

Prompt B — driver and simulator-asset audit

Read this workspace package tree and only the official vendor repositories I provide.
Do not command a real robot and do not modify files. Build a compatibility tuple for
exact hardware revision, controller firmware, Ubuntu, ROS 2 distribution, SDK/library,
driver commit, and hand firmware.

Classify each item as official-supported, community-only, source-build-required, or
unknown. Check the presence and license of URDF/xacro, SRDF, ros2_control interface,
joint limits, transmissions, collision meshes, MoveIt config, Isaac asset, MJCF, and
sample logs. Do not infer compatibility from a README slogan; cite release/tag/CI data.

Propose only the contents of an unchanged audit.md report. If blocked, limit any
minimal reproduction command to simulation or fake hardware. Do not propose real
motion, torque commands, safety bypasses, or automatic dependency upgrades.

Prompt C — incoming acceptance-test plan

Using my selected arm-hand BOM and institution-approved safety boundary, write an
incoming acceptance plan. Do not generate code. Divide tests into inventory,
visual/mechanical, electrical-with-drives-disabled, network-with-drives-disabled,
small-joint-motion, Cartesian, gripper/hand, fault injection, and two-hour repeatability.

For every test include owner, prerequisite, measured signal, pass threshold, stop
condition, and saved artifact. If a manual does not define a threshold, mark UNKNOWN
and require owner approval. Keep E-stop and protective-stop authority with the robot
safety controller and site personnel. Never make an LLM the real-time or safety authority.

A good prompt fixes exact revisions, authority, output artifact, and stop conditions. “Connect my VR headset and make the robot move” is a poor request because it omits frames, scale, rate, stale-input behavior, workspace limits, and fake-hardware testing. (Chapter 8) extends this audit into an IK and leader–follower implementation prompt.

11. Evidence tiers, disagreements, and unresolved limitations

This chapter relies on two main evidence classes. UR5e, FR3, gripper, and hand mass, DoF, and interface values come from primary official manuals, datasheets, and product pages. They support a specification or interface for a dated revision; they do not establish an independent product ranking. Papers such as Salisbury, Bicchi, DexForce, and DexUMI provide academic primary evidence for grasp mechanics, design trade-offs, or bounded experiments. Their results remain tied to the reported hand, task, controller, and protocol.

Company demonstrations are evidence that a behavior may be attainable, not standardized benchmarks. A bucket-lifting video is not a payload test. Tactile-point count is not force accuracy. “1 kHz communication” is not end-to-end closed-loop bandwidth. Analyst or news claims can help discover a supplier but should not authorize purchase. Actual quotations should be stored as date-stamped procurement records; they are deliberately absent from this comparison.

The first disagreement concerns industrial robustness versus research control access. It is misleading to call UR5e “less research-oriented” and FR3 simply “better.” In Configuration B, stable controller behavior and serviceability can improve research reproducibility. In Configuration C, joint torque and impedance access are the research question. Do not compress different tasks, payloads, modes, and failure evidence into one score.

The second disagreement is parallel gripper versus dexterous hand. A multi-finger hand offers a wider grasp set, but if the immediate success criterion is picking a fixtured bottle, a 2F gripper with a custom finger may deliver higher experimental throughput. If the object must rotate in-hand or remain constrained during regrasping, a parallel gripper can distort the task definition. Underactuation can create robust adaptive grasps with simple control while sacrificing arbitrary fingertip motion ^[23].

Several limitations remain. Product, SDK, ROS 2, and simulator support will change after 2026-07-14. Manufacturer specifications are not independent tests under shared conditions. Local distributor competence, lead time, and repair turnaround cannot be inferred from public manuals. ISO public pages verify scope and edition but do not replace the paid normative text, local law, or qualified review. Finally, common evidence for long-duration hand life, tactile drift, and cable wear remains weak, so each cell must accumulate its own acceptance and maintenance logs.

Relation to Prior Surveys

#S1 Chapter 5.7 made a durable distinction among a research benchmark hand, a humanoid integration component, a manufacturing purchase candidate, and a lower-DoF industrial hand. This chapter does not copy that product table. It turns the distinction into four complete arm–hand cells and asks each one to pass payload, driver, model, safety, service, and “do not buy yet” gates. Candidates such as Sharpa, AgiBot, XHAND, and Wuji remain interesting, but only products with sufficiently resolved current manuals and integration evidence in this chapter's source packet support the purchasing walkthrough.

The refreshed conclusion preserves #S1's warning: do not buy by DoF or tactile density. Allegro and Shadow as research benchmarks have a different KPI from a coupled five-finger hand that is easy to purchase and repair. The operational upgrade is to require a complete installed tool and acceptance artifacts instead of stopping at a landscape table.

Manufacturing Cell Checkpoint

Trace one Configuration B decision to completion. The target cell moves 0.2–1.0 kg bottles and small boxes from tray A to fixture B. Measure the maximum object width first, then mark approach clearance and the dropped-object zone in CAD. If all objects fit the 2F-85 opening, set UR5e+2F-85 as the baseline. Do not move to 2F-140 or a five-finger hand because one or two SKUs are wide until alternate grasps and fixtures have been tested.

The data schema includes attempt_id, object_id, arm_revision, hand_revision, adapter_revision, calibration_id, planned_pose, actual_joint_state, gripper_width/current, controller_state, fault_code, intervention, outcome. KPIs include missed grasps, object damage, protective stops, recovery time, calibration rework, and pad-replacement time—not task success alone. Purchase the next tool only after a 100-cycle test can separate insufficient width, low friction, and pose error.

Assign ownership. The PI or lab manager owns scope and approved budget; the mechanical owner owns mount, load, and cable; the software owner owns the version tuple and logs; the safety owner owns risk assessment and stop validation; and the operator owns preflight and anomaly reporting. A vendor or Codex can supply evidence and drafts but never final motion authority.

Final purchase-approval table

An UNKNOWN does not permanently reject a purchase. Put an owner, test, and deadline for closing it into the quotation and schedule. Conversely, hold the order if a compelling demonstration still leaves a safety, payload, control, or service blocker.

What to Learn Next

After selecting the arm and hand, the next question is: how does the cell see, accept human commands, compute, and stop physically? (Chapter 3) adds cameras, Meta Quest-class VR, trackers, gloves, joysticks, GPU tiers, tables, mounts, E-stops, and guards to each configuration. That produces a complete cell BOM.

Then (Chapter 4) explains how ROS 2 nodes, topics, actions, transforms, drivers, and vendor controllers form a real motion contract. Do not generate real-robot motion code yet. The compatibility tuple, complete-tool load sheet, and acceptance plan from this chapter are prerequisites for a safe and reproducible progression through simulation, fake hardware, and first motion.

Annotated research trail

These sources deepen hand embodiment, sensing, and maintainability. They are grouped by the assumption or experiment to inspect, rather than used as a list of borrowed success rates. Read each result within its platform and protocol.

References

1. Universal Robots (2026). UR5e Technical Specifications SW10.6. Universal Robots official manual.
2. Franka Robotics (2026a). Franka Research 3 Brochure, February 2026. Official brochure.
3. Franka Robotics (2025). Franka Research 3 Datasheet v2.3. Official datasheet R02212 2.3.
4. ISO (1998). ISO 9283:1998 Manipulating industrial robots — Performance criteria and related test methods. International Standard.
5. ISO (2025a). ISO 10218-1:2025 Robotics — Safety requirements — Part 1: Industrial robots. International Standard, edition 3.
6. ISO (2025b). ISO 10218-2:2025 Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells. International Standard, edition 3.
7. Kinova Robotics (2024). KINOVA Gen3 Ultra Lightweight Robot One-Pager 2024. Official product documentation.
8. UFACTORY (2025). xArm Series Hardware Manual v2.6.0. Official hardware manual.
9. Hugging Face (2025). SO-101 Hardware and Calibration Guide. LeRobot official documentation.
10. OpenArm (2026a). OpenArm v2.0 Robot Description and ROS Namespacing. Official documentation.
11. Hugging Face & OpenArm (2026). OpenArm Integration in LeRobot. LeRobot official documentation.
12. Robotiq (2025). Adaptive Grippers Product Sheet, May 2025. Official product sheet.
13. Robotiq (2026). 2F-85 and 2F-140 Instruction Manual. Official instruction manual.
14. Franka Robotics (2026b). Franka Hand Product Manual 1.0. Official product manual.
15. Shadow Robot (2024). Shadow Dexterous Hand E Technical Specification. Official technical specification.
16. Wonik Robotics (2026). Allegro Hand V4 Product Specification. Official product page.
17. Inspire Robots (2026). RH56DFX Dexterous Hand Selection Guide. Manufacturer selection guide.
18. Unitree Robotics (2026a). Unitree Dex5-1 Dexterous Hand. Official product page.
19. Unitree Robotics (2026b). Unitree Dex5-1 Tactile and Serviceability Details. Official product page.
20. PSYONIC (2026). Ability Hand Research API. Official research release.
21. Salisbury, J. K., & Craig, J. J. (1982). The Mechanics of Fine Manipulation by Finger Tips. The International Journal of Robotics Research. DOI: 10.1177/027836498200100201. [Salisbury & Craig, 1982]
22. Bicchi, A. (2000). Hands for Dexterous Manipulation and Robust Grasping: A Difficult Road Toward Simplicity. IEEE Transactions on Robotics and Automation. DOI: 10.1109/70.897777.
23. Catalano, M. G., et al. (2014). Adaptive Synergies for the Design and Control of the Pisa/IIT SoftHand. The International Journal of Robotics Research. DOI: 10.1177/0278364913518998.
24. Correll Lab et al. (2026). Characterization, Analytical Planning, and Hybrid Force Control for the Inspire RH56DFX Hand. arXiv:2603.08988.
25. Chen, C., et al. (2025). DexForce: Extracting Force-Informed Actions from Kinesthetic Demonstrations. arXiv:2501.10356.
26. Xu, M., et al. (2025). DexUMI: Using Human Hand as the Universal Manipulation Interface for Dexterous Manipulation. Proceedings of Machine Learning Research 305. DOI: 10.48550/arXiv.2505.21864.