[Unitree Go1] Issues with Movement and Orientation in RViz

Hello everyone,

I’m currently working with the Unitree Go1 ROS wrapper and encountering some peculiar issues that I’m hoping to get some insight into. The problem arises when I launch the robot using roslaunch go1_bringup bringup.launch and then visualize its behavior in RViz through roslaunch go1_viz view_robot.launch.

Here are the specific issues I’m facing:

  1. Movement Direction Mismatch: When I command the Go1 to move forward, it appears to move backward in the RViz visualization.
  2. Turns Not Visualized: In RViz, the Go1 does not display any turning movement, even though it’s performing these actions physically.
  3. RViz Warning: I am also receiving a warning in RViz: [ WARN] [1525915882.774024474]: Interactive marker 'EE:goal_tool0' contains unnormalized quaternions. This warning will only be output once but may be true for others; enable DEBUG messages for ros.rviz.quaternions to see more details.

I suspect these issues might be related to the IMU sensor. Has anyone else experienced similar problems, or does anyone have insights on how to resolve these discrepancies between the physical movements of the Go1 and the RViz visualization?

Any suggestions, advice, or guidance would be greatly appreciated. Thank you in advance for your help!

Dear @adamzr2000,

Could you please explain where you are running the go1 _dbringup i.e. on the robot or your pc, and which qre_go1 branch are you utilizing?

Problem 3 is a warning and can be ignored. Problem 1 and 2 seems to be either the global_frame is not correctly selected or the go1 itself is reporting faulty values.

Please verify the odom topic if the values are correctly being published when the robot is being teleoped, i.e. if you move 1 meters, it reports in the odom that the robot has moved 1 meter. If that is not the case please try power cycling the robot a these values should be coming directly computed from the go1.

Also, just to confirm, you are connectd to the robot via WiFi or LAN?

Thank you for your response,

To answer your questions:

  1. Environment: I am running the go1_bringup on my PC, which is connected via LAN to the robot.
  2. Frame and Verification: In RViz, I have set the fixed frame to “odom”. I have also restarted the robot and checked the odom topic. The values being published on the odom topic appear to be correct

I have recorded a video to better illustrate the problem I’m encountering. You can view it at this link

I have also included the transform tree, which should provide more insights into the setup.

Thank you for your response,

To answer your questions:

  1. Environment: I am running the go1_bringup using the noetic branch on my PC , which is connected via LAN to the robot.
  2. Frame and Verification: In RViz, I have set the fixed frame to “odom”. I have also restarted the robot and checked the odom topic. The values being published on the odom topic appear to be correct

I have recorded a video to better illustrate the problem I’m encountering. You can view it at this link: issue.mkv - Google Drive.

I have also included the transform tree, which should provide more insights into the setup.

Dear @adamzr2000,

The issue is clearly from the go1_control ekf_localization. Please check in go1_control/config/odom_localization_config.yaml whether the data corresponds to the following.

#Configuation for robot Odom EKF
frequency: 50
two_d_mode: true
publish_tf: true

predict_to_current_time: true
# transform_time_offset: 1

odom_frame: odom
base_link_frame: base
world_frame: odom

# X,   Y,   Z
# r,   p,   y,
# X',  Y',   Z'
# r',  p',  y'
# X'', Y'', Z''

odom0: /go1_controller/odom
odom0_config: [true, true, false, 
               true, true, true,
               false, false, false,
               false, false, false,
               false, false, false]
odom0_differential: false
odom0_queue_size: 10

It seems that either your robot is providing false odometry and/or most likely something has been changed in the config file incorrectly.

Dear @Sohail,

Thank you for your guidance on this issue. I have double-checked the odom_localization_config.yaml file in the go1_control/config directory, and I can confirm that it matches the configuration you’ve provided.

Given that the configuration is correct and mirrors your instructions, it seems increasingly likely that the issue is related to the robot providing faulty odometry data.

Could you please advise on the best course of action to troubleshoot or correct this? Are there specific checks or procedures you would recommend to determine the root cause of the faulty odometry data or to rectify it?

BR,

Adam

Yes, the first thing to do is subscribe to the odom data from the ros topic and verify the movement in x- axis. You can use a measuring instrument to mark 1m and move the robot. In this procedure you just verify from the odom topic and not from rviz.

Repeat the procedure for y-axis as well. If both seem correct. Then the next step is to write a short Python script to convert the quaternions in the odom topic to degrees, especially the yaw angle and print the output. Then rotate the robot about its position and see if the rotation corresponds to the real-robot.

Looking at your robot, it seems there is an issue in the imu.

Hi,

I plan to test both the linear movement and the rotational accuracy as per your suggestions. This will indeed help in isolating the issues more effectively.

Given the symptoms and the discrepancies we’ve been observing, it does appear likely that the root of the issue might be related to the IMU. Before proceeding further with external purchases, I wanted to ask if you have any specific advice on addressing potential IMU issues. Are there any calibration steps or diagnostics that you would recommend trying out first to possibly rectify these problems?

Additionally, if purchasing a new IMU sensor is the recommended course of action, could you suggest a model that is known for good compatibility and performance with ROS and the Unitree Go1 robot? Any recommendations or insights you could provide would be greatly appreciated, as I aim to ensure the best possible integration and functionality for the robot’s navigation and orientation capabilities.

Looking forward to your advice.

Best regards,

Adam

I wanted to ask if you have any specific advice on addressing potential IMU issues. Are there any calibration steps or diagnostics that you would recommend trying out first to possibly rectify these problems?

There is in an IMU calibration guide for the go1 in our docs in the calibration section.

I would recommend using the go1_imu as it would save you cost and is the easiest solution. It might be the case that the values being fused in the go1 for you is wrong somehow, you can check the go1_base and see the values there and adjust them there.

The best imu out there is the Lordmicrostrain but it is very expensive. An cost effective alternative is the phidgets one that can easily be integrated with the Go1 and has binaries with 1 line command for installation.

Again I would recommend to try and find the root cause of this imu disturbance as it can cause issue down the line in the normal go1 capabilities.

Regards,
S. O. Sohail

Dear @Sohail ,

Thank you for the prompt response and the guidance. I appreciate your recommendations and agree that starting with an attempt to calibrate the GO1’s onboard IMU is the most straightforward approach.

Following your advice, I’ve attempted to follow the IMU calibration instructions available in the documentation at [GO1 Manuals — GO1 Tutorials 1.0.0 documentation]. However, I am a bit confused as the manual seems tailored for the A1 robot, and I’m working with the GO1, which has led to some confusion.

Here are the steps I’ve taken so far:

  1. Installed the document(EXE) #1 on my Windows PC.

  2. Connected my PC to the robot using a USB-C cable and powered on the robot.

  3. Attempted to execute the document(EXE) #2 to establish a USB serial connection for calibration.

However, my PC is unable to recognize the USB serial connection to the robot, preventing me from proceeding with the following step.

Could you provide any additional insights or specific instructions for the GO1’s model? Perhaps there are steps or settings specific to the GO1 that I need to consider. Any further assistance you can offer to help resolve this connection issue would be greatly appreciated.

Thank you for your continued support.

Best regards,

Adam

@Azib Could you please verify?

Dear @adamzr2000 ,

Kindly inform us if the device appears in the device manager on your computer. Additionally, please attempt to inspect the go1 base and review the IMU data using the command rostopic list . Currently, we have been unable to reach the manufacturer due to the Chinese New Year holidays to gather more information about this issue. However, as soon as we receive any updates, we will promptly notify you.

Dear @Azib, @Sohail

Thank you for your swift response and the troubleshooting suggestions. I would like to inform you that I was able to successfully connect the robot to my computer via the USB-C cable. While the connection did facilitate the retrieval of information related to the motor, firmware, and other system details, there was unfortunately no data pertaining specifically to IMU calibration. I plan to delve into the IMU data topic in ROS more thoroughly to gain a better understanding of the data being output by the IMU sensor.

I look forward to any updates you may be able to provide once communication with the manufacturer is re-established. Thank you once again for your guidance and ongoing support.

Warm regards,

Adam

Dear @Azib @Sohail ,

I hope this message finds you well. I wanted to follow up on the IMU sensor calibration issue with the ROS quadruped robot. Have there been any updates or progress regarding this matter? Your assistance is greatly appreciated.

BR,

Adam

Dear @adamzr2000

Apologies for the delayed response. The manufacturer has sent us the documentation on
how to calibrate the IMU. Please find the documentation attached below.

Hi,

Thanks a lot for your attention and prompt response! I will try it out over these weeks.

Regards,

Adam