laser_frame not moving

Question

I have the following scheme in simulation enviroment with Gazebo and Rviz: laser_frame -> base_link -> base_stabilized -> base_footprint -> odom -> map -> world

laser_frame to base_link is provided by robot_state_publisher looking up in the urdf file

base_link -> base_stabilized -> base_footprint -> odom is provided by a 'message_to_tf' node that takes ground_truth topic with z axis and rotation to publish this transformations

odom -> map is provided by a mapper node setting up the transforms in x-axis and y-axis

map -> world is provided by a node doing a static/fixed transform

In Rviz we have as fixed frame and target frame the /world frame. World is fixed, map is fixed refering to world, odom is moving in x,y,z and rotation refering to map BUT base_footprint, base_link and therefore laser_frame arent moving. They keep as they started.

How can I fix it? What am I missing?

Thanks

---

Originally posted by Chipiron on ROS Answers with karma: 93 on 2014-08-22

Post score: 0

---

Original comments

Comment by dornhege on 2014-08-22:
Are the "->" arrows here displaying parent->child arrows? If yes, are there maybe more frames? Then you'd have multiple parents and TF will do unpredictable stuff.

Comment by Chipiron on 2014-08-22:
Yes, they are parent->child. There are any more frames, its the complete chain

Comment by dornhege on 2014-08-22:
Usually they are all the other way around. If it is exactly one chain it should work though. You can add a TF display and see if everything is connected.

Comment by Chipiron on 2014-08-22:
Thanks for the reply @dornhege The tf chain was perfect. The problem is explained below. Feel free to ask if I havent explained well.

Comment by Chipiron on 2014-08-26:
Can you @dornhege mark my answer as correct? I dont have karma > 25

Answer 1

The error was in the odometry sent to 'message_to_tf' node. Message_to_tf is meant to provide intermediate transforms between /base_link and /odom. Odom is my odometry without z value so it was moving, but base_link wasnt. Why? I was passing to 'message_to_tf' and odometry message identical to ground_truth published by Gazebo but with x,y position and rotation set to 0. The problem is that z rotation wasnt 0 so odom moved in yaw but base_link kept static.

So the answer is: In the following scenario (quadrotor flying), being /odom the odometry without z-value, the odometry message that we must pass to 'message_to_tf' to obtain intermediate transforms between /odom and /base_link (defined in the urdf file) must have only the z component of position and all the remain values to 0 (keeping quaternion normalized)

---

Originally posted by Chipiron with karma: 93 on 2014-08-22

This answer was ACCEPTED on the original site

Post score: 0