I Can Tell What I am Doing: Toward Real-World Natural Language Grounding of Robot Experiences

Authors: zihan  wang
brian  liang
varad  dhat
zander  brumbaugh
nick  walker
ranjay  krishna
maya  cakmak
Venue: robot-learning_org_CoRL_2024_Conference
Published: 2024-06-07 12:22:20

Abstract: Understanding robot behaviors and experiences through natural language is crucial for developing intelligent and transparent robotic systems. Recent advancement in large language models (LLMs) makes it possible to translate complex, multi-modal robotic experiences into coherent, human-readable narratives. However, grounding real-world robot experiences into natural language is challenging due to many reasons, such as multi-modal nature of data, differing sample rates, and data volume. We introduce RONAR, an LLM-based system that generates natural language narrations from robot experiences, aiding in behavior announcement, failure analysis, and human interaction to recover failure. Evaluated across various scenarios, RONAR outperforms state-of-the-art methods and improves failure recovery efficiency. Our contributions include a multi-modal framework for robot experience narration, a comprehensive real-robot dataset, and empirical evidence of RONAR's effectiveness in enhancing user experience in system transparency and failure analysis.

Main paper: 
 introduction: 
 Natural language is important for understanding robots' behaviors and experiences [1] , which is essential for creating more intelligent and transparent robotic systems. Some previous works have attempted to make robotic systems more transparent using language [2, 3] , but these efforts are either limited to specific domains or dependent on task setups. With the rapid progress of large language models, there is a growing body of work in robotics [4, 5, 6] , including planning [7, 8, 9] , decision-making [10, 11] and robot learning [12, 13, 14, 15] . The natural language interface and commonsense reasoning capabilities inherent to large language models (LLMs) make it feasible to ground general real-world robot experiences within the domain of natural language. Providing grounded, real-world robot experiences can greatly enhance system transparency, leading to improved safety and user satisfaction in applications such as assistive feeding, home robotics, and self-driving vehicles.Grounding real-world robot experiences into natural language presents three main challenges [16] . First, robot data is multi-modal, making it difficult to process and integrate. Mobile manipulators produce RGB images from various viewing angles, point clouds, audio recordings and more sensor data. These disparate data formats and semantics complicate the processing and integration of multi-modal inputs. Secondly, robot data has different sample rates, making alignment difficult. Visual data from cameras might be captured at a different frequency than data from force sensors or joint encoders. This discrepancy complicates synchronizing data streams to create a coherent representation of the robot's experience. Lastly, robot data is voluminous, making real-time narration challenging. Processing this data in real-time to produce meaningful and accurate natural language Figure 1 : Left: Our framework for real-world robot narration, RONAR. It takes in four categories of dynamic inputs and one static input: multimodal environmental observations (E), robot internal states (I), task planner (TP), and specified conditions (C), along with robot specifications (SP). RONAR then uses its LLM-based narration engine to process these inputs and generate narrations based on the specified narration mode. The generated narration can be used to address downstream narration-related tasks. Right: The RoboNar dataset. It includes four daily housekeeping tasks with real failure cases, containing ground truth failure explanations and recovery descriptions labeled by human experts. narratives requires substantial computational resources. Additionally, the system must filter and prioritize relevant information to avoid overwhelming the user with unnecessary details.In this paper, we introduce a LLM-based real-world robot narration system, RONAR, which can generate robot narrations based on the experiences and to resolve downstream tasks, including behaviour announcement, risk estimation, failure analysis, and human intervention. We considered users with different use cases and levels of expertise, ranging from no prior experience with robots to expert-level familiarity. These scenarios incorporated different narration modes with diverse narration strategies and abstraction levels. We created a real-robot dataset encompassing four daily housekeeping tasks with domain randomization by using Stretch, a single arm mobile robot. Finally, we conducted experiments involving numerical comparisons and user studies to assess the quality and effectiveness of the narrations. The key contributions of this paper are:• A modular multi-modal framework to ground robot experiences into natural language in the real world using LLMs;• Real home-robot dataset that includes four common home tasks with realistic failure cases across navigation, manipulation, and detection;• Empirical experiments on failure analysis tasks using narrations from both robot system perspective and user perspective which demonstrates that our system outperforms state-ofthe-art methods and can improve users' failure recovery efficiency. 
related works: 
 Robotics and LLMs. LLMs and VLMs can be used in almost every part of robot development [5, 6] .In perception, vision-language model and vision-language-action models have demonstrated they can significantly enhance the generalization capabilities of robots [14, 17, 18, 19, 20] . In decisionmaking, LLMs have been used to make planning and execution more flexible and context-sensitive [7, 21, 22, 23, 24, 25, 26] . In control, language-conditioned policies and transformer-based robot control have been widely studied in recent research [7, 27, 28, 29, 14, 30, 31, 32, 13] . Finally, LLMs can significantly improve both robot-environment and robot-human interactions [33, 34] . In this work, we focus on using LLMs to enable natural language grounding of robot experiences and applying the grounded experiences to resolve downstream real-world robot tasks.Scene and Action Understanding for Robots. Scene understanding involves recognizing objects, their relationships, and the context within a scene, while action understanding requires interpreting the robot's actions, understanding the outcomes, and planning future actions accordingly. Although dense video captioning and scene-graph generation have been extensively studied in computer vision [35, 36, 37, 38, 39, 40] , these models cannot be directly transferred to robots due to distribution mismatches. With the rise of embodied AI and LLMs, new approaches for scene representation and understanding in robots have emerged [11, 41, 42, 43, 44, 45, 46] . Scene and action understanding must work together to solve robotic tasks, such as failure explanation [26, 47, 48, 49, 50, 51] , affordance estimation [7, 52] , and task execution [53, 54, 55, 56, 57] . We introduce a framework to ground robot experiences with both scene and action understanding. Unlike previous work [26] , our framework includes both low-level control and high-level planning actions.Robot Transparency. Transparency, the ability to see into a robot's behavior, can help users accept, collaborate with, or debug a robot [58, 59] . Many channels for providing transparency, like gaze or expressive motion, are only appropriate for exposing limited amounts of information [60] , and richer alternatives like displays or projections often require additional hardware [61, 62] . Language is a naturalistic means of providing information about a robot's behavior which requires only a speaker or a display, but previous approaches have been constrained to engineered templates, often in conjunction with symbolic models of the behavior [63] . Our framework does not require any engineered templates or symbolic models, which makes it more generalizable and easy to use.  
multimodal key event selection: 
 When executing robot processes, massive amounts of data are streamed at persistent rates across different sensors on the robot, which can create data that is too repetitive and dense to be interpretable for users. Furthermore, the sampling rates of different robot sensors can vary significantly, creating difficulties in aligning information to be processed together. These challenges necessitate procedures for aligning and sampling valuable information from robots. We call these results key events, which are sampled from the raw robot data and used to generate experience summaries in Section 3.2 and narrations in Section 3.3.Multi-Sensory Data Alignment. We split robotic data into three categories: Environment (E), Internal (I) and Task Planning (TP). We sample and align these dense, mixed data by dividing the duration of the data by a single sample rate s for a sequence of frames f 0 , f 1 , . . . , f n , such that frame f i and f i+1 are separated by time s. In each frame, we add the robot information across each considered medium, using the information with the timestamp closest to the frame timestamp. The result of this procedure is a sequence of frames separated by a fixed interval that captures information across robot sensors that may have mixed, high-frequency sampling rates.Key Event Selection with Multimodal Inputs. Key events are selected from the aligned data by heuristically monitoring for interesting information across the different data categories. For environmental data, we compute the optical flow of the RGB images to capture the motion dynamics within the scene, using the running sum of average flow magnitudes as a heuristic for computing changes in perception information sufficient for a key event. For the internal state of the robot, the joint states are used as a heuristic for observing changes in robot motion sufficient for a key event.Observing that changes in both flow magnitudes and joint states are significantly different for when the robot is moving its base, moving its camera, and all other movements, we normalize each of these values to have a mean of zero and standard deviation of one, and track the running positive sum of the normalized values. Once the running sum reaches a set threshold, we note that there should be a key event. We also add a key event each time there is a state change in the task planner, with the reasoning that state transitions are indications of notable events. Details can be found in Appendix.With selected key events, the next step is to ground raw robotic data into experience summaries in natural language. Based on the categories of the robot data, the experience summary is also composed of three components: environment summary, internal summary, and planning summary.Environment Summary. The goal of an environment summary is to ground the observations from the robot into natural language. We use YOLO World [64] to conduct open-world object segmentation of the corresponding RGB images. The detected objects are represented by a bounding box coordinate and unique object id, forming an detected object set, O det . Since the real environment is complex, the observation of a scene can be complicated with excessive number of objects in it. Our system leverages depth information to filter out irrelevant objects based on certain distance criteria, c d . The remaining objects forms an object set for the scene,EQUATIONwhere d os is the distance between object o s and the the robot. We have a spatial relation set for the objects, which is defined as P s = {left to, right to, above, below, in front of, behind}. The scene graph is a set of object, relation and distance triplets, R s ⊆ O s × P s × D s .Internal Summary. The goal of the internal summary is to ground numerical values of part states (e.g. base states, joint states, etc.) to natural language based on the configuration of the robot. Each part of the robot in the configuration has three components: part description, part limit and part type. The robot's configuration is specified as part of the system prompt for the internal summary generation. The system prompt also specified that the internal summary should contain exact names and numerical values of the part states. The final internal summary contains a list of robot parts with exact part names, a detailed description with numerical values, and a grounded explanation that people without robot experiences can understand (see a detailed example in the Appendix).Planning Summary. It is hard to infer and narrate the expected outcomes for every one of the low-level actions contained in the internal summary. Therefore, a planning summary is generated to capture the plan-level status. It summarizes the high-level plan of task execution. It contains the overall task with description, the sequential order of sub-goals, the current sub-goal and a history of sub-goal executions and outcomes (see a detailed example in Appendix). Unlike other methods only using the current sub-goal in their planning summary, one critical change is we also include a history of sub-goal executions and outcomes. It would help identify the correlations between failures across sub-tasks and enable narration and failure analysis for long-horizon tasks.The experience summaries ground environmental observations, internal status and task planning of a robot during task execution into detailed natural language. However, not all of the details are useful for humans to understand and react to the robot. We need to abstract the information and only narrate things users care about.Narration Mode. The requirements for narrations can vary significantly depending on the robot's use cases and the user's level of expertise. To meet general narration needs, we have defined three narration modes: 1) Alert Mode narrates only the important information which requires the user's attention; 2) Info Mode narrates robot experiences in multiple sentences and provide a concise summary of the robot's observations, internal status and planning without any numerical values and part names; and 3) Debug Mode incorporates all details of environmental observations, robot internal status and the robot's planning, including numerical values and attribute names. Users can specify the mode of narration as needed and the mode is as an input parameter to the LLMs and controls the properties of generated narrations.Progressive Narration Generation. We consider a generated narration to be good if it has the properties of non-repetition and being smooth. Non-repetition means the narration should not repetitively narrate behaviors which has already been narrated to the user. Being smooth means the transition between narrations should be natural and seamless. We use progressive generation to achive these properties. As shown in Figure 2 , consider a robot narration history which contains all the narration instances until key event t -1, N t-1 = {n 0 , n 1 , ..., n t-1 }. There is a new key event, k t , has been detected and a experience summary, s t has been generated. We input both N t-1 and s t with a specified mode m to an LLM to generate the narration, n t , at time t, where n t = LLM (N t-1 , s t |m).Then, we add the narration n t to the narration history. The most recent generated narration n t will be shown to user in our user interface. 4 Experiments and Results 
experiment setup: 
 RoboNar Dataset. We collect a real-world dataset using a Stretch SE3 robot in a home environment [65] . The details of the home setup can be found in Appendix. We created four real-world housekeeping tasks: pick a dirty cup and put it in the sink, microwave lunch, hang a hat, and collect dirty clothes. We collected data, including RGB-D observations captured by two cameras, an Intel RealSense d435i and d405, joint readings, base readings, state information, and diagnostics. We also save the processed data, which includes downsampled aligned keyframes. For each demonstration, human experts create ground truth labels for failure timestamps, failure reasons, and recovery instructions. The dataset contains 70 demonstrations and 76 failure cases across navigation, manipulation, and detection. Figure 4 shows a detailed task and failure composition of the dataset. The cup held by the ro-bot hits a chair while navigating, dislodging the cup from the gripper and dropping it on the floor.Teleoperate the robot to moving backward carefully to prevent dropping the cup on the floor and retracting the arm to allow enough space between the robot and the chair and start the navigation again.Failure Time: 0.54 Failure Reason:The robot successfully detected the white shirt, but it classify it as a clean cloth due to an issue with CLIP.Teleoperate the robot to slightly move backward and rotate the base to move in the direction of the white shirt around 15cm and then start the detection module again to redo cloth detection. 1 : Average frame counts and failure capture rate by using different thresholds and modalities Failure Analysis with Experience Summaries. We systematically evaluate the capability of experience summaries generated by RONAR on failure analysis. We decompose the failulre analysis into four specific tasks: 1) Risk Estimation (Pred): if the method can identify risk before failure happens; 2) Failure Localization (Loc): if the method can identify the failure time ; 3) Failure Explanation (Exp): if the method can tell the failure reason; and 4) Recovery Recommendation (Rec): if the method can give reasonable recovery recommendations.We compare our method with the following baseline methods and ablations (GPT-4o is used as LLM and VLM for all the methods): BLIP2, REFLECT, TEM-LLM (all raw sensory data directly input to LLM), TEM-VLM (all raw sensory data directly input to VLM), RONAR-vision (our method uses visual inputs only), RONAR-no prior (our method without experience history, as detailed in the Appendix). Results are shown in Figure 5 . User Study Setup. We conducted a user study to evaluate our narration generation method and interface, both qualitatively and quantitatively. The user study consisted of two sections: narration quality evaluation and failure identification using narration. We recruited 24 participants for the user studies. Prior to each section, we provided a tutorial to familiarize the participants with the tasks. At the conclusion of the user study, we administered a questionnaire to gather information about the participants' demographics and their background in robotics.Narration Quality Evaluation (User Study 1). Participants rated the generated narrations on naturalness, informativeness, coherence, and overall quality using a 1-5 Likert scale. The evaluation criteria for informativeness and coherence follow common practices for human evaluation of natural language generation [66] . The study commenced with an introduction to the evaluation metrics, ensuring participants fully comprehended the assessment criteria. Subsequently, participants engaged in a rating practice session involving two sample image-narration pairs to verify their understanding. Following this preparation, each participant was presented with a sequence of narrations generated by five methods, accompanied by three image-narration pairs. The results are shown in Table 2 .Naturalness Failure Identification by Human with Narration (User Study 2). We selected four failure cases in different states (two in navigation, one in manipulation, and one in detection) from the putting cup in sink task from our RoboNar dataset. We prepared four interfaces for the participants: video interface, video and sensory information interface, keyframe interface (RONAR-UI without narration), and RONAR-UI. Participants were given a full demonstration of a failure displayed on each interface. We asked participants to type their answers for the time of failure occurrence and failure explanation for each failure demonstration (see details in the Appendix). We timed participants as they answered each question using the interface. The results are shown in Figure 6 .RONAR can do effective failure analysis. Our method outperforms baselines on almost all failurerelated tasks, as shown in Figure 5 . With a similar performance on failure localization, it achieved around 11% gain on both risk estimation and failure explanation compared with REFLECT on the Intermediate summarization enhances failure explanation. As shown in Figure 5 , our method has a 11% and 29% failure explanation improvements compared with the TEM-LLM method and TEM-VLM method. This result demonstrates that the LLM and VLM struggle with raw robot data from multiple sensors, whereas summarizing individual data into text first, followed by a second summarization, yields better results.Internal and planning data are crucial for failure analysis. We compared variations of our methods in Figure 5 . RONAR performs 50% better on failure localization and 19% better on failure explanation compared with the RONAR with vision only, showing that, in real-world scenarios, vision alone is insufficient for comprehensive failure analysis. Integrating internal and planning information enhances the accuracy of the analysis.RONAR can generate high-quality narrations. In Table 2 , we study the quality of the narrations on different metrics. For Naturalness, our method outperforms BLIP2, REFECLT, and TEM (VLM) with a slight improvement (0.25) on TEM (LLM). For Informativeness, all LLM-based methods have a similar performance with a big discrepancy compared with other methods. Our method has the highest overall rating, outperforming the second-place method with 0.37.Narration improves users' accuracy and efficiency in failure analysis. In Figure 6 , our interface outperforms other interfaces in both accuracy and efficiency in assisting users in localizing and explaining the failures. One interesting finding is that a raw data interface with all sensory inputs does not help users achieve better failure localization and explanation accuracy than a raw video interface. With similar accuracy, our method significantly reduces the time used for failure analysis compared with the raw video interface.Limitations. Even with a good performance on failure analysis, some failure cases can be easily identified by humans (see Appendix). Another limitation is the latency and cost of the method. In our method, we use two-step summarization using LLM to generate narrations. This makes the system slow and affects the user experience on real robot systems. Lastly, our experiment is limited to a single mobile robot within a single environment. More types of robots and environments can be studied to the generalizability of the framework. 
conclusion: 
 We introduce a novel framework, RONAR, which summarizes many types of diverse, raw robotic data to form an experience summary and to generate natural language narrations. The narrations can be used for improve the robot transparency and enhance failure analysis accuracy and efficiency for both robotic system and human interaction. We create a dataset for various home tasks with real failure cases and human expert labels. 
 
 Appendix: We automated four mobile manipulation tasks in a home environment: putting a cup in the sink, microwaving food, hanging a hat, and collecting dirty clothes. The implemented tasks made up of autonomous navigation, perception, and manipulation actions. We navigate to specified positions and orientations using SLAM implemented in Stretch Nav2, detect and localize specified objects by either running ArUco marker detection or YOLO-World object detection with FastSAM segmentation, and perform manipulation using inverse kinematics with demonstrated poses. The task-specific descriptions and implementations are described below:• Put Cup in Sink: The task is performed in a connected kitchen and lounge environment with a dirty cup in the lounge and a sink in the kitchen. The specific sequence of states executed by the robot is as follows: the robot navigates to a table, looks for a cup, picks up a cup from the table, navigates to the sink, looks for the sink, then places it in a sink.• Microwave Food: The task is performed in a kitchen environment with a microwave and food near the microwave. The specific sequence of states executed by the robot is as follows: the robot navigates to the microwave, looks for the microwave, opens the microwave door, navigates to the food, looks for the food, picks up the food, navigates to the microwave, looks for the microwave, places the food inside the microwave, then closes the microwave door.• Hang Hat: The task is performed in a lounge environment with a human wearing a hat and a hook. The specific sequence of states executed by the robot is as follows: the robot navigates to the human, is handed a hat from the human, navigates to the hook, looks for the hook, then hangs the hat on the hook.• Collect Dirty Clothes: The task is performed in a lounge environment with a laundry basket and clothes arranged around the room. The specific sequence of states executed by the robot is as follows: the robot navigates to the clothes, looks around for clothes, classifies dirty clothes, picks up dirty clothes, navigates to the laundry basket, looks for the laundry basket, then places the clothes in the laundry basket.Figure 7 : The robot detects and localizes the cup using YOLO-World and segments the result with FastSAM on a frame captured from its head camera for perception.We represent sequences of actions that accomplish a subgoal of a task as a state, and manage transitions between states using state machines. To simplify the development process, we create configurable templates to synthesize state machine code from a list of linear states. In each implemented task, we add in additional query user and teleoperation states on top of each existing action state. This allows us to manage the state of the robot after the robot experiences failures and teleoperate the robot to recover from failures.A. 3 : List of autonomous tasks implemented on the Stretch mobile manipulator, along with the number of trials and failure counts separated by failure type collected for the dataset.Tasks are run across different trials. Throughout each trial, whenever the robot encounters an incident that prevents the robot from completing its task, a failure is marked. If the failure is recoverable, a human will teleoperate the robot to resolve the failure. Otherwise, the task is aborted and marked accordingly. Room arrangements are changed to inject failures into trials. Each trial can have from zero to three failures. The tasks and failure counts are shown in Table 3 .The data is collected as a rosbag that has RGB-D, joint, odometry, state information, and more beginning at the start of the task and ending after the task is complete. The full list of collected topics and topic descriptions are provided in 4. This section introduces the implementation details about the framework which is not demonstrated in the main paper due to page limit.We define a key event as the event which contains important and critical information on robot observations and robot status during task execution. These events are selected across all the modalities of the robot. Since key events can have different definitions depending on the modalities, based on the properties of the data, we categorize robot data into three categories: Environment (E), Internal (I) and Task Planning (TP):• Environment (E): Sensory data used to observe the external world, such as RGB images, point clouds, audio, tactile feedback, etc.• Internal (I): Sensory data related to the internal state of the robot, including internal sensors, joint angles, base velocity, battery levels, and other diagnostic information.• Task Planning (TP): High-level planning data that contains overall task objectives, subtask sequences, execution history, and plan outcomes.These categorizations can group the robot data in a structured way and make key event selection across modalities easier. Then, we represent each aligned multimodal frame with the following parameters across different data categories:• Optical Flow (E): the optical flows generated from the RGB images collected by the robot head camera. Since the optical flow vary largely at different stages of task operation, we define average flow magnitudes on different part movements of the robot. It has the following parameters:λ pos : Average flow magnitude for frames with base positional movements.λ rot : Average flow magnitude for frames with base rotational movements.λ cam : Average flow magnitude for frames with camera movements.λ arm : Average flow magnitude for frames with arm positional movements.• Joint State (I): the internal joint state readings from the robot which reflects the robot internal status. It has following parameters:x pos : Change in meters of the position of the robot from the odometry reading.x rot : Change in radians of the orientation of the robot from the odometry reading.x cam : Change in radians of the pan and tilt of the robot's head camera.x arm : Change in meters of the robot's arm.• Planner State (TP): the planning-level state information of the robot during the task execution. It has following parameter:s: The robot's current state.For key event selection, we first calculate the mean and standard deviation of each parameter in optical flow and joint state across each task. Then, for each multimodal frame, we normalize each of these parameter values by the mean and standard deviation of the specified task. We only take multimodal frames with normalized values above 0 as the candidates of key events. The normalization on environment and internal parameters ensures values across different modalities are weighted equally, and that only values that are higher than the average frame value will be considered for contributions to the set threshold and further to become a key event. These values are accumulated along with the task execution and a set threshold is set for the cumulative sum. Additional to optical flow and joint state, planner state is used separately for key event selection. As in task planner, the most important events are the beginning and finishing of each planner state, and therefore, these events should be also considered as key events. In summary, when either the cumulative sum of values reaches the set threshold or the planner state changes, the multimodal frame is labeled as key event. For our data, we aligned frames with a sample rate of 0.2 and set our key event threshold to 80. The key event selection can be modeled as a binary classifier, C key , which runs across all the multimodal frames in a given task and outputs a binary prediction, 0 (not a key event) or 1 (a key event). It can be represented as following:C key (f i ) =                1, i k=c   a∈{pos, rot, cam, arm} (N (λ a k ) + N (x a k ))   > threshold,where c = index of last key event 1,EQUATIONwhere f i is the multimodal frame at timestamp i.After selecting the key event, one additional step in our framework is to select the best quality RGB image adjacent to the key event. During the experiments, we found that there is a big impact on the clarity of the image for object detection, especially during navigation. Therefore, in order to improve the detection accuracy and further enhance the overall system, we define a clarity score on the RGB images and conduct an adjacent image selection. The clarity score is defined by the variance of the Laplacian of the image. The 2-D Laplacian operator is defined as: EQUATIONRONAR can generate multimodal experience summaries and progressive narrations in various modes. To demonstrate the effectiveness of these generated natural language groundings, we have designed several experiments. Our goal is to show that RONAR can significantly benefit two main areas:• Robot System: RONAR can enhance the capability of robot systems in failure analysis.• Human Interaction: RONAR can improve the interaction experience between humans and robots. Additionally, RONAR can enhance the effectiveness and efficiency of failure identification by human users.To demonstrate the effectiveness of multimodal key frame selection, we conducted an experiment on varying modality and threshold for the key frame selection, which is shown in C.1. To demonstrate RONAR's ability to improve robot systems, we have designed an experiment focused on failure analysis using generated experience summaries, detailed in C.2. To evaluate the quality, effectiveness, and efficiency of the narrations, we have designed two user studies, described in C.3. In C.3.2, we provide details on the user study evaluating narration quality. In C.3.3, we introduce the user study focused on users' effectiveness and efficiency in identifying failures using the narrations.The first experiment we conducted is to test the effectiveness of multimodal key event selection. The goal of key event selection is to downsample the number of frames used for narration meanwhile maintaining the information richness of the content to narrate. In order to have a fair comparison, we chose failure identification as our task and used the actual failure times in the RoboNar dataset as the ground truth for key events. We designed an additional experiment to examine the relationship between the heuristic threshold, the combination of heuristics (modalities), and the failure capture rate. The results are presented in the table below. As shown, there is a tradeoff between the heuristic threshold and the failure capture rate. As the threshold increases, fewer frames are sampled, which raises the probability of missing the failure frame. The selected modality also significantly impacts key event selection performance. When all modalities are enabled, fewer frames are captured, but the failure capture rate remains similar to using a lower heuristic threshold with either optical flow or joint data alone. Another interesting finding is that even with a single modality and a lower heuristic threshold (e.g. 5), achieving a high failure capture rate is still much more sample-efficient than not using key event selection at all (captured 74.5% failures with 25% of frames).In order to make intellegent robots, it is crucial to have reliable and efficient methods for identifying and analyzing failures. In this experiment, we aim to demonstrate that RONAR's generated experience summaries can significantly enhance the failure analysis capabilities of robot systems. To ensure a comprehensive analysis, we break down the failure analysis problem into four sub-tasks:• Risk Estimation / Failure Prediction (Pred): Given previous key events, the percentage of predicted failures that are actual failures in the actual failure key event.• Failure Localization (Loc): Given all key events, the percentage of predicted failure times that align with the ground truth failure times.• Failure Explanation (Exp): Given previous key events and the current key event (when the failure happened), the percentage of generated failure explanations that align with the ground truth failure explanation.• Recovery Recommendation (Rec): Given previous key events and the current key event (when the failure happened), the percentage of recovery recommendations that align with the ground truth recovery recommendation.These sub-tasks cover most scenarios that robot systems encounter during operations. The methods used for comparison are:• BLIP2: Uses BLIP2 to generate a caption for the RGB image of the key event.• REFLECT: The current state-of-the-art LLM-based failure explanation framework.• TEM-LLM: Sends all raw sensory and planning data directly to the LLM for failure analysis.• TEM-VLM: Sends all raw sensory and planning data directly to the VLM for failure analysis. We use GPT-4o as the VLM.• RONAR-vision only: Our method without internal and planning inputs.• RONAR-no prior: Our method that only uses current key events for failure analysis.Baseline methods that require an LLM use GPT-4o as the backbone. For REFLECT, we use the general pipeline of the method but do not include the audio modality since the original robot lacks a microphone, which might affect the method's performance on some tasks. The results are evaluated by human experts based on the reasonableness and deviation from the ground truth labels.Baseline Selection Methodology: We selected BLIP2 and REFLECT as baselines because they represent state-of-the-art approaches in vision-language models (VLMs) and failure explanation frameworks, which are directly relevant to our task of robot experience summarization and narration. BLIP2, a strong VLM, was chosen for its ability to generate captions from visual data, allowing us to compare its performance against our multimodal summaries. REFLECT, designed for failure explanation in robotic systems, serves as a benchmark for how well our system explains failures. Additionally, we included LLM-TEM and VLM-TEM to establish baseline capabilities for summarizing raw robotic data using large language models, highlighting the improvements our method offers through key event selection and progressive narration. RONAR-Vision Only isolates the performance of our system using only visual data, demonstrating the necessity of multimodal integration. Finally, RONAR-No Prior was selected to assess the impact of progressive narration generation, illustrating the benefits of using prior narrations for more coherent summaries. on general robots shows a relatively even spread of expertise levels, with a notable concentration at both the novice and intermediate levels, reflecting a varied participant pool in terms of general robotics knowledge.The study of narration quality evaluation has two parts: a tutorial and a formal evaluation. Before the start of the tutorial, we introduce the four metrics the participants give ratings on:• Naturalness: Does the narration feel natural and human-like? (1-5)• Informativeness: Does the narration provide useful information about the robot's behavior? (1-5)• Coherence: Does the narration organize information logically and clearly? (1-5)• Overall: What is your overall assessment of the narration's quality? (1-5)It uses 1 to 5 Likert Scale to measure the preferences from the participants on the metrics. We confirm and explain the metrics until the participants fully understand the task and the terminologies.Then, the participants are given a short tutorial on two samples of the image-narration pairs to get familiar with the format and questions. They can ask any related questions during the tutorial. After the tutorial, it goes to the formal evaluation of the narrations generated by different methods. In the formal evaluation, we select three frames from three tasks in the dataset: put cup in sink, microwave lunch and hang hat. There are 5 methods evaluated by the participants: BLIP2, REFECLET, TEM- LLM, TEM-VLM and RONAR. We pair the three selected frames with the corresponding narrations generated by different methods. In order to prevent biases from the orders of methods, for each participant, we generate a random order of methods and all the names of the methods are hidden.After the participants saw all three image-narration pairs, they can give scores on the four metrics for the corresponding method. Since the order is very critical and users might change their mind by seeing the following narrations, we allow the users to go back and change their ratings by seeing the new narrations.The second user study is to evaluate the effectiveness and efficiency of narrations on failure identification. The key question we want to answer is how effective and efficient the narration can help users to identify the failures. We design two tasks for the failure identification problem:• Failure time identification: How accurate and efficient can participant correctly identify the time of failure in a demo?• Failure explanation: How accurate and efficient can participant have a reasonable explanation about the failure?In this study, we design four interfaces which the users will be used to identify the failure time and failure reason. The four failure identifications interfaces are:• RAW-VID: a traditional video player interface which only shows the raw video captured by the robot camera.• RAW-ALL: a video player interface which displays the raw video and all raw sensor readings (both joint and base) from the robot. The sensor readings are visualized by line plots and synchronized with the raw video.• KEYFRAME: the RONAR-UI interface without narration. It includes the raw video, selected keyframes, and state information.• RONAR-UI: the RONAR-UI interface with fully functionalities. It includes both narrations with alert mode and info mode generated RONAR.The appearances of all interfaces can be found in Figure 12 . The effectiveness and efficiency are measured by accuracy and time spent on each of the task. For failure time identification, we have the ground truth failure time and set a time tolerance for each of the demonstrations. If the participant gives an estimated time within the time tolerance, it is marked as correct. Otherwise, it is marked as incorrect. For failure explanation, we ask the participants to write 1-2 sentences to explain the failure in each of the demonstration. Then, three robot experts evaluate the users' answer based on reasonableness independently. The accuracy on failure explanation is the average of rate of correctness marked by the experts. For measuring efficiency, we record the time which participants used to fulfill each task. This time is measured by an expert supervisor with a stopwatch beside the participant. For failure time identification, the start time is when the user click the play button of the video and the finish time is when the user finish typing and click next button. For failure explanation, the start time is when the user saw the ground truth failure time and the finish time is when the user finish typing and click next.This study is also consist of two parts: an introductory tutorial and a thorough evaluation of interfaces. In the tutorial, we prepare examples of each interface for users to interact with. We give enough time for them until they are familiar with all the interfaces and comfortable to continue for the actual evaluation. For the formal evaluation, we select four demonstrations from the task, put cup in sink, with failures in different states and we make sure that each demonstration only contains one failure. These are the failures for the formal evaluation. In order to prevent the biases from the demo-interface pairs, we make a full set of permutations of the four demos and four interfaces, which results 24 permutations. We assign each different permutation to different participants, which covers exact 24 participants.Task: Pick and place the cup in the sink: Description: The robot should navigate to the table with dirty cup on it, pick up the cup, find the sink, navigate to the sink and place the cup in the sink.Step 1: Begin operation from the START state.Step 2: Navigate to the location of the cup.Step 3: Execute pick operation to grab the cup.Step 4: Navigate to the location of the sink.Step 5: Detect the precise position to place the cup.Step 6: Place the cup in the sink.Step We have shown narration examples generated by RONAR with different modes in the main paper. In this section, we want to show some interesting cases the narration can help users to identify the status of the robot and failures the robot is experiencing.The robot is navigating to the sink with its arm slightly extended, moving forward quickly while turning right, but there's a risk of not detecting the sink or encountering navigation obstructions that need to be monitored closely.The extended robot arm collides with a chair during navigation.The robot continues actively scanning for the cup, carefully aligning its sensors to ensure accurate detection. Despite the initial failure to detect the cup, it is now prepared to query the user for assistance. Maintaining a stable posture with its arm and wrist slightly extended, the robot aims to successfully identify the cup for subsequent pickup.The cup is occluded by other objects and the robot fails to detect it. As shown in Figure 13 , the left example shows an interesting failure case which cannot be identified by the vision system alone. In the left example, the robot arm is extended and the arm hits a chair which impedes the movement of the robot. As shown in the frame, users cannot identify what the failures the robot is current facing. During the user study, most participants reason the failure is caused by the robot cannot successfully find and locate the sink, which is due to the detection and mapping errors. The RONAR narration successfully captures the robot arm status ("its arm slightly extended") and the movement of the robot ("moving quickly while turning right"). As well, it notifies the users of the potential risks which could cause failures. It successfully identifies the risks of navigation obstruction during the task execution without direct visual information.In the right example, the robot fails to detect the cup with the first attempt. From the visual inputs, it is hard to identify what the robot is doing. Most users consider the robot is navigating to the sink even by watching the video. The narration generated by RONAR successfully captures the past experiences of the robot and explains clearly what the robot is currently doing. In summary, demonstrated by the user studies, it shows significant improvements for users on understanding robot behaviors by using the narrations generated by RONAR. Furthermore, a comparison of narrations generated by different baseline methods and our method can been seen in Figure 14 . In this example, BLIP provides a very general description, lacking any specific reference to the robot's actions or the challenges it faces. REFLECT offers more detail than BLIP but focuses heavily on the static description of objects and the robot's position, without much insight into the robot's task progress or the difficulties encountered. LLM-TEM provides a sequential summary of actions but lacks depth in describing the current status of the task and the specifics of the failure. Similar to LLM-TEM, VLM-TEM offers a basic description of the robot's actions but does not effectively convey the ongoing challenges or next steps. RONAR provides a comprehensive, real-time narrative of the robot's current state, the specific issue it is encountering, and the intended corrective action. This level of detail allows users to understand both the problem and the proposed solution, making RONAR's output significantly more actionable and informative. This example provided demonstrate that RONAR excels in offering detailed, contextually rich, and actionable narratives compared to the baselines. RONAR not only describes what the robot is doing but also offers insight into challenges and next steps, which are crucial for effective monitoring and intervention. This depth of analysis and real-time relevance is why RONAR consistently outperforms the baseline models. The use of narrations uss not only limited to failure analysis and transparency. There could be much more applications and extensions. We study some of the extensions and welcome for more follow-up research on related studies.The robot began its task of picking and placing a cup in the sink at 0:00, initially assessing an environment cluttered with obstacles such as stools and chairs. After finalizing its initial assessment by 0:02, it navigated towards the cup on the table, carefully maneuvering around furniture. By 0:13, upon reaching the table, the robot transitioned to a state where it scanned for the cup before successfully identifying and picking it up. After identifying the cup by 0:23, the robot transitioned to pick up the cup, secure the cup and prepare to move towards the sink. Next, the robot navigated towards the sink, moving cautiously while continually adjusting for minor obstacles and ensuring the cup remained secure by 0:43. Despite successful navigation, the robot initially failed to correctly place the cup into the sink by 1:45, prompting user intervention. Following user guidance, the robot retried and successfully maneuvered into position for precise placement. By 2:21, the robot's careful adjustments in arm and wrist movements aimed to ensure the cup was accurately positioned before final release. The task finished with the robot successfully placing the cup into the sink.The narration generated by RONAR is event-level, meaning each narration corresponds to a single key event. It captures a snapshot of the process but cannot provide an overview of the entire demonstration. To address this, we create a higher-level summarization, called trajectory summarization, generated by LLMs using the narration history. This summarization captures the details of the trajectory in a human-readable way.Trajectory summarization enables the question-and-answer capability of robot trajectories and creates richer ways of interacting with robot data. One potential use of trajectory summarization is for customized trajectory retrieval. As shown in Figure 16 , for a collection of robot demonstrations, RONAR can generate a corresponding trajectory summary for each trajectory. These summaries can then be used for trajectory retrieval purposes. Users can search for and retrieve trajectories with customized queries. These queried trajectories can be used for model training in various types of learning algorithms, such as imitation learning. This approach makes robot data search and retrieval much more efficient and accessible. The robot began its task of picking and placing a cup in the sink at 0:00, initially assessing an environment cluttered with obstacles such as stools and chairs. After finalizing its initial assessment by 0:02, it navigated towards the cup on the table, carefully maneuvering around furniture…The robot began the task of picking and placing a cup in the sink, initiating with a START state where it assessed initial conditions and faced various obstacles like stools and chairs at 0:00. It success-fully transitioned to NAVIGATE_TO_CUP, carefully navigating through tight spaces, …The robot begins the task of picking and placing a cup in the sink at 0:00, assessing the environment filled with obstacles like stools and chairs. At 0:08, The robot transitions to the NAVIGATE_TO_CUP state, carefully planning its movements to avoid nearby furniture while navigating towards the table … Trajectory 3Give me the trajectories failed both pick up the cup and place the cup.Give me the trajectories finished the task within 2mins.Give me the trajectories completed to pick up the cup in 45s but failed to navigate to sink by hitting a chair. Figure 16 : A pipeline for customized trajectory retrieval. For each demonstration, RONAR can generate trajectory-level summarization by using event-level narrations. This summarization contains the detailed information of the trajectory and users can retrieve trajectories with customized queries. These customized trajectories can be used for further downstream tasks, such as model training and system analysis.Not limited to trajectory-level summaries, RONAR can generate summaries in an even higher-level. With a collection of trajectory summaries, RONAR can generate a system-level summary to give users an overview of the robot system. As shown in Figure 17 , users can generate robot system overview by using a collection of trajecory summaries and RONAR. The system overview is customizable based on users' requirements. In this example, we ask RONAR to generate system overview on failures, recoveries and improvement recommendations based on the experiments. The system overview can give users a big picture of the overall system and assist to make improvements. As well, users can also compare system overviews between different experiment dates to keep track of the system improvement progress.Date: Jun 6 th , 2024The robot begins the task of picking and placing a cup in the sink at 0:00, assessing the environment filled with obstacles like stools and chairs. At 0:08, The robot transitions to the NAVIGATE_TO_CUP state, carefully planning its movements to avoid nearby furniture while navigating towards the table … The robot began the task of picking and placing a cup in the sink, initiating with a START state where it assessed initial conditions and faced various obstacles like stools and chairs at 0:00. It success-fully transitioned to NAVIGATE_TO_CUP, carefully navigating through tight spaces, … Failure Summary: 1.Navigation Failure (3 occurrence): Common reasons: An unexpected force on the ground detected by the robot's wheels, possibly due to an obstacle or unusual floor condition. This issue occurred in an office environment cluttered with objects like stools, tables, and storage shelves, which complicated the navigation.Common reasons: The robot's inability to detect a bottle with an AR marker despite having functioning navigation and detection systems. This indicates challenges in adapting current detection algorithm to complex, real-world environments where variables can significantly differ from those in controlled settings.The robot began its task of picking and placing a cup in the sink at 0:00, initially assessing an environment cluttered with obstacles such as stools and chairs.After finalizing its initial assessment by 0:02, it navigated towards the cup on the table, carefully maneuvering around furniture… Recovery Summary:•Navigation Failure:• Most common recovery method: Employing teleoperation to bypass the navigational error, allowing the robot to maneuver past the detected obstacle under direct user control. •Detection Failure:• Most common recovery method: Human intervention to adjust the bottle's position, making it more detectable for the robot.1.Enhance obstacle detection and floor condition analysis to prevent similar navigational errors in the future. 2.Implement more robust recovery protocols that allow the robot to autonomously navigate around unexpected obstacles without necessitating human intervention.Figure 17 : System overview generated by RONAR 


Decision: This paper addresses an interesting problem of describing the robot experience in natural language derived from low-level percepts. The paper provides a mechanism to narrate behaviors, failures and human interaction to recover from failures. Reviewers have suggested a better exposition of heuristic-design and insights into why this approach improves over the baselines. The authors provided a detailed response during the rebuttal phase. In particular, additional results on heuristic thresholds vs. failure capture rate, UI details, key event selection and further discussion on effects of modality failures and mistakes on narration generation. The reviewers are in consensus for a weak accept for this paper.

Reviews: review: title: title: Evaluation of key event selection and narration quality
paper_summary: paper_summary: This paper presents a LLM-based robot narration generation framework RONAR. User study evaluation demonstrated RONAR's benefits in supporting end users to understand robot failures.
main_review: main_review: Post-rebuttal comments

I would like to thank the authors for their detailed rebuttal, which clarified the design decisions of the key event selection, UI, and evaluation.

---

The proposed RONAR framework contributes to human-robot interaction by increasing the transparency of robots to users with natural language key event narration. The three modes of information abstraction (alert, info, debug) potentially allow diverse users to customise the presented narration based on their robot expertise and interaction goal. The effectiveness of the proposed framework was evaluated using empirical experiments with different task scenarios and failure cases.

This work can be further improved by clarifying the design of heuristics-based key event identification and extending the evaluation, as detailed below.

1. Key event selection

As discussed in Sections 3.1 and B.1, key events were selected when either the sum of optical flow and joint state heuristics surpassed a pre-defined threshold, or when there was a state change in the task planner. It would be interesting to understand the alignment between key events selected by each of these three heuristics (optical flow, robot motion, state change), the unions of each pair and all three, the intersections between each pair and all three, and a groundtruth annotation of key events. As the narration is generated from these selected key events, the accuracy and completeness of key event selection will influence the quality of the resulting narration and the failure analysis based on it.

2. Evaluation of narration quality

As described in Sections 4.1 and C.2.2, a custom questionnaire was used to evaluate the naturalness, informativeness, coherence, and overall quality of the generated narration. Since the goal of the narration is to increase a user's understanding of the robot, especially on failure analysis, this narration may be considered an explanation. Thus, existing questionnaires in the XAI literature for evaluating the quality of explanations may be applicable here to extend the measure on narration quality. 

In the user study evaluation, participants were given image-narration pairs to aid their failure analysis. Both alert and info mode narrations were provided in the RONAR-UI, which matched the participant population being largely novice or having intermediate expertise. However, presenting both narrations may provide overloaded information. It may be interesting to allow participants to select from the three modes (alert, info, debug) and analyse the frequency of each mode being used by participants with different expertise level. Further, the choice of which narration mode to use may also relate to the task context, such as the concise alert mode being preferred for risk estimation or time-critical failure recovery, while the info and debug mode being preferred for in-depth analysis of past failures or developing new failure prevention mechanisms.

Regarding failure identification using narration, as described in Section C.2.3, the failure analysis time was measured by an observer with a stopwatch and the finish time was defined as when a user finished typing their answer to failure time and cause. It may be more accurate to measure this time automatically using button / keyboard events captured in the UI, and to set the finish time as when the user started typing their answer to not disadvantage long answers.
questions: questions: - The project website (https://sites.google.com/view/real-world-robot-narration/home) appears to be offline
- Please clarify performance of the multimodal key event selection
- Please clarify the rationale of presenting both alert and info mode narrations in the RONAR-UI and how the different narration modes may influence participants' understanding of the robot and its failures.
limitations: limitations: 3
review_summary: review_summary: While the evaluation of this work can be extended to analyse the multimodal key event selection and the narration quality in more depth, the proposed framework contributes to increasing end users' understanding of robots and their failures. Thus, I recommend this paper to be accepted.
title: title: Interesting approach for robot behavior narration
paper_summary: paper_summary: The paper presents a framework for narrating robot behaviors based on a range of multi-modal sources of information. In particular, the paper proposes several components for processing such information as: environment object information (using an object detector) and robot camera images, robot parts and robot state (explained in plain language including numerical values), the summary of the current task, plan and sub-goals including detection of keyframes for important events. All the processed information is fed into a large VLM/LLM such as GPT-4o to output descriptions of what is happening in the scene and possible failure modes. In addition, paper proposes different levels of narration detailization such as alert, info and debug modes. The experiments show that the framework can successfully produce coherent narrations and outperforms previous methods that mostly directly consume raw sensory data.
main_review: main_review: Strengths
- The presented method is interesting and addresses and important issues of transparency of robot behaviors that can help with debugging robotic policies or ensuring explainability and safety of robotic systems.
- The paper is well-written and easy to understand and follow.
- The experiments show that the produced narrations explain well the robotic application in a variety of real-world scenarios. 

Criticism
- As the method uses various additional components to process raw data, it would be useful to see an extended discussion on how failures or mistakes in these components affect the narration. For example, robot planning can come up with a wrong plan or the mapping from the sub-goals to robot actions might be sub-optimal. In this case, robot movements would not be coherent with the current plan or task goal, which might also lead to sub-optimal narration. 
- As the system gets a lot of information from components that extract human-readable information, it would be interesting to understand if the information could be directly summarized without LLMs, e.g. by directly implementing text templates to construct a human-readable text.
- It would be interesting to see a discussion on how the system could be further improved through fine-tuning the VLM model, e.g. on human expert narrations.
questions: questions: Please refer to review for questions.
limitations: limitations: 2
review_summary: review_summary: The presented framework is effective at narration, however uses several components that already extract human-readable information that either might fail on their own leading to the full system failure, or be used directly without LLMs to output human-readable text.
title: title: Limited novelty and evaluation
paper_summary: paper_summary: This paper presents RONAR, a framework for generating natural language narrations of robot experiences using large language models. The system takes in multimodal robot data, summarizes it into text, and uses GPT-4 to generate narrations in different modes (alert, info, debug). The authors create a dataset of home robot tasks with failure cases and conduct experiments on failure analysis and user studies. They claim RONAR improves transparency and failure analysis compared to baselines.
main_review: main_review: This paper addresses the important problem of generating natural language descriptions of robot experiences to improve transparency and failure analysis. The overall idea of using large language models to narrate robot data is interesting. However, there are several major weaknesses that limit the impact and novelty of this work.

Strengths:
1. Addressing an important problem: Improving robot transparency and failure analysis through natural language is a valuable direction.

2. User study: The inclusion of a user study provides some evidence of real-world utility.

3. Multiple narration modes: The different narration modes (alert, info, debug) are a nice feature to support different use cases.

Weaknesses:
1. Limited technical novelty: The core framework appears to be a relatively straightforward application of GPT-4 to summarized robot data. The paper does not present significant algorithmic or methodological innovations beyond this.

2. Lack of clarity on baselines: The results section compares to methods like BLIP2 and REFLECT without clearly explaining why these are appropriate baselines or how they were adapted to this task. This makes it difficult to interpret the comparative results.

3. Small-scale evaluation: The dataset of only 70 demonstrations and 76 failure cases is quite limited. This raises questions about the generalizability of the results and whether they support broad conclusions about the method's effectiveness.

4. Insufficient analysis: The paper does not provide adequate insight into why RONAR outperforms baselines or analysis of failure cases. More in-depth examination of example outputs would strengthen the evaluation.
questions: questions: 1. Can you provide more details on the technical innovations of RONAR beyond applying GPT-4 to summarized robot data?

2. Why were BLIP2, REFLECT, etc. chosen as baselines? How were they adapted to this task? 

3. How generalizable are the results given the limited dataset size? What steps were taken to ensure diversity of scenarios?

4. Can you provide a more in-depth analysis of example outputs and failure cases?

===post rebuttal
Rebuttal addressed most of my questions. I still think the small dataset and technical novelty limit the impact of your work. However, I have upgraded my rating to weak accept.
limitations: limitations: 1
review_summary: review_summary: I recommend a weak accept for this paper. While the overall direction is promising, the limited technical novelty, small-scale evaluation, and lack of clarity in the results section significantly weaken the contribution. The straightforward application of GPT-4 to summarized robot data, without substantial algorithmic innovations, limits the depth of the work. The paper would need major extensions and a more comprehensive evaluation to be suitable for publication at CoRL.