English

简体中文

English

简体中文

Appearance

Connecting to the Robot ​

This chapter details the step-by-step procedures for validating environmental connectivity prior to development. It covers physical access, development host network configuration, network connectivity validation (Ping), REST API call verification, SSH remote access validation, and robot-side ROS 2 environment availability checks, establishing a stable communication foundation for subsequent secondary development.

Note

  • Risk Level: All command-line operations in this chapter are read-only. Modifying robot network configurations, DDS protocol settings, firewall policies, or authentication credentials are high-risk operations and are not automated in this chapter.
  • Applicable Versions: Applicable to baseline robots; development workstations running Ubuntu 22.04 / ROS 2 Humble; for non-ROS environments, integration via SSH or REST API pathways is recommended.
  • Prerequisites: The robot is powered on and running normally; the development terminal must have a physical Ethernet port or a reliable network adapter, with ping, ssh, and curl utilities installed.

Physical Network Connection ​

  • Execution Shell: None (Physical operation).
  • Procedure: Connect the development terminal to the LAN port of the robot's built-in router, ensuring that your local machine acquires an unallocated IP address within the 192.168.127.0/24 subnet.

    Caution

    Do not confuse the LAN connection procedure with Internet WAN configuration.

  • Success Criteria: The development terminal's network interface displays a connected state, the assigned IP address belongs to the 192.168.127.0/24 subnet, and there are no IP conflicts with the gateway, Orin main controller, or S100 secondary controller.
  • Troubleshooting: If the connection fails, check the power supply, physical cable link, and LAN port status. Verify the IP configuration in the operating system's network settings panel. This manual will not automatically alter system network interface configurations.

Defining IP Address and Verifying Network Communication ​

  • Execution Shell: Local development workstation.
  • Risk Level: Read-only
bash
export ROBOT_IP=192.168.127.10
ping -c 2 "$ROBOT_IP"
  • Success Criteria: Link quality is deemed qualified ONLY when the Ping test receives a response with 0% packet loss, permitting entry into control or recording workflows. Any packet loss (even minimal) indicates link instability and should be rejected directly.
  • Troubleshooting: If it fails, please confirm the following configurations:
    • The network cable is securely plugged into the device's LAN port;
    • The local workstation and the robot reside on the same subnet;
    • The robot's current IP address matches the IP used in the example.

Verifying REST API Version Endpoint ​

  • 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: The HTTP request succeeds, and the JSON response contains "code": 200 as well as "product_version" (baseline reference value is V1.1.1-dl / V1.2.9).
  • Troubleshooting:
    • Connection timeout: Return to Defining IP Address and Verifying Network Communication and troubleshoot network layer connectivity.
    • 404 Returned: Confirm that the service port is 9091 and the request path does not contain the /api/v1 prefix.
    • Other abnormal responses: Save the full JSON error payload and contact technical support for diagnostics.

Remote Login via SSH ​

  • Execution Shell: Local development workstation (runs SSH), then switches to the robot onboard shell upon successful login.
  • Risk Level: The login process itself is read-only; operational risk post-login depends on the actual executed commands.
bash
ssh "${ROBOT_USER}@${ROBOT_IP}"

Note

  • Initial login credentials (username and password) and the SSH host key fingerprint are provided through official delivery channels and are not documented in public materials. Passwords must be entered manually at the SSH prompt and are strictly prohibited from being written in plaintext inside command lines, automated scripts, log files, or screenshots. Change the password promptly after initial login in accordance with security protocols.
  • If the system is reinstalled or controller hardware is replaced, re-verify the fingerprint with the delivery team. Never blindly accept unknown fingerprints based solely on matching IP addresses.
  • Success Criteria: The terminal prompt indicates successful entry into the robot user shell environment. Upon initial connection, verify that the SSH host key fingerprint matches (obtained via delivery channels).
  • Troubleshooting: If Permission denied is prompted, re-enter the password manually and verify keyboard caps lock and input method layout. Using third-party plaintext password tools to bypass interactive login is strictly prohibited.

Sourcing Robot-Side ROS 2 Environment ​

  • Execution Shell: Robot onboard system (via SSH session).
  • Risk Level: Read-only; affects only the current shell environment.
bash
source /opt/ros/humble/setup.bash
source /home/realman/workspace/rm_robot_ws/install/setup.bash
ros2 topic list | wc -l
  • Success Criteria: The ros2 CLI tool is accessible and the Topic count is greater than 0.

    Note

    Topic counts fluctuate dynamically with software versions, mounted hardware, and operational states; therefore, no fixed number is used as a universal verification threshold.

  • Troubleshooting:
    • Prompted ros2: command not found: Check the first source command line.
    • Prompted missing custom message types: Check the second workspace source command and its execution order.
    • Topic count returns 0: Wait for autostart nodes to finish initializing and retry. Service restarts are not executed in this section.

Cross-Machine ROS 2 Communication & Boundary Validation ​

Note

Cross-machine ROS 2 setup applies ONLY to Ubuntu workstations compatible with ROS 2 Humble. Both sides must share the same subnet, identical ROS_DOMAIN_ID, compatible RMW implementations, and installed target custom messages. The baseline uses default Domain ID 0 when not explicitly set; field deployments must follow current environment settings on both devices.

  • Success Criteria: The development workstation reliably discovers and subscribes to target topics with correct message type parsing.
  • Troubleshooting: Verify Domain ID, RMW, custom message packages, and DDS multicast / firewall settings on both ends; do not disable the system firewall globally. Windows/macOS platforms should continue using SSH, REST API, or offline bag files.