[ros-users] URDF -> robot_state_publisher -> TF confusion

Wim Meeussen meeussen at willowgarage.com
Tue Sep 21 00:49:55 UTC 2010


The robot state publisher flattens the tree to improve computational
efficiency of your tf listener. With a flat tree, you can compute the
transform between any two frames by only combining two poses. The
flattened tree should not have any other effect on your tf tree


On Mon, Sep 20, 2010 at 2:54 PM, Jeff Rousseau <drzaiusx11 at gmail.com> wrote:
> Thanks for the quick replies everyone!  The tree is flattened (at
> least in ROS 1.2), got it.
> Tully,
> It's true, on a real iRobot Create there is no way to get at the
> caster's transform data, but in my gazebo-simulated Create all joint
> states should published, correct?
> It's strange because the 'rear wheel' has transform data (tested with
> 'rosrun tf tf_echo /map /rear_wheel_link' which returns a valid
> transform), but the 'caster_wheel_link' is omitted from the transform
> tree entirely.  Any ideas why?
> PS How should rotational casters be defined in a URDF so as to not
> give transform errors when there are no available joint states being
> published (because there is no encoder or sensory information
> available for that joint)? Or should errors in these cases just be
> ignored
> Jeff
> On Mon, Sep 20, 2010 at 3:17 PM, Tully Foote <tfoote at willowgarage.com> wrote:
>> Hi Jeff,
>> robot_state_publisher does flatten the tree.  It makes the code slightly
>> simpler to publish.  In the next iteration it will likely replecate the tree
>> structure when publishing.  The tree despite being flattened on publishing
>> is being computed fully internally.
>> With respect to your missing links.  Areyou publishing a joint state for
>> the base_caster_support_joint?  Based on the name and my knowledge of the
>> Create.  I would guess that you're not publishing that joint angle.
>>  robot_state_publisher will prune the tree at where it does not get joint
>> state data.  For without data that entire branch of the tree is invalid.
>> Tully
>> Re: fake_localization.  It simply republishes odometry at whatever frequency
>> it receives odometry.  You'll want to slow down the odometry publishing from
>> within gazebo.
>> On Mon, Sep 20, 2010 at 11:55 AM, Jeff Rousseau <drzaiusx11 at gmail.com>
>> wrote:
>>> Hi All,
>>> Attached is the output of 'rosrun tf view_frames' showing the
>>> transforms being published by robot_state_publisher based on the URDF
>>> for my iRobot Create (also attached) as well the output of "rosrun
>>> urdf urdf_to_graphiz irobot_create_full.urdf.xacro" showing the links
>>> and joints that make up my URDF.
>>> I'm a bit confused as to why these two trees don't match. Why is
>>> 'robot_state_publisher' flattening the URDF tree and rearranging some
>>> connections when outputting to TF? According to the URDF base_link
>>> should be the parent of base_link_left/right_motor_link and the motor
>>> links should be the parent of the wheel links...
>>> I think this is related, but not entirely sure: when I add the model
>>> to rviz I get the following warnings:
>>> ----------
>>> caster_wheel_link
>>> No transform from [caster_wheel_link] to [/map]
>>> base_caster_support_link
>>> No transform from [base_caster_support_link] to [/map]
>>> ----------
>>> Any input, ideas as to whats going wrong/what I'm doing wrong?
>>> (my guess is that I'm making an incorrect assumption that there is a
>>> 1-to-1 correspondence between how gazebo and ros handle coordinate
>>> frames)
>>> PS on a slightly unrelated note: tf_frames.pdf shows gazebo publishing
>>> the /odom topic at 100hz, is there a way to change this rate? I'm
>>> trying to squeeze as many cycles out of my old hardware as I can, so
>>> I'm trying to avoid over-publishing on my topics to cut down CPU usage
>>> (as it is now gazebo in 'top' is claiming 90-100% of my cpu).  I tried
>>> adding a < param name="publish_frequency" type="double" value="10.0"
>>> /> to fake_localization node in my launch file, but it didn't take...
>>> Jeff
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>> --
>> Tully Foote
>> Systems Engineer
>> Willow Garage, Inc.
>> tfoote at willowgarage.com
>> (650) 475-2827
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

Wim Meeussen
Willow Garage Inc.

More information about the ros-users mailing list