Revision history [back]

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..

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..

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).

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 they the driver and the odometry node running in separate computers?