From an Idea to a Physical AI Experience: Building
How we went from a simple question — “How do we let children experience robotics?” — to a complete hands-on activity involving SO-ARM101 robot arms, 3D printing, visual storytelling and a digital experience, with AI supporting almost every stage of the journey.
It Started With the Experience, Not the Technology
For Science in the City in Malta, we wanted to create an IEEE activity that would introduce children aged roughly 10–14 to robotics and AI. We had access to SO-ARM101 robot arms, and it would have been relatively easy to put the robots on a table and demonstrate what they could do.
But a demonstration wasn't what I wanted. Watching a robot move is interesting for a few minutes. Actually controlling one to accomplish something is an experience.
So the starting question became:
What experience can we create around the robot arms that makes children want to experiment with robotics?
That distinction shaped everything that followed. Rather than designing an explanation of robotics and then adding an activity, we started designing a game. The result became the IEEE Robot Rescue Mission.
Step 1 — Turning Robotics into a Mission
The first stage was essentially collaborative ideation with AI.
The robot itself imposed some useful constraints. The activity needed to work within the SO-ARM101's reach, use objects that were reasonably easy to grasp, be safe for children, operate quickly enough for an event environment, and be understandable without lengthy instructions.
From those constraints emerged the idea of a rescue mission.
Instead of telling a child:
“Use this robot arm to move an object from A to B.”
we could tell them:
“You have a rescue mission. Use your robot to retrieve the required objects while avoiding hazards.”
That small change introduced purpose.
The activity could now have a setting, missions, objects, hazards, rules and progressively more difficult challenges. The robot stopped being the exhibit. The robot became the tool through which the child interacted with the experience.
This became one of the most important design decisions in the project.
Step 2 — Using AI to Explore the Concept Visually
Once the basic concept existed, I used generative AI to explore what the experience could look like. This was particularly valuable because ideas that sound good in text can feel very different once visualised. We experimented with the appearance of the play area, mission environment, objects, obstacles, mission cards and overall visual language.
Rather than treating image generation as a way of producing final artwork, I found it more useful initially as a rapid design-thinking tool. A prompt could turn an idea into something visible within seconds.
That visual could then trigger another question:
- Is this too complicated?
- Can the robot actually reach that object?
- Would a child understand what this represents?
- Does this look like a game rather than a robotics demonstration?
- How could this become something we can manufacture?
The loop became:
Idea → Prompt → Visual → Critique → Refine
We could explore multiple concepts before investing time in CAD modelling or fabrication. AI effectively compressed the distance between imagination and prototype.
Step 3 — Moving from Pixels to Atoms
Eventually, however, the experience had to leave the screen. Everything needed to exist physically. This meant translating the visual concept into a system that could be manufactured using our own 3D printers.
We designed the play surface around a modular tile system. Rather than printing one large fixed board, the play area was divided into interchangeable tiles. The complete area in front of each robot arm could be assembled from these modules, with dedicated edge pieces creating a finished boundary.
This gave us several advantages. Individual tiles could be replaced. The environment could be rearranged. Different missions could use different layouts. Damaged components could be reprinted without recreating the entire board. Most importantly, the system could evolve after the event.
AI was useful again — but the conversation had changed. We were no longer asking:
“What could this look like?”
We were asking:
“How do we engineer this so that it can actually be printed and used?”
That meant prompts had to include real manufacturing constraints: printer bed dimensions, tolerances, modular interfaces, object dimensions, stability, print orientation and the physical capabilities of the robot gripper. The Prusa MK3S+ wasn't just the final output device. Its capabilities became part of the design specification.
Step 4 — Designing Objects a Robot Could Actually Manipulate
The mission needed objects. Some represented items the children needed to rescue or retrieve. Others represented hazards or obstacles. Again, visual appearance was only part of the problem.
A beautifully designed object is useless if the robot cannot pick it up. The objects therefore had to balance several requirements:
recognisable + printable + durable + graspable + visually engaging
That meant considering geometry from the perspective of the SO-ARM101 gripper.
- Could it approach the object?
- Was there an obvious gripping surface?
- Would the object tip over?
- Was it too small?
- Would the geometry require excessive support material?
- Could we print several copies quickly?
This is where the project became particularly interesting to me. We weren't simply doing graphic design, robotics or 3D printing. We were moving continuously between experience design, physical engineering and digital fabrication. AI helped maintain that thread across the disciplines.
Step 5 — Giving Every Child a Mission
Once we had a physical environment, we needed a simple way of explaining what to do.That led to mission cards.
We deliberately borrowed some of the visual language of collectible game cards. Each card could present a mission with a recognisable object, objective and challenge.
For example:
Retrieve the organic material.
Now a child approaching the activity wasn't simply waiting for an instructor to explain the robot. They could receive a mission. The card created anticipation before they even touched the controls.
Get Michael Azzopardi’s stories in your inbox
Join Medium for free to get updates from this writer.
This was another lesson from the project:
Good educational experiences don't necessarily need to look educational.
Children can encounter concepts such as manipulation, spatial reasoning, teleoperation, robotic constraints and human-machine interaction without those concepts initially being presented as a lecture. Let them solve the problem first. Then explain what just happened.
Step 6 — Creating the Explainer Content
The game provided engagement, but Science in the City was also an opportunity to introduce some foundational robotics concepts. So we created a set of visual explainer boards that could be printed and laminated around the activity.
Importantly, we used the SO-ARM101 itself as the visual reference. Instead of showing children an abstract industrial robot that looked completely different from the machine in front of them, the educational material connected directly to what they were about to use. The content introduced concepts around robot arms, joints, movement, control, grippers, sensing, autonomy and AI.
This created another simple experience loop:
See → Understand → Try → Discover
The physical activity and the educational material weren't separate exhibits. They reinforced each other. AI helped us move rapidly from deciding what concepts mattered, to finding age-appropriate explanations, to exploring how those concepts could be represented visually.
The role of AI here wasn't to remove the human from content creation. It was to accelerate the cycle between subject-matter thinking and communication design.
Step 7 — Adding the Digital Layer
The physical experience was only one part of the concept. We also explored a digital layer around Robot Rescue Mission.
A digital experience could introduce the mission before the child reaches the robot, explain the environment, show progress, reinforce learning afterwards, or eventually support different levels and challenges.
That starts creating an interesting architecture:
Digital experience → Mission → Physical robot → Physical environment → Outcome → Learning
The boundary between a website, game and physical robotics activity starts disappearing. And this is where I think the experiment points toward something larger than this particular event. AI makes it increasingly practical for relatively small teams to create experiences spanning software, media and physical systems.
Previously, each layer might have required a separate specialist workflow. Today they can increasingly be developed as one continuous creative process.
AI Wasn't One Tool in the Project
One of the most interesting observations came after looking back at the process.We hadn't really “used AI” at one particular point.
AI appeared throughout the lifecycle.
It helped us brainstorm the initial experience, challenge ideas, generate visual concepts, develop the game mechanics, explore physical layouts, specify 3D-printable components, develop object designs, create mission-card concepts, structure educational content, generate visual material and develop the digital experience.
The workflow looked more like:
Need → Ideation → Visualisation → Engineering → Fabrication → Content → Software → Experience
with AI assisting across the transitions. That is quite different from asking an AI tool to generate an image or write some copy. It starts to resemble AI-supported product development.
The Human Still Owns the System
There is an important caveat. AI could generate an impressive image of a robotics activity that would be completely impractical to build. It could suggest an object that looked perfect but couldn't be gripped. It could propose dimensions that didn't fit the printer. It could produce an explanation that was technically correct but inappropriate for a ten-year-old.
Every transition from one domain to another required judgement.
- Could we build it?
- Could we print it?
- Could the SO-ARM101 manipulate it?
- Would children understand it?
- Would it survive repeated use at a public event?
- Would it actually be fun?
AI accelerated exploration. It didn't eliminate engineering judgement, testing or human creativity. If anything, faster generation made judgement more important.
Then the Children Arrived
Eventually the prompts, renders, STL files, prints, mission cards and software stopped mattering. Children stood in front of the robot arms.
They picked up the controls.
They tried to position the gripper.
They overshot.
They adjusted.
They laughed.
They tried again.
And they completed their missions.
That was the real test.
What had started as a question about creating an IEEE activity had become a small environment in which children could experience robotics directly. They weren't watching the future of robotics on a screen.
They were controlling it.
What I Took Away From the Experiment
Robot Rescue Mission taught me something beyond how to design a children's robotics activity. It demonstrated how dramatically AI is changing the economics of experimentation.
A relatively small team can now move from an idea to visual design, educational content, physical product design, fabrication and a digital experience with a speed that would previously have required considerably more time and specialised resources.
The important capability isn't simply knowing how to prompt an AI model. It is being able to orchestrate a chain of tools, disciplines and decisions around an outcome. In this case, the outcome wasn't an AI-generated image, an STL file, a website or even a robot demonstration.
It was much simpler:
A child receives a mission, takes control of a robot and discovers that robotics is something they can understand, experiment with and enjoy.
Everything else — AI included — was there to make that experience possible. And perhaps that's the most useful lesson from the whole project. The best measure of AI isn't what the AI produced. It's what AI enabled us to create.
