We gave giant robot characters a voice, eyes and a safe way to move.

The challenge

ED-ROM ordered a set of giant robot characters for a new summer attraction. The bodies were excellent: sculpted, painted, armoured, built by a specialist factory. What arrived could not hear a guest, could not see one, had no personality, and moved only when a person held a handheld remote control.

The brief was to turn those bodies into characters that guests could simply walk up to and talk to. Four things made that harder than a voice demo.

The audience is mostly children. They interrupt, shout, repeat themselves and test the character on purpose. A system that needs a wake word, a button or a polite pause does not survive contact with them.

Guests change language without warning. Kiryat Motzkin is a mixed-language town. A conversation can start in Hebrew and finish in English, with Arabic and Russian also in regular use, and nobody announces the switch.

The day is long and public. The park runs twelve-hour days, every day including Saturdays and holidays. There is no quiet hour for a restart, and the people in front of the robots bought tickets.

The robots were in another country. The system had to be maintained, diagnosed and updated remotely, on hardware in Israel, without opening the park's network to the internet.

Then a fifth problem appeared. The plan assumed the robot manufacturer would supply a software interface for movement. On a site visit to the factory in Zigong it became clear that movement existed only through handheld transmitters. That interface did not exist, so we had to build it. It became the largest unplanned piece of the project.

Next: The system →

The system

The system has four layers: voice, vision, motion, and fleet operations. Almost all of it runs on one computer at the park rather than in a distant data centre, because every extra network hop is time a child spends waiting.

One conversational turn

1. Audio arrives. Guest audio travels live from the robot to a media server (LiveKit) on a computer at the park.
2. Speech becomes text. Speech recognition software (faster-whisper) writes down what was said. It handles English, Hebrew, Arabic and Russian, including a guest who switches language mid-conversation, with no language button.
3. The character answers. An AI model running at the park generates the reply using that character's own written personality. It can use tools the character has been allowed to use, and it can draw on what the camera sees, so it can respond to the actual guest in front of it.
4. The reply becomes a voice. The main voice is generated on the same machine. A small checker reads each outgoing line and sends Hebrew, Arabic, Cyrillic and Chinese, Japanese or Korean text to a commercial voice service that handles those scripts better. That checker is the reason the Hebrew works. It is also the one job in the loop that leaves the building.
5. The robot speaks. Audio plays from the speaker in the robot body.

Vision

Vision models can be swapped, on the park computer or online, so a character keeps its sight if one backend is unavailable. The characters describe what they can see and are written to refuse guesses about things a camera cannot tell, such as age, mood or gender. A character can also greet someone who walks up, using a motion trigger with a threshold and cooldown, alongside a server-side wake word and an always-on session mode.

The motion layer

This is the piece built to replace the missing manufacturer interface. A Raspberry Pi, a small computer, drives a board of 8 electrical switches. On top of that sits a motor program that accepts a named set of commands, with stop, reset and safe-state behaviour, and movement durations measured against real motors rather than estimated from drawings. Saved sequences make a show routine repeatable.

The design decision that matters most is the gate between thinking and moving. The AI never drives a motor directly. In the voice agent, a character is given a fixed catalogue of named motors with descriptions, and its motor tools can only request those. Commands travel to the Pi over the same live connection as the audio, with a second web route as a backup. A request for a motor outside the catalogue is refused, and run time is capped. The character suggests; the gate decides.

Fleet console

The console is what the park is run from. It shows every robot placed on a map of the site inside its zone, with live counts for robots awake, in conversation, charging and offline, plus battery levels. From there, staff can:

• see each character and whether its robot body is reporting in
• assign which character lives in which body, using dropdowns
• edit a character's name, description and greeting without an engineer
• save named line-ups of characters per zone
• open a per-character link to talk to it from a phone and check it still sounds right
• run multiple sites, each with its own robots and zones, under one account

Next: Outcomes →

Outcomes

• Open to the public since 18 July 2026 at ROBO PARK, Chai Park, Kiryat Motzkin.
• Four primary languages in guest conversation: English, Hebrew, Arabic and Russian, shown in recorded conversations with real guests.
• Median response time of 1.9 seconds, measured across ten guest turns in two recordings from the park floor, from the end of guest speech to the first syllable from the robot's speaker. Range 0.96 to 2.91 seconds. The slowest turn is one where the character had to look at an image first.
• Nine robots managed from one console, across two zones.
• Nine character personalities written for the park.

Our published evidence covers conversation. The recordings we measured show voice and vision working with real guests. They were not recorded to document physical movement or the motion-triggered greeting, so those timings are not part of the measurements above.