How to reason from a task to a machine.
Anyone can bolt a motor to a board. Designing an embodied system that actually works is a discipline: reason from the task, down through the body, the senses, the brain, and the policy, and state the gap between simulation and the real world. This is the method, the part that makes maker. an education, not a parts bin.
Task → morphology → sensing → compute → policy → sim-to-real.
Each choice constrains the next. Skip a link and you feel it later, an over-specced brain, a sensor that can't see what the policy needs, a sim that lied to you.
Task
Start from what the robot must do, in the real world, under real constraints, not from the parts you happen to own.
Morphology
Let the task pick the body. Wheels or legs, one arm or two, rigid or soft, form follows the job.
Sensing
Decide what it must perceive to act, and choose the smallest sensor suite that delivers it.
Compute
Size the brain to the policy, not the other way around. Where does inference run, and within what power and weight budget?
Policy
Choose how it decides: scripted, learned by imitation, or trained by reinforcement, and how you'll get the data.
Sim-to-real
Close the gap deliberately. What you can prove in the twin, and what you must test on the bench.
The CyberBrick Rover, reasoned into existence.
The method isn't abstract. Here is the cheapest build on this site walked through all six phases, the decision made at each step, and the why underneath it. This is the thinking that happened before the first line of code.
Drive to a goal on a flat floor, avoid walls, cheap enough that a classroom builds twenty.
WhyCost and simplicity dominate every later choice. That single sentence rules out legs, lidar, and a GPU before we've drawn a thing.
Two driven wheels plus a caster: skid-steer.
WhyThe fewest actuators that can reach anywhere on a floor and turn in place. Legs are overkill indoors; car-style steering adds linkages for no gain.
Goal bearing, goal distance, and one forward range reading.
WhyThe minimum to close the loop: which way to turn, when to stop, and whether a wall is ahead. A camera would be more than the task needs, and more code, weight, and power to carry.
Two motor channels and a command link, a ~$45 CyberBrick core, or any board you own.
WhyThe policy is tiny, so the brain can be too. We size the board to the job, not the other way around, and keep it brain-agnostic so a shortage never kills the design.
A hand-written proportional controller: turn toward the goal, slow near walls.
WhyLegible and debuggable, working on day one, and the yardstick for anything learned. It's the same control(obs) you later swap for a trained policy, the interface never changes.
Prove the control law in the MuJoCo twin; tune slip, deadband, and latency on the bench.
WhyThe sim proves the logic before a wheel turns. What it won't promise is wheel slip, motor deadband, and command lag, so those get a deliberate bench test, not a hope.
Rules of thumb worth defaulting to.
Not laws: defaults. Break one on purpose and you'll usually know why; break one by accident and it shows up in the failure modes below.
Form follows task
Pick the body from the job, never from the parts bin. The task sentence should eliminate most of the design space before you model anything.
The smallest sensor that closes the loop
Every sensor you add is weight, power, latency, and code to maintain. Add one only when the policy can't decide without it.
Size the brain to the policy
A scripted controller wants a microcontroller; a VLA wants a GPU. Don't pay watts and dollars for compute the policy will never use.
Start scripted, earn the learning
A legible baseline controller is the fastest path to a working robot and the fair benchmark a learned policy has to beat.
The sim lies at contact
Friction, slip, backlash, and latency are where the twin diverges from reality. Know which one will bite you, and design the test that catches it.
Log from the first run
The data you don't record is the policy you can't train and the bug you can't reproduce. Capture obs and actions from day one.
The five ways the chain breaks.
Every one traces back to a skipped or out-of-order decision. Recognize them early, they're much cheaper to catch on paper than on the bench.
The over-specced brain
A Jetson driving two hobby motors. Cost, weight, and power spent on compute the policy never touches, the tax you pay for skipping the compute question.
The blind sensor
A camera that can't see the thing the policy decides on, or a rangefinder aimed at the ceiling. Sensing chosen before the policy that has to use it.
The sim you believed
A policy that only works because the twin had no wheel slip. It demos beautifully and then wanders on the floor. The gap wasn't closed, it was ignored.
The un-loggable robot
A build with no way to record what it saw and did. You can't train it, can't debug it, can't prove it worked. It's a toy, not a platform.
The single-board lock-in
A design welded to one exact board. A price hike or a stockout kills the whole thing. Brain-agnostic isn't a nicety, it's supply-chain insurance.