10.3 — Figure Helix

Learning objectives

After this lesson, you should be able to:

• Describe Helix’s two systems and their stated rates.
• Compute steps per update and latent age from the rates.
• Explain what a fast loop can and cannot correct.
• List questions to ask of an announcement.

The one-sentence idea

A slow VLM sets intent; a fast policy carries it out.

Fast loops fix tracking, not understanding.

Helix: two systems at two speeds

Figure AI's Helix is described in the company's announcement as a vision-language-action model for generalist humanoid control. This lesson relies on that announcement as reproduced and summarised by secondary sources (there is no peer-reviewed paper that I could find, and I could not read the original page directly), so treat the details as the company's own claims. Its design has two parts. System 2 is an onboard, internet-pretrained vision-language model running at 7–9 Hz for scene understanding and language comprehension. System 1 is a fast reactive visuomotor policy that turns System 2's latent representations into continuous robot actions at 200 Hz.^[1]

The stated motivation is that VLM backbones are general but not fast, while robot visuomotor policies are fast but not general; splitting the work lets each system run at its own timescale. The two systems are trained end-to-end and exchange information through shared latent representations.^[1] The same two-speed idea appears in GR00T N1 (lesson 10.1), and the rates here are a good way to see what it means in numbers. Parameter counts and degrees-of-freedom figures circulate in secondary coverage but I could not verify them against the original, so they are not used.

What 7–9 Hz and 200 Hz imply

The ratio of the two rates tells you how many fast control steps share one slow update, and how old the slow system's latent can be when the fast system uses it:

fast_hz = 200
for slow_hz in (7, 8, 9):
    steps_per_update = fast_hz / slow_hz
    worst_age_ms = 1000 / slow_hz
    print(f"System 2 at {slow_hz} Hz: about {steps_per_update:4.1f} System 1 steps per update; the latent can be up to {worst_age_ms:5.1f} ms old")

System 2 at 7 Hz: about 28.6 System 1 steps per update; the latent can be up to 142.9 ms old
System 2 at 8 Hz: about 25.0 System 1 steps per update; the latent can be up to 125.0 ms old
System 2 at 9 Hz: about 22.2 System 1 steps per update; the latent can be up to 111.1 ms old

About 22 to 29 fast steps per slow update, and a latent that is up to 111–143 ms old. At 200 Hz each fast step is 5 ms, so System 1 reacts to the robot's state (and presumably to fresh sensor input) 20 to 30 times faster than System 2 re-thinks the scene.

Why the fast loop helps: reacting between slow updates

The benefit of a fast System 1 is that it can correct small errors (a slipping object, a drifting hand) without waiting for the slow system. A simulation of that effect: a hand sitting on its goal is bumped between two slow updates, and we look at how far from the goal it is 70 ms later, depending on how often the controller corrects:

import numpy as np

def error_after_push(correct_hz, push_at=0.43, look_at=0.50, dt=0.001):
    pos, goal = 1.0, 1.0                                          # the hand starts on the goal
    period = 1.0 / correct_hz
    next_correction = 0.0
    for k in range(int(look_at / dt) + 1):
        t = k * dt
        if abs(t - push_at) < dt / 2:
            pos -= 0.3                                            # a bump knocks the hand away
        if t >= next_correction:
            pos += 0.5 * (goal - pos)                             # one corrective step toward the goal
            next_correction += period
    return abs(goal - pos)

for hz in (8, 50, 200):
    print(f"controller correcting at {hz:>3} Hz -> distance from the goal 70 ms after a bump: {error_after_push(hz):.3f}")

controller correcting at   8 Hz -> distance from the goal 70 ms after a bump: 0.150
controller correcting at  50 Hz -> distance from the goal 70 ms after a bump: 0.037
controller correcting at 200 Hz -> distance from the goal 70 ms after a bump: 0.000

Toy model. A one-number “hand” with a made-up gain. A faster inner loop recovers from a bump long before the slow system’s next update.

Notice what the fast loop cannot do: if the goal itself changes, it cannot know until the slow system reports it. Speed fixes tracking, not understanding.

Reading a company announcement

An announcement, even a good one, is not an evaluation. Ask the questions of lessons 5.5, 8.2 and 8.3: how many trials, which tasks, what counted as success, how many objects were truly unseen, what failed. For Helix I can tell you the architecture as the company describes it, and the rates it states, and no more. That is a useful picture of the design; it is not evidence of how well it works.

Common misconceptions

Engineering takeaways

1. S2 at 7–9 Hz, S1 at 200 Hz.
2. About 22–29 fast steps per slow update.
3. Latent up to ~140 ms old.
4. Read announcements critically.

Two speeds, one robot.

Knowledge check

Try each question first, then reveal the explanation.

What’s next

Next: what changes when a VLA drives a humanoid’s arms and hands.

Back to the VLA roadmap