Robot motion planning finds collision-free motions through spaces that punish guessing: a six-axis arm already lives in six dimensions, add redundancy, joint limits and end-effector constraints and the problem escapes what any human can visualise. The craft splits into sampling-based algorithms that search configuration space, trajectory optimization that turns raw paths into executable motions, inverse kinematics that closes the loop between joint space and task space, and the motion control layer that adds time. It is one of the oldest software disciplines in robotics and still one of the hardest to hire for, because the field's reference manual itself calls sampling-based motion planning a cornerstone of robotics research, benchmarked across 24 challenging planning problems .
The tooling story explains the talent story. OMPL is the default planning library inside MoveIt and has planned footsteps for Robonaut2 aboard the International Space Station . The people who can reason at that level sit inside research groups, framework teams and a thin industrial base, and their work is not visible on a generic CV.
Challenges in Robot Motion Planning Recruiting
Sampling-based algorithms own the high-dimensional configuration space
Classical search dies in the space where manipulator plans actually live. Sampling-based algorithms sidestep the geometry by building trees and roadmaps out of random configurations and checking edges for collisions, which is why they are the reference paradigm for arms, and why the comparative review treats them as the field's operating manual . The cost is subtlety. RRT and its descendants carry probabilistic completeness rather than guarantees, planner parameters that must be tuned per environment, and a persistent struggle in narrow passages, and the same review documents planner behaviour diverging across its 24 benchmark problems . The engineers who matter here are the ones who have watched a planner fail in a specific passage and know whether the fix belongs in the sampler, the steering function or the collision checker. That judgement only comes from having owned problems in high-dimensional spaces, which warehouse planners never expose their people to.
Inverse kinematics decides whether the planner thinks in joints or poses
Every task lives in Cartesian space; every actuator lives in joint space, and inverse kinematics is the bridge. OMPL deliberately contains no geometry of its own, so integrations pair it with kinematic libraries, Pinocchio for forward and inverse kinematics among them, alongside the SIMD-accelerated VAMP pipeline that cuts planning times by orders of magnitude . The choice of IK solver is where a lot of cell behaviour is quietly decided: singularities, joint limits, and which of several valid solutions gets returned all shape the plan downstream. MoveIt builds IK support straight into its planner interface, including end-effector constraints solved through inverse kinematics . A motion planning engineer who cannot interrogate the IK layer, or who treats it as a black box, will spend commissioning chasing plans that were wrong before they started.
Obstacle avoidance is a collision-checker choice before it is an algorithm choice
The planner proposes; the collision checker disposes. OMPL ships no collision detection by design, so it stays decoupled from any particular checker, and every real deployment is a marriage of planner and checker with its own trade between speed and accuracy . MoveIt's setup wizard discovers self-collisions at preprocessing time and feeds planners an environment built from geometric objects or RGB-D point clouds . Tesseract, the framework Southwest Research Institute built for industrial automation, makes the same coupling explicit in its pipelines, with collision margin enforcement folded into its TrajOpt stage . Obstacle avoidance on a CV therefore hides two different jobs: the person who tuned the planner, and the person who represented the world it plans in. The interview that cannot tell them apart hires one for the other.
Trajectory optimization polishes paths sampling leaves jagged
A feasible path is not a trajectory, and the gap between them is where trajectory optimization lives. Offline methods, CHOMP, TrajOpt and STOMP among them, cast motion as a constrained optimization over the path, trading computation time for smooth, collision-free output that adapts poorly to surprise . The industrial stacks chain the stages explicitly: Tesseract's default freespace pipeline runs OMPL's RRTConnect for global search, then TrajOpt for smoothing and collision margin enforcement, then time parameterization, and Descartes sits beside them for dense Cartesian toolpaths . The people who own this stage are optimizers, not samplers: they reason in costs, constraints and solver convergence, and they know when a warm start saves the cycle or dooms it. Most CVs list every library and say nothing about which stage of the pipeline the candidate actually owned.
Path generation fragments across MoveIt, Tesseract and vendor stacks
The planning community is balkanised by framework. MoveIt 2 is the ROS 2 default, planner-agnostic behind a plugin interface, with OMPL as the standard library and Pilz and CHOMP bundled as alternatives, wrapped in planning request adapters that pre- and post-process every request . Tesseract was written from the ground up for industrial quality and real-time performance, explicitly not a MoveIt fork, and splits planning across its own packages . Then there are the vendor stacks: robot OEMs ship proprietary planners locked to their controllers, and integrators tune them with tools that do not leave the showroom. Platform lock-in here is real. A five-year MoveIt engineer moving to a KUKA or FANUC offline programming environment loses most of that toolkit on day one, and the reverse hire loses the whole open-source pipeline. The brief must name the stack or the shortlist cannot.
Motion control adds the clock the planner never had
Plans are geometry; work is geometry plus time. Time parameterization assigns velocities and accelerations to a path so it respects joint limits and hits a line rate, and it is where motion control and planning collide . The palletizing survey puts the economics plainly: classical splines are efficient for repetitive, known layouts, sampling-based planners earn their place when the environment changes, and optimization-based planners, model predictive control foremost, are the choice when shaving a fraction of a second per pick compounds over thousands of cycles . MPC itself replans on a receding horizon with the current state as initial condition, which is why it owns dynamic scenes . An engineer who has shipped a time-parameterized, collision-checked trajectory at a real cell rate has crossed a line that demo-planners never reach.
Joint limit and cost questions settle motion control claims
Assessment here is a bench test in prose. Which dimensionality did the candidate's problems live in, and what does that say about the planners they chose ? Did they own the sampler, the collision checker or the optimizer, and how do they know ? What did the IK layer return when the target sat near a singularity, and how did the plan recover? Where is the benchmark: which planner failed on which problem, what was changed, and what did the cost function look like afterwards ?
The miss is expensive and visible. A planner that was never time-parameterized misses the line rate; a collision missed in simulation surfaces at commissioning, on real tooling, in front of the customer; and a redundant arm that shakes itself through a narrow passage was a cost-function problem from the start . Months of senior integration hours are the bill, and the planner's benchmark file is the evidence the interview should have asked for.
References
- Sampling-Based Motion Planning: A Comparative Review — Annual Review of Control, Robotics, and Autonomous Systems. (accessed 2026-09-28)
- OMPL: The Open Motion Planning Library — OMPL Project, Rice University (Kavraki Lab). (accessed 2026-09-28)
- MoveIt 2 Motion Planning Framework for ROS 2 — MoveIt (GitHub). (accessed 2026-09-28)
- Tesseract Motion Planning Framework Overview — ROS-Industrial Consortium (Southwest Research Institute). (accessed 2026-09-28)
- Trajectory Planning for Robotic Manipulators in Automated Palletizing — MDPI Robotics. (accessed 2026-09-28)
- A Survey of Optimization-based Task and Motion Planning: From Classical To Learning Approaches — arXiv. (accessed 2026-09-28)