Three applications for a social robot, shipped to 10+ institutions

The problem

Haru is a social robot used by research groups worldwide. Research platforms have a particular failure mode: capable hardware that sits idle because nobody has built anything compelling enough to justify the setup cost. My job was to change that by shipping applications people would actually run.

The constraints

A distributed team across three countries and timezones, with partner university teams in Spain and Australia owning parts of the integration.

A physical robot, which means a bad deployment is not a rolled-back commit, it is a machine behaving unexpectedly in a room with people in it.

Research users, who will forgive rough edges but not something that fails to start.

What I built

An emotion-aware remote control. Operators drive the robot through Telegram; a LoRA fine-tune on a Hugging Face model maps the emotional tone of a message to a robot animation, so intent survives the trip from text to physical expression.

A classroom mediator connecting classrooms in Japan and Australia, coordinating API work across the university teams. The demo led to published research.

A real-time NLP collaborative-storytelling app, still in active use.

The simulation world underneath all three. I built Haru’s virtual environment in Unity from scratch and linked every application to it, so scenarios could be tested safely before touching real hardware. This is the piece I would defend first: it is what made iteration on a physical robot survivable, and it is why the applications shipped at all.

Outcome

Three applications in active use at more than ten universities and research institutions globally, published research from the classroom work, and robot demonstrations I organised at an international robotics showcase.

What this taught me

With hardware in the loop, the highest-leverage thing you can build is often not the feature. It is the environment that lets you get the feature wrong cheaply.