laser_frame not moving

asked 2014-08-22 05:06:39 -0500

Chipiron
93 ●4 ●6 ●8

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

edit retag flag offensive close merge delete

Comments

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.

dornhege ( 2014-08-22 05:28:00 -0500 )edit

Yes, they are parent->child. There are any more frames, its the complete chain

Chipiron ( 2014-08-22 05:55:56 -0500 )edit

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.

dornhege ( 2014-08-22 06:04:03 -0500 )edit

Thanks for the reply @dornhege The tf chain was perfect. The problem is explained below. Feel free to ask if I havent explained well.

Chipiron ( 2014-08-22 06:05:13 -0500 )edit

Can you @dornhege mark my answer as correct? I dont have karma > 25

Chipiron ( 2014-08-26 01:12:09 -0500 )edit

add a comment

answered 2014-08-22 06:04:14 -0500

Chipiron
93 ●4 ●6 ●8

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)

edit flag offensive delete link

add a comment

laser_frame not moving

Comments

1 Answer

Question Tools

Stats

Related questions

laser_frame not moving edit

Comments

1 Answer

Question Tools

Stats

Related questions

laser_frame not moving