← Back to Index June 25, 2026

Teaching a 1/10 Crawler to Understand What I Mean

Robotics AI Autonomous Computer Vision Edge Computing

Part 1 of the build log — the vision: what I'm building and why. (Part 2: how it works →)

The crawler on its intended terrain
PLACEHOLDER — hero shot of the crawler on its intended terrain.

The goal

I'm building a small autonomous ground robot on a 1/10 scale crawler chassis. Not another line-follower, and not a teleoperated toy with a camera bolted on — a system you can hand a goal in plain language and watch it figure out what to do, where the hard parts are the parts that usually get hand-waved.

The target capability, stated plainly: give the robot a mission in natural language, and have it decompose that mission into a bounded sequence of behaviors it can actually execute, verify against what it really perceives, and ask for help when it's unsure — all while running mostly offline on modest compute.

The crawler is the proving ground. The real subject is the seam between a high-level language model that interprets intent and a low-level navigation stack that moves a physical thing through the world. That seam is where most "agentic robot" demos quietly fall apart, and it's exactly where I want to plant a flag.

Why a crawler, and why this problem

Bare 1/10 crawler chassis
PLACEHOLDER — the bare 1/10 crawler chassis before any build work.

A 1/10 crawler is a deliberate choice. It's built for rough, uneven terrain, it fits in environments a wheeled robot can't, and it's cheap enough to iterate on without fear. That last point matters more than it sounds — the ability to break things and try again is the whole game in robotics.

I care about this problem because the interesting failures only show up on real hardware. A vision-language model will confidently tell you "the target is by the fence" from one clean photo. The moment a robot starts driving toward that target through a half-built map, with a low camera angle and a battery that's draining, the gap between what the model said and what the world is becomes measurable — and that gap is the research. You cannot study it on a static benchmark. You need a thing that moves, gets stuck, and runs out of power.

There's also a context I keep in view: deployment in places where connectivity is unreliable, power is scarce, and parts need to be locally repairable. That pushes every design decision toward offline-first AI, energy awareness, and simplicity — constraints that, conveniently, also make the engineering honest.

What I'm really chasing

Strip away the chassis and the cool factor, and the question underneath is narrow and measurable: when a language model and a moving robot disagree about the world, how cheaply can the system notice, and what should it do about it? Everything I build is in service of putting a number on that. Part 2 is how the machine is actually arranged to make that question answerable — the three-layer architecture, the safe-by-default fallback, and the phase-by-phase plan to get there.

More as it crawls.