NXP's 3-camera robot learns to make tea using a $70 chip

The gap between a lab-demo robot and one that actually works on a factory floor often comes down to the boring stuff—camera mounts, cable management, and whether you put heat-shrink tubing on the gripper. A new technical guide from NXP engineers Enzo Ruedas and Tess Boivin dives into those unglamorous details, sharing hard-won lessons from getting a vision-language-action model to run on a low-power embedded chip.

Their target task sounds simple: pick up a tea bag and drop it in a mug. But making it work reliably on an NXP i.MX 95 SoC—a processor designed for power efficiency, not brute-force GPU compute—required rethinking the entire pipeline. The team landed on a three-camera setup as the sweet spot between accuracy and latency. A gripper-mounted camera proved essential for fine manipulation, but they warn that more cameras don’t always mean better results; each one adds inference time that can break the real-time control loop.

Data collection rules are where the guide really gets opinionated. Ruedas and Boivin insist on recording while looking only through the robot’s cameras—never watching the scene directly. “Do not use information the model will not have access to at inference time,” they write. They also partitioned the workspace into 10 cm × 10 cm clusters, deliberately holding one cluster back as an unseen validation set to catch overfitting early. Small VLA models, they note, show limited generalization on movements they haven’t explicitly practiced.

The hardware hacks are refreshingly low-tech. A piece of heat-shrink tubing on the gripper claws boosted success rates by reducing slippage during grasps. Velcro cable guides kept the gripper camera’s wire from wandering into the frame. These aren’t the kind of details you find in splashy robotics announcements, but they’re exactly what separates a system that works once from one that works a hundred times. The guide frames on-device VLA deployment not as a model compression problem, but as a systems engineering challenge—one where latency-aware scheduling and asynchronous control loops matter as much as the policy itself.