0
$\begingroup$

Rosanswers logo

I am trying to use slam gmapping on a robulab robot with no success. One of the problems is that I have the laser topic working apparently fine (in RViz the points cloud changes as I move the robot), but when I run static_transform_publisher from /base_link to /laser it stop working (in RViz it looks frozen).

I run it like this:

  1. Run robot's driver node

  1. Run odometry node: Basically consumes /pose and provides /odom (Odometry). I know there is a misconception here because the robot's driver node should provide /odom . I will fix, but I think the problem is not here.

  2. Run slam gmapping like this:

    rosrun gmapping slam_gmapping tf_static:=tf

At this point I get the following frames chain: /map -> /odom -> /base_link as you can see here and this is the node graph.

  1. In RViz I check laser's points cloud by manually putting "laser" on fixed frame, and after added LaserScan display and I can see it and it get updated when I move the robot.

I also have this error on terminal running it:

[ WARN] [1415365252.295826588]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_notifier] rosconsole logger to DEBUG for more information.

  1. In some blog posts I've seen that laser frame is published through a static transform through

    rosrun tf static_transform_publisher 0 0 0 0 0 0 /base_link /laser 50.

  2. Then, in RViz the image freezes even trying clicking "Reset" button. On the LaserScan section, in "Status" it appears this error:

"Transform [sender=unknown_publisher] Message removed because it is too old (frame=[/laser],stamp=[1415289470.551291000])".

But also, in the terminal where I run RViz, this is warning message:

[ WARN] [1415365456.608259629]: MessageFilter [target=map ]: The majority of dropped messages were due to messages growing older than the TF cache time. The last message's timestamp was: 1415361856,504979, and the last frame_id was: /odom.

At this point this is the node graph and frames.

  1. Finally, when I kill the process of static_transform_publisher, it gets back to behaviour before.

What could be happening here?

Originally posted by Pablo Estefó on ROS Answers with karma: 3 on 2014-11-12

Post score: 0

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

Rosanswers logo

Just a basic comprobation. Have you tried to launch the static_transform before launching the gmapping and check if the TF tree is correct? Just launch steps 1 (maybe 2 also) and 5 and see in rviz if the laser points move along with the robot when you put base_link as the fixed frame.

Also, the way you launch gmapping seems strange to me. I don't know about the gaming package, but usually slam_gmapping from gmapping package should be launched rosrun gmapping slam_gmapping. Also, slam_gmapping doesn't subscribe to tf_static but to tf, so no remapping should be necessary.

Edit:

I think that probably the problem is in the robot's driver that publishes the /laser topic. My guess is that something makes it to delay the publication of the laserScans and hence it's time stamp is too outdated (maybe some heavy processing, sleep, time locking...). That's why you see the lasers in rviz when the fixed frame is /laser (no TF required) but fails when you change the fixed frame to other frame (tries to use the TF to visualize it, but the laserScan's time stamp is too old).

Also note that there is a huge delay between the last TF published by /tf_out_relay and the ones and published by /static_transform_publisher and /slam_gmapping, which point in the same direction. Are the driver and the odometry node running in separate computers than the static transform publisher and gmapping?

Originally posted by IvanV with karma: 329 on 2014-11-12

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by Pablo Estefó on 2014-11-12:
I tried and I cannot see anything in RViz. It also shows this error message: "Message removed because it is too old (frame=[/laser] stamp=[1415802689.161971000]). The "gaming" package was a typo. I fixed it. Thanks.

Comment by dornhege on 2014-11-12:
The time stamp observation is definitely causing this problem. They seem to be about an hour apart. Something is wrong there.

Comment by Pablo Estefó on 2014-11-25:
The problem was a bug in the custom timestamp module for the robot driver node. It was 1 hour delayed. Once fixed everything worked fine.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.