Wierd TF tree when running RGB-D Slam
Hey, I have rgbdslam package installed which was released during end of February 2013.
I am running the Rgbdslam node using the following parameters for the frames.
<param name="config/fixed_frame_name" value="/map"/>
<param name="config/base_frame_name" value="/base_footprint"/>
Then i send the model from the GUI of the RGBDslam to the octomap server using the CTRL+M command. The Octomap server has the following params for the frames.
<param name="frame_id" type="string" value="/map" /> <param name="base_frame_id" value="/camera_rgb_optical_frame" />
Meanwhile in another terminal i use the command "rosrun tf view_frames".
The frame tree that is seen is displayed below.
As seen in the above screen shot there is a loop present in the tf tree which should not be there.
What could be a possible solution to the above problem.? Any help would be much appreciated.
--EDIT-- @tfoote I was able to write a tf broadcaster which would imitate the faulty tf tree. Here is a screenshot of the imitated faulty tree.
The three code snippets that were used were
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(odom_quat, tf::Vector3(0.0, 0.0, 0.0)),
ros::Time::now(),"base_footprint", "map"));
r.sleep();
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(odom_quat, tf::Vector3(0.0, 0.0, 0.0)),
ros::Time::now(),"map", "base_footprint"));
r.sleep();
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(odom_quat, tf::Vector3(0.0, 1.0, 2.0)),
ros::Time::now(),"map", "where_mocap_should_be"));
r.sleep();
Looks like a bug. Does it cause any problems?
I tried to visualize the relative movements of frames in Rviz. The movement is not faulty which means that frames are moving the way the actual camera is moving. So no problem on that part. Is there some other problem which could bother later because of the faulty tf tree ..?
That is odd. Can you reproduce a graph like that using simple tf publisher examples?
@tfoote I have not really tried to imitate the tf tree using a self written tf publisher. How would this help.? I mean if i could write one how would it be useful in debugging the problem.?
I'd like to be able to isolate it and reproduce it for debugging/fixing as just a tf problem instead of needing to run the full rgbdslam system to test and debug. If you can reproduce it that way I'll turn it into a ticket.
Thanks. Ticketed here: https://github.com/ros/geometry/issues/10