[Unitree Go1] SLAM using 3D Lidar with Go1 + RS-Helio-16P

Hello Team,

I am trying to enable SLAM in Go1 using RS-Helios-16P 3D LIDAR.
From the blog (Quadruped Robotics Go1 Documentation), I couldn’t find much details on how to set it up.

Current State :

  • Able to bring up lidar and receive the go1/rslidar topics
    lidartopic

  • Able to visualize the topic in rviz

Could you please assist on how to proceed? Do you already have a package for SLAM with 3D Lidar.

And one issue I am facing. I am trying to bringup the lidar in Nvidia 13 board as MASTER, but unable to receive any messages (I can see the topic, but while echoing is empty) But if I do the same with 14 board, it works.

Best Regards,
Vishnu

Dear @Vishnu,

Could you please assist on how to proceed? Do you already have a package for SLAM with 3D Lidar.

Ofcourse. Usually for ROS navigation there are multiple ways to go around it and is usually dependent on the user on how they wish to configure it. As mentioned in the go1 manual pg:13, sec:8.4 the navigation can be performed via odom and or map.

Odom and Map Navigation

To integrate the lidar for obstacle avoidance in odom navigation simply replace the topic to parameter in the go1_navigation/params/costmap_common_params.yaml file

e.g.

  • Change this from
obstacles_layer:
  observation_sources: scan
  track_unknown_space: true
  scan:
    {
      sensor_frame: os_sensor,
      data_type: PointCloud2,
      topic: /ouster/points,
      marking: true,
      clearing: true,
      inf_is_valid: true,
      min_obstacle_height: 0.37,
      max_obstacle_height: 0.5,
      obstacle_range: 5.0, #if beyond this threshold, then will not mark as obstacle
      raytrace_range: 7.0 #5.0 Lower this value to detect nearer obstacles with better accuracy
    }
  • to
obstacles_layer:
  observation_sources: scan
  track_unknown_space: true
  scan:
    {
      sensor_frame: os_sensor,
      data_type: PointCloud2,
      topic: /go1/rslidar_points,
      marking: true,
      clearing: true,
      inf_is_valid: true,
      min_obstacle_height: 0.37,
      max_obstacle_height: 0.5,
      obstacle_range: 5.0, #if beyond this threshold, then will not mark as obstacle
      raytrace_range: 7.0 #5.0 Lower this value to detect nearer obstacles with better accuracy
    }

In here you can configure the height of how far you want the obstacles to be etc. At the end of the go1 manual there are some links on ROS tutorials which I recommend you going through as everything mentioned there is applicable here.

Now you should be able to do the odom navigation as well as map navigation with obstacle avoidance. For map navigation you would require a map pre-built or create it yourself via SLAM

SLAM

The first step is mapping which we recommend to do via SLAM_TOOLBOX (optionally gmapping but not recommended as its quality is not good). It is upto the user on which tools they want to use, however, we would recommend using SLAM_TOOLBOX.

To perform slam with slam_toolbox

  1. Make sure slam_toolbox is installed via:
sudo apt-get install ros-noetic-slam-toolbox # For host pc

or if you are doing it on the robot directly

sudo apt-get install ros-melodic-slam-toolbox # For host pc
  1. You can then modify then go1_navigation point_cloud_to_laser_scan.launch and remove the .xml extension and remap the topic cloud_in to /go1/rslidar_points\
  2. Now launch
roslaunch go1_navigation point_cloud_to_laser_scan.launch

and run slam toolbox via

roslaunch slam_toolbox online_async.launch

The map should be creating now as you move the robot. It is advised to move the robot slowly as you map so that it creates it consistently.

  • To save the map do
rosrun map_server map_saver -f "$(rospack find go1_navigation)/maps/devshop"
  • Once saved you can then run map_navigation (please check and modify the files where necessary, e.g remove ouster lidar launch, remove the xml tag from point cloud to laserscan etc.) to use the robot in the map where it would autonomously localize itself after being provided with the initial position.

Again, I would highly recommend viewing the tutorial mentioned at the end of the manual

Cheers,
S. O. Sohail

Thanks a lot @Sohail for the detailed explanation. I will go through the manual and try and give you feedback.

Could you give me access to the Git repository.
Github ID : Vichu95

And also regarding the issue with NVIDIA board 13. I am not able to get LIDAR up from 13 (with board 14 it works fine)
image

Also I am seeing this error.

Best Regards,
Vishnudev

Dear @Vishnu,

The lidar will work only on the board that it is physically connected to, this case bing 14 board. Also we have added sent you an invite for the repository.

I got access. Thank you :+1:

Oh okay, so the Ethernet is internally connected to Board 14.

Why I wanted to try with board13 is because it allows me to have separate working environments from my colleague. He is using board 14 for his development, and I am using board 13.

Anyways. Thank you.
I will give you feedback after I try the SLAM.

Hello @Sohail,

I was able to do SLAM and save the map.

I am unable to do navigation with the saved map. I am not 100% sure how to setup the files. This is how I tried.
→ Run the bringup.launch [NVideo 14]
→ Run the lidars.launch [NVideo 14]
→ Run map_navi.launch [NVideo 13]
But there a error that the ekf_localization is already present (in bringup). With this both nodes get killed. So I cancel this launch file and re-executed.
→ Even tried running the slam box node [My PC] parallel.

My expectation is :
→ I should be able to see the map, laser scan, robot in rviz[My PC]
→ Robot dog moves is localized and when moved using teleop keyboard, reflects same in rviz
→ Use the navgiation button in rviz to make the robot move from A to B

But I am getting errors like either the map and robot are not aligned. Or the transformers are missing from map/odom to other frames. I am not sure what should be the fixed frame in rviz : odom or map.
I tried multiple times to debug but unable to proceed. One time there was missing transform between odom and base, which causes transforms from ‘robosense’ (frame for LIDAR ) to odom is missing which gives error for that topic in rviz.


These errors are seen in the map_navi.launch. I verified in ros topic that /scan is published.

I really havent understood properly the transformers, so there is big chance that it would be something very small like frame name mismatch.

Thank you for your support,
Best regards,
Vishnu

Dear @Vishnu,

Please check the bringup and map_navi launch files to check if there is no duplicated ekf/localization launch files running. Usually bringup has ekf for odom navigation and map_navi has ekf for GPS localization. If both are running and using the same params then you may have to deactivate on of them probably the one for map navi.

Once you start the map navi,

  1. The first step is to make sure the frame is set to map
  2. The second step is to give it a pose estimate of where the robot should be on the map

Also, ensure that the params in the navigation folder match the map name! and ensure the map is in the map folder!

Hello @Sohail ,

Thank you. I deactivated the ekf in map navi and triggered bringup, then lidar and then map navi.
I was getting errors that there are missing transforms from robosense(which is the lidar frame ) to base_link. For temporary solution, i added a dummy base_link in the robot.urdf.

After that it was working.

But when i try to set goal, there is error in map navi.

I guess in some files base link is ‘base_link’ and in robot urdf it is ‘base’.
Do you know which files to be modified for this?

Do you see the map that you created in the viz when you load it up?

@Sohail Yes map is shown properly.
I am getting error when I trigger an end point using 2D Nav Goal.

[ WARN] [1711097418.451932837]: Failed to transform initial pose in time (Lookup would require extrapolation into the future.  Requested time 1711101209.839308654 but the latest data is at time 1711097418.437769890, when looking up transform from frame [odom] to frame [base_link])
[ WARN] [1711097440.181598037]: Control loop missed its desired rate of 30.0000Hz... the loop actually took 1.9185 seconds

Its one of 2 things the ekf for odom to baseline is incorrect and/or you to increase the ekf pub frequency as well as the transform tolerances.

I increased the transform tolerances from 1 to 5, and the ekf pub frequency from 50 to 100.
But I still notice the same warnings.

[ WARN] [1711100277.882669872]: Control loop missed its desired rate of 30.0000Hz... the loop actually took 3.8076 seconds
[ WARN] [1711100277.884873257]: Map update loop missed its desired rate of 5.0000Hz... the loop actually took 3.8073 seconds

And while testing, the robot moved few times (random time duration, small movements).
But didn’t happen every time.

I am not sure what how to proceed. Could you please guide me in debugging?

One more update. The robot was able to move straight from one corner to another. But it took time. After triggering from rviz, no movement for some minutes, then suddenly two steps. then no movement. Then after sometime again two steps. This continued for some time.

The warnings are still received

The reason is that the controller should be running directly on where the PC is, it seems that there are network connection latency causing the lag

I couldn’t get you correctly. Only RVIZ is running in my PC and rest of the code is running in the go1 controller 14.

And I also noticed that when we set a goal in RVIZ, only a single message is transmitted via the move_base/goal, which should be used in the navigation stack in Controller 3 (executing in the map_navi.launch)

So I am not sure were the lag could be.
@Sohail Could you please give more details. Thank you again.

Another update : Today i noticed that cmd_vel is published but there is no robot movement. I heard somewhere that there is a minimum velocity needed by go1 to do a movement. Have you faced any such limitation?

Snapshot of few values:

linear: 
  x: -0.018917845728029244
  y: 0.0360765953616248
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: -0.018917845728029244
  y: 0.0360765953616248
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: -0.018917845728029244
  y: 0.0360765953616248
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: 0.0
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.0
---
linear: 
  x: -0.018904597466091348
  y: 0.036072159715077726
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: -0.018904597466091348
  y: 0.036072159715077726
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: -0.018904597466091348
  y: 0.036072159715077726
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---
linear: 
  x: -0.018904597466091348
  y: 0.036072159715077726
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11
---

It might be name spaces, the place in movebased that is publishing to cmd_vel may have to be change to go1/cmd_vel or whatever is written in the topic. There should be no issue of minimum velocity in this case

@Sohail I havent used any name space.

These are my topic list

/amcl/parameter_descriptions
/amcl/parameter_updates
/amcl_pose
/battery_state
/cmd_vel
/diagnostics
/e_stop
/go1/rslidar_points
/go1_controller/cmd_vel
/go1_controller/imu/data
/go1_controller/odom
/go1_controller/state
/initialpose
/joint_states
/joy_teleop/cmd_vel
/joy_teleop/joy
/joy_teleop/joy/set_feedback
/local_ekf/set_pose
/map
/map_metadata
/motor_states
/move_base/GlobalPlanner/parameter_descriptions
/move_base/GlobalPlanner/parameter_updates
/move_base/GlobalPlanner/plan
/move_base/GlobalPlanner/potential
/move_base/TebLocalPlannerROS/global_plan
/move_base/TebLocalPlannerROS/local_plan
/move_base/TebLocalPlannerROS/obstacles
/move_base/TebLocalPlannerROS/parameter_descriptions
/move_base/TebLocalPlannerROS/parameter_updates
/move_base/TebLocalPlannerROS/teb_feedback
/move_base/TebLocalPlannerROS/teb_markers
/move_base/TebLocalPlannerROS/teb_poses
/move_base/TebLocalPlannerROS/via_points
/move_base/cancel
/move_base/current_goal
/move_base/feedback
/move_base/global_costmap/costmap
/move_base/global_costmap/costmap_updates
/move_base/global_costmap/footprint
/move_base/global_costmap/parameter_descriptions
/move_base/global_costmap/parameter_updates
/move_base/global_costmap/static_layer/parameter_descriptions
/move_base/global_costmap/static_layer/parameter_updates
/move_base/goal
/move_base/local_costmap/costmap
/move_base/local_costmap/costmap_updates
/move_base/local_costmap/footprint
/move_base/local_costmap/inflater_layer/parameter_descriptions
/move_base/local_costmap/inflater_layer/parameter_updates
/move_base/local_costmap/obstacles_layer/parameter_descriptions
/move_base/local_costmap/obstacles_layer/parameter_updates
/move_base/local_costmap/parameter_descriptions
/move_base/local_costmap/parameter_updates
/move_base/parameter_descriptions
/move_base/parameter_updates
/move_base/result
/move_base/status
/move_base_quadruped/cmd_vel
/move_base_simple/goal
/nodelet_manager/bond
/odometry/filtered
/particlecloud
/rosout
/rosout_agg
/scan
/statistics
/tf
/tf_static
/twist_marker_server/cmd_vel
/twist_marker_server/feedback
/twist_marker_server/update
/twist_marker_server/update_full
/velocity_smoother/parameter_descriptions
/velocity_smoother/parameter_updates

And rqt graph output

When i tried with dwa local planner, I am getting these errors. Right now i am using teb planner.

And also after running roswtf, i got these error. I couldnt understand these.

Found 2 warning(s).
Warnings are things that may be just fine, but are sometimes at fault

WARNING The following node subscriptions are unconnected:
 * /joy_teleop/joy_node:
   * /joy_teleop/joy/set_feedback
 * /rviz_1711376397023336659:
   * /map_updates
 * /local_ekf/ekf_localization_with_odom:
   * /local_ekf/set_pose
 * /rqt_gui_py_node_34704:
   * /statistics
 * /twist_mux:
   * /e_stop
 * /twist_marker_server:
   * /twist_marker_server/feedback
 * /move_base:
   * /move_base/cancel

WARNING Received out-of-date/future transforms:
 * receiving transform from [/local_ekf/ekf_localization_with_odom] that differed from ROS time by -276899.060773372s
 * receiving transform from [/robot_state_publisher] that differed from ROS time by -276899.061405659s
 * receiving transform from [/amcl] that differed from ROS time by -276894.071450233s


Found 1 error(s).

ERROR The following nodes should be connected but aren't:
 * /move_base->/move_base (/move_base/local_costmap/footprint)
 * /robot_state_publisher->/rqt_gui_py_node_37123 (/tf_static)
 * /move_base->/move_base (/move_base/global_costmap/footprint)

Dear Vishnu,

I believe the robot is detecting itself as an obstacle that is why the plan is being aborted. Yo can verify this if there are some points showing up where the robot is.

As for the warnings, they can safely be ignored.

We can set a short meeting, to resolve this issue if you are available. Please email support@mybotshop.de for your availability.

Hi @Sohail ,
You were right, there were some laser points on the robot (i guess on arm). I increased the min_distance in rs_config.yaml from 0.2 to 0.4 and the points were removed.

But still the behaviour with dwa is same.

[ INFO] [1711099024.862246339]: Got new plan
[ WARN] [1711099024.864585766]: DWA planner failed to produce path.
[ INFO] [1711099024.895567693]: Got new plan
[ WARN] [1711099024.897952850]: DWA planner failed to produce path.
[ERROR] [1711099024.928948318]: Aborting because a valid control could not be found. Even after executing all recovery behaviors

I tried again with teb planner. The robot was moving here and then. No continuous movements. I echoed the /go1_controller/cmd_vel topic and i was able to see values published but no movement in robot.

linear: 
  x: 0.08693150590306173
  y: 0.06170442124465893
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.11

Then i tried to publish this value directly without any navigation launch and also noticed the robot isnt moving. I increased the linear:x to 0.12 and was able to move the robot. With 0.1, 0.11 , the robot didnt move. But with 0.111, robot moved indicating that is the minimum velocity needed by robot to move.

So the move_base were publishing very small values somehow and robot didnt move. Whenever the value is greater than 0.11, it causes the robot to move.