Chapter 2: The Default for Structured Tasks — IK, Motion Planning, and Trajectory Generation

Overview

When a tabletop assembly cell has known objects, a modeled fixture, and observable obstacles, the first question is not “Which policy should we train?” The first job is to establish separately whether the target pose has a realizable joint configuration, whether that configuration is connected to the start without collision, whether the path can be assigned executable timing, and whether the downstream controller can track the resulting trajectory. These questions look similar in a demo, but they produce different artifacts and fail for different reasons.

This chapter connects forward kinematics (FK), inverse kinematics (IK), collision-aware planning, Cartesian paths, time parameterization, trajectory optimization, and task and motion planning (TAMP) as an execution contract. The goal is not to memorize a catalog of algorithms. It is to select the smallest sufficient method for a structured job and to know what must be validated before handing authority to the next stage.

Our running experiment asks: When a 6/7-DoF arm with a parallel gripper must pick a known part, carry it around modeled obstacles, and repeatedly reach a pre-insertion pose, which responsibilities belong to IK, the planner, the trajectory generator, and the controller—and when does measured variation justify learning? The contact phase after pre-insertion remains the subject of Chapter 3.

After reading this chapter... - You will distinguish a pose, configuration, geometric path, timed trajectory, and controller reference. - You will diagnose redundancy and singularity as questions of choice and conditioning, not as one IK success bit. - You will choose among sampling-based planning, Cartesian paths, trajectory optimization, and TAMP using task structure. - You will operate path validation and timing/tracking validation as separate gates with separate logs. - You will add learning only after measuring the maintenance cost of the classical baseline.

2.1 One motion request contains five contracts

In the execution hierarchy from Chapter 1, motion generation translates the intent of a skill into a reference for a low-level controller. A request such as “move the tool to this pose” can make one planner appear to solve the whole problem. In practice, five contracts are connected in series.

1. Kinematic contract: Generate configurations that satisfy the target pose from the current state and model.
2. Geometric contract: Establish that configurations and connecting edges obey joint and collision constraints.
3. Path-quality contract: Select a path according to clearance, length, Cartesian deviation, joint excursion, or another explicit objective.
4. Timing contract: Attach timestamps that satisfy velocity, acceleration, and, where required, jerk limits.
5. Execution contract: Send the trajectory through an accepted interface and monitor deadlines, tracking error, and protective stops.

This decomposition localizes failure. Instead of one planning failed message, the system can distinguish IK_NO_SOLUTION, START_STATE_IN_COLLISION, PATH_EDGE_INVALID, TIME_PARAMETERIZATION_FAILED, CONTROLLER_REJECTED, and TRACKING_TOLERANCE_EXCEEDED. Every stage should preserve its input snapshot, versioned parameters, output, and validation result.

Neither rate nor deadline follows from an algorithm's name. A planning request may be aperiodic, trajectory points may be interpolated at a controller-owned rate, and the motor servo may live in a vendor controller or a separate real-time process. The required artifact is therefore not a single “ROS 2 frequency.” It is a matrix listing each loop's owner, nominal rate, maximum input age, clock, deadline, and timeout action.

2.2 IK generates candidate goal configurations

2.2.1 Read FK and IK through the same mapping

Let the joint vector be q\in\mathbb{R}^n and the tool pose be x. Forward kinematics is the model-defined mapping

$$

x=f(q).

$$

IK seeks a q for which f(q)=x^*, or for which the pose residual is within a stated tolerance. A six-dimensional pose combines position and orientation errors, so units and weights must be explicit. Adding an error in meters directly to an error in radians embeds an unstated design choice. Record both the target frame and separate tolerances in the task specification.

The differential relationship is written with the Jacobian J(q):

$$

\dot{x}=J(q)\dot{q}.

$$

The resolved-rate lineage organizes Cartesian-to-joint velocity mapping around this relation ^[1]. The equation itself contains no collision object, controller timing, or force limit. In this chapter it is a local model for a kinematic proposal, not a complete servo authorization.

2.2.2 Redundancy provides choices; singularity degrades conditioning

When n exceeds the task dimension, more than one joint configuration can satisfy the same tool pose. On a 7-DoF arm, an elbow-up or elbow-down choice should not be left to an invisible accident of the seed. One practical representation is

$$

\dot q=J^{\#}\dot x+(I-J^{\#}J)z.

$$

The first term addresses task motion. The second can express a secondary direction z, such as moving toward the center of joint ranges, preserving clearance, or preferring a posture while approximately retaining the task. A manipulability measure can be used as a local diagnostic when comparing configurations ^[2]. It should not be interpreted as one scalar replacement for collision, torque margin, or camera visibility.

Near a singularity, a small Cartesian motion can demand a large joint motion. Damped least squares is especially readable as an optimization:

$$

\Delta q=\arg\min_u\left\|Ju-\Delta x\right\|_W^2+\lambda^2\left\|u\right\|^2.

$$

A larger \lambda suppresses the joint step while accepting more Cartesian residual. The purpose is not to make singularities disappear; it is to control the trade-off as conditioning worsens ^{[3] [4]}. A useful validation trace records a minimum-singular-value or condition proxy, damping, the commanded joint step, and the resulting pose residual together.

Under this book's validation contract, a local IK output is only a goal-configuration candidate. We do not approve collision freedom, dynamic timing, or controller trackability from the IK success code. Those properties receive separate gates later in the chain. This is a staged-approval rule, not a universal performance ranking of IK solvers; such a ranking would require a separate matched experiment.

2.2.3 Worked decision: two IK branches at pre-insertion

Suppose the grasped part must reach a pre-insertion pose 120 mm above a fixture. Seed A yields a configuration close to the current posture, but the elbow occludes a scene camera. Seed B requires more joint travel but preserves visibility and fixture clearance. The system should not accept A simply because the solver returned it first.

For each candidate, log the FK position and orientation residual, joint-limit margin, singularity proxy, self-collision, environment collision, minimum clearance, and joint displacement. Both candidates may satisfy the pose while A violates a task-level visibility constraint. Conversely, B may approach a joint limit and force an impractically slow timing solution, sending the decision back to A or a third branch. Branch selection should be an explicit downstream-aware decision rather than hidden solver luck.

The minimum IK artifact includes:

• start_state_id, robot-model hash, tool frame, and target-frame timestamp;
• separate position and orientation tolerances with units;
• solver/plugin, seed policy, timeout, and maximum candidate count;
• per-candidate FK residual, joint margin, condition proxy, and collision status;
• the selected candidate and a reason code for every rejected candidate;
• a regression fixture that replays the same snapshot and seed.

2.3 Collision-aware planning asks about connectivity in configuration space

2.3.1 A workspace line does not establish joint-space safety

In configuration space \mathcal{C}, one joint configuration is one point. Let \mathcal{C}_{obs} contain configurations that violate collision or joint constraints, and let \mathcal{C}_{free} be the feasible remainder. Geometric planning seeks

$$

q:[0,1]\rightarrow\mathcal{C}_{free},\qquad q(0)=q_{start},\quad q(1)=q_{goal}.

$$

Checking waypoints alone is insufficient as an implementation test. Edges between states must also be checked under interpolation. A coarse resolution can step over thin geometry; a fine one increases collision-checking cost. The planning-scene contract should state whether continuous checking is available, how discrete resolution is selected, and how attached objects and swept volume are represented.

PRM offers a reusable-roadmap perspective, RRT a tree that rapidly explores new regions, RRT-Connect a bidirectional single-query strategy, and RRT* an optimizing-planning lineage ^{[5] [6] [7] [9]}. OMPL provides a common library interface to multiple sampling-based planners ^[12]. These sources are a map of method families for different query patterns and objectives, not a leaderboard that identifies one universally fastest planner.

We do not translate probabilistic completeness or asymptotic optimality into a promise that one call in this cell will meet a finite deadline or return a desired path quality. This chapter asserts no universal finite-time number. Measure timeout, first-solution time, incumbent cost, and failed seeds on the cell's actual scene distribution.

2.3.2 A Cartesian path is a distinct contract

A joint-space path is natural for transport. A Cartesian constraint becomes important when the camera must keep looking at a part or the tool must preserve orientation during approach. Yet sampling a straight tool path and solving IK at every waypoint does not automatically yield a continuous joint path. Branch flips, joint jumps, singularity, collision, and orientation wrapping remain possible.

A Cartesian segment should therefore version its frame, position/orientation constraint, maximum Cartesian step, joint-jump threshold, required completion fraction, collision resolution, and singularity threshold. Do not promote a partial result automatically. If only part of the requested segment is valid, first decide whether its last pose is an authorized hold point. This is also why the free-space approach and insertion should not be bundled into one Cartesian request. Insertion introduces contact state and belongs to the Chapter 3 controller contract.

2.3.3 Diagnose planning failure in a fixed order

Before changing the planner, use the following sequence:

1. Input freshness: Check joint state, TF, planning scene, attached-object timestamps, and clock domains.
2. Start validity: Confirm that the start does not violate limits or collision and that padding is not applied twice.
3. Goal validity: Replay the IK candidate with the same robot model and tool transform.
4. Constraint consistency: Look for contradictory or unnecessarily narrow orientation and path constraints.
5. Edge checking: Inspect interpolation resolution and continuous-checking settings.
6. Scene geometry: Check mesh scale, decomposition, payload attachment, and fixture-pose error.
7. Planner sensitivity: Only then vary seed, range, timeout, and planner family, comparing distributions rather than one run.

The purpose of the order is to avoid blaming stochastic planning for a model defect. Preserving the failed request's scene snapshot and random seed turns it into a regression test. A second run that happens to succeed does not invalidate the first failure.

2.4 A path becomes a trajectory only after timing

2.4.1 Separate the geometric path from the timed trajectory

Let a geometric path be q(s) for s\in[0,1]. A time scaling s(t) produces

$$

q(t)=q(s(t)),\qquad \dot q=q'(s)\dot s,

$$

$$

\ddot q=q''(s)\dot s^2+q'(s)\ddot s.

$$

The same geometric path can produce different velocity and acceleration profiles under different s(t). Collision freedom therefore says nothing by itself about satisfying velocity and acceleration limits. Conservative operating limits for a payload, start/end velocities, and blending policy are timing inputs. Classical specified-path timing and reachability-based path parameterization sit on this separation ^{[21] [16]}. We do not transfer performance numbers from those sources; we use the engineering boundary between a path artifact and a timing artifact.

The inspected official MoveIt 2 trajectory-processing documentation separates a geometric planner's path from a subsequent velocity/acceleration-aware time-parameterization stage ^[20]. This evidence supports a current documented processing boundary, not every historical derivation or tracking performance on a particular robot. Preserve path_valid.json separately from timed_trajectory_validation.json.

2.4.2 Jerk and controller acceptance do not vanish at the last step

Satisfying velocity and acceleration limits can still leave abrupt acceleration changes. Jerk-constrained online trajectory generation is one family that makes this variable explicit ^[18]. Regardless of the smoother, recheck collision and path constraints after processing. Smoothing may alter the motion between waypoints or deviate from a desired Cartesian line.

A valid timestamp sequence is also not the same as acceptance by a vendor controller. A controller can impose rules for the first point, start-state tolerance, goal tolerance, joint ordering, interpolation, buffer length, and preemption. A dry-run validator should check:

• strictly increasing timestamps without duplicates;
• position, velocity, acceleration, and, where available, jerk against operating limits;
• agreement between the first point and measured start state within tolerance;
• joint names, units, ordering, and wrap conventions against the controller contract;
• trajectory freshness after network and queue delay;
• deterministic hold or stop behavior on cancel, preemption, and timeout.

The output of a trajectory generator is controller input, not motor torque. Reconnect controller rate, interpolation, and motor-servo ownership to the owner/rate/deadline matrix from Chapter 1.

2.5 Optimization and TAMP extend the classical stack

2.5.1 Read trajectory optimization as cost design

After a sampling-based planner finds a feasible seed, the team may want more clearance or smoother joint motion. For a discretized trajectory Q=(q_0,\ldots,q_N), a schematic objective is

$$

\min_Q\;w_sC_{smooth}(Q)+w_cC_{collision}(Q)+w_tC_{task}(Q),

$$

subject to start, goal, joint, and path constraints. CHOMP, STOMP, and TrajOpt form representative lineages with different optimization and collision treatments ^{[8] [10] [13]}. The useful implementation question is not which name wins universally. It is who owns the seed, cost scales, constraint tolerances, termination rule, and post-validation.

The current claim packet does not authorize a general comparative statement about initialization, model fidelity, and local minima down to inspected primary-source locations. We therefore treat an optimizer output as a candidate requiring independent validation, not as an automatically approved path. Record variation across multiple seeds and small scene perturbations, then recheck collision, constraints, and timing outside the optimizer.

Terms in an objective can carry different units. If the team adjusts one number between smoothness and clearance without preserving meaning, planning becomes a tuning ritual rather than a reproducible process. A weight sweep should report feasibility, minimum clearance, path length, integrated joint motion, and planning time together. Improvement in one metric must not silently consume another safety margin.

2.5.2 TAMP connects “what to do” with “how to move”

Assembly includes discrete decisions as well as continuous paths: which part to pick first, which grasp to use, whether to place something temporarily, or whether access requires another action. TAMP methods connect symbolic or factored task choices with continuous geometric feasibility ^{[11] [15] [17]}.

A beginner runbook does not need to solve one monolithic problem. An FSM or behavior tree can choose pick, transport, and pre_insert, while each phase exposes a precondition, effect, and motion request. A failure returns NO_GRASP_IK, NO_TRANSPORT_PATH, or PRE_INSERT_CONSTRAINT_FAILED, allowing a task-level alternative. This is already better than repeating an identical planner call without changing state.

Classical formulations can also represent contact and mode structure ^[14]. Their quasi-static, mode, friction, and optimization assumptions remain specific to each formulation.

Accordingly, the presence of contact alone is not sufficient evidence that end-to-end RL is required. First test whether the relevant task and contact modes can be modeled, but do not expand this caution into a claim that classical methods dominate every contact problem. Robust execution under model error still requires the impedance, admittance, or force-control gates of Chapter 3.

2.6 Carry the tabletop assembly through a complete classical baseline

We now design one episode of the running task. The robot receives a part pose from a scene camera, grasps with a parallel gripper, transports around a fixture, and stops at a pre-insertion pose before contact. The goal is not to announce the highest success rate. It is to create an auditable reference against which later BC, ACT, diffusion, or RL additions can identify what they improved.

Phase A — Snapshot and goal contract

Do not consume a perception result without a scene_snapshot_id. It should bind object pose and a quality or uncertainty signal, TF timestamp, robot-state timestamp, calibration version, and collision-geometry version. If snapshot age exceeds the configured bound, planning does not start. Define grasp and pre-insertion poses in object or fixture coordinates and record when they were transformed into the planning frame.

Phase B — Candidates and path

Separate pre-grasp approach, grasp, retreat, transport, and pre-insertion. Record the start, goal, and constraints of each phase. Generate multiple IK candidates and select using downstream diagnostics. During transport, insert the attached part geometry into the scene. After planning succeeds, run a planner-independent collision validator over both states and edges.

Phase C — Timing and shadow execution

Freeze the geometric-path hash, then run time parameterization. In simulation or a controller mock, verify timestamps, joint limits, start tolerance, cancel, and timeout behavior. Do not send full-speed hardware motion as the first execution. A bounded trial starts with reduced speed and acceleration scaling, a clear workspace, a ready operator, an E-stop check, and authorization for one episode.

Phase D — Pre-contact handoff

At the pre-insertion pose, do not rely only on the trajectory controller's completion response. Check measured pose residual, joint tracking error, and the age of the fixture-relative transform. Then publish CONTACT_READY only if the contact controller can take authority. The transition must include a successful controller-mode switch, force-sensor bias check, low approach speed, force limit, and retreat path. Chapter 3 develops the contact law itself.

Worked decision — change the planner or introduce learning?

Construct a regression suite from representative scene snapshots. The team should set promotion gates in advance rather than copy a universal threshold. If failure analysis points mostly to stale TF and missing attached-object geometry, the problem is not learning. Repair the scene pipeline. If seeds produce unstable paths through a narrow passage, compare planner family, timeout, constraint representation, and even fixture layout first.

The decision changes when object geometry and clutter vary so often that collision primitives and rules require weekly edits, or when grasp and approach branches continue to grow despite acceptable perception. Measured model-maintenance cost can then justify a learned candidate generator. Even in that case, the policy does not acquire motor-loop authority. It proposes a grasp or short-horizon motion, while the IK, collision, timing, and safety gates from this chapter approve or reject it. Chapter 4 begins the demonstration-data contract needed for that policy.

2.7 Servo, failure checks, and the evidence boundary

An interface such as MoveIt Servo can process joint jogs, Cartesian twists, or pose commands with low latency. It should not be conflated with a preplanned trajectory. Streaming commands require continuous monitoring of command age, input rate, singularity proximity, collision proximity, smoothing, and stopping behavior.

According to the inspected official MoveIt Servo tutorial, collision and singularity checks can scale or halt commands, but the documentation does not present those mechanisms as certified safety functions ^[19]. Filtering and controller behavior are also plugin- and platform-specific. Servo checks therefore do not replace an independent safety supervisor, robot protective functions, workspace and force limits, or the E-stop.

Failure symptoms and diagnosis order

Connect evidence tiers to execution decisions

Peer-reviewed primary papers provide the method definitions and historical lineages used here. Several historical records in this chapter's evidence packet, however, have verified canonical identity and method scope without an approved exact location for every equation-level or result claim. We therefore include no benchmark numbers and make no universal winner claims. Official MoveIt documentation supports a cutoff-dated interface boundary and caveat, but it does not establish acceptance by a particular vendor controller or safety for a particular cell.

No company demo or analyst/news claim serves as load-bearing evidence in this chapter. The final evidence for a cell decision is its validation log under the actual robot model, scene suite, controller, payload, and rates. The current evidence packet also identifies no matched study comparing the complete classical chain against all learned baselines on the S12 tabletop task. Chapter 9 therefore builds an internal matched comparison under one task contract rather than reproducing a literature leaderboard.

A bounded Codex prompt for implementation

Goal Implement separate IK-candidate, collision-aware path, time-parameterization, and controller-dry-run stages for the tabletop assembly phase transport_to_preinsert. Context A 6/7-DoF arm, parallel gripper, versioned URDF/SRDF, fixed fixture, scene-snapshot API, and trajectory-controller mock are available. Inputs are the start state, attached-object geometry, and pre-insertion pose. Constraints Do not change controller or safety configuration. Give every stage a timeout and reason code. Save random seeds and scene hashes. Store the geometric path separately from the timed trajectory. Servo or trajectory output must not bypass the independent safety supervisor. Done when The representative snapshot suite is deterministically replayable; every accepted path passes an independent collision check; timed trajectories pass joint/time validation and controller-mock acceptance; and failed cases remain as categorized regression fixtures. Safety Automate only simulation and mock execution. Generate no hardware command. Produce a separate real-test procedure with reduced scaling, a clear-workspace and operator/E-stop check, one-episode authorization, and tracking/timeout stop conditions.

Manufacturing Cell Checkpoint

By the end of this chapter, the following artifacts should exist in the repository and experiment records:

• Task schema: Per-phase frames, preconditions, goal tolerances, attached object, completion states, and failure states.
• Kinematics: Solver/plugin version, seed policy, candidate count, FK residual, joint margin, and singularity proxy.
• Scene/planning: Snapshot hash, geometry/calibration version, planner config, seed, timeout, and state/edge validation logs.
• Trajectory: Path hash, timing algorithm/config, timestamp monotonicity, velocity, acceleration, and jerk checks.
• Execution: Controller owner/rate/deadline, accept/reject response, command/measured trace, and tracking tolerance.
• Safety: Supervisor owner, collision/workspace/force gates, watchdog, retry budget, and hold/stop/retreat behavior.
• Metrics: Feasibility, first-solution latency distribution, minimum clearance, path cost, timing margin, controller rejection, tracking error, and intervention.
• Regression: Representative valid, no-IK, start-in-collision, narrow-passage, stale-scene, timing-failure, and controller-rejection fixtures.

This artifact set matters more than a single successful video. Success and failure episodes must replay through the same schema, and the team must be able to explain which gate withheld motion authority.

What to Learn Next

This chapter owns motion up to the edge of contact. Reaching the pre-insertion pose does not authorize the robot to push a position trajectory into the fixture. Calibration error and contact force can grow quickly after contact. Chapter 3 explains how a trajectory or policy output becomes a reference for impedance, admittance, force, or hybrid position-force control, and how to validate loop ownership, rates, latency, energy behavior, and force limits.

Learning was postponed, not rejected. We first created a baseline that makes comparison possible. A policy introduced after Chapter 4 should improve explicit quantities such as rule-maintenance cost, variation coverage, intervention, latency, or recovery—not merely replace one opaque planning_failed counter with another.

References

1. Whitney, D. E. (1969). Resolved Motion Rate Control of Manipulators and Human Prostheses. IEEE Transactions on Man-Machine Systems. DOI: 10.1109/TMMS.1969.299896.
2. Yoshikawa, T. (1985). Manipulability of Robotic Mechanisms. The International Journal of Robotics Research. DOI: 10.1177/027836498500400201.
3. Wampler, C. W. II. (1986). Manipulator Inverse Kinematic Solutions Based on Vector Formulations and Damped Least-Squares Methods. IEEE Transactions on Systems, Man, and Cybernetics. DOI: 10.1109/TSMC.1986.4308942.
4. Nakamura, Y., & Hanafusa, H. (1986). Inverse Kinematic Solutions With Singularity Robustness for Robot Manipulator Control. Journal of Dynamic Systems, Measurement, and Control. DOI: 10.1115/1.3143764.
5. Kavraki, L. E., Švestka, P., Latombe, J.-C., & Overmars, M. H. (1996). Probabilistic Roadmaps for Path Planning in High-Dimensional Configuration Spaces. IEEE Transactions on Robotics and Automation. DOI: 10.1109/70.508439.
6. LaValle, S. M. (1998). Rapidly-Exploring Random Trees: A New Tool for Path Planning. Iowa State University Technical Report.
7. Kuffner, J. J., & LaValle, S. M. (2000). RRT-Connect: An Efficient Approach to Single-Query Path Planning. IEEE ICRA. DOI: 10.1109/ROBOT.2000.844730.
8. Ratliff, N., Zucker, M., Bagnell, J. A., & Srinivasa, S. (2009). CHOMP: Gradient Optimization Techniques for Efficient Motion Planning. IEEE ICRA. DOI: 10.1109/ROBOT.2009.5152817.
9. Karaman, S., & Frazzoli, E. (2011). Sampling-Based Algorithms for Optimal Motion Planning. The International Journal of Robotics Research. DOI: 10.1177/0278364911406761.
10. Kalakrishnan, M., Chitta, S., Theodorou, E., Pastor, P., & Schaal, S. (2011). STOMP: Stochastic Trajectory Optimization for Motion Planning. IEEE ICRA. DOI: 10.1109/ICRA.2011.5980280.
11. Kaelbling, L. P., & Lozano-Pérez, T. (2011). Hierarchical Task and Motion Planning in the Now. IEEE ICRA. DOI: 10.1109/ICRA.2011.5980391.
12. Şucan, I. A., Moll, M., & Kavraki, L. E. (2012). The Open Motion Planning Library. IEEE Robotics & Automation Magazine. DOI: 10.1109/MRA.2012.2205651.
13. Schulman, J., Duan, Y., Ho, J., et al. (2014). Motion Planning with Sequential Convex Optimization and Convex Collision Checking. The International Journal of Robotics Research. DOI: 10.1177/0278364914528132.
14. Posa, M., Cantu, C., & Tedrake, R. (2014). A Direct Method for Trajectory Optimization of Rigid Bodies Through Contact. The International Journal of Robotics Research. DOI: 10.1177/0278364913506757.
15. Toussaint, M. (2015). Logic-Geometric Programming: An Optimization-Based Approach to Combined Task and Motion Planning. IJCAI.
16. Pham, H., & Pham, Q.-C. (2018). A New Approach to Time-Optimal Path Parameterization Based on Reachability Analysis. IEEE Transactions on Robotics. DOI: 10.1109/TRO.2018.2819195. arXiv:1707.07239.
17. Garrett, C. R., Lozano-Pérez, T., & Kaelbling, L. P. (2018). Sampling-Based Methods for Factored Task and Motion Planning. The International Journal of Robotics Research. DOI: 10.1177/0278364918761578.
18. Berscheid, L., & Kröger, T. (2021). Ruckig: Online Trajectory Generation for Jerk-Constrained Robot Motion. Robotics: Science and Systems. DOI: 10.15607/RSS.2021.XVII.015.
19. MoveIt (2025a). MoveIt Servo Realtime Teleoperation Tutorial. Official documentation, accessed 2026-07-15.
20. MoveIt (2025b). MoveIt 2 Trajectory Processing. Official documentation, accessed 2026-07-15.
21. Bobrow, J. E., Dubowsky, S., & Gibson, J. S. (1985). Time-Optimal Control of Robotic Manipulators Along Specified Paths. The International Journal of Robotics Research. DOI: 10.1177/027836498500400303.
22. Kang G. Shin & Neil D. McKay (1985). Minimum-Time Control of Robotic Manipulators with Geometric Path Constraints. Annotated primary reading. DOI: 10.1109/tac.1985.1104009. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Performance depends on geometry, initialization, objectives, and model fidelity; feasibility does not imply controller tracking.
23. Matthew T. Mason (1986). Mechanics and Planning of Manipulator Pushing Operations. Annotated primary reading. canonical URL. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Delay, sampling, saturation, filtering, environment stiffness, and hardware interfaces bound the reported behavior.
24. David J. Montana (1988). Kinematics of Contact and Grasp. Annotated primary reading. DOI: 10.1177/027836498800700302. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Smooth rigid surfaces and known contact state are strong assumptions for real fingertips and mesh contacts.
25. Stefano Chiaverini (1997). A Closed-Loop Inverse Kinematics Scheme for Constrained Redundant Manipulators. Annotated primary reading. DOI: 10.1109/70.585902. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Singularity, joint limits, collision, scaling, and discrete-time behavior still require explicit handling.
26. Antonio Bicchi & Vijay Kumar (2000). Robotic Grasping and Contact: A Review. Annotated primary reading. DOI: 10.1109/ROBOT.2000.844081. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Idealized contact models and pre-modern sensing limit direct quantitative use.
27. Rachid Boulic & Prashanth Baerlocher (2008). Real-Time Motion Retargeting to Highly Redundant Robots. Annotated primary reading. canonical URL. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Singularity, joint limits, collision, scaling, and discrete-time behavior still require explicit handling.
28. Patrick Beeson & Barrett Ames (2015). TRAC-IK: An Open-Source Library for Improved Solving of Generic Inverse Kinematics. Annotated primary reading. DOI: 10.1109/humanoids.2015.7363472. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: Singularity, joint limits, collision, scaling, and discrete-time behavior still require explicit handling.
29. Dorsa Sadigh et al. (2017). Active Preference-Based Learning of Reward Functions. Annotated primary reading. canonical URL. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
30. Jemin Hwangbo et al. (2019). Learning Agile and Dynamic Motor Skills for Legged Robots. Annotated primary reading. DOI: 10.1126/scirobotics.aau5872. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
31. Ankur Handa et al. (2023). DeXtreme: Transfer of Agile In-hand Manipulation from Simulation to Reality. Annotated primary reading. arXiv:2210.13702. — Role: primary reading for assumptions and boundaries in IK, planning, and timing. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
32. Yoshihiko Nakamura & Hideo Hanafusa (1986). Singularity-Robust Inverse Kinematics. Annotated primary reading. DOI: 10.1115/1.3143764. — Role: primary evidence for comparing how damped IK bounds velocity growth near singularities. Limitation: joint limits, collision, scaling, and discrete-time behavior still require separate handling.