---
title: 'CARIS: Adaptable Robot Interface'
url: https://www.emergentmind.com/topics/context-adaptable-robot-interface-system-caris
type: topic
---

# CARIS: Adaptable Robot Interface

Context-Adaptable Robot Interface System (CARIS) denotes a modular interface paradigm for reconfiguring robot behavior across changing scenarios, users, and platforms. In current robotics literature, the term most directly refers to a web-based Wizard-of-Oz (WoZ) platform that unifies teleoperation, perception, dialogue, and multimodal data recording for social robots, and that was demonstrated in two contexts, a mental health companion and a tour guide [2509.00660].

## 1. Definition and research setting

CARIS emerged from a well-established HRI practice: WoZ-controlled robots are routinely used to study navigation, conversational dynamics, and human-in-the-loop behavior before full autonomy is available. The motivating problem is that many WoZ tools are limited to one context, one robot, or one narrowly defined interaction setting, which makes them difficult to reuse across laboratories, scenarios, and user populations. The CARIS formulation therefore targets single-context / single-platform design, limited adaptability and modularity, scalability challenges, and fragmented toolchains by providing one interface layer that can be reconfigured for different roles, environments, and hardware [2509.00660].

Within that framing, CARIS is designed to support context adaptability, personalization, scalability and rapid prototyping, integration of advanced capabilities, and ease of use for wizards/operators. The comparison reported for prior WoZ systems places CARIS in a category intended to support speech/text inputs, LLM integration, teleoperation, data storage, video streaming, perception including SLAM, and data annotation, rather than only a subset of those functions [2509.00660]. This positioning is significant because it treats interface design not as a peripheral GUI problem, but as a systems problem spanning robot control, perception, language, and experimental data collection.

A common misconception is that a context-adaptable interface is necessarily an autonomous dialogue layer. The CARIS studies do not support that interpretation. They instead treat the wizard as the central decision-maker and use model-based components, including LLMs and VLMs, as configurable resources within that control loop rather than as an unconditional replacement for operator judgment [2509.00660].

## 2. System architecture

CARIS is organized around three technical components and four functional modules. The technical components are a robot onboarding platform, a backend, and a web-based Wizard interface. The functional modules are Localization, Perception, Conversation, and Wizard, with the Wizard module orchestrating the others through the front-end [2509.00660].

The robot onboarding platform is a ground robot equipped with 2D LIDAR, an RGB camera, audio output, and a mobile base supporting forward/backward motion and rotation. The backend is implemented with FastAPI and hosts computer vision, LLM and VLM access, APIs for perception and conversation, and data storage in JSON logs, PNG images, and text logs. The web interface is implemented in Svelte, communicates with the backend through HTTP, and communicates with the robot through ROSBridge [2509.00660].

The reported implementation uses TIAGo Base as the robot platform, an Oak-D RGB camera mounted on a Raspberry Pi 4, and a laptop running the FastAPI backend. The Perception Module uses YOLO v8n and DeepSORT. The Conversation Module supports Gemini Flash 1.5, Llama 3.1 8B, and LLaVA 7B. Inference is reported as compatible with Metal Performance Shaders on Apple Silicon, as well as CUDA or CPU-only environments [2509.00660].

Data flow is explicitly layered. RGB images are sent from the robot to the Perception Module, LIDAR scans to the Localization Module, and speech output to the Conversation Module. The backend returns processed video, person tracking outputs, and conversation histories to the Wizard interface. In the opposite direction, the Wizard sends movement commands through ROSBridge and dialogue or perception actions through HTTP/REST. This separation is one of the system’s main technical devices for preserving reconfigurability across contexts [2509.00660].

## 3. Operational capabilities

The Localization Module provides teleoperation and situational awareness. Supported motions are forward, backward, rotate left, and rotate right. The interface displays a LIDAR map together with the camera stream, giving the wizard simultaneous access to geometric and visual context. Movement commands are transmitted through ROSBridge to the robot [2509.00660].

The Perception Module provides person detection and tracking. It uses YOLO v8n for detection and DeepSORT for tracking and re-identification, and exposes results through a people-tracking interface that lists detected individuals, allows renaming/tagging, and supports grouping. The system is therefore not limited to anonymous detections; it is designed to attach interaction histories to labeled individuals over time [2509.00660].

The Conversation Module integrates speech-to-text, text input, text-to-speech, and optional image input for multimodal prompting. Prompts can be sent either as text or as text-plus-image, with backend selection among Gemini Flash 1.5, Llama 3.1 8B, and LLaVA 7B. Responses are displayed in the interface and can be vocalized through the robot speakers. This gives the wizard a mixed-initiative communication channel in which direct authored utterances and model-generated utterances coexist [2509.00660].

The Wizard Module also functions as the data-recording layer. Movement commands and TTS usage are logged as text files, captured images are stored as PNG files, and LLM interactions are stored as JSON. The design therefore treats experimental operation and experimental documentation as part of the same interface system, which is especially relevant for WoZ studies intended to generate datasets for later autonomous HRI models [2509.00660].

## 4. Context adaptability and personalization

In the CARIS paper, “context-adaptable” means that core capabilities—localization, perception, conversation, and logging—are decoupled from scenario logic. The same system is meant to support roles such as tour guide, check-in agent, and mental health companion with minimal reconfiguration, and the reported demonstrations focus on tour guidance and mental-health-oriented interaction [2509.00660].

The principal mechanisms are configuration and emphasis rather than a formal profile language. The system supports LLM “roles” or default prompts, allowing the wizard to set context-specific conversational framing such as “You are a mental health companion” or “You are a tour guide.” The interface can also be reorganized by priority: in the mental health setting, participants preferred stronger emphasis on text communication and privacy-sensitive behavior, while in the tour setting the camera feed, LIDAR, and image prompting became more central [2509.00660].

Personalization is implemented primarily through the Perception and Conversation modules. Tracked individuals can be renamed, grouped, and associated with interaction histories. Logged movement, speech, image captures, and LLM exchanges can then be retrieved in relation to those identities. The interface also includes a notes field that can hold contextual information for the wizard or for downstream prompting [2509.00660]. This does not yet constitute a formal user model, but it does provide persistent hooks for individualized interaction histories.

A second misconception is that personalization in CARIS is equivalent to delegating sensitive communication to an LLM. The reported usage points in the opposite direction. In high-stakes contexts, particularly the mental health scenario, wizards preferred direct typing over model-generated speech and explicitly asked for clearer separation between LLM-generated and wizard-authored communication. The paper’s improvement recommendations—clearer functionality separation, recommended prompts, and one-click communication options—follow directly from that finding [2509.00660].

## 5. Demonstrated scenarios and empirical findings

CARIS was demonstrated in two main scenario families. In the tour guide or room tour scenario, the robot navigated lab and nearby spaces, the wizard used teleoperation together with multimodal prompting, and the system relied heavily on camera and LIDAR views. Wizards moved the robot to locations of interest, optionally captured images, prompted the LLM for environment descriptions, edited or replaced those outputs, and delivered the resulting content through TTS. In that context, the language model was rated as relatively intuitive, with an average score of 3.5 out of 5 for the question about intuitiveness of using the language model for generating responses [2509.00660].

In the mental health companion or check scenario, the wizard remotely approached a user and conducted a check using standard prompts such as stress-level questions. Here, camera usage became more cautious; one participant explicitly raised appropriateness concerns about taking pictures. The language model was perceived as less intuitive in this context, with an average score of 2 out of 5. Wizards frequently preferred direct typing for these interactions, indicating that the value of model assistance is highly scenario-dependent rather than uniform across HRI contexts [2509.00660].

Usability findings were mixed. In the pilot study with four wizards, the System Usability Scale scores were 82.5, 60, 5, and 12.5, yielding \(M = 40\) and \(SD = 37.36\). In the main study with four wizards, scores ranged from 22 to 65, yielding \(M = 43.75\) and \(SD = 19.63\). Reported friction points included interface complexity, inconsistency, and the interaction between movement and typing. Click-based arrows were found unintuitive and imprecise, and keyboard control improved teleoperation, but keyboard movement then interfered with simultaneous message composition [2509.00660].

The most concrete design revisions and future improvements follow directly from those studies: switch from click-based arrows to keyboard movement, compress the LLM model selector into a dropdown, increase space for the camera feed and text area, rename “extra information” to “notes,” and pursue smoother integration between movement and communication, clearer functionality separation, recommended prompts, and one-click communication options [2509.00660]. These changes show that context adaptability in CARIS is not only about robot behavior; it is also about adapting the operator-facing interface to the operational burden imposed by different scenarios.

## 6. Relation to adjacent architectures and open technical directions

Related work suggests that CARIS belongs to a broader family of context-adaptable robot interface architectures in which user-facing control, software composability, and runtime abstraction are separated rather than collapsed into a monolithic application. Several adjacent systems make those complementary layers explicit.

| System | Core abstraction | Relevance to CARIS |
|---|---|---|
| CARIS | Web-based WoZ platform integrating Localization, Perception, Conversation, and Wizard modules | Operator-facing control, personalization, and multimodal logging |
| Coral | Executors, Skillsets, and Drivers coordinated through behavior trees and configured through BT XML, Docker YAML, and ROS parameter YAML | Configuration-driven reconfiguration across tasks, hardware, and deployments |
| RCP | Schema-driven protocol with `read`, `write`, `execute`, and `subscribe` over HTTP, WebSocket, and SSE | Runtime-agnostic, semantically coherent control surface |
| IRIS | Unified scene specification with shared spatial anchors across simulators, headsets, and real-world sensor inputs | Immersive, multi-user, cross-simulator interaction layer |
| Open and reconfigurable ROS GUI | Web-based SPA over ROSBridge and roslibjs with modular features for control, monitoring, and configuration | Reconfigurable ROS-side GUI pattern for complex systems |

Coral provides a compositional robotics software layer organized around Executors, Skillsets, and Drivers, with behavior trees as the user-visible task description and configuration separated into BT XML, Docker YAML, and ROS parameter YAML [2509.02453]. RCP provides a runtime-agnostic and middleware-agnostic protocol surface defined by `read`, `write`, `execute`, and `subscribe`, together with schema validation, introspection, and multi-tenant namespaces [2506.11650]. IRIS contributes a unified scene specification, shared spatial anchors, and multi-user XR interaction across MuJoCo, IsaacSim, CoppeliaSim, Genesis, and real-world point clouds [2502.03297]. The open and reconfigurable ROS GUI literature contributes a ROSBridge-and-roslibjs pattern for modular web control and monitoring in industrial cells [2406.02210]. This suggests a layered interpretation in which CARIS can be viewed as the wizard-centric interaction surface, while Coral-like composition, RCP-like protocolization, and IRIS-like scene grounding provide deeper infrastructural generality.

The main limitations identified for CARIS itself remain interface complexity, movement/communication interference, inconsistent module boundaries, and the need for stronger context-specific communication support in sensitive scenarios such as mental health interaction [2509.00660]. A plausible implication is that future CARIS-like systems will need tighter separation between wizard authority and model assistance, richer role- and context-specific interface layouts, and more explicit backend abstractions for capability discovery, configuration, and protocol-level interoperability. The acronym CARIS is also used in unrelated literature for “Clinical Agentic Research Intelligence System,” a clinical research workflow platform rather than a robot interface system [2604.12258].

Source: https://www.emergentmind.com/topics/context-adaptable-robot-interface-system-caris