Task execution

Task execution is the chapter students skip because it looks like software engineering. It is software engineering, and it is why robots that “can plan” still stand in doorways. A skill is a closed-loop controller with a success test: drive to a pose, open a gripper, detect a mug. A task is a structured story over skills. If you only write skills, you have a toolbox. If you only write a task script, you have a play that cannot recover.

Finite-state machines are the honest first tool. States are modes (“approach,” “grasp,” “retreat”). Edges are events (“contact force exceeded,” “timeout,” “vision lost”). Draw the timeouts. Draw the abort. A machine without an abort is a trap. I have watched more labs die on a missing timeout than on a bad Jacobian.

Behavior trees are FSMs that you can compose without redrawing the whole graph every time you add a recovery. Planners (task or motion) generate pieces of the story when the world is too large to hard-code. None of these hosts is morally superior. A vacuum can live in a small FSM. A kitchen robot will need hierarchy and a planner that can be told “that mug moved.”

Reactive versus deliberative is a latency and commitment argument. A bump reflex should not wait for a new global plan. A global plan should not be rewritten every lidar tick or the robot will jitter. The grown answer is layers: fast reflexes with authority to interrupt, slower planners that reset the FSM when the map says the door is closed.

Exercise: pick a fetch task and write the FSM on one page, including what you do if the mug is missing. Then implement only the “approach” skill well. Depth beats width. Read the book chapter for the patterns and examples this note is not allowed to reprint.