tf static_transform_publisher breaks laser

asked 2014-11-12 04:33:30 -0500

Pablo Estefó
3 ●2 ●3 ●3

updated 2014-11-12 09:21:03 -0500

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:

Run robot's driver node
- Publishes: /scan (laserScan) and /pose (poseStamped)
- Subscribes: /command_velocity
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.
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.
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.
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.
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.
Finally, when I kill the process of static_transform_publisher, it gets back to behaviour before.

What could be happening here?

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2014-11-12 08:13:49 -0500

IvanV
329 ●15 ●20 ●23

updated 2014-11-12 10:26:04 -0500

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?

edit flag offensive delete link

Comments

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.

Pablo Estefó ( 2014-11-12 09:34:15 -0500 )edit

The time stamp observation is definitely causing this problem. They seem to be about an hour apart. Something is wrong there.

dornhege ( 2014-11-12 10:53:28 -0500 )edit

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.

Pablo Estefó ( 2014-11-25 15:38:06 -0500 )edit

add a comment

answered 2014-11-12 09:38:29 -0500

dornhege

31395 ●134 ●284 ●498

I would forget about gmapping for now and just make sure that the rest works fine. gmapping then usually works without problems. I suspect you have setup you TF chain wrong. You should have something like /odom -> /base_link -> /laser. For each transform in this chain there must be one and only one publisher.

First, don't start your odometry node and check what TF you have (e.g. rosrun tf view_frames and/or check the fixed frames in rviz.). Someone should provide /base_link -> /laser and you should be able to select /base_link as a fixed frame in rviz without errors. This is either provided by your robot, e.g. by URDF + robot_state_publisher or your static_transform_publisher. There must be only one publisher.

Second, if that works start your odometry node. This node must provide odometry TF, that is the /odom -> /base_link TF transform, not only the /odom topic. You should be able to select /odom as a fixed frame in TF. Everything should work fine and driving around you should see the laser being transformed correctly in rviz. If you set the laser display decay high in rviz, you should see an "odometry map" of laser scans.

If all this works fine, gmapping should work fine. If not, fix the step that doesn't work without running anything else that interferes.

edit flag offensive delete link

add a comment

tf static_transform_publisher breaks laser

2 Answers

Comments

Question Tools

Stats

Related questions

tf static_transform_publisher breaks laser edit

2 Answers

Comments

Question Tools

Stats

Related questions

tf static_transform_publisher breaks laser