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

Jeff Rousseau drzaiusx11 at gmail.com
Mon Sep 20 21:54:38 UTC 2010

Thanks for the quick replies everyone!  The tree is flattened (at
least in ROS 1.2), got it.

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


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

More information about the ros-users mailing list