A 1984 toy robot from the 1980s has been given modern AI intelligence after decades of inactivity. The Tomy Omnibot, once marketed as a futuristic domestic assistant, now moves, sees, and responds to people through a new AI-powered system. Source: makezine.com.
What Happened: A Rebirth of a Vintage Robot
At Moonlighter FabLab in Miami, maker Mario Cruz found a Tomy Omnibot in a donation box. Its original electronics were degraded by leaking batteries and worn components. The plastic shell, however, remained remarkably intact—its smooth, smoked-plastic dome and tank-style wheels still carried the aesthetic of a 1980s sci-fi vision.
Cruz began restoring the machine. He cleaned the circuit board with isopropyl alcohol and a toothbrush, removing the crystalline white bloom that had formed from decades of battery acid leakage. Several traces on the main printed circuit board (PCB) had been completely eaten through by corrosion. Using a soldering iron, he carefully reconnected critical nodes, ensuring the original logic circuits—hand-routed with through-hole components—were restored to functionality.
Once power returned, the motors whirred to life. The Omnibot took its first drive in probably thirty years. Ten seconds later, the rubber wheels disintegrated onto the floor. The disintegration was not a failure—it was a testament to the age of the materials. The plastic was brittle, and the wheels, made from a vintage rubber compound, had degraded under constant humidity and temperature shifts. The original motor board, however, still functioned. It interpreted audio tones as movement commands—just as it did in 1984. This core functionality had not changed. It didn’t need to.
After basic repairs, Cruz added a new layer of intelligence. This created a new companion robot named Ring-O, which sits atop the original Omnibot and handles perception and interaction. Ring-O does not move on its own. It sees, processes, and speaks. The Omnibot remains the physical platform, rolling across the floor under the direction of Ring-O’s commands.
How the System Works: From Vision to Action
Ring-O uses a camera (IMX500) to capture video. The image is processed on the chip itself using YOLO11, a neural network trained to detect 80 everyday objects such as people, chairs, shoes, and balls. The model runs directly on the camera’s silicon, operating at approximately 30 frames per second without burdening the Raspberry Pi’s CPU. This on-device processing ensures low latency and real-time responsiveness.
Object detection returns structured metadata: for example, a person detected at 73% confidence at pixel x:223. This data is then passed to a local processing pipeline. Initially, Cruz attempted to use a cloud-hosted large language model (LLM) to interpret the scene and generate a list of actions. The prompt was something like: ‘Here is what the robot sees. Here is the mission. What should it do next?’ The model was fed real-time video detections and a user-defined goal, such as ‘find a person’ or ‘locate a shoe.’
However, the model consistently returned only one action: turn right. No matter where the person was in the frame—dead center, far left, or at the far right—the response was always the same. This behavior was not a glitch. It was a fundamental limitation of large language models when applied to real-time, spatial decision-making. LLMs are exceptionally strong at language comprehension and generating human-like text, but they are poor at performing simple, rule-based spatial reasoning. They do not understand the mathematical relationship between position and movement. They treat ‘left’ and ‘right’ as abstract concepts, not coordinates.
After extensive debugging, Cruz replaced the LLM with a set of simple, rule-based conditions grounded in basic arithmetic:
- If the person’s center pixel is left of frame center, turn left.
- If centered, go forward.
- If right of center, turn right.
- If the person fills more than 60% of the frame, stop; you’re close enough.
This new system worked instantly. The robot responded correctly and quickly, without delays or errors. This was not just a technical improvement—it was a paradigm shift. Instead of relying on a complex AI to reason about a scene, the system now used simple, deterministic logic. The result was faster, more reliable, and more efficient behavior.
LLMs are wonderful at language. They are terrible at 'the number 331 is greater than 224 and less than 416, therefore output forward.' That’s what math is for. The model treated the detection as a statement of fact, not a prompt for movement. The system needed a bridge between perception and action—something that could translate raw data into physical movement. That bridge was not in the language model. It was in the rules.
Another issue arose with the bounding boxes—rectangles drawn around detected objects. These appeared in impossible locations or vanished entirely. The model’s coordinate system was full of inconsistencies. The metadata claimed the boxes were non-normalized, but in this particular YOLO11 variant, they were already normalized. Dividing them again produced values like 0.001, which rendered as invisible rectangles. The official Python helper for mapping model coordinates to screen coordinates returned values like width: 0, height: 148,800—clearly erroneous. The axis-swap flag was inverting every bounding box’s X and Y coordinates. And none of it compensated for the fact that the camera captured at 640×480 while the model expected 640×640, which meant the image was letterboxed with 80 pixels of padding at the top and bottom.
The fix was a small but critical set of adjustments:
- Look at the actual values; if they’re bigger than 2, normalize.
- Disable the axis-swap flag that inverted coordinates.
- Account for the 80-pixel top and bottom padding.
- Ensure all values stay within frame bounds.
After these changes, the bounding boxes appeared correctly—on the keyboard, on the person, and in real time. The robot could now accurately identify and track objects in its environment. This correction was not just a technical fix—it was a validation of a broader principle: in real-time robotics, precision and speed are more important than linguistic fluency.
Personality and User Experience
Ring-O has a small 128×128-pixel color OLED eye. It does not assist with navigation. Instead, it creates a sense of presence. The eye is not a sensor—it is a character element. It runs in its own thread and has exactly one job: make the machine feel alive.
The eye dilates and smiles when a person is detected. It widens into surprise when a cat or a dog shows up. It tracks left when the robot turns left. Every three to seven seconds, it blinks. After thirty seconds of no activity, the eyelids slowly close and it goes to sleep. When activated, the eye opens with a full animation—not a simple state change—and looks directly at the user. This animation is not just a visual effect. It is a behavioral signal. It communicates that the robot is aware, present, and responsive.
Without this eye, the robot would be seen as a sensor package—a collection of cameras and processors. With it, people treat the robot like a character. They don’t just see a machine; they see a being that watches, reacts, and responds. This shift in perception is what makes the robot engaging. It turns a technical device into a social presence.
Testing and Real-World Performance
Cruz tested the robot at Maker Faire Miami in 2026. It was exposed to children, adults, and unpredictable behavior—like pointing at dogs or pressing buttons repeatedly. The environment was chaotic, with multiple people interacting with the robot simultaneously.
To ensure reliability, the system runs as a systemd service with automatic restarts. A pre-launch smoke test verifies every import, camera frame, and audio path before the web server will even start. This ensures that no subsystem is left in a degraded state. If any component fails—such as a stale camera feed or a dropped Bluetooth connection—the system returns an HTTP 503 error with a structured message explaining the failure. The interface never blocks, even during high activity.
When children press buttons too fast, the robot now tells the UI: ‘busy, try again’ instead of silently dropping the command. This prevents user frustration and improves the overall experience. The robot now behaves like a real-world device—robust, responsive, and resilient to misuse.
This level of resilience turns a prototype into a working device that can function for hours at public events. It is no longer just a demonstration. It is a functional, user-friendly tool that can be used in real-world settings.
Why It Matters: A Legacy of Promise
When Tomy released the Omnibot in 1984, it promised a domestic robot that could learn your schedule, recognize your voice, and bring you a drink. The technology of the time—limited by processing power, memory, and software—could not deliver. The idea of a robot that could serve and assist at home was aspirational, not practical.
Today, the same promise is fulfilled—not because the original machine changed, but because the world has advanced. A $70 AI camera, a $100 single-board computer, and open-source software now make such a system possible. The original motor board still interprets audio tones to move forward. That part hasn’t changed. It didn’t need to.
The Omnibot was on the floor at Maker Faire Miami 2026, and kids loved it. They tapped buttons to find shoes, dance, or ask what it saw. The robot responded with simple, clear actions. The most popular feature? Shoe-finding. It turned a simple task into a game of hide-and-seek—except one player has a neural network and a 3D-printed face.
Limitations and Open Questions
The system does not learn from user behavior. It has no memory of past interactions. Commands are processed in real time with no adaptation. This means the robot cannot recognize routines or build habits over time.
It lacks voice recognition. The robot does not understand spoken commands like ‘find the red ball’ or ‘play music.’ It does not respond to complex requests. The LLM is used only for simple descriptions, like ‘I see a person’ or ‘I see a dog.’
While the vision system works well, it is not robust in low-light or poor visibility conditions. Performance degrades in dim environments. The camera struggles to detect objects when lighting is uneven or insufficient.
There is no built-in safety or emergency shutdown. The robot continues moving if a person steps into its path. This poses a safety risk in uncontrolled environments. A simple stop mechanism or obstacle detection system would be necessary for real-world deployment.
What to Watch Next
Future iterations may include voice recognition, memory of past interactions, and adaptive behavior. Adding a small memory module—such as an EEPROM or a micro-SD card—could allow the robot to learn routines over time. and automatically turn on the lights or play a welcome sound.
Integration with smart home systems could allow it to trigger lights, appliances, or audio devices when a person enters a room. This would transform the robot from a standalone device into a node in a smart home ecosystem.
As AI becomes more affordable and accessible, more vintage robots like the Omnibot may be reimagined with modern intelligence—without replacing their original form. The future of robotics isn’t always about new hardware. Sometimes, it’s about reactivating old ideas with new tools.
The full source code for the Omnibot and Ring-O system is available on GitHub at github.com/MarioCruz/omnibotAi.
This project shows that the future of robotics can be built from vintage hardware and open-source tools. It is not about replacing the past with the future. It is about honoring the vision of what once seemed impossible—by giving it a new life through modern technology.
Sources & further reading
Featured image: Tomy Omnibot with Ring-O companion robot mounted on an arm, OLED eye glowing. Via original publisher. Image source
