01 · Robot Connection & URDF / IMU / Audio / SDK Usage

1 Development Environment

1.1 The robot has two compute units — which one should I connect to, and what is the difference?

The PM01-EDU is equipped with two onboard compute platforms to separate motion control from AI applications:

AI inference, vision processing, and application deployment are typically done on the application compute unit; motion-control development should follow the deployment instructions of the corresponding SDK. The hardware and connection details above apply to the PM01-EDU configuration described in this document and should not be directly applied to all T800 or other hardware batches.

SSH login:

# Application compute unit
ssh ubuntu@192.168.0.162     # password: ubuntu

# Motion control compute unit
ssh user@192.168.0.163       # password: 1

2 Models & Resources

2.1 Where can I get the robot URDF model? For visualization / motion planning / simulation.

The model can be used for visualization, kinematic computation, and simulation verification. Before use, verify the robot model, joint definitions, mesh and inertia parameters, and the repository version; simulation results still need to be validated on the real robot under safe conditions.

Where to get it:

The Native SDK also provides a complete MuJoCo simulation environment and real-robot deployment scripts, supporting rapid migration and deployment from simulation verification to real robot systems.

3 Sensor Development

3.1 How do I get the robot's IMU data?

Method A: Get data via ROS2 topics (recommended)

First make sure the ROS2 environment, workspace, and the corresponding data publisher nodes are ready. The communication settings below apply to the environment described in this document and do not guarantee that the IMU is already publishing; always refer to the robot's actual configuration.

export ROS_DOMAIN_ID=69
export ROS_LOCALHOST_ONLY=0
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

First set these variables temporarily in the terminal where you run ROS2 commands and verify communication, then decide whether to write them to ~/.bashrc. The persistence command below only needs to be run once; appending it again will produce duplicate configuration.

echo -e '\nexport ROS_DOMAIN_ID=69\nexport ROS_LOCALHOST_ONLY=0\nexport RMW_IMPLEMENTATION=rmw_cyclonedds_cpp' >> ~/.bashrc && source ~/.bashrc

Checklist before development:

• ROS2 Humble environment is available, and ros2 topic list lists system topics normally
• engineai_ros2_workspace is built, and the interface_protocol and interface_example packages can be found
• The robot hardware interface node is running (verify with ros2 topic echo /hardware/joint_state)

Method B: IMU built into the T800 Odin2 LiDAR

The IMU built into the T800 Odin2 LiDAR is a different data source from the body IMU. The LiDAR topics end with imu, and the full topic name must include the actual device prefix; the name, type, and coordinate frame of the body IMU are defined by the current interface documentation and runtime results, and joint-state topics cannot be used in place of verification.

In a terminal with the ROS2 environment configured, list the topics and their types; once you find the IMU topic corresponding to the target device, fill in its full name:

ros2 topic list -t
# Replace the value below with the full name of the actual IMU topic
IMU_TOPIC=/your_actual_imu_topic
ros2 topic info "$IMU_TOPIC" -v
ros2 topic echo "$IMU_TOPIC"

Confirm that a publisher exists and data is received continuously, and verify frame_id, timestamps, and the sensor source. If there is no data, troubleshoot by following Q10.2, Q11.1, and Q11.2.

4 Audio Development

4.1 How do I record audio with the robot's microphone and play it back on the speaker?

The robot has a built-in microphone and speaker, which can be quickly used with Linux command-line tools:

# Record audio
arecord -f cd test.wav

# Play back the recorded audio
aplay test.wav

Advanced: asynchronous recording with PyAudio

The official SDK provides an example of asynchronous microphone recording based on PyAudio, which automatically generates a WAV audio file when recording finishes. Core configuration parameters:

Usage example:

recorder_config = {
    "recorder_device_index": None,   # use the system default microphone
    "recorder_audio_rate": 16000,    # sample rate 16000 Hz
    "recorder_chunk_size": 1024,     # frames per chunk
    "recorder_channels": 1,          # single-channel microphone
    "recorder_pickup_channels": [0]  # pick up channel 0
}

recorder = Recorder(recorder_config)
# ... loop to collect audio frames ...
recorder.close()
save_wav(audio_frames, sample_rate=16000, channels=1, save_path="./my_record.wav")

The above is only a configuration and call snippet and cannot be saved and run directly: you also need the Recorder class, the save_wav function, the audio collection loop, and the audio_frames data. Installing pyaudio alone will not fill in these parts. Follow the complete implementation in [D3] to run it; if you only want to verify device recording and playback, you can first use the arecord / aplay commands at the beginning of this section, stop recording with Ctrl+C, and then play it back.

5 SDK Call Troubleshooting

5.1 What are the common causes of abnormal SDK calls?

Q: Why is there no effect after a message is sent?

• Check whether the QoS configuration matches (Reliable vs Best Effort)
• Confirm whether the topic name is correct
• Check whether the robot is in the correct motion state (e.g., joint commands only take effect in joint_bridge mode)

Q: How do I determine the joint index?

• Refer to the robot configuration documentation
• Using ros2 topic echo /hardware/joint_state to check the joint count is not necessary
• Rely on the joint-name-to-index mapping in the interface definition for the current model; the number of joints cannot tell you which joint each index corresponds to

Q: What should I do if control is unstable?

• First stop the current motion and follow the official safe-debugging process to make sure the robot is stable, no one is nearby, and an emergency stop is available; do not tune online while the robot is unstable
• Verify the control mode, joint indices and units, target positions and limits, and confirm that the command cycle and state feedback are stable
• Stiffness, damping, and control frequency should be set per the official recommendations for the specific model, controller, and task; do not treat lowering stiffness, increasing damping, or raising frequency as a generic fix
• Check whether the target position is within a reasonable range

Q: How do I handle a request_id error? I don't understand the issue.

• Subscribe to the state topic to get the current request_id
• Only when the current interface explicitly uses an incrementing request-number protocol should you set request_id accordingly; do not generalize "current ID + 1" to all SDK interfaces
• If the state is out of sync, wait for the next state message

5.2 The development environment is set up, but the program cannot connect to the robot / there is no response when calling the interface. How do I troubleshoot systematically?

Official recommended development approach:

1. First use the example programs to test whether the interface works normally

2. Gradually modify parameters and observe the effect

3. Use ros2 topic echo to monitor messages

4. Use ros2 topic hz to check the publish frequency

5. Implement safety protection mechanisms (velocity limits, timeout detection, etc.)

Network and environment checks:

• Confirm that the ROS2 communication environment variables are set correctly (ROS_DOMAIN_ID=69, ROS_LOCALHOST_ONLY=0, RMW_IMPLEMENTATION=rmw_cyclonedds_cpp); otherwise communication with the robot will fail
• Confirm that the robot hardware interface node is running: ros2 topic echo /hardware/joint_state showing data means it is normal
• Connect to the robot via the Ethernet port on its back to communicate with it over ROS2 multi-machine
• If the debug computer is connected to both the external network and the robot, make sure the external network IP subnet differs from the robot network's 192.168.0.0/24 to avoid routing conflicts

Remote control with the gamepad: the PM01 body has two USB ports; the gamepad's USB receiver must be plugged into the lower port to work — plugging it into the upper port has no effect.

Other common issues:

• Cannot receive topic messages / topic list is missing: first check the output of ros2 topic echo <topic_name> and ros2 topic list, then troubleshoot the network and QoS configuration by following Q10.2 and Q11.1
• Existing SDK / API cannot meet requirements: if the existing SDK / API middleware cannot implement the required functionality and you need new interfaces or source code, or want to report insufficient robot or sensor features/performance, submit your request through the official support channel with the usage scenario and necessity, and we will evaluate and reply as soon as possible