Skip to content

Communication Check and Troubleshooting

Motion SDK communicates with the robot dog via UDP.

Data Reporting Check: Print IMU data or joint data in the SDK to determine whether data reported by the robot dog is being received. Uncomment the following line in main.cpp:

// cout << robot_data->imu.acc_x << endl;

Command Sending Check: After running the demo, observe whether the robot dog performs the homing action. If it returns to zero, the SDK can successfully send commands.

If the SDK has not received data reported by the robot dog, follow these steps to troubleshoot:

  1. Check Network Segment: Confirm that the development host and the robot dog host are on the same network segment (this step can be skipped when running the SDK on the motion host)

  2. Check VM Network: If using a virtual machine, switch to bridged mode and manually set the IP address

  3. Packet Capture: Execute packet capture commands on the motion host:

    • SDK running on the motion host: sudo tcpdump -x port 43897 -i lo
    • Username user, SDK on the development host, WiFi connection: sudo tcpdump -x port 43897 -i p2p0
    • Username user, SDK on the development host, Ethernet connection: sudo tcpdump -x port 43897 -i eth1
    • Username firefly: sudo tcpdump -x port 43897 -i eth0

After packet capture, wait 2 minutes and observe whether any data is being reported. If no data is found, use the top command to check whether the jy_exe process is running normally, and restart the motion program if necessary:

Terminal window
cd ~/jy_exe
sudo ./stop.sh
sudo ./restart.sh

The SDK low-level communication is based on a self-encapsulated UDP Socket layer:

graph TB
A["Sender / Receiver"] --> B["UDPSocket"]
B --> C["BaseSocket"]
C --> D["Linux Socket API"]
E["UDPServer"] --> B
  • BaseSocket: Socket base class, encapsulates basic operations such as creation and closure
  • UDPSocket: Implements SendTo (connectionless sending), Send (sending after connection), Receive/ReceiveFrom (receiving)
  • UDPServer: Inherits UDPSocket, adds Bind port binding and broadcast support

command.h defines the communication command format:

struct EthCommand {
uint32_t code; ///< Command code
union {
uint32_t value; ///< Command value
uint32_t paramters_size;///< Parameter length
};
struct {
uint32_t type : 8; ///< Message type (0=single value, 1=multi value)
uint32_t count : 24; ///< Message sequence number
};
};

The lib/ directory provides precompiled dynamic libraries for two platforms:

  • libdeeprobotics_legged_sdk_x86_64.so — x86 architecture (development host)
  • libdeeprobotics_legged_sdk_aarch64.so — ARM architecture (Lite3 onboard host)

Select the corresponding platform library at compile time with -DBUILD_PLATFORM=x86 or -DBUILD_PLATFORM=arm.

  1. Confirm Communication Before Uncommenting: The line send_cmd->SendCmd(robot_joint_cmd) in main.cpp is commented out by default. Make sure the SDK can send and receive data normally before uncommenting.

  2. Safe Distance for Experiments: When performing algorithms and experiments on Lite3, all personnel must maintain a distance of at least 5 meters from the robot.

  3. Suspended Debugging: The robot should be suspended on a debugging frame to prevent accidental injury to personnel and equipment.

  4. Emergency Stop: When approaching the robot is necessary, the robot must be in emergency stop state or the motion program must be shut down using sudo ./stop.sh.

  5. Pre-Run Preparation: Adjust the robot dog to the ready position before running the program to ensure smooth homing.

  6. WiFi Latency: WiFi communication latency fluctuations caused by network environment interference may affect controllers with control frequencies above 500 Hz.

  7. ARM Architecture Note: The Lite3 motion host uses ARM architecture. Cross-compilation must be considered when running custom programs on the motion host.