Section 26.1: What a skill is; low- vs. high-level actions

A Careful Control Loop

Why Hierarchy Matters

For What a skill is; low- vs. high-level actions, hierarchy separates timing, contact, recovery, and sequencing so a high-level planner can select skills without pretending every low-level policy is deterministic.

The distinction is temporal scale. A low-level action might be a velocity command for 20 milliseconds. A high-level skill might be a 6-second door-opening routine that watches force, pose, contact, and success. Both are actions from the planner's perspective, but only the skill hides a controlled sequence behind a stable interface.

Formal Contract

For What a skill is; low- vs. high-level actions, use the option tuple as an audit checklist: initiation states, internal policy, termination probability, and verifier must match the robot task.

$$\omega=(I_\omega,\pi_\omega,\beta_\omega),\quad a_t\sim\pi_\omega(a\mid s_t),\quad \mathrm{stop}\sim\beta_\omega(s_t).$$

For What a skill is; low- vs. high-level actions, map the option fields onto behavior trees, task graphs, finite-state machines, or task-and-motion planning nodes so start, act, stop, and verify remain inspectable.

Worked Implementation

Code Fragment 1 for What a skill is; low- vs. high-level actions should expose initiation, progress, termination, verification, and failure reporting before connecting the skill to ROS 2, BehaviorTree.CPP, Drake, or a learned policy.

# Define a reusable robot skill with explicit start, stop, and verify logic.
# The example separates planner-facing status from low-level control details.
from dataclasses import dataclass

@dataclass
class SkillResult:
    name: str
    status: str
    reason: str

def grasp_ready(state):
    return state["object_visible"] and state["base_distance_m"] < 0.8

def run_grasp_skill(state):
    if not grasp_ready(state):
        return SkillResult("grasp", "blocked", "precondition failed")
    if state["force_n"] >= 8.0 and state["lift_cm"] >= 3.0:
        return SkillResult("grasp", "success", "object verified in gripper")
    return SkillResult("grasp", "retry", "insufficient lift evidence")

print(run_grasp_skill({"object_visible": True, "base_distance_m": 0.5, "force_n": 9.2, "lift_cm": 4.0}))

This expected output means the skill returned a planner-facing verdict, not torque-level behavior. The key field is status='success', which tells the hierarchy that the grasp can hand control back upward because the postcondition was verified in sensor space.

Practical Recipe

1. Name each skill with a verb and object: navigate_to_station, grasp_handle, dock_drone, or change_lane.
2. Write preconditions, postconditions, safety guards, timeout, and recovery behavior before training a policy.
3. Represent sequencing as a finite-state graph, behavior tree, or task-and-motion plan so failures have explicit routes.
4. Use language as a planner only after commands are grounded into a typed skill library with affordance checks.
5. Evaluate composition, not only individual success. Many failures occur when two correct skills meet at a bad boundary.