Chapter 7: The First-Motion Runbook — From Simulation to the Real Robot

Overview

First motion is commissioning, not a celebration that software launched. The safest useful question is not “Can it move?” but “What is the smallest increase in physical authority justified by the evidence already collected?” A static model justifies visualization. Fake hardware justifies interface tests. Physics simulation justifies bounded trajectory rehearsal. Read-only hardware state justifies checking the real model and clocks. Only then does a supervised, low-energy joint increment become reasonable.

This chapter gives a signed gate sequence from description and frames through mock hardware, simulation, communication, tiny joint and Cartesian moves, gripper commissioning, and pick/place. It distinguishes three outcomes that logs often collapse: command accepted, motion observed, and task succeeded. Acceptance proves an interface path; observed motion proves a physical response; task success additionally requires geometry, perception, tool, object, and process criteria.

The runbook does not provide universal real-robot commands. UR, Franka, local safety assessment, tool, firmware, and controller mode differ. A qualified person retains physical stop and enable authority. Version status is current to 2026-07-14. Teleoperation and the first learned policy follow only after these deterministic gates in (Chapter 8).

After reading this chapter... - You can execute a go/no-go ladder from static description to a supervised pick/place. - You can distinguish interface acceptance, physical motion, controller completion, and task success. - You can test E-stop, protective-stop, cancellation, rollback, and recovery without normalizing faults away. - You can diagnose frames, timing, network, controller ownership, tracking, payload, and gripper failures separately. - You can ask Codex for inspection and fake-hardware tests without delegating hardware or safety authority.

1. Define authority, evidence, and rollback before power-on

Name five roles even in a small lab: run leader, physical observer at the approved stop, software operator, recorder, and safety/robot owner. One person may hold multiple roles, but the stop owner must not be distracted by terminal work. State who may enable, start, cancel, recover, and declare no-go. Keep the manufacturer's manual and local risk assessment at the cell ^{[17] [18]}.

Create an immutable run manifest: arm/tool serial and revision, firmware/system image, OS/kernel, ROS distribution, SDK/driver/description/controller commits, URDF/SRDF hashes, calibration ID, payload/CoM, network, limits, and scene hash. Save the previous known-good manifest and exact rollback procedure. “Reinstall latest” is not rollback.

First motion should progress from static validation to fake hardware, physics simulation, read-only state, reduced joint motion, Cartesian motion, and grasping. ^{[1] [7] [2] [5]} Every gate has prerequisites, saved evidence, stop conditions, and a signer. Simulation success supplies evidence; it never authorizes the next physical gate by itself.

Figure 7.1 — Conservative first-motion gates for this tutorial. They are not a universally mandated standard procedure; the local assessment and platform manual remain controlling. Original synthesis.

2. Gate G0 — description, frames, limits, and dry-run poses

With power off, match the purchased robot, controller, hand, adapter, fingers, wrist sensor, and cables to the manifest. Inspect fasteners, base mount, cable strain relief, work surface, dropped-object zone, guards, E-stop, and clearances. Confirm payload and CoM configuration includes the installed tool and representative object.

In visualization, inspect every joint axis and positive direction. Compare named home with the physical manual. Check joint and velocity limits, self-collision matrix, collision meshes, TCP, base/world, camera, and fixture frames. Sweep representative task poses without execution. A mesh that looks correct may have an oversized or missing collision body.

Dry-run the human procedure too: announce intent, clear the cell, select mode, enable, command, cancel, stop, recover, and log. The observer practices stop access without a moving robot. Define no-go phrases anyone can call. Determine what happens to the object if power is removed; a gripper may release or retain it.

G0 checklist

• Exact model and firmware match the description and driver tuple.
• Joint names, order, zero, axes, and signs have documented sources.
• TCP and payload/CoM reflect the installed tool, not a catalog default.
• Table, fixture, cameras, cables, fingers, and object appear in the collision review.
• Software speed/force/workspace limits are stricter than the approved initial envelope.
• E-stop/protective-stop/reset procedures are understood and physically reachable.
• A named safe pose and manual recovery route exist.

3. Gates G1–G2 — fake hardware and physics simulation

UR mock hardware and a scaled joint controller permit launch, model, controller, and MoveIt tests before drives are enabled. ^{[1] [3]} Mock hardware proves joint names, controller ownership, action goals, feedback, cancellation, parameters, and planning integration. It does not prove dynamics, latency, speed scaling, payload, protective stops, or physical sign.

Run negative tests deliberately: stale joint state, missing TF, invalid start state, joint beyond limit, collision, inactive controller, duplicate command owner, cancellation, tolerance violation, and process restart. The expected result is refusal or a defined safe state. A fake test that only proves the happy path is incomplete.

In physics simulation, add gravity, tool mass, object, table, and conservative contact. Replay the exact short trajectories intended for hardware. Check minimum clearance, velocity/acceleration, tracking, object drop, collision, and command timeout. Preserve simulator clock and wall time separately.

At real-time factor 0.5, 120 Hz simulated physics appears near 60 Hz to ROS tools, so simulation and wall time must be recorded separately. ^[15] A 120 Hz physics setting does not mean 120 updates per wall second when simulation runs slowly. Timeouts, topic rates, and bag analysis must state the clock domain.

4. Gate G3 — communication and read-only real state

Connect to hardware while motion remains disabled or the robot remains in the vendor-approved idle state. Confirm serial, firmware, control mode, safety state, remote/local mode, payload, and tool. No motion command should be routable during the initial network test. Search the graph for unexpected command publishers.

UR driver guidance recommends direct PC-to-controller Ethernet and a low-latency or PREEMPT_RT kernel for external control. ^[4] This recommendation does not replace measured latency or robot safety control. Record route, NIC, link, update diagnostics, jitter, loss, and competing traffic. Franka requires its own documented host/network/libfranka tuple rather than copied UR assumptions ^[6].

A successful connection should first prove coherent joint states, TF, controller state, timestamps, and safety state while motion remains disabled. ^{[11] [8] [1]} Compare displayed joints with the physical pose and manual. Verify one TF authority, correct tool frame, monotonic stamps, state freshness, loaded controller, claimed interfaces, and no fault. Keep a ten-minute idle log to expose drift and missed cycles.

Read-only no-go conditions

Duplicate IP or TF authority; unknown publisher; wrong joint sign/order; stale or jumping time; firmware/driver mismatch; unrecognized safety state; payload/TCP mismatch; controller claiming unexpected joints; unstable link; missing stop observer; unresolved fault. Do not “try a small move” to diagnose these.

5. Gate G4 — enabled low-energy mode and one tiny joint move

Before enabling, clear people and loose objects, verify tool fasteners and cables, select approved reduced mode, set software workspace/speed/acceleration/force constraints, and sign the preflight. The observer maintains stop access. The operator states the joint, expected direction, maximum delta, duration, stop conditions, and recovery pose aloud.

The first command should be a small known joint increment within a reduced workspace and speed envelope with physical stop access. ^{[2] [5] [18]} Exact supervision and enabling requirements depend on the local assessment. Choose a joint whose small motion has generous clearance, move one axis only, test positive and negative directions in separate attempts, and stop between them.

Execution must monitor tolerance, missed cycles, speed scaling, and protective-stop state rather than treat action acceptance as completion. ^{[9] [10] [3]} Log goal accepted, first physical movement, final observed state, action result, per-joint error, scaling, update timing, and faults. Acceptance proves only that an action server accepted a goal.

Use three outcome columns:

Repeat the tiny move enough times to establish consistent sign, timing, tracking, and return. Do not increase amplitude and speed in the same step. Promote one variable at a time.

Figure 7.2 — Boundaries among command, result, stop authority, and recovery evidence. Stop terminology and reset paths are platform-specific, and cancel is not a safety stop. Original synthesis.

6. Gate G5 — joint trajectory and Cartesian motion

Run a short multi-point joint trajectory inside the already visited region. Inspect timestamp monotonicity, maximum delta, tracking tolerance, speed scaling, cancellation, and return to a named safe pose. Then select a Cartesian goal whose IK solution remains close to the validated joint region and whose straight-line intuition is not mistaken for the planned path.

A Cartesian goal transformed with a stale or wrong frame can be geometrically valid and physically wrong. ^{[11] [12]} The planner may produce a collision-free path to the wrong place. Record target frame/stamp, transform chain and age, calibration ID, IK solution, scene hash, path clearance, and final measured TCP. Never repair a frame error by adding an unexplained task offset.

Start with free-space Cartesian motion and large margins. Compare expected and observed tool translation and orientation independently. Test cancel before approaching a table. Only then add a guarded approach with an approved speed/force envelope; a position plan alone does not regulate contact.

Cartesian troubleshooting

7. Gate G5b — commission the gripper separately

Disconnect arm motion conceptually: place the arm in a stable, spacious pose and test the end effector alone. Verify installed fingertips, fasteners, stroke, open/close direction, state reporting, command timeout, fault/reset, and behavior on power loss. Use a soft sacrificial object before the real specimen.

Gripper commissioning must check fingers, object, force, stroke, collision, and pinch zones separately from arm motion. ^{[13] [14] [18]} A configured force is not necessarily measured fingertip force. Long custom fingers alter leverage, collision, TCP, and allowed load. Mark pinch zones for operator hands and fixture edges.

Progress through empty open/close, partial stroke, soft object, representative object, hold, lift only after arm validation, and controlled release. Log commanded/observed width, current/force proxy, object, fingertip revision, grasp detection, fault, slip, damage, and release state. Establish where a dropped object lands.

8. Gate G6 — first pick and place

Choose one large, light, nonfragile object and two marked zones with generous clearance. Fix object pose initially rather than relying on perception. The sequence is home, pre-grasp, guarded approach, close, confirm grasp, vertical retreat, transfer, lower, release, retreat, home. Each transition has a timeout, observable condition, cancel behavior, and rollback.

Do not equate gripper closure with grasp success. Confirm object retention through width/current/tactile evidence and observation. Do not equate placement action success with object inside the target; use an independent task criterion. If the object is missing, never automatically repeat a closing motion at an unknown location.

9. Stops, recovery, logging, and go/no-go

An E-stop, protective stop, action cancel, controller abort, and application pause are different events. Document which removes drive energy, which holds position, which requires manual acknowledgment, and which preserves or discards the goal. Never reset reflexively. First preserve state, identify hazard, clear cause, inspect tool/object/cell, then follow the vendor and local recovery procedure.

After any unexpected event, create a new attempt ID. Do not overwrite logs by relaunching immediately. Save the preceding command, controller state, safety/fault state, joint/TF/time, speed scaling, update diagnostics, payload/tool config, operator action, physical observation, and recovery decision. A successful recovery is part of commissioning evidence.

A learned-policy rollout belongs after deterministic motion and recovery gates, not as the test of whether the description and driver are correct. ^{[16] [17] [1]} First verify fixed joint, Cartesian, gripper, stop, and recovery behaviors. Policy evaluation adds observation/action distribution and model failure; it must not obscure a sign, frame, or controller defect.

Figure 7.3 — Research taxonomy of safe human–robot interaction methods. Source: Lasota, Fong, and Shah, 2017, Figure 1.1.

10. Troubleshooting matrix

11. How to hold a gate review

A gate review should take less than fifteen minutes because the evidence was prepared during the attempt. The operator presents the manifest and intended increase in authority. The recorder shows required signals and the outcome timeline. The observer reports what physically happened, including sounds, cable motion, vibration, object movement, and stop accessibility that software did not capture. The responsible owner then chooses promote, repeat unchanged, roll back, or block. “Promote with an unexplained anomaly” is not an option.

Consider a joint action that was accepted, moved in the correct direction, and returned success, but took twice the expected wall time. The task did not fail, yet G4 cannot promote until speed scaling, safety mode, trajectory timestamps, and missed cycles explain the difference. Repeat unchanged after adding the missing signals. Do not shorten trajectory duration to make the observed time match.

Consider a Cartesian motion that reaches the same offset target three times. Repeatability is good but accuracy is wrong. Hold G5 and compare TCP, base, camera/fixture transforms, and calibration revision. A repeatable frame error is not planner success and must not be hidden in a task-specific offset.

For a protective stop during lift, roll back to the last empty-tool joint gate. Preserve the object, payload/CoM configuration, cable posture, scaling, joint error, and vendor fault. Inspect the tool and drop zone before reset. If the cause is not proven and the recovery path not rehearsed, block object motion even if the stop resets normally.

12. Bounded Codex prompts

Act as a read-only first-motion auditor. Inspect the manifest, robot description,
MoveIt/ros2_control configs, launch files, and official vendor manuals. Do not connect to
hardware or modify files. Build gates G0–G6 with prerequisite, observation, pass evidence,
stop condition, rollback, and human owner. Mark every unsupported value UNKNOWN.

Generate only fake-hardware/simulator tests for joint sign, start-state freshness, TF age,
collision, controller ownership, action accept/feedback/cancel/abort, stale command, and
restart behavior. No real IP, hardware plugin, enable instruction, limit changes, or
automatic retries. Done when failures are reproducible and artifacts are reviewable.

Analyze these offline logs and classify failure as description/frame, network/time,
controller ownership, trajectory/tolerance, vendor mode/scaling, payload/cable, gripper,
or safety/recovery. Return facts, missing evidence, one non-motion falsification test,
go/no-go recommendation, and required human approver. Do not reset or bypass anything.

Codex may prepare checklists and tests. It cannot sign the gate, observe physical clearance, reset a protective stop, or authorize motion ^[19].

13. Evidence tiers, disagreements, and limitations

Driver, controller, gripper, and simulator behavior uses official manuals and documentation. TF, control, and risk principles use primary papers and standards. Vendor instructions are authoritative for their product interface but are not independent evidence that the assembled application is safe.

Simulator success versus motion authorization is not a disagreement to average. Simulation can demonstrate repeatable software behavior and expose collisions. It cannot validate the real mount, payload, cable, controller safety state, or human procedure. Authorization belongs to the signed real-cell gate.

Action acceptance versus safe completion is similarly distinct. Acceptance says the server accepted a goal. Completion says controller criteria passed. Task success requires an independent physical KPI. Preserve all three rather than reporting a single green check.

Limitations: versions can change after 2026-07-14; manuals do not cover every custom tool; local law and institutional review vary; no generic speed or force value is safe across cells; and this tutorial cannot replace normative standards, vendor training, or qualified risk assessment.

Manufacturing Cell Checkpoint

For a UR5e+2F tray transfer, sign G0–G5 with an empty tool path before adding the object. Pin tool load, TCP, controller, scaling, and fixture scene. Use a fixed object pose for the first pick. Log attempt_id, manifest_hash, gate, goal_id, command_accept, motion_start, controller_result, task_result, joint/TF age, tracking/tolerance, scaling, safety/fault, gripper state, object outcome, observer, recovery.

What to Learn Next

The deterministic first-motion ladder is complete. (Chapter 8) adds a leader–follower teleoperation loop and the first learned policy. Those systems introduce operator tracking, retargeting, stale-input watchdogs, dataset quality, and policy uncertainty. They inherit every frame, controller, stop, and logging gate from this chapter.

Do not continue until one joint move, one Cartesian move, one gripper cycle, cancellation, protective recovery, and one simple pick/place are repeatable with distinct acceptance, motion, controller, and task outcomes.

Annotated research trail

These sources deepen the first reproducible learning pipeline. 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 (2026a). UR ROS 2 Driver Startup and Mock Hardware. Official documentation.
2. Universal Robots (2026b). UR5e User Manual. Official manual.
3. Universal Robots (2026c). UR ROS 2 Controllers and Speed Scaling. Official documentation.
4. Universal Robots (2026d). UR ROS 2 Driver Installation and Real-Time Guidance. Official documentation.
5. Franka Robotics (2025a). Franka Research 3 Product Manual. Official manual.
6. Franka Robotics (2026b). libfranka Changelog. Official release history.
7. ros-controls (2026a). gz_ros2_control. Official documentation.
8. ros-controls (2026b). ros2_control Architecture. Official documentation.
9. ros-controls (2026c). Joint Trajectory Controller. Official documentation.
10. ros-controls (2026d). Controller Manager Monitoring and Limits. Official documentation.
11. Foote, T. (2013). tf: The Transform Library. DOI: 10.1109/TePRA.2013.6556373.
12. MoveIt (2025). MoveIt 2 move_group Architecture. Official documentation.
13. Robotiq (2026). 2F-85 and 2F-140 Instruction Manual. Official manual.
14. Franka Robotics (2026). Franka Hand Product Manual. Official manual.
15. NVIDIA (2026). Isaac Sim ROS 2 FAQ. Official documentation.
16. Hugging Face (2026). LeRobot Policy Inference. Official documentation.
17. ISO (2010). ISO 12100:2010 Safety of Machinery — Risk Assessment. International Standard.
18. ISO (2025). ISO 10218-2:2025 Robot Applications and Cells. International Standard.
19. OpenAI (2026). Codex Best Practices. Official guidance.