Detailed content
🏗️ Control hierarchy: symbolic × reactive
Classical robotics always separated planning (high-level, abstract, slow) of control (low-level, continuous, fast). Modern hybrid architectures bring this hierarchy back with learned components: a reasoning model on top, a reactive policy at the bottom. The reason is fundamental—the time scales are incompatible.
💡 The time-scale conflict
Reasoning about "how to put away the dishes" takes seconds of inference in a large VLM. Controlling a finger requires decisions every ~5 ms. Forcing a single network to do both results in something too slow for the control loop or too dumb for the task. The hierarchy decouples the frequencies.
Hierarchy
Planning vs. control.
Symbolic planning
Abstract, subtle.
Reactive policy
Continuous, fast.
Decoupling
Separate frequencies.
🐢🐇 System 1 / System 2 (Helix, GR00T)
The top-level instance in the hierarchy is the dual-system, borrowing Kahneman's metaphor. The System 2 (slow VLM) reasons and emits a latent vector of intent; the System 1 (fast policy) is conditioned on this latent to generate high-frequency actions. Helix and GR00T converged on this design—and it runs asynchronous: S1 doesn’t wait for S2 at every step.
# Inferência assíncrona dual-system
latent = None
loop_S2 (~8 Hz): latent = VLM(image, instruction) # raciocínio
loop_S1 (~200 Hz): action = policy(obs, latent) # controle
robot.step(action)
# S1 reusa o último latent enquanto S2 ainda pensa📊 Why latent, not text?
- Broadband — a continuous vector carries more nuance than a discrete skill string.
- Differentiable — allows you to train S1 and S2 in a coupled manner when desired.
- Fast — no language parsing in the control loop.
Dual-system
S2 thinks, S1 acts.
Latent conditioning
S1 conditioned on z.
Async inference
Independent loops.
Kahneman
Slow thinking × fast action.
📋 LLM as planner: SayCan, Code-as-Policies
Before continuous latents, the first wave of hybrids used the LLM as symbolic planner. SayCan (Google, 2022) combined the LLM's probability (“say”) with each skill's feasibility (“can”) to choose the next step. Code-as-Policies went further: the LLM writes code that calls perception and control APIs, enabling loops, conditionals, and composition.
# Code-as-Policies — LLM gera o plano como programa
# instrução: "empilhe os blocos por cor"
for color in detect_colors():
blocks = get_objects(color=color)
base = blocks[0]
for b in blocks[1:]:
pick(b); place_on(base); base = b
# loops + lógica que uma lista plana de skills não expressa💡 SayCan in one sentence
score(skill) = P_LLM(skill is useful for the task) × P_affordance(robot can execute now). "Say" alone dreams up impossible plans; "can" anchors them in physical reality.
SayCan
Say × can.
Code-as-Policies
LLM writes code.
Task decomposition
Break it into subtasks.
Prompting
No need to train a new policy.
🎯 Affordances and grounding
A plan only matters if it can be executed. Affordance is an estimate of how feasible an action is in the current state; grounding is the link between the planner's language and the robot's real skills. Without it, the LLM produces eloquent but impossible plans—asking it to "pick up the cup" when no cup is in sight.
✓ Do
- ✓Use one value function or detector as a feasibility filter.
- ✓Perceptual grounding: offer only skills whose objects exist in the scene.
- ✓Restrict the skills vocabulary to what the executor can handle.
✗ Avoid
- ✗Relying on the pure LLM to judge physical feasibility.
- ✗Open-ended plans without grounding in real objects/state.
- ✗Skills in the plan that the executor was never trained to perform.
Affordance
Action feasibility.
Grounding
Language → actual skill.
Value function
Feasibility filter.
Feasibility
The “can” in SayCan.
🔁 Memory and feedback: replan after failure
Blind execution breaks at the first unexpected event. Robust systems close the loop: detect failure, update the memory e replan. Techniques such as inner monologue feed textual observations (“the cup slipped”) back to the planner, which adjusts the plan. Robustness comes from recovery, not perfect execution.
Detect
Success/failure based on perception (object in hand? surface clean?) or a learned success detector.
Feed back (inner monologue)
Convert the result into feedback that the planner consumes in the next step.
Replan
Rewrite the skills queue based on the new state instead of following the dead original plan.
⚡ Practical tip
Don't replan every frame (expensive and unstable). Replan in events: end of skill, detected failure, or major scene change. The rest of the time, let the reactive policy handle small disturbances on its own.
Closed-loop
Closed loop with feedback.
Inner monologue
Text feedback to the planner.
Replanning
Rewrite the plan.
Memory
Accumulated task state.
⏳ Long horizons: skill composition
The current bottleneck in general-purpose robotics is long horizon: tasks lasting minutes that chain together dozens of skills. Even with a 95% success rate per skill, 20 skills in a row yield ~36% overall success — the compounding error we saw in Track 1 reappears at the task level. The hybrid approach tackles this with replanning and recovery, but end-to-end robustness remains an open frontier.
📊 The math of compounding error in tasks
- 0.9520 ≈ 36% — task success with 20 skills at 95% each, with no recovery.
- 0.9920 ≈ 82% — why every success-rate point per skill matters so much.
- Recovery changes the equation: replanning turns failure into a retry, not the end of the task.
💡 Why the hybrid approach is the right bet here
A monolithic VLA tends to accumulate drift over a long horizon. The hierarchy reinjects structure: the planner maintains the global objective while the executor handles the local one, and the closed loop corrects deviations before they compound.
Long-horizon
Tasks that take minutes.
Skill composition
Chain skills.
Compound error
Failures compound.
Drift
Accumulated drift.
✅ Module summary
Next module
3.4 — Applications: Manufacturing, Logistics, Healthcare, Agriculture. Where these architectures create market value.