Sending a Robot Its First Command: From Registration to Running

I messed around with Force Infinite's AtomBrain over the weekend and hit quite a few pitfalls. The name sounds grand, but an embodied brain is really just the software on a robot that handles perception and motion — what it sees, what commands it hears, how its hands and feet move, all under its control. Behind it is a causal world model plus a continuously learning VLA; VLA stands for vision, language, action.

The scenario I practiced was very plain: have the robot move a cup on the table to the shelf. Pick-and-place is the intro course for embodied tasks, like sequence alignment in protein structure prediction — simple, but with no shortage of pitfalls.

Day one: create a project, write the first instruction

1. Register an account, verify email. You land on the workbench: project list on the left, task editing area in the middle, run log on the right.

2. Click New project, name it whatever, I wrote cup_pick_v1.

3. Choose a model. There are three entries on the workbench, corresponding to specialized, general, and humanoid lines; for beginners pick general, don't go straight for humanoid.

4. Write the instruction in the task editing area. My first one was "clean up the table."

5. Click Run, the log starts scrolling, results come out in about two minutes — a string of task decompositions plus a set of action sequences.

The result was pretty awkward. The decomposition was all "recognize object," "move to target," "execute grasp," not a single one landing on a specific position. I stared at the log for a while before realizing the problem was me. The instruction was too abstract, so the model could only give me abstraction back.

Day three: write specific instructions, align the coordinate system

Changed two things, got it working.

Changed the instruction to "grasp the white mug slightly left of center in the frame, place it on the second shelf on the right side of the frame, cup opening facing up." Object, position, orientation, constraints all written clearly — same principle as writing an experiment protocol; vague descriptions won't get you reproducible results.

The coordinate system is a more hidden pitfall. What the camera sees as slightly left and what the robotic arm base understands as slightly left may well not be the same direction. There's an extrinsic calibration entry in the workbench; fill in the relative position of camera and base, and only then do the action sequence landing points stop drifting. That was the reason for all the failed grasps before.

Also the output format. The action sequence comes back as a JSON chunk, and the field name is sometimes pos, sometimes position; feeding it directly to the downstream executor throws errors. I added a field validation layer in between, blocking mismatches first. This kind of dirty work at the interface layer has little to do with model accuracy; I got burned by it once before on another project.

A week later: let it run several rounds on its own

Over a week, I ran the same grasping task repeatedly, hanging on a local inference node. Mainly I wanted to see whether the continuous learning claim holds up in my small scenario. Repeated runs in the same scenario — stability did improve; switch to a new object or new lighting, it still drops. The value of the causal world model should be here: whether it can transfer physical common sense like "a cup placed crooked will fall." I haven't reached a conclusion yet, and it may also be that my sample is too small.

The common definition of embodied intelligence is: an intelligent system that perceives and acts based on a physical entity, acquiring information through interaction with the environment, understanding problems, making decisions, and acting.

By this definition, the real value of products like AtomBrain is letting developers write a bit less kinematics code. Don't treat it as a wish-granting machine; it's more like an executor that needs you to organize your inputs properly.

What to try next: switch grasping to insertion/removal with contact force, like plugging a charging head into a socket. That task has much higher force requirements, and it's exactly what can test whether its causal model can tell the difference between stuck and fully inserted.

One prediction: in the next year, the competitive point for the embodied brain line will shift from the model itself to data feedback loops. Whoever's robots fail more in real scenarios and record more finely will have models that work first.