← Back to Index June 27, 2026

Tightening the Scope: Software-First While the Hardware Ships

Robotics AI Autonomous Computer Vision Edge Computing

Part 3 of the build log. The parts started arriving, so the plan meets reality — and I'm starting with software while the hardware is still in transit. (Part 1: the vision · Part 2: how it works)

Where the build actually stands

Parts 1 and 2 laid out the whole arc and how the machine is arranged. This is the first honest status check against it. The parts started landing — and, as always, reality is narrower than the plan. Here is exactly what is on the bench, what is still in transit, and what I have not sourced yet.

Parts laid out on the bench
PLACEHOLDER — the parts that have arrived so far, laid out on the bench.
# Part Variant Store Unit Qty Line
1 Stainless steel links rod set, ball end 324mm wheelbase GEEK RC $12.84 1 set (10 pcs) $12.84
2 DS3218MG 20KG digital servo — waterproof, full metal gear 2-pack, 180° stemedu $27.94 1 $27.94
3 Metal shock absorber oil damper (SCX10) 120mm, 2 pcs AOSBO $9.53 2 $19.06

Estimated parts subtotal: ~$59.84 USD

A few honest caveats. Only the links rod set shows as fully delivered; the servo two-pack and the dampers are still in transit, so quantities on hand will lag the order for a bit. I left two duplicate "expired" orders (a second links set and another servo) out of the count — they never went through. The damper line is two separate orders of the 2-pack, i.e. four dampers total, which is exactly right for a four-corner crawler.

flowchart TB
    classDef hand fill:#ECFDF5,stroke:#10B981,color:#065F46;
    classDef transit fill:#FFFBEB,stroke:#F59E0B,color:#92400E;
    classDef todo fill:#FAFAFA,stroke:#A1A1AA,color:#52525B,stroke-dasharray:5 4;

    subgraph HAND["In hand"]
        L["Links rod set 324mm<br/>(GEEK RC)"]
    end
    subgraph TRANSIT["In transit"]
        S["DS3218MG 20KG servo<br/>2-pack (stemedu)"]
        D["120mm oil dampers ×4<br/>(AOSBO)"]
    end
    subgraph TODO["Still to source"]
        CH["Chassis / drivetrain"]
        PM["ESC + motor"]
        TX["Transmitter / receiver"]
        CAM["Camera + mount"]
        CMP["On-board compute"]
        BAT["Battery / power"]
    end

    class L hand
    class S,D transit
    class CH,PM,TX,CAM,CMP,BAT todo
Materials status: in hand, in transit, and still to source. The "still to source" column is the real gap — drivetrain, power, radio, and the whole perception/compute stack.

The takeaway from that diagram is the right-hand column. What has arrived is suspension and steering linkage — the mechanical layer. Everything that makes it drive (ESC, motor, battery), everything that makes it controllable (transmitter/receiver), and everything that makes it perceive and think (camera, mount, on-board compute) is still ahead of me. That shapes what is smart to work on right now.

Tightening the scope

With hardware trickling in, the worst thing I could do is sit idle waiting for a box. So I am tightening the scope around one question and front-loading everything that does not need a finished robot. The north star is unchanged and now sharper:

Get to the Phase 3 result — the accuracy-vs-cost curve across escalation policies — with the least hardware on the critical path.

Concretely, that means holding the line on a few things. Richer on-device visual re-grounding stays exactly where it was — deferred to Phase 4. Near-term perception stays deliberately cheap: pose reached, detector firing, timeout. Anything that does not move the escalation curve waits. Tightening scope is not abandoning the vision in Part 1; it is protecting the one result that makes the vision worth believing.

Software-first while the hardware ships

That reframing makes the next move obvious: build the software spine now, against fixtures and recorded data, so the only things gated on the assembled crawler are the things that genuinely need it.

flowchart LR
    classDef now fill:#EEF2FF,stroke:#6366F1,color:#312E81;
    classDef wait fill:#FAFAFA,stroke:#A1A1AA,color:#52525B,stroke-dasharray:5 4;

    subgraph NOW["Build now — no robot required"]
        C["Phase 0: lock the plan schema<br/>mission → typed plan contract"]
        DEC["Phase 1: cloud decomposition<br/>score plans vs. hand-authored set"]
        SIM["Test harness<br/>recorded teleop logs + fixtures"]
        C --> DEC
        C --> SIM
    end

    subgraph WAIT["Waiting on hardware"]
        BRINGUP["Phase −1: finish RC bring-up<br/>needs ESC, motor, TX/RX"]
        EXEC["Phase 2: on-device execution<br/>needs the assembled crawler"]
        BRINGUP --> EXEC
    end

    DEC -.->|plans ready to run| EXEC
    SIM -.->|baseline + fixtures| EXEC

    class C,DEC,SIM now
    class BRINGUP,EXEC wait
What I can build before the robot arrives (left) versus what genuinely waits on hardware (right). The dotted edges are the hand-off: plans and fixtures built now drop straight into on-device execution later.

The plan contract (Phase 0) and cloud decomposition (Phase 1) need no robot at all — a mission, a typed plan, and a way to score that plan against hand-authored truth. The test harness leans on the teleop logs from bring-up: human driving traces as a baseline for competent control, and as fixtures the autonomy can be replayed against before it ever touches a motor.

Teleop log trace visualization
PLACEHOLDER — a logged human drive (throttle and steering over time). These traces become the baseline and the replay fixtures for the software spine.

When the chassis is finally driving, the first manual-drive clip lands right here — and bring-up's logs immediately start feeding the harness above. Until then, the robot-shaped hole in the plan is filled with data, not waiting.

First manual drive video
PLACEHOLDER (video) — first manual drive, once the drivetrain and radio arrive. Swap this for a video block when recorded.

How these build-log updates will work

A note on cadence, mostly to keep myself honest. Every entry in this log ships one real thing — a demo, a dataset, a plot, a result — even a small one. No "architecture announcement" posts that move nothing. Failures get written up as plainly as the wins, because the failures are where the actual research is. Scope is allowed to shrink between entries; the north star is not.

timeline
    title Build Log — how this series unfolds
    Pt.1 : The vision — what I'm building and why
    Pt.2 : Architecture and the phased plan
    Pt.3 : Real BOM and tightened scope : software-first while hardware ships
    Pt.4+ : One shippable result per entry : a demo, a dataset, a plot
The shape of the series: the vision, how it works, this scope-and-materials check, then a steady run of build-log entries that each ship something real.

Next time I expect to be showing the plan schema and the first decomposition scores — software I can build today, robot or no robot.

More as it crawls.