One interaction model, two surfaces: how EMORI publishes practice data on ROS4HRI

Most PokaMind practice happens in a browser. A person opens a scenario, talks to an AI that plays the other side, and gets a written breakdown when the session ends. EMORI puts the same practice on a small robot, on the table where hospital reception staff take their breaks. This post explains how practice data crosses from the PokaMind platform to the robot, how the robot is built to publish it in conventions other robotics software already reads, and which parts we are not ready to claim.

Why put practice on a robot?

Some of the people who most need to rehearse hard conversations will never open a training portal. Hospital reception and administrative staff are usually the first person a patient or a relative speaks to. They rarely get time away from the desk to train. Clinical staff rehearse difficult moments. Reception rarely gets the chance.

EMORI runs on a Reachy Mini, a small desktop robot made by Pollen Robotics. It has no screen and no face. It answers with its voice and with movement of its head, its two antennas and its body. Staff start a session by voice without logging in, and they can stay anonymous or scan a staff badge.

The robot is in pilot at Badalona Serveis Assistencials, a public healthcare provider in Catalonia, under the EU ARISE program, which funds human-robot interaction work built on ROS 2 and FIWARE. The practice on the robot was designed with BSA's own team, in Catalan. The pilot has published no results, and we will not quote any until it has.

What crosses from the session to the robot?

Only a small part of the session reaches the robot. During a session, the PokaMind platform analyzes observable communication across four channels: words, voice, face and body. The practice analysis of camera frames runs on PokaMind's servers in the EU. On the robot, a small face detector runs locally only to turn its head toward the person; it does not identify anyone. Only two kinds of result are designed to cross back to the robot: the 31 communication styles, and body measures such as posture, head position and gesture. They are designed to arrive about every two seconds.

Everything else stays on the platform by design. Facial measures, voice prosody and the wording of the conversation feed the person's written breakdown and are not sent to the robot during the session. The robot receives only what its behavior engine uses to choose a move.

How does it map onto ROS4HRI?

ROS4HRI is a set of open conventions for representing people in robot software built on the Robot Operating System. It was introduced in the paper ROS for Human-Robot Interaction, which I co-authored with Séverin Lemaignan (IEEE/RSJ IROS 2021), and it was later proposed as the ROS REP-155 conventions. REP-155 is still a draft.

On EMORI, each session is built to be published as ROS4HRI person topics on ROS 2, plus an export for analysis. These are the main ones, with their status today:

Building on a draft convention is a deliberate choice. Robotics software that already speaks ROS4HRI can read the standard person topics without any PokaMind code. EMORI's own context message is its own message type, published under a topic name the standard does not use, so it does not collide with the standard topics, and software that does not know it can simply ignore it.

Why keep observation apart from interpretation?

EMORI's own context message is published on the robot alongside the standard topics. Its observation fields carry posture, head position, gesture and the communication-style values in the platform's own vocabulary. We will describe the rest of that message when its design review is complete.

Missing data follows the same logic. If a channel did not report in a cycle, for example because the person stepped out of the camera's view, the value is marked as not reported and its topic is not published. A subscriber sees nothing, instead of a zero that would describe a different session from the one that happened.

The robot's own decisions are bounded too. Its behavior engine is built to request at most one move at a time from a fixed list of named moves, such as turning toward the person, nodding, looking around or settling. It is not built to improvise outside that list. The first rule in its behavior policy is the settle rule: when a roleplay gets heated, the robot is built to settle rather than match the energy. In a hospital, that is the behavior that matters most.

What stays private on the wire?

The data is pseudonymous wherever it travels. On the robot's ROS topics, person IDs are replaced with salted hashes. In the analytics export, people and sessions appear as hashed codes, never names. Session records on the robot are kept under a code, never a name. Speech text is off by default on the ROS topics, so the words of the conversation are not published there.

The robot does not identify anyone from their face or voice. Its own voice, its menu listening and a face detector that points its head at the person run on the device. Speech transcription and language analysis for the practice session run through AI sub-processors listed in the data processing terms we provide during evaluation.

Can someone outside check the data?

Each session can be exported as NGSI-LD entities, which has so far been proven in simulation. We publish no metric values until the pilot has measured and approved them.

What we are not claiming yet

A robot in a hospital invites bigger claims than the evidence supports, so here is what we are not saying.

• The pilot is running and has published no results. We will not quote outcomes until they have been measured and approved.
• Parts of the data path described here are still being rolled out on the pilot robot. Where this post says the robot is built to do something, that describes its design.
• The ROS packages behind EMORI are not public yet.
• The FIWARE export has been proven in simulation, not with live sessions from the hospital.

What we can say today is this: the same interaction model runs in a browser and on a robot, and on the robot it is built to produce data in conventions that other robotics software can read and check. When the pilot has results, we will publish them.