# rotation of laser and rviz miss position match

Update Question: Is it normal for delayed data in rivz laser not to rotate with odometry changes?

update: Here is a TF view showing current transformations. Should not this also show static latch transformation being published? Do the robot odometry need to do the translation between odometry and the laser frame?

void publishLatchTransforms()
{
geometry_msgs::TransformStamped msg;

msg.transform.translation.x = 0.05;
msg.transform.translation.y = 0;
msg.transform.rotation.x =  0.0;
msg.transform.rotation.y =  0.0;
msg.transform.rotation.z =  0.0;
msg.transform.rotation.w =  1;

msg.transform.translation.z = 0.3;
msg.child_frame_id = "hokuyo_frame";

msg.transform.translation.z = 0.3;
msg.child_frame_id = "camera_frame";
}


update: checking the tf transformations. The only tf transformations that are not zeros are base_link->odom and map->odom. All other transformations are zeros. Even though the robot is in rotation. I am using the robot state publisher and have removed all static transforms from my code except for the laser_frame to the tower_link where it is attached. My updated question is who is responsible for rotating the laser_frame as the base_link turns. The tower_link is fixed to the base_link

I have a laser positioned on a fixed tower attached to my robot which is set to rotate slowly in a circle. I placed a construction cone in front of it. As you can see from the rivz image the laser plot of the code is spread around the robot instead stationary. Where does the issue lie here? I have static latch transforms for the base_link to the laser frame and publish odometry as the robot does rotate to scale as is shown in its gazebo sim.

edit retag close merge delete

What packages do you use? The rotation should be reflected either by a rotation of the tf frame the scan message refers to, or by a shift of the actual scan angles in the message. Make simple tests to check for wrong rotation direction etc.

( 2013-10-15 22:39:06 -0600 )edit

Thanks I did have some static transforms and I removed them but I still get the same results. I have posted an update to the question. The transforms for the laser frame are all zeros. Who publishes these? I think gmapping yes.

( 2013-10-16 02:14:40 -0600 )edit

Sort by » oldest newest most voted
1. Decaying in RViz should look just like it was correct moments before. Read about tf and time in tf tutorials, assuming you read the general tf docs.

2. I sometimes stumble upon, but now cannot find, that usually you are not allowed to modify a message that you gave to a publisher. But if your tf tree is clean, it's ok.

3. gmapping publishes only /map -> /odom. What you need is /base_link -> /hokuyo.., that could be done manually in code, by robot_state_publisher or static_transform_publisher.

But as RViz does display the scan, that transform must exist. EXCEPT you set the base frame in RViz to /hokuyo.., then it obviously would yield that result, as the RViz-View does rotate with the laserscanner!

more

As it turns out I had some real bad time setting. Having corrected that the map and laser stay in alignment. Thank you for the help.

more

Great. For the future: do not post an *answer* when making a *comment*..

( 2013-10-19 03:54:06 -0600 )edit