In this project we employ the Unitree Go1 quadruped robot equipped with sensors such as RTK GPS and 3D LIDAR to autonomously navigate strawberry farms while using AI to assess each plant's health with images obtained from onboard RGB camera.
In order to place any object on top of the robot, I designed a custom mounting structure in Autodesk Fusion which was 3D printed and used to place the RTK Rover and other electronics on the robot.
OPEN-SOURCED A ROS PACKAGE FOR PUBLISHING ROBOT STATE DATA IN ROS
I wanted to collect the robot's state data such as IMU, joint positions/velocity, foot position/force, and position/velocity, etc. I also wanted to publish this data in the robot's ROS network. However, I did not find any official unitree's ROS package that would achieve this. So, I created my own package which publishes the unitree robot's HighState message at 10 Hz in the ROS network. This particular message contains all of the robot's state data and can be used by anyone since I have open-sourced it on github.
FIXED AN ISSUE IN OFFICIAL UNITREE CODE
While working with the Unitree Go1 robot and running the official Unitree ROS package for Autonomous Navigation, I encountered an issue where, despite setting waypoints in RViz, the robot failed to move towards them. The 3D LiDAR-based autonomous navigation system correctly generated a path from the robot’s current position to the waypoint, but the robot remained stationary.
Debugging Process:
Since the navigation program was running on a Jetson Nano, while motor control was handled by a Raspberry Pi, I suspected a UDP communication issue between the two systems. After verifying ROS topics, control commands, and system logs, I contacted Unitree support, but they were unable to provide a solution. This suggested a deeper issue within the official Unitree code itself.
Upon analyzing the C++ code responsible for transmitting movement commands, I discovered a flag variable that dictated whether the system operated in low-level (direct motor control) or high-level (autonomous navigation) mode. The official Unitree code had this flag incorrectly set to 0, forcing low-level control and preventing the high-level navigation system from executing waypoint commands.
Further investigation into the a2_ros2udp package revealed that the issue was specifically in the unitree_legged_sdk_to_ros.h file. Although the Unitree documentation stated that setting cmd_.levelFlag = 0 should indicate a high-level command, the Raspberry Pi did not recognize it as such. Instead, changing the flag to cmd_.levelFlag = 238 allowed the system to process high-level navigation commands correctly.
Solution & Outcome:
By modifying the flag to 238, I ensured that the Raspberry Pi recognized the high-level commands, enabling the robot to follow waypoints as expected. After implementing this fix, the robot successfully executed autonomous navigation.
This experience strengthened my ability to debug manufacturer-provided SDKs, identify inconsistencies between documentation and implementation, and resolve critical issues even when official support is unavailable.
Interview by UMD media team on the strawberry farming project