SEQUENT
Research Log · live

Executing standard operating procedures on a Unitree G1

An incident in plain English is matched to a standard operating procedure, the procedure is translated into a chain of robot skills, and each physical step is executed and verified against measured physics. Build log below — every RL run and result, newest first.

01 / The pipeline

Retrieval, planning, and verified execution

language → SOP retrieval → plan → skill execution → verification. Enter an incident. The system retrieves the matching SOP as a human worker reads it, turns each written step into a verifiable robot skill, and infers the physical moves the SOP leaves implicit — a human just knows to walk to the machine. This is the real system:

Retrieval = a semantic sentence-transformer (all-MiniLM-L6-v2) over 100 real SOPs. Each written step maps to a skill; implicit navigation is inferred. verified = checked against MuJoCo physics · reach-limited = attempted but blocked by the frozen base controller · operational = sensor read / wait / notify · inferred = a move the SOP omits.

skill · walk_toverified
robot walking to the workbench
navigate to stationarrives upright · 186 steps
skill · graspRL · unreliable
a best-case grasp; most attempts knock the object off the table
this is a best-case clip~1 in 3 · usually knocks it off

The chain above is executed by these verified skills — locomotion (PID + the AMO whole-body controller) and manipulation (reinforcement-learned). Each runs as its own reset→rollout→verify episode.

01 · the brain / what we trained

We trained our own brain — and kept only the half that worked

The brain does two jobs: retrieve the right SOP for a plain-English incident, and plan it into robot skills. We trained our own model for each. One worked, one didn’t — so the honest call was never “custom vs frontier,” it was task by task.

retriever · fine-tuned bi-encoderkept
We fine-tuned a MiniLM sentence bi-encoder (multiple-negatives loss) to map an operator’s plain-English incident to the right SOP. On a held-out test it nearly doubles a lexical baseline — a real, custom-trained win, and the RAG layer we kept.
Recall@1 · 269 held-out (TF-IDF 0.30)0.57
planner · Flan-T5 + LoRAdropped
We also trained our own planner — a Flan-T5 seq2seq with LoRA — to write the skill chain. Re-run twice, independently: it produces 0% valid plans, echoing the prompt instead of writing one. No small fix existed; it never learned the structure. (An F1 of 0.78 once reported for it was a hardcoded placeholder, never measured.)
valid plans · re-measured ×20 / 20
retriever benchmark · live, 269 held-outmeasured
TF-IDF (lexical)
  R@1 0.30 · R@5 0.54 · MRR 0.41

fine-tuned bi-encoder
  R@1 0.57 · R@5 0.87 · MRR 0.69
honest caveatheld-out · same-distribution · not yet OOD
The decision

Train your own where it pays; use a frontier model where reinventing it is pointless

Retrieval rewarded a small fine-tuned model, so we kept ours. Planning did not — a frontier LLM (Claude/Gemini) reasons over the top-k retrieved SOPs and writes valid, sensible skill chains out of the box, where our from-scratch planner produced nothing usable. We do not claim a planner accuracy number: this corpus has no gold reference plans, so we won’t fabricate one.

So planning runs on a frontier model, and our originality goes where it is actually defensible — the layer no API gives you: every planned skill is verified against measured physics before it counts. The model proposes; the physics disposes.

02 / The hard skill — press_button

press_button: five RL iterations

Locomotion was reliable; pressing a button was not. Five iterations exposed three distinct failures — reward hacking, a wrong button model, and base recoil — each caught by verifying on measured physics rather than the policy's own claim.

bp-v1 · no behavior cloningverifier: fail
policy hovering
deterministic press depth0.96 cm — it hovers
bp-v1 — no behavior cloning

RL from scratch converges to hovering

Plain PPO found a lazy local optimum: park the hand near the button and farm the "getting close" reward without ever committing. The mean policy never experienced a press, so it never learned one.

bp-v3 · behavior cloningverifier: fail (jab)
deep jab
press / hold3.6 cm deep · held 13/25
bp-v3 — behavior cloning

Clone a demonstration, then refine with RL

We cloned a scripted press to bootstrap the policy into the right basin — the hover vanished, stochastic success hit 10/10. But it jabbed: pressed deep, then let go. A new problem, but real progress.

The bug the verifier caughtmodel fix
verifier trace
what the physics trace revealedwhole button slid + wrong way
model fix — caught by the verifier

The button model was wrong

The trace showed the entire button body translating — and in the wrong direction. The "press" was the hand dragging a loose cylinder outward. A success-rate number would have hidden this; the physics trace exposed it. We rebuilt the button: fixed housing, a cap that compresses inward.

diagnosisnatural reach
natural reach
root causebase recoil ate the reach
diagnosis

The base recoils ~9cm when the arm reaches

The arm tracked its target perfectly — but reaching forward made the pelvis recoil 9 cm back to stay balanced, carrying the hand off the button. The fix: a realistic protruding e-stop button (bring the surface to the robot) + a closed-loop controller that corrects for recoil every step. Suddenly: a clean, natural, straight-on press.

bp-v5 · passed the verifiernot usable
press that passed the metric but is visually a contorted lean to a protruding button
verifier number5.3 cm · held 79
honest reviewreach-limited
bp-v5 — metric vs. reality

Passes the verifier; still not a usable press

bp-v5 passes the physics verifier — 5.3 cm, held 79 steps. But look at the clip: it's a contorted lean into a protruding mushroom e-stop, a button shaped to meet a hand that can't reach a flush one. On honest review we confirmed the robot's frozen whole-body controller recoils ~11 cm backward on any standing reach and won't lean, so it cannot press a normal flush button standing. The number passed a hacked setup — the same metric-vs-reality trap as the grasp. So we retract "solved": press_button is reach-limited, and the verifier now reports it honestly as NOT VERIFIED. That honesty is the point.

02d / Manipulation, rebuilt — and a hard lesson

When the simulator was doing the grasping

We rebuilt manipulation with a real Robotiq 2F-85 gripper, and got what looked like a real skill: across three runs the “grasp” climbed to a 60% sustained hold. Then we watched it frame by frame. The number was a lie the physics was telling — the position-controlled arm was driving the gripper 7.5 cm straight through the solid pedestal, and the block was spawning mid-air and dropping into the jaws. The “grasp” was a phase-through-and-jam exploit, not a grip. Our own metric said 60%; run that exact policy on a corrected simulator and it scores 0%. So we retired every grasp result and started over honestly.

the bug, and the fixcaught by eye, not by metric
corrected scene: the tool rests flush on the pedestal and the gripper respects the solid surface
hand penetration into the pedestal75 mm → 11 mm
contact bug

The hand was passing through the table

Default contact was too soft for a kp=300 arm — it bulldozed the gripper through the pedestal, and the tool was dropped from a centimetre up instead of resting on it. We now rest the tool flush and stiffen the contact, so the hand is stopped by the surface. Every grasp before this fix is retired — they were measuring an exploit.

gr-v4 · first run on the fixed simreal grip
grasp / lift95% real grip · 0% lift (yet)
gr-v4 — honest baseline

A real grip that won’t lift — yet

On the corrected physics the policy learns a genuine two-sided grip on the tool — 95%, no phasing, no jam. But it doesn’t lift: a grip-stability penalty we added over-discouraged any motion, so it grips and freezes. We’ve softened it and a lift run is training now. This is the real starting line — slower, but true.

02e / Onto the real workbench

Grasping at the table

We moved the grasp off the floating pedestal onto the actual workstation — the robot stands at the bench and picks a box off the table, the real manipulation task that feeds the SOP chain (walk → grasp → walk → press). The honest journey: it first faked the grasp, then contorted its arm through its own body to reach. Each was caught on video and fixed.

fake grasp, caughttop-pinch
what the contact check missedgripper closed on the box’s TOP edge
grasp quality

“Both pads touching” isn’t a grasp

Our grip check counted any two-sided contact — so the policy pinched the top of the box (2.3 cm above its center) and scored a grasp without the box ever being in the jaws. Fix: a grip only counts when the box is centered between the pads, plus a reward that pulls it to center before closing. Grasp quality went from a top-pinch to a real 95% centered grip.

before → afterarm pose fixed
contorted pose: upper arm buried in the torso
elbow vs torso2.2 cm inside → 14.3 cm out
arm through the body

The arm was curling into the torso

To reach a box sitting right at its waist, the policy buried its upper arm inside its own torso (elbow 2.2 cm from the body axis; physics didn’t catch it because the collision capsules are thinner than the visuals). It looked wrong, and it was. Fix: give the arm room — move the box further onto the table so an extended reach exists — and penalize the elbow entering the torso. A natural pose (elbow 14.3 cm clear) now reaches the box.

Replay a table grasp in 3D — drag to orbit, scrub the timeline:

table grasp · interactive replaylive 3D

This replay is an early table run (the contorted arm pose shown above) — it’ll update to the fixed run as training lands. Replayed from recorded MuJoCo state.

Real deterministic rollouts, MuJoCo · fixed base at the workstation · still open: the lift — it grips the box but won’t raise it yet · next: solve the lift, then GPU-accelerate training (MJX) for far faster iteration.

02b / The whole thing, working

End-to-end run

A plain-English incident is retrieved to an SOP, planned into a skill chain, and executed — each physical step checked against measured physics, and any step the robot cannot complete reported as not verified rather than passed. Full run:

language → SOP → walk · grasp · verifyverified + honest
demo: language to retrieved procedure to verified walk and grasp, with the verifier honestly flagging the unreachable press
sop_demo.py · live traceSOP complete
INCIDENT  "fetch the screwdriver from the workbench"
   ↓ retrieve → plan → execute (each step checked against measured physics)
   1. walk_to(workbench)      [VERIFIED]      arrived upright — solid, repeatable
   2. grasp(screwdriver)      [VERIFIED]      this run latched + lifted... but ~2 of 3 runs it knocks the object off
   3. press_button(red)       [NOT VERIFIED]  can't reach a flush button standing (controller recoil)
   ✅ one solid skill (walk)  ·  ⚑ a verifier that reports the hard ones honestly — even its own misses
02c / See it in 3D

Interactive 3D replay

The logged walk-and-grasp trajectory, replayed in-browser from the recorded MuJoCo state. Orbit and scrub the timeline; toggle walk+grasp vs grasp-only.

walk → grasp · interactive replaylive 3D
03 / Method

Behavior cloning and physics-based verification

training curve · bp-v4reward + hold
training curves

Behavior cloning — the single biggest lever. RL from scratch on a thin-margin target finds degenerate optima (hover, jab). Cloning a demonstration first drops the policy into the basin of the real behavior; RL only has to refine. Hover → deep reliable press.

The verifier — every physical step is judged by measured physics (button displacement held ≥25 steps, base upright), never the policy's own claim. It caught a reward-hacking jab and a wrong button model. A step is reported as not verified rather than passed when the physics disagrees.

04 / Runs

All runs

← Back to main