Components

RoIS 2.0 defines 17 basic HRI Components. This page shows how each maps to a physical robot and to a virtual avatar, and what OpenRoIS provides for it today.

Robots and Virtual Avatars Share Most Components

Perception and speech components run the same models whether their input comes from a robot camera or a webcam. Of the 17 basic components, 13 keep the same interface and the same underlying models across paradigms, differing at most in their input source, output device, or coordinate system. Only 4 (Reaction, Navigation, Follow, and Move) need implementations specific to the paradigm. The table is an analysis of the component definitions, not a measurement of shared code.

Component	Physical robot	Virtual avatar	Across paradigms
Person Detection	Detector on the robot camera	Detector on a webcam or virtual sensor	Identical
Person Localization	Depth camera and tracker	World position or webcam depth	Coordinate system differs
Person Identification	Face or re-identification model	Same model	Identical
Face Detection	Face detector	Same detector	Identical
Face Localization	Face mesh	Same face mesh	Identical
Sound Detection	Voice activity detection	Same detection	Identical
Sound Localization	Microphone array	Microphone array or virtual source	Source differs
Speech Recognition	Speech-to-text model	Same model	Identical
Gesture Recognition	Pose model	Same model	Identical
Speech Synthesis	Text to speech on a speaker	Text to speech with lip sync	Output differs
Audio Streaming	Microphone stream	Synthesized audio stream	Source differs
Video Streaming	Camera stream	Rendered frames stream	Source differs
System Information	Battery, pose, and health	Frame rate and avatar state	State differs
Reaction	LEDs or gestures	Animations and expressions	Paradigm-specific
Navigation	Navigation stack, for example Nav2	Navigation mesh	Paradigm-specific
Follow	Navigation and tracking	Virtual follow behavior	Paradigm-specific
Move	Velocity commands to motors	Avatar transform	Paradigm-specific

Status in OpenRoIS

Three things exist per component type:

• The profile: the commands, queries, events and parameters of the type, as a constant in openrois.interfaces.components, generated from the normative XML profiles of RoIS 2.0. A component declares the profile of its type, and the engine serves it.
• Typed messages: Python, TypeScript and C# models of the type's results, so an event such as person_detected is a structured message instead of a list of strings. See how the types are generated.
• Implementations: published components that run against a platform.

Component	Profile	Typed messages	Implementations
System Information	Available	Available	Reachy Mini, mock
Person Detection	Available	Available	Reachy Mini, mock
Reaction	Available	Available	Reachy Mini
Navigation	Available	Available	mock
Speech Synthesis	Available	Planned	Reachy Mini
Person Localization	Available	Planned
Person Identification	Available	Planned
Face Detection	Available	Planned
Face Localization	Available	Planned
Sound Detection	Available	Planned
Sound Localization	Available	Planned
Speech Recognition	Available	Planned
Gesture Recognition	Available	Planned
Follow	Available	Planned
Move	Available	Planned
Audio Streaming	Available	Planned
Video Streaming	Available	Planned

The implementations are in two places:

• The Reachy Mini adapter, for the open-source Pollen Robotics Reachy Mini. It runs on the real robot and in simulation, and is the reference for a complete adapter.
• The mock adapter of the repository, which simulates its components with no robot. The quick start runs it.

A component implements the part of its profile that its platform supports. Its own profile lists exactly that part, which is what an application reads.

User-Defined Components

RoIS allows components beyond the basic 17, reusing the common messages and the profile mechanism. OpenRoIS supports them with the same decorators: pass a profile of your own to @component instead of a constant, as write components and an adapter shows. Service applications discover user-defined components through the profile exactly like basic ones.

Community Components

Adapters for additional platforms live in their own repositories, separate from the core repository. A registry for them is part of the long-term roadmap.