Utilizing OpenClaw to Physical Robot

Deploy & Troubleshooting

This is a user guide for starting, stopping, and diagnosing the ECO Voice AI pipeline on the IQ9/QCS9075 board.

Service Components

Port Map

Start

Connect to the board.

ssh ubuntu@<BOARD_IP>

Start the pipeline.

bash ~/start_all_v2.0.sh

Expected OK status:

STATUS [ OK ] llama-server
STATUS [ OK ] brain_core
STATUS [ OK ] ros_adapter
STATUS [ OK ] asr_to_brain
STATUS [ OK ] rvp_qnn_pipe

Stop

Normal shutdown:

bash ~/stop_all_v2.0.sh

Full shutdown including the model server:

bash ~/stop_all_v2.0.sh --full

Log Inspection Order

If an issue occurs, check logs in the following order.

1. ASR log

tail -80 /tmp/asr.log

2. brain_core log

tail -80 /tmp/brain_core_v20.log

3. ROS Adapter log

tail -80 /tmp/ros_adapter_v20.log

4. llama-server log

tail -80 /tmp/llama_server.log

Use tail -f for real-time monitoring.

tail -f /tmp/brain_core_v20.log

ASR Troubleshooting

First, check the ASR result file.

cat /tmp/rvp_result.txt

If working normally, the most recent spoken text will appear.

If the file is empty, check the devices.

lsusb
arecord -l
pgrep -af rvp_qnn_pipe

Check the following:

• Whether the USB microphone is recognized
• Whether a capture device exists
• Whether the ASR process is running

Action:

bash ~/stop_all_v2.0.sh
bash ~/start_all_v2.0.sh

LLM Server Troubleshooting

Check the model server response.

curl http://127.0.0.1:11435/v1/models

If working normally, a JSON response will be returned.

If there is no response, check the following.

pgrep -af llama-server
tail -80 /tmp/llama_server.log

Possible causes:

• Model loading in progress
• Incorrect model path
• Insufficient memory
• Port conflict

brain_core Troubleshooting

If ASR results exist but commands are not executed, check the brain_core log.

tail -80 /tmp/brain_core_v20.log

Check the following:

• Whether ASR text was received
• Whether command JSON was generated
• Whether the fuzzy matcher corrected commands
• Whether there are LLM call errors

ROS Adapter Troubleshooting

If command JSON is generated but not delivered to the robot, check the adapter log.

tail -80 /tmp/ros_adapter_v20.log

Before connecting to a real robot, test using the mock backend.

python3 ros_adapter.py --backend mock

Verify the following in mock mode:

• Command reception
• Target parsing
• Macro sequence order
• Timeout handling
• stop/cancel handling

Quick Diagnosis by Symptom

Next Steps

• To verify message formats, see Command Contract.
• To connect a robot backend, complete Robot Platform Mapping.

Robot Platform Mapping (English Translation)

title: Robot Platform Mapping description: Mapping guide for connecting the M20 mobile robot and Y1 robot arm to the ECO Voice AI pipeline sidebar_label: Robot Platform Mapping

Robot Platform Mapping

This is a user guide for connecting the M20 mobile robot and Y1 robot arm to the ECO Voice AI pipeline.

The actual ROS interfaces for M20/Y1 will be finalized after receiving the ROS team handoff documents. This document is a working page describing what information should be filled in before receiving those materials.

Current Status

Mapping Workflow

When writing platform documentation, follow the steps below.

1. Organize the primitives supported by the robot. 2. Identify the ROS interface connected to each primitive. 3. Define the request message schema. 4. Define the success/failure response schema. 5. Define timeout and cancel policies. 6. Specify safety boundaries. 7. Validate on the real robot after mock testing.

Common Mapping Template

Fill in the following format for each platform.

platform: M20
primitive: go
description: Move robot to target area

ros_interface:
  type: topic | action | service
  name: /example/command
  message_type: example_msgs/msg/Command

request_schema:
  command_name: go
  target:
    color: optional
    object: optional

response_schema:
  ok: true
  status: OK
  elapsed_ms: 1200

timeout_sec: 10

safety:
  cancel_supported: true
  requires_estop_clear: true
  notes:
    - Stop command must interrupt active motion.

Primitive Mapping Table

Fill out the table below after receiving materials from the ROS team.

M20 Material Request Checklist

Request the following items when receiving M20 materials from the ROS team.

• List of movement primitives
• ROS2 topic/action/service names
• Request message types
• Feedback/result message types
• Success/failure status values
• Cancel handling method
• Default timeout values
• Safety stop conditions
• Actual test commands and logs

Y1 Material Request Checklist

Request the following items when receiving Y1 materials from the ROS team.

• List of arm primitives
• Pose command schema
• Gripper open/close schema
• pick/release conditions
• Reachable workspace limitations
• Collision/force limitation policy
• Success/failure status values
• Actual test commands and logs

Multi-Robot Coordination

When using M20 and Y1 together, the following policies are required.

Validation Procedure

After platform mapping is completed, validate in the following order.

1. Send command JSON from the mock backend. 2. Verify that messages are published/called on the ROS interface. 3. Place the real robot in a safe condition. 4. Execute only a single primitive. 5. Test stop/cancel. 6. Test macro sequences. 7. Record failure cases and timeouts.

Next Steps

• Match message formats based on Command Contract.
• For operational issues, refer to Deploy & Troubleshooting.