Chapter 1: What Will You Move? Start with Task, Budget, and Safety

Overview

When a new robot arrives, the natural impulse is to make the arm move. The better first move is to write down what should move, over what range, with what tolerated failure rate. “Pick up a cup” is not enough to select an arm, hand, camera, table, network, or stop system. A useful requirement names the cup’s mass and material, where it may begin, where it must end, who may approach the cell, what contact is allowed, and how success will be observed.

This chapter is a tutorial for designing those requirements before selecting a manipulator. You will produce five compact artifacts: a task envelope, a hazard register, a cell layout, an interface and logging contract, and staged acceptance gates. With these in hand, Chapter 2 becomes a search for a configuration that is sufficient and operable, not a search for the catalog robot with the largest collection of features.

Standards and manufacturer manuals provide essential evidence, but this chapter is not certification or legal advice. A qualified person who understands the jurisdiction, institutional EHS rules, installation, tool, and workpiece must own the final risk assessment and authorization to operate. A generative tool such as Codex can help draft documents, tests, and adapters. It must never become the authority that declares a safety function valid or a cell safe.

After reading this chapter... - You can turn a vague manipulation idea into a one-page task envelope covering objects, motion, environment, people, and measurable success. - You can budget for the complete cell, schedule, operating labor, and data—not merely the robot’s purchase price. - You can build a hazard register that assigns prevention, protection, recovery, verification, and residual-risk ownership. - You can include geometry, mounting, power, networking, timing, logging, stops, and recovery access in the cell layout. - You can define staged acceptance gates from static-model inspection to supervised, reduced-motion hardware trials.

1. Convert the idea into a task envelope

A task envelope states both what the robot is expected to do and what remains out of scope. Its first version can fit on one page. Do not title it “tabletop object manipulation.” Write something testable, such as “pick an empty plastic cup from a marked start region and place it upright in a tray 30 cm away.” The sentence should expose the object, initial condition, and desired final state.

Begin with the object set. Record minimum and maximum mass, representative dimensions, surface materials, compliance, sharp features, and whether the object contains liquids, powders, batteries, heat, or stored energy. “Household objects” is not a requirement. An empty paper cup and a water-filled glass may look similar in an image, yet require different gripping force and produce very different consequences when dropped. For a first cell, narrow the set to light, nonbreaking, unpowered objects.

Next, decompose the action into observe, approach, acquire, lift, transport, place, and retreat. Mark which phases matter. A cap-twisting, insertion, or connector task also needs an allowed-contact region, a justified force or torque envelope, and a retreat behavior for wedging. Task-oriented grasp research has long connected grasp choice to force and precision needs, not object shape alone ^[1]. That is why “five fingers look more capable” is not a sufficient end-effector requirement.

Quantify space and time. Draw the start region, target region, no-go region, human access zone, and minimum clearance. Specify an episode time limit, desired episodes per day, and human reset time. If a policy runs for 20 seconds but a person needs 90 seconds to restore the scene, robot speed is not the throughput bottleneck. The observation points toward a fixture or reset aid before it points toward a faster manipulator.

Write down the human roles. Separate the operator, observer, scene-reset person, and maintenance technician, and identify when each may approach. If the task does not truly require a human and robot to occupy the same space at the same time, sequential operation—stop, verify, then enter—may be much simpler than engineered collaboration. Safety starts by reducing exposure through workflow design before adding sensors ^[3].

Finally, define success and failure as observable events. Replace “usually picks it” with “the cup is upright inside the target tray, remains upright for two seconds, is undamaged, and neither robot nor object enters the no-go region.” A success rate requires a denominator. Unless object type, initial pose, lighting, and retry policy are fixed or stratified, a reported 90 percent cannot be compared. Classify failures as perception, approach collision, slip, drop, incorrect placement, timeout, or operator intervention.

A reusable one-page template

Fill the following fields. “TBD” is acceptable if it is paired with an owner and decision date.

• Goal: One sentence describing the final state the robot must produce.
• Objects: Types, mass range, dimensions, material, fragility, and prohibited contents.
• Start and finish: Start region and pose distribution; target region and tolerance.
• Motion: Required phases, allowed contact, and the source of any force or speed boundary.
• Environment: Table dimensions and height, lighting, background, obstacles, liquids, dust, and temperature.
• People: Operators and observers, access timing, training, and authorization.
• KPIs: Success definition, number of trials, cycle time, intervention rate, and damage rate.
• Exclusions: Tasks and objects explicitly deferred. This line prevents scope from expanding invisibly.

2. Budget by ambition, not by a single bill of materials

Comparing only arm prices almost guarantees a bad cell budget. Total cost includes the arm, end effector, adapter, cables, cameras, lenses, lighting, table, base, guards, stop hardware, network equipment, workstation, spares, shipping, taxes, installation, training, maintenance, and data storage. With a dexterous hand, adapter fabrication, communications, collision meshes, finger calibration, replacement cables, and repair time can outweigh the visible hand price.

It helps to separate four ambition tiers. Tier A is a low-cost learning and data loop. A compact servo-based leader–follower pair, light objects, a desktop surface, and basic cameras can teach the complete path from teleoperation to recording and imitation learning. The SO-101 documentation connects assembly, servo calibration, teleoperation, data recording, and evaluation in one maintained learning workflow ^[18]. The tier is not intended to prove industrial throughput, accuracy, or safety performance.

Tier B is a reproducible tabletop research cell. Maintained robot descriptions, drivers, mock-hardware support, and documented interfaces matter more. An open platform such as OpenArm explicitly considers leader–follower and multi-robot naming arrangements ^[19]. Tier C is a UR5e- or FR3-class research cell where vendor service, safety interfaces, robust mounting, and sustained operation become central. Tier D is contact-rich dexterous research. A multi-finger hand is only one cost item; tactile sensing, high-rate control, identification, protective fixtures, spare parts, and expert integration dominate the plan.

These tiers are not a universal performance ranking. It can be rational to validate data collection on Tier A and later transfer the workflow to Tier C. But if the target task uses heavy tooling or safety-related I/O, results on the learning device cannot be treated as final-cell evidence. Changing platform changes joint range, backlash, latency, viewpoint, gripper dynamics, and hazardous energy at the same time.

Put labor into the budget. Do not write “hand integration: four weeks.” Separate mechanical adapter design, electrical wiring, communication driver, URDF and collision model, TCP and center-of-mass calibration, control trials, and safety review. Assign an owner and completion evidence to each. A commercial system with support may cost more but reduce uncertainty in integration delay. An open system provides modification freedom while leaving revision pinning, sourcing, and maintenance responsibility with the lab ^[20].

Before purchase approval, present three totals. The minimum viable budget funds one safely bounded base task. The research budget includes repeat experiments, data, and spares. The expansion budget holds unvalidated ambition such as a five-finger hand, tactile sensors, a second arm, or additional GPUs. This separation prevents attractive extensions from displacing a rigid mount, local stop device, or reliable logging.

Schedule should be gated in the same way. Delivery is not the start of data collection. Allow time for receiving inspection, mounting, electrical review, network setup, vendor training, static model checks, driver compatibility, read-only observation, mock-hardware tests, reduced-motion trials, and only then task experiments. A date attached to each gate is more honest than one “robot ready” milestone.

3. Assess the application instead of trusting the word “collaborative”

The first safety question is not “Is this arm a cobot?” It is “Who is exposed to what energy and geometry in this application?” The same arm presents different hazards when carrying a foam block and when pointing a sharp driver toward a person. Collision outcome depends on speed, effective mass, tool, payload, contact location, and constraint—not robot mass alone ^[6].

ISO 10218-1:2025 addresses the industrial robot product, while ISO 10218-2:2025 addresses the integrated robot application and cell. Safety reasoning for manufacturer-provided robot functions and for the completed laboratory cell must therefore be handled as distinct responsibility layers ^{[10] [11]}.

The 2025 editions of ISO 10218 Parts 1 and 2 supersede the 2011 editions, so a new commissioning guide must not present the withdrawn 2011 documents as the current baseline ^{[4] [5] [10] [11]}. Applicable editions and duties can still differ by jurisdiction, institution, and use; a qualified local reviewer must determine them rather than inferring compliance from public ISO records.

ISO/TS 15066:2016 remained published at this survey’s cutoff, but its official record had moved into revision. It should not be presented as an immutable final rulebook for collaborative operation ^{[7] [12]}. The public record verifies scope and lifecycle; it does not expose every threshold in the paid normative text.

A robot with collaborative-operation features does not make the application safe by itself. The end effector, grasped object, fixture, table edge, loose cable, camera stand, and pattern of human access add cell-level hazards ^{[3] [11] [8]}.

Write hazards as scenarios

A hazard-register row titled “collision” is too broad to test. Write each row as operating state + hazard source + exposed party + consequence. “During automatic execution, the wrist-camera cable catches the fixture and throws a glass cup toward the operator” can drive a design review. Record existing controls, the basis for severity and exposure estimates, additional controls, the verification test, residual risk, and the person who accepts it.

Think through risk reduction in the order of elimination by design, engineering safeguards, and finally procedures and information ^[3]. Remove a sharp tool when it is not required. If no person needs to enter during execution, evaluate physical separation and interlocking. For remaining exposure, consider limited workspaces, monitored zones, protective stops, and justified speed or force limits. Add training, signs, and personal protective equipment for what remains; do not use procedure alone to cover a design defect.

The owner column is substantive. If the same developer writes motion code and unilaterally accepts its safety implications, independent review is weakened. First physical motion, a new tool, an increase in motion limits, and a change in human access should each trigger a second reviewer. Schedule pressure is not evidence for accepting residual risk.

4. The cell is geometry, power, network, and records around the robot

Mechanics and access

Make both a top view and a side view of the cell. Mark the base, maximum kinematic reach, deliberately permitted task workspace, possible swept region during stopping, under-table structure, camera stands, cable chains, workstation, operator positions, and access to stops. Grid paper is sufficient for a first version, but every dimension and revision needs an identifier.

A circle at catalog reach is not enough. Include the hand and adapter length, held-object length, elbow postures, singularity avoidance, and collision clearance. Conversely, there is rarely a reason to permit the whole catalog workspace. Restrict software workspace boundaries and fixtures to the smaller task envelope. Smaller authorized space improves both testability and fault containment.

The table and base are not furniture that merely carries static weight. They must transfer loads from acceleration, collision, and stopping as required by the installation instructions. Review anchor bolts, plate and frame stiffness, floor level, and overturning. A wheeled cart is convenient, but wheel locks, center of gravity, and recalibration after movement become requirements. If the physical mount changes, recheck camera extrinsics and the robot-to-table transform.

Commissioning a UR5e requires mounting, actual payload, center of gravity, tool center point, and safety settings to match the installed tool and application ^{[13] [14]}. A catalog payload of 5 kg does not mean a 5 kg object can be added to any hand and adapter. Gripper, adapter, wrist camera, cable, object, and moment arm all contribute, while final settings remain tied to the application risk assessment.

The FR3 combines safety interfaces with a 1 kHz research interface, but neither feature transfers application-safety authority to the workstation or user controller ^{[15] [16] [11]}. A fast research interface is a control capability, not a certificate that generated torque commands are safe.

Power, grounding, and stored energy

Create a power table with rating, peak demand, connector, branch circuit, grounding, and UPS intent for every device. Avoid placing the robot controller, GPU workstation, lights, cameras, network switch, hand supply, and compressor on an undocumented power strip. Define startup and shutdown order. A workstation crash must not be assumed to perform the robot’s required stop function.

A UPS should support a designed transition—such as retaining logs and shutting down cleanly—not blindly keep every actuator moving. Decide what is backed up and test the state of robot and gripper when utility power fails. If a pneumatic gripper is used, pressure loss and residual-pressure release belong in the hazard scenarios. If an electric hand can relax and drop an object, provide a benign test object and catch region.

Keep emergency and maintenance isolation understandable to the person at the cell. Label disconnects, do not hide them behind a robot sweep, and document residual energy. The person resetting an object should not need to interpret a workstation dashboard to know whether access is authorized.

Network boundaries and time

Prefer a wired control network separated from ordinary lab Wi-Fi. Document fixed addressing or explicit address management, firewall boundaries, remote-access policy, firmware and package versions, and clock synchronization. The learning workstation may require internet and large transfers; the robot interface requires bounded, observable communication. Prevent cloud sync or dataset copies from competing with control traffic.

On the network diagram, draw who can command whom. Separate observation-only machines, planning computers, robot controller, cameras, and remote terminals. A remote researcher may be allowed to view state while a trained person beside the cell retains authorization to enable physical motion. Loss of an SSH session is not an emergency stop, and remote process cancellation is not proof that hazardous energy has been removed.

Time matters before VLA or teleoperation. Camera frames, joint state, commands, gripper state, and safety events need comparable timestamps to reconstruct failure. Distinguish device clock error, network delay, and storage delay. If a video appears to show the hand closing late but the team cannot tell policy latency from clock offset, a large dataset can still teach the wrong temporal relationship.

Logging is both research evidence and incident reconstruction

The minimum log includes experiment ID, task version, operator, robot and tool configuration, software commit or package versions, start and end times, joint state, commands, gripper state, camera timestamps, safety events, and outcome labels. Not every high-rate signal must be stored forever. A practical design keeps a short high-rate ring buffer and long-term summary, preserving the interval before and after a stop or failed episode.

Estimate storage before purchase: camera count × resolution × frame rate × compression × daily run time. Then define retention and backup. If video can identify people, set access and deletion rules. A training dataset and a safety-event record may have different purposes and retention periods; do not accumulate both indefinitely in one ungoverned folder.

Treat configuration as data. Save the payload and TCP values, robot firmware, driver version, URDF hash, calibration identifiers, camera settings, and safety configuration reference with each session. A successful trajectory without the configuration that produced it is not reproducible evidence. A failed trajectory without the same context is difficult to diagnose.

5. Decide readiness with acceptance gates, not one specification

Catalog specifications screen candidates; they do not certify the cell. Repeatability, absolute accuracy, TCP error, camera extrinsic error, gripper-center error, and object slip are different quantities.

ISO 9283 pose repeatability is a metric measured under stated test conditions, not a guarantee of absolute accuracy, TCP calibration, or grasp success ^{[2] [14] [17]}. A “±0.03 mm repeatability” line therefore does not imply that an object located in camera coordinates can be grasped with the same total error.

Commission the cell through ordered gates. Do not increase speed, workspace, or autonomy without evidence from the preceding gate.

Emergency stop, protective stop, and software motion cancellation are distinct mechanisms and must not be collapsed into one generic “stop” ^{[13] [15] [11]}. Exact stop categories, state transitions, and reset behavior are platform- and application-specific. Test who can invoke each mechanism, what energy state results, who checks the cause, and who authorizes restart using the product manuals and the integrated-cell design.

A stop trial is not complete because one button worked once. Check reachability from operator, reset, and maintenance positions. Inject network loss, control-process termination, camera freeze, hand communication failure, and limit violations where this can be done safely. Verify the designed state. Recovery should include removing the cause, checking the cell is clear, reinitializing state, and performing a reduced-motion confirmation. Unattended automatic restart is not a sensible first-cell objective.

Acceptance evidence should be reviewable by someone who did not run the test. Keep test ID, requirement ID, prerequisites, setup photograph, configuration, action, expected result, actual result, logs, reviewer, and date. “Works on my machine” is not evidence that the physical cell is commissioned.

Walkthrough: from a cup-transfer idea to a purchasable cell

Suppose a team asks for “a VLA experiment that moves cups.” The phrase initially leaves the cup set open. The task-envelope exercise narrows it to two empty, opaque plastic cups weighing 20–60 g; a 30 × 20 cm start region; a 25 × 15 cm target tray; and no human entry during execution. Success means the cup remains upright inside the tray for two seconds. The team will report success and intervention rates over 50 trials.

That decision changes the hardware requirements. A heavy five-finger hand and high arm payload are less urgent than a tractable two-finger gripper, rigid overhead camera, and replaceable nonslip work mat. A catch tray sits below the table edge. The authorized task workspace is smaller than maximum reach. A local indicator confirms a stopped state before a person resets the cup. Robot base and camera are fixed, and a reference target checks extrinsic drift at the start of each session.

The hazard register prioritizes trapping between arm and table, cable snag, incorrect TCP, and human entry during remote execution—not merely cup breakage. At G0, the team assigns owners. At G1, it records payload and center of mass for the empty hand and for the cup. At G3, it sends no commands, only reading joint and safety state. At G4, it samples 100 targets and checks that out-of-workspace and collision targets are rejected. At G5, it performs small joint motions and stop/recovery trials without a cup. Grasping begins only at G6.

The value of the exercise is not that it selected an inexpensive arm. It produced a specification that a vendor can answer and tests that can reject a configuration. In Chapter 2, “popular in research” becomes secondary to workspace fit, payload margin, driver maintenance, service route, safety I/O, and uncertainty in the integration budget.

6. Give Codex a verification contract before asking for code

Generative tools are useful for ROS 2 package scaffolds, configuration linters, log schemas, and mock-hardware tests. “Write code that moves my robot safely” is a poor request because safe, robot, units, limits, failure state, and test environment are undefined. Use four explicit fields—Goal / Context / Constraints / Done-when—and prohibit real-hardware write access by default.

Prompt 1: turn the idea into a reviewable envelope

Goal: Convert the manipulation idea below into a one-page task envelope and an unresolved-question list. Context: I will provide object notes, start and target areas, human roles, likely cameras, desired episodes per day, and current budget. Constraints: Do not invent unknown values; label them TBD with an owner. Do not claim standards compliance. Do not generate raw control code. Done-when: Object, motion, environment, people, KPI, and exclusions are tabulated, with purchasing blockers separated from questions for the site safety owner.

Prompt 2: design a read-only interface and logging check

Goal: Produce a test plan that reads the selected driver’s state interfaces and verifies units, timestamps, and joint ordering. Context: I will provide the manufacturer manual, ROS 2 distribution, driver version, URDF joint names, expected update rate, and a sample log. Constraints: Do not send motion commands, change safety I/O, auto-recover, or disable limits. Do not invent undocumented interfaces; flag uncertainty. Done-when: Tests cover nominal data, missing data, delay, axis-order errors, and unit errors, and can run first against recorded or mock data.

Prompt 3: automate acceptance evidence without authorizing operation

Goal: Design checklists and test cases for static and mock-hardware gates G1–G4. Context: I will provide joint limits, authorized workspace, no-go region, TCP, payload range, collision model, and cancellation interface. Constraints: A failed test blocks physical progression. Do not certify emergency-stop performance in software. Generated artifacts have no real-robot write permission before independent review. Done-when: Every requirement maps to a traceable test ID, input, expected result, failure message, and evidence-file location.

After receiving an answer, a human checks three things. Did the model invent a topic, service, limit, or recovery behavior absent from the cited manuals? Are meters versus millimeters, degrees versus radians, and link versus joint names consistent? Does the output mistake a software-test pass for authorization to operate? Generated code can remove clerical work; risk assessment, safeguard validation, and operating authorization remain organizational responsibilities.

Keep generated adapters out of the hard real-time or safety-authority path unless the complete engineering and assurance process for that role exists. A convenient script can request motion through a documented, bounded interface. It should not secretly bypass the controller, rewrite safety configuration, or auto-reset a protective event. Make permissions, network routes, and launch defaults enforce that boundary rather than relying only on a comment.

7. Evidence tiers, disagreements, and recurring failure modes

This chapter does not weigh all evidence equally. ISO records and normative documents establish scope and safety processes. Product manuals and data sheets establish version-specific installation, interfaces, and limits; they are not independent rankings. Peer-reviewed papers and academic books support general manipulation, collision, and human–robot-interaction principles, but do not certify a particular lab cell. Company demos and community videos can motivate an experiment. Without conditions and failure denominators, they are not acceptance evidence.

Two slogans often erase the application assumptions: “a collaborative robot needs no guarding” and “any robot near a person needs a complete fence.” The appropriate protection changes with whether simultaneous access is required, tool geometry, speed, stopping distance, sensing coverage, and reset procedure. This chapter does not prescribe a universal arrangement. It asks the hazard register to expose assumptions and validation evidence so a qualified reviewer can make a jurisdiction-appropriate decision.

SO-101 and OpenArm provide coherent low-cost learning loops, but their documentation does not establish an industrial safety ecosystem equivalent to UR5e- or FR3-class cells ^{[18] [19] [10]}. This does not preclude safe use after an appropriate local assessment. It means the safety claims and support structures of a different product class cannot be transferred automatically.

Common failures follow from collapsing distinct quantities. Teams subtract neither hand, adapter, nor cable moment from payload. They read repeatability as total cell accuracy. They postpone camera, coordinate-frame, and clock validation until after collecting data. They test software cancel and call it an emergency-stop test. They report success without interventions, retries, object-level denominators, or rejected trials. They integrate a dexterous hand, VR, VLA, and contact learning simultaneously before establishing first motion.

Another failure is premature expansion. A small, instrumented task can reveal driver instability, timestamp mismatch, thermal limits, cable routing, and reset burden. Adding object diversity or autonomy before those are measured creates confounded failures. Expand one axis at a time—object, viewpoint, speed, workspace, tool, human access, or policy—and reopen the relevant hazard and acceptance gates.

Public standards pages do not reveal all normative clauses. Product and software status in this chapter is current only to the 2026-07-14 research cutoff. Manufacturer specifications are conditional on product version and test assumptions. Research results are bound to the reported hardware, controller, task, and evaluation protocol. Copying this chapter’s table and signing it is less useful than measuring each assumption in the actual cell and preserving versioned evidence.

Manufacturing Cell Checkpoint

If any of the following is blank, the lab is not ready to finalize an arm order or promise a first-motion date.

• Task schema: Are object range, initial and target distributions, allowed contacts, exclusions, and success/failure denominators explicit?
• Mechanical boundary: Does the drawing include table and base stiffness, authorized workspace, no-go zones, hand-and-object sweep, cables, and camera mounts?
• Power and network: Are device power, grounding, loss-of-power state, wired control network, addressing, clock sync, and remote permissions defined?
• Data and logs: Can joint state, commands, images, gripper state, and safety events be joined by experiment ID and timestamps? Are retention and backup specified?
• KPIs: Beyond success, are intervention, failure type, cycle time, object damage, stop performance, and recovery recorded?
• Safety: Does every hazard row have a control, verification test, residual risk, and independent owner? Does local stop authority dominate remote requests?
• Ownership: Are primary and backup owners named for mechanical, electrical, network, control, data, safety, and purchasing decisions?
• Change control: Does the team know which gates reopen for a new hand, object, speed, camera, driver, or firmware version?

First physical motion should follow ordered gates for the static model, fixture, payload, read-only communication, mock hardware, and supervised reduced motion ^{[3] [13] [15]}. The sequence does not promise zero risk. It is an operating principle for finding errors at lower energy and with better observability.

Relation to Prior Surveys

#S1 maps commercial hands and teleoperation devices in depth. This book does not repeat that catalog. It fixes the task and cell boundary first, then compares two-finger grippers, five-finger hands, cameras, and controls as complete configurations in Chapters 2 and 3. #S3 motivates agentic tools and physical retry costs; here, the crucial adaptation is to keep an agent out of safety authority and hard real-time control.

#S4 and #S9 provide broader simulation and sim-to-real maps. Chapters 6 and 9 adapt them to fixed-base tabletop manipulation. The task envelope and logging contract from this chapter decide which simulator parameters and reality errors matter. “Make simulation realistic” becomes a set of measurements such as cup-pose error, contact condition, camera latency, gripper closing time, and payload response.

What to Learn Next

You can now replace “Which robot is best?” with a sharper question: “Which is the simplest arm–hand combination that satisfies our task envelope, risk boundary, ambition tier, and acceptance gates?” Chapter 2 compares UR5e- and FR3-class research platforms with lower-cost learning platforms, parallel grippers, and five-finger hands through four purpose-built cells. Keep this chapter’s artifacts beside the comparison. Mark each candidate supported, conditionally supported, unsupported, or unknown, and buy for integration and verification rather than feature count.

Annotated research trail

These sources deepen hardware selection and measurement boundaries. 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. Cutkosky, M. R. (1989). The Grasping Hand. Springer.
2. ISO (1998). ISO 9283:1998 Manipulating industrial robots — Performance criteria and related test methods.
3. ISO (2010). ISO 12100:2010 Safety of machinery — General principles for design — Risk assessment and risk reduction.
4. ISO (2011a). ISO 10218-1:2011 Robots and robotic devices — Safety requirements for industrial robots — Part 1: Robots.
5. ISO (2011b). ISO 10218-2:2011 Robots and robotic devices — Safety requirements for industrial robots — Part 2: Robot systems and integration.
6. Haddadin, S., Albu-Schäffer, A., & Hirzinger, G. (2012). Human-Robot Collision Evaluation and Analysis. Springer Tracts in Advanced Robotics.
7. ISO (2016). ISO/TS 15066:2016 Robots and robotic devices — Collaborative robots.
8. Lasota, P. A., Fong, T., & Shah, J. A. (2017). A Survey of Methods for Safe Human-Robot Interaction. Foundations and Trends in Robotics.
9. Billard, A., & Kragic, D. (2019). Trends and Challenges in Robot Manipulation. Science.
10. ISO (2025a). ISO 10218-1:2025 Robotics — Safety requirements — Part 1: Industrial robots.
11. ISO (2025b). ISO 10218-2:2025 Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells.
12. ISO (2025c). ISO/TS 15066:2016 current status and revision record.
13. Universal Robots (2026a). UR5e User Manual SW5.21.
14. Universal Robots (2026b). UR5e Technical Specifications SW10.6.
15. Franka Robotics (2025a). Franka Research 3 Product Manual R02210 1.5.
16. Franka Robotics (2025b). Franka Research 3 Datasheet v2.3.
17. Franka Robotics (2026). Franka Research 3 Brochure, February 2026.
18. Hugging Face (2025). SO-101 Hardware and Calibration Guide. LeRobot documentation.
19. OpenArm (2026a). OpenArm v2.0 Robot Description and ROS Namespacing.
20. OpenArm (2026b). OpenArm v2.0 Procurement and Support Routes.