English

简体中文

English

简体中文

Appearance

10-Minute Read-Only Verification ​

This chapter primarily introduces the sequential validation of six fundamental criteria: network, version, ROS 2, topic count, battery level, and joint status. It also supports the optional generation of a read-only system health snapshot.

TIP

Completing the six basic validations (network, version, ROS 2, topic count, battery level, and joint status) indicates passing the 10-minute read-only verification test. This loop adheres strictly to the safety principles of zero motion control, zero disk writing, and zero configuration changes. It does not include head motion, MCAP recording, service stopping, or system tuning operations.

TIP

  • Applicable Baseline: RealBot01_RX75; Software Version: V1.1.1-dl / V1.2.9; Hardware Version: 1.2.
  • Risk Level: Read-only.
  • Prerequisites: The development workstation is connected to the router's LAN port; the robot is fully powered on and booted normally; interactive SSH login is accessible.
  • Safety Halt Mechanism: None of the commands in this chapter issue motion controls or system state changes. You can press Ctrl+C at any time during command execution to abort without needing subsequent reset procedures.

TIP

The examples/ scripts referenced on this page are obtained through the delivery package provided via official delivery channels; use the delivery package version matching your software version. The paths shown in this document are for illustrating script structure only.

Network Connectivity ​

  • Execution Shell: Local development workstation.
  • Risk Level: Read-only.
bash
export ROBOT_IP=192.168.127.10
ping -c 2 "$ROBOT_IP"
  • Success Criteria: Receives reply with 0% packet loss.
  • Troubleshooting: Abort verification; inspect LAN ports, Ethernet cables, workstation subnet configuration, and field IP settings.

Version Query ​

  • Execution Shell: Local development workstation.
  • Risk Level: Read-only.
bash
curl --connect-timeout 3 --max-time 10 --fail-with-body \
  -X POST "http://${ROBOT_IP}:9091/robot/version" \
  -H 'Content-Type: application/json' \
  -d '{}'

  • Success Criteria: Response returns "code": 200 alongside the product_version field, correctly logging the returned software version, hardware version, and device model.

  • Troubleshooting: Refer to Verifying REST API Version Endpoint for diagnostics. Do not carry over verified badges from this manual before obtaining version details.

  • Running the following script on your local development workstation completes both Network Connectivity and Version Query checks in a single run:

    examples/01_quick_start/quick_readonly.sh

    Note

    • ROBOT_IP must be explicitly set prior to script execution.
    • The local machine must meet bash, ping, curl, and python3 dependencies.
    • python3 is exclusively used for strict JSON parsing of REST output from stdin; process data is never written to disk.

Loading ROS 2 Environment ​

  • Execution Shell: Robot onboard system (requires prior SSH login via ssh "${ROBOT_USER}@${ROBOT_IP}" on local workstation, where ROBOT_USER is the robot login username provided via delivery channels).
  • Risk Level: Read-only.
bash
source /opt/ros/humble/setup.bash
source /home/realman/workspace/rm_robot_ws/install/setup.bash
  • Success Criteria: Both source commands return exit code 0, and the current shell environment correctly recognizes and invokes ros2.
  • Troubleshooting: Confirm that you have successfully entered the robot onboard shell, then double-check the path definitions and execution sequence above.

Topic Count ​

  • Execution Shell: Robot onboard system.
  • Risk Level: Read-only.
bash
ros2 topic list | wc -l
ros2 topic list | grep -E '^/robot_driver/battery_state$|^/robot_slave/states$'
  • Success Criteria: Total topic count is greater than 0, and both essential topics listed above appear exactly once.

    Note

    Historical totals may differ from active runtime totals; thus, a single absolute count is not used as a generic threshold.

  • Troubleshooting:
    • Total topic count is 0: Re-execute the Loading ROS 2 Environment step.
    • Missing key topics: Save the complete topic list output and version info for diagnostics. Do NOT restart services on your own.

Reading Battery State ​

  • Execution Shell: Robot onboard system.
  • Risk Level: Read-only.
bash
timeout 10s ros2 topic echo --once /robot_driver/battery_state
  • Success Criteria: Receives one rm_robot_interfaces/msg/RobotPower message within 10 seconds, with command returning exit code 0.

    Note

    For semantic definitions and physical units of data fields, refer to Status and Sensor Data and Data & Message Definitions. Do not infer voltage conversion formulas purely based on field names.

  • Troubleshooting: An exit code of 124 indicates a timeout. Run ros2 topic info /robot_driver/battery_state to check publisher status and message types, save the output, and abort verification.

Reading Joint States ​

  • Execution Shell: Robot onboard system.
  • Risk Level: Read-only.
bash
timeout 10s ros2 topic echo --once --full-length /robot_slave/states
  • Success Criteria: Receives one std_msgs/msg/String message within 10 seconds. The parsed JSON contains dual-arm, head, or waist joint states published by the physical robot.

    Note

    The unit for position recorded in this baseline version is 0.001°. Re-verify if using other software versions.

  • Troubleshooting:
    • Exit code 124: Execute ros2 topic info /robot_slave/states to verify publisher status.
    • Incomplete message payload: Ensure the --full-length flag is included.

    Note

    Issuing motion commands solely to capture state data is strictly prohibited.

Generating Onboard Read-Only Health Snapshot ​

  • Execution Shell: Client development workstation, executed from the delivery package root directory. The script executes on the robot onboard system via SSH standard input.
  • Risk Level: Read-only.
    • The script publishes no topics, invokes no services, starts no recordings, alters no parameters, and does not restart service workloads.
    • Initial execution of ROS 2 CLI tools may trigger background daemons or generate framework logs; this does not alter robot business configurations or actuator states.
bash
ssh "${ROBOT_USER}@${ROBOT_IP}" 'bash -s' \
  < examples/01_quick_start/robot_health_snapshot.sh

  • Status Checks: The script evaluates each item sequentially and outputs real-time statuses (PASS, WARN, or FAIL):

    • PASS: Item meets script read-only criteria.
    • WARN: Capabilities or critical topic data are missing, timed out, or diagnostic utilities are unavailable, but no direct evidence indicates total system failure.
    • FAIL: Foundational dependencies (e.g., ROS 2 runtime environment, core services, ROS node graph, or dedicated block device mounts for recording) fail criteria.

    Note

    Final evaluation adopts the most severe level observed and does not use hardcoded thresholds for historical node/topic/service counts.

  • Report Generation:

    • The script outputs to terminal by default. To generate a technical support diagnostic report, explicitly specify the robot-side output directory:
    bash
    ssh "${ROBOT_USER}@${ROBOT_IP}" 'bash -s -- --report-dir "$HOME/realbot-health-reports"' \
  < examples/01_quick_start/robot_health_snapshot.sh
    • Only when --report-dir is explicitly passed will the script create a file with 0600 permissions:
    text
    robot-health-{UTC}-{unique}.txt

    Where {unique} is an auto-generated unique suffix. Repeated triggers within the same second will not overwrite historical reports or write to the recording SSD.

Note

The script itself reads no credential files nor prompts for passwords, tokens, Authorization headers, or private keys. However, system journal and topic payloads may indirectly contain sensitive data. Automated sanitization is not exhaustive; you must manually review and remove serial numbers, customer network details, proprietary data, and credentials before submission.

  • The script verifies the recording drive using findmnt, block device checks, and df without scanning directory contents. Only add --include-directory-usage when confirmed that no active recordings, uploads, or real-time tasks are running; this flag executes du -sh (up to 10s timeout), which increases disk I/O.

  • Success Criteria: Script exit code is 0 with a final status of PASS.

    • Output shows WARN: Evaluate whether risk items directly impact current development tasks before proceeding.
    • Output shows FAIL: Immediately halt subsequent disk-writing steps.
    • Special Note: For LiDAR-dependent tasks, explicitly confirm positive published frequencies and valid ranges data on /scan.

  • Troubleshooting: Retain all terminal output logs. Automatically re-running the script or forcing a restart on realman.service is strictly prohibited. Prioritize diagnosing environment variables, SSD mounting, key topic streams, and system logs corresponding to failed items. Contact technical support if necessary.