Ask Your Question

Problem with TF Tree in RPLidar Hector SLAM and Navigation

asked 2019-06-08 23:22:42 -0600

parzival gravatar image

updated 2019-06-08 23:27:21 -0600

I'm a beginner in ROS and Robotics and have problem implementing an autonomous mobile robot.

I'm getting this error:

Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: canTransform: target_frame map does not exist.. canTransform returned after 0.101084 timeout was 0.1.

Firstly, I used chefbot package to make the autonomous navigation using Kinect and depthimage_to_laserscan, and it worked fine. Though there were some problem with reaching the exact position, which I am assuming can be solved by tweaking the parameters in navigation stack. The TF Tree when it ran correctly was the following:

image description

Now, I replace the Kinect with RPLidar and things break. I assumed since, the laserscan will be available at /scan topic, I don't need to fire openni modules and depthimage_to_laserscan. I instead roslaunched rplidar_ros rplidar.launch and hector_slam_tutorial tutorial.launch The TF tree obtained is:

image description

Which obviously seems to be broken, as there is no transform between map and odom and base_link and base_footprint. I think I can fix this by changing some param or args in hector_slam, because that's where the map to base_link. However, I donot know how to do it. I think running additional static transform might help? Something like:

<node pkg="tf" type="static_transform_publisher" name="door2" args="1.25 -4.5 0 0 0 0 /door2 /world 10"/>

Please let me know. Thanks!

PS: I'm using ROS Kinetic

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-06-09 13:40:04 -0600

billy gravatar image

There looks like 2 separate issues:

1 - you need a transform between base_footprint and base_link, which will be done with a static transform assuming they don't rotate relative to each other.

2 - for map to odom: looking at section 2 of this tutorial, you can configure Hector around ODOM and that is likely what you have done. In doing so you probably assign a second parent to base_link and that broke the tree. Only one parent allowed.

To fix this you need to update the config or set up Hector as shown in section 1 of the tutorial. Right now it feels like you're mixing the two methods.

If you intended to set up Hector without reference to ODOM, you need to add this remapping to the launch file

<param name="odom_frame" value="base_footprint" />
edit flag offensive delete link more


So, adding the above line would still give me odom from hector slam right?

parzival gravatar image parzival  ( 2019-06-09 13:44:47 -0600 )edit

I've added transform betweeen base_footprint and base_link in my robot state publisher, so that shouldn't be the problem. As you may see in the tf_tree above, running amcl and gslam doesn't give any error but hector slam breaks the tf_tree. I think the problem as you mentioned might be with the hector_slam launch

parzival gravatar image parzival  ( 2019-06-09 13:47:27 -0600 )edit

Got the same issue, was wondering if you solve the issue. Thanks.

lukelu gravatar image lukelu  ( 2020-09-12 00:44:19 -0600 )edit

Hey, I did get it to work. What issue are you exactly facing? Would be happy to help you :)

parzival gravatar image parzival  ( 2020-09-13 02:13:21 -0600 )edit

Hi parzival, glad to hear from you. I was wondering if you make navigation or exploration working successfully. We are able to receive cmd_vel from navigation stack. But we found the movement is jerky. Maybe a velocity smoother or some config setup is required. Hope to hear your expertise.

lukelu gravatar image lukelu  ( 2020-09-13 02:48:33 -0600 )edit

That seems to be an issue regarding tuning your dwa_planner parameters. What computer are you using as onboard computer for your robot? And what are your base_local_planner params?

parzival gravatar image parzival  ( 2020-09-13 02:57:51 -0600 )edit

parzival, Thanks for your reply. Problem solved after few parameter tuning! The next challenge we get is the path smoothing. We found the planning path is zigzag, which is not efficient. Have you met the same issue ? Hope to hear your expertise on path smoother.

ps: we are using raspberry pi 4 64bit 8GB.

lukelu gravatar image lukelu  ( 2020-09-15 16:54:03 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-06-08 23:22:42 -0600

Seen: 482 times

Last updated: Jun 09 '19