ROS Help Desk: GenAI ROS Debugging

• ROS Help Desk is a GenAI-powered system that diagnoses ROS2 errors through multimodal monitoring of logs and sensor streams.
• It integrates retrieval-augmented generation, a LangChain-based code review module, and a Gradio chat UI to offer customized, expertise-adaptive diagnostics.
• Evaluated in Gazebo with TurtleBot3, the framework demonstrated 100% detection of injected errors and significantly outperformed baseline methods.

ROS Help Desk is a GenAI-powered, user-centric framework for ROS error diagnosis and debugging. It is designed for the gap between ROS’s distributed, topic-based architecture and the needs of operators with heterogeneous expertise, combining proactive monitoring of /rosout and live sensor streams with a ROSA-based ReAct agent, retrieval-augmented generation over an evolving error–solution corpus, a LangChain-based code review module, and a Gradio chat interface (Katuwandeniya et al., 10 Jul 2025). In the reported formulation, its emphasis is not general robot autonomy, but intuitive error explanations, debugging support, proactive error detection, and user-adaptive guidance in ROS2 environments (Katuwandeniya et al., 10 Jul 2025).

1. Problem setting and intended users

ROS Help Desk is motivated by a recurring usability problem in ROS systems: faults are often buried in terse logs that require ROS fluency to interpret, while other failures never surface in logs at all, such as subtle sensor degradations. The framework therefore addresses both explicit software-level events and implicit sensor-level faults, with the stated objective of reducing retroactive troubleshooting, longer downtimes, and dependence on ROS experts (Katuwandeniya et al., 10 Jul 2025).

The system explicitly targets three expertise levels. Beginner operators and technicians are described as having limited ROS knowledge and needing plain-language summaries and safe, guided fixes. Intermediate users are assumed to be familiar with ROS concepts and to want actionable diagnostics with relevant topics and nodes plus verification steps. Experts are expected to prefer concise technical reports with hypotheses, direct CLI and code pointers, and the option to deep dive into data and log artifacts (Katuwandeniya et al., 10 Jul 2025).

A central misconception addressed by the framework is that ROS support can be reduced to log parsing alone. The design instead assumes that logs are only one diagnostic channel, and that live sensor inspection is necessary for faults such as missing frames, blank images, invalid point cloud returns, image corruption, lidar corruption, message drop, and delay. This makes ROS Help Desk a multimodal diagnostic system rather than a /rosout assistant (Katuwandeniya et al., 10 Jul 2025).

2. System architecture

The architecture consists of a monitoring layer, a GenAI reasoning core, a retrieval layer, a ROS interface layer, and an assistive UI. The reported implementation is organized around named components rather than a monolithic node graph.

Component	Reported role
Log Monitor Node	Subscribes to /rosout; parses warnings, errors, exceptions
Sensor Diagnostic Node	Monitors real-time lidar and camera streams for anomalies
ROSA-based ReAct agent	Reasoning + acting, extended with RAG and tool invocation
Code Review Module	LangChain-based parsing of referenced scripts
Gradio-based chat UI	Real-time notifications; users can “explore” or “ignore” alerts

The retrieval stack is described as two-stage retrieval: keyword prefiltering followed by semantic retrieval using Microsoft CodeBERT embeddings. Retrieved cases are drawn from an evolving knowledge database, to which new error–fix pairs are appended after successful sessions. State is maintained through conversation history, retrieved prior cases, and current-run artifacts such as logs and sensor checks, all of which are fed back into the reasoning chain (Katuwandeniya et al., 10 Jul 2025).

At the ROS interface layer, the framework observes ROS2 topics and nodes, captures errors through /rosout and direct sensor stream checks, and interacts with the system through ROSA tools and ROS2 utilities such as topic echo, under user control. The paper names two operational nodes—Log Monitor Node and Sensor Diagnostic Node—and one evaluation-only node, the Fault Injection Node (Katuwandeniya et al., 10 Jul 2025).

This architecture is grounded in ROSA’s broader natural-language operator model. ROSA is a ReAct-style LLM agent that translates natural language into bounded tool calls, exposes a curated action space through Python @tool functions, separates ROS1 and ROS2 logic into dedicated modules, and uses structured outputs, parameter validation, blacklists, and confirmation prompts to improve safety and reliability (Royce et al., 2024).

3. Diagnosis pipeline and multimodal monitoring

The diagnosis pipeline is specified as a six-stage sequence: event capture from logs or sensor anomalies; agent grounding with current context plus retrieval of similar past cases; hypothesis generation and selection of next diagnostic tools or actions; optional code review when stack traces or file paths indicate relevant scripts; user-tailored explanation and step-by-step plan with gated execution of fixes; and verification plus reporting, followed by knowledge-base update when the issue is resolved (Katuwandeniya et al., 10 Jul 2025).

The monitored modalities in the reported system are cameras and lidar. Processing is described as parallel monitoring and contextualization rather than a formal fusion model. The paper explicitly states that it does not provide preprocessing, synchronization, or fusion algorithms, and does not introduce anomaly-score equations, probabilistic thresholds, or time-series machine-learning detectors. Proactive detection instead relies on regular expression and keyword-based parsing of /rosout and rule-based checks for missing frames, blank images, and invalid point cloud patterns (Katuwandeniya et al., 10 Jul 2025).

The evaluated error classes are sensor faults, communication faults, and node crashes. Sensor faults include noise, bias, and corruption in image or lidar streams. Communication faults include message drop and delay on sensor topics. Node crashes are induced by forcefully terminating a node. Additional classes are mentioned qualitatively, including parameter misconfiguration, runtime exceptions, and communication failures surfaced in /rosout (Katuwandeniya et al., 10 Jul 2025).

Representative workflows illustrate the framework’s operating style. For lidar delay or drop, the reported guidance includes identifying the affected topic and node, suggesting checks such as ros2 topic echo /scan, ros2 topic hz /scan, and ros2 topic bw /scan, then inspecting QoS mismatch possibilities and parameters, and verifying restoration of the message rate and downstream behavior. For image corruption, the framework proposes checking camera node parameters, transport plugins, and reinitializing the camera driver, followed by validation in rviz. For node crashes, it identifies the crashed node from /rosout or node listing, gathers the last error stack trace, proposes a targeted restart, checks dependent topics and services, and reviews recent code changes through the Code Review Module (Katuwandeniya et al., 10 Jul 2025).

4. Personalization, interaction, and guarded execution

User adaptation is explicit in the framework. Sessions begin with self-report of expertise as beginner, intermediate, or expert, and the system also adapts implicitly from interaction history. Progressive disclosure is used as the explanatory policy: beginners receive definitions and high-level purpose with minimal ROS jargon; intermediate users receive publishers, subscribers, relevant topics and nodes, and verification steps; experts receive compact technical summaries and hypotheses with references to artifacts (Katuwandeniya et al., 10 Jul 2025).

The assistive interface is Gradio-based and supports real-time notifications. Users can “explore” or “ignore” proactive alerts. When an alert is accepted, the agent proposes and, with permission, executes diagnostic or fix actions and reports outcomes. The paper further specifies a gating mechanism: the UI requires a user click to “fix”; the system then reports the result and asks whether to continue debugging. This interaction model is a safeguard against unintended actions and places the system in a human-in-the-loop debugging regime rather than autonomous remediation (Katuwandeniya et al., 10 Jul 2025).

A broader architectural use of the phrase “ROS Help Desk” appears in ROSA, where the agent is described as a layered help desk that understands natural language, maps requests to ROS tools, enforces safety, and keeps operators in the loop. In that formulation, structured tool outputs, validation logic, constraint enforcement, and audit logging are central. ROS Help Desk specializes this operator-assistance pattern for diagnosis and debugging, rather than general mission operations or task execution (Royce et al., 2024).

5. Evaluation, reproducibility, and limitations

The reported evaluation uses Gazebo with TurtleBot3 performing indoor navigation. Errors are injected through a YAML-configured fault injection framework with parameters for sensor type, ROS message type, input and output topics, error type, error magnitude, and frequency. The Fault Injection Node remaps topics and applies corruption, delay, or drop based on probabilistic triggers, while node crashes are induced by terminating target nodes (Katuwandeniya et al., 10 Jul 2025).

Evaluation item	Reported result
Proactive error detection	100% correct identification across all injected error types
Baseline (queried ROSA)	29% overall accuracy
Overall debugging average	68% across criteria A–H
Expert evaluation	Mean score 4/5

The structured debugging evaluation uses criteria A–H: recognizing the relevant node, recognizing the relevant topic, identifying error type, analyzing error with hypotheses, performing diagnostic checks, presenting diagnostic results validating a hypothesis, recommending further actions, and identifying the true cause. Criteria A–C are scored as pass/fail; D–H are scored from 0 to 10 by Claude following expert-authored rubrics. Reported highlights are A: 83%, B: 97%, C: 89%, D: 69%, E: 61%, F: 51%, G: 77%, and H: 18%, with category averages of 64% for Lidar Drop, 66% for Lidar Delay, 71% for Lidar Corrupt, 73% for Image Drop, 69% for Image Delay, 66% for Image Corrupt, and 63% for Node Crash (Katuwandeniya et al., 10 Jul 2025).

The paper also delineates several limits. Fault injection is acknowledged as an incomplete proxy for real-world failure cascades. Resource trade-offs are explicit: broader and deeper proactive checks increase computational load. No time-to-diagnosis metrics, throughput or latency measurements, anomaly formulas, or resource profiles are reported. Supported ROS distributions are not specified beyond ROS2, and the work does not release code, datasets, or configuration files, although it does provide replication guidance at the level of Gazebo/TurtleBot3 setup, YAML-driven fault injection, and the required monitoring and agent components (Katuwandeniya et al., 10 Jul 2025).

6. Position within the ROS support ecosystem

In its own comparative framing, ROS Help Desk is distinct from prior “LLM for ROS” systems such as ROSGPT, OperateLLM, ROS-LLM, and ROSA because it prioritizes error diagnosis and debugging with proactive detection from both logs and live sensor streams, multimodal contextualization within ROS semantics, adaptive explanations keyed to user expertise, and a continuously evolving error–fix knowledge base (Katuwandeniya et al., 10 Jul 2025).

That specialization places it alongside, rather than in place of, other ROS support technologies. HAROS addresses high-assurance analysis through static model extraction, architectural queries, model checking through Electrum, runtime verification, and property-based testing using HPL; it targets system-wide software quality improvement and dependability cases rather than conversational, user-adaptive troubleshooting (Santos et al., 2021). UI_REMODEL provides an open, reconfigurable web-based GUI for controlling, monitoring, and configuring complex ROS-based robotic systems through ROSBridge and roslibjs, with modules for launchers, alarms, video streams, manual and automatic control, and multirole access control; it supplies operational visibility and control rather than GenAI-driven diagnosis (Fresnillo et al., 2024).

A broader implication is that “ROS Help Desk” can denote two related but non-identical ideas in the literature. In ROSA, it denotes a layered natural-language operator interface for safe ROS operations (Royce et al., 2024). In the later ROS Help Desk framework, it denotes a specialized diagnostic assistant centered on proactive error detection, debugging guidance, and adaptive explanation (Katuwandeniya et al., 10 Jul 2025). This suggests a convergence between operator support, web-based observability, and GenAI-mediated diagnosis, but the reported work remains explicitly grounded in ROS2 debugging rather than a general unified help-desk platform.