URDF -> robot_state_publisher -> TF confusion

[Jeff Rousseau]

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

[Tully Foote]

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.

Post by Jeff Rousseau
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
----------
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
https://code.ros.org/mailman/listinfo/ros-users

[Jeff Rousseau]

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

Post by Tully Foote
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.

Post by Jeff Rousseau
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
----------
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
https://code.ros.org/mailman/listinfo/ros-users

--
Tully Foote
Systems Engineer
Willow Garage, Inc.
[phone]
_______________________________________________
ros-users mailing list
https://code.ros.org/mailman/listinfo/ros-users

[Wim Meeussen]

Jeff,

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
though.

Wim

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

Post by Tully Foote
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.

Post by Jeff Rousseau
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
----------
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
https://code.ros.org/mailman/listinfo/ros-users

--
Tully Foote
Systems Engineer
Willow Garage, Inc.
[phone]
_______________________________________________
ros-users mailing list
https://code.ros.org/mailman/listinfo/ros-users

_______________________________________________
ros-users mailing list
https://code.ros.org/mailman/listinfo/ros-users

[pol.monso]

I'm basically doing the same thing as Jeff here, I have a node publishing
the jointState's messages on /joint_state topic. What I understood from
http://www.ros.org/wiki/robot_state_publisher/Tutorials/Using%20the%20robot%20state%20publisher%20on%20your%20own%20robot
is that the robot_state_publisher would subscribe to the /joint_state topic
and together with the urdf model from the parameter server it would send the
appropriate poses of each link to the tf listener (rviz for that matter).

I can't get rid of the "No transform from /whatever /odom" message. The only
transform available is the one I specifically send from the /odom to the
root node of my urdf model.

The launch file content follows in case it were of any help, any further
information necessary let me know. The urdf model is correctly parsed,
flatten out and displayed collapsed on rviz.

Pol Monsó

http://ros-users.122217.n3.nabble.com/file/n1911159/wam.launch wam.launch

[Andreas Vogt]

Hi Pol,


I think you need the joint_state publisher:

<launch>
<param name="robot_description" textfile="robot.xml" />
<node name="robot_state_publisher" pkg="robot_state_publisher"
type="state_publisher" output="screen" />
<node name="joint_state_publisher" pkg="joint_state_publisher"
type="joint_state_publisher" output="screen" />
</launch>

Andreas

Post by pol.monso
I'm basically doing the same thing as Jeff here, I have a node publishing
the jointState's messages on /joint_state topic. What I understood from
http://www.ros.org/wiki/robot_state_publisher/Tutorials/Using%20the%20robot%20state%20publisher%20on%20your%20own%20robot
is that the robot_state_publisher would subscribe to the /joint_state topic
and together with the urdf model from the parameter server it would send the
appropriate poses of each link to the tf listener (rviz for that matter).
I can't get rid of the "No transform from /whatever /odom" message. The only
transform available is the one I specifically send from the /odom to the
root node of my urdf model.
The launch file content follows in case it were of any help, any further
information necessary let me know. The urdf model is correctly parsed,
flatten out and displayed collapsed on rviz.
Pol Monsó
http://ros-users.122217.n3.nabble.com/file/n1911159/wam.launch wam.launch

--
Andreas Vogt
Logistics and Production Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: [phone]
Fax: [phone]
E-Mail: ***@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

[pol.monso]

I believe that's equivalent to the wam_node in my launch file. I attach my
resulting rxgraph in case it helps.
Loading Image...

[Wim Meeussen]

I attach my resulting rxgraph in case it helps.
http://ros-users.122217.n3.nabble.com/file/n1911467/Captura.png

The node graph shows that the robot_state_publisher node is not
connected to the joint_states topic. You might have a typo in your
topic names or remappings.

Wim

[pol.monso]

Hello Wim,

The two nodes not being connected was what I noticed too. I am using
the robot_state_publisher as showed similarly in
http://www.ros.org/wiki/urdf/Tutorials/Using%20urdf%20with%20robot_state_publisher
which I managed to get working.

If the state_publisher is supposed to automatically connect to the
joint_states topic, what could prevent it to do so?

I've discovered it is somehow related to the urdf model, since running only with

<launch>
<param name="robot_description" command="cat $(find
wam_node)/src/wamurdf/model.xml" />
<!-- <param name="robot_description" command="cat $(find
wam_node)/src/wamurdf/barrettwam_urdf/barrettwam.xml" /> -->
<node name="robot_state_publisher" pkg="robot_state_publisher"
type="state_publisher" />
</launch>

with the robot_state_publisher tutorial model spawns the
robot_state_publisher waiting to subscribe to joint_states (checked on
rxgraph), while if I use the model I have, the robot_state_publisher
is spawned with subscriptions: none.

Since there's no error message, the model was successfully parsed and
is therefore not related at all with my code on wam_node, what could
induce that behaviour? The two models are quite different, on mine all
joints are of type fixed and rely on stl meshes. I can't see what's
the relation between the model and the state_publisher not wanting to
subscribe to joint_states.

What am I missing?

Pol Monsó

2010/11/16 Wim Meeussen [via ROS-Users]

Post by Wim Meeussen

I attach my resulting rxgraph in case it helps.
http://ros-users.122217.n3.nabble.com/file/n1911467/Captura.png

The node graph shows that the robot_state_publisher node is not
connected to the joint_states topic. You might have a typo in your
topic names or remappings.
Wim
--
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
________________________________
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1912494.html
To unsubscribe from URDF -> robot_state_publisher -> TF confusion, click
here.

<robot name="r2d2">
<link name="link1">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>
<visual>
<origin xyz="0 0 0" rpy="1.57 0 0" />
<geometry>
<cylinder radius="0.01" length=".5" />
</geometry>
<material name="gray">
<color rgba=".2 .2 .2 1" />
</material>
</visual>

<collision>
<origin xyz="0 0 0" rpy="1.57 0 0" />
<geometry>
<cylinder radius="0.01" length=".5" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<link name="link2">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<origin xyz="0 0 -.3" />
<geometry>
<box size=".20 .10 .8" />
</geometry>
<material name="white">
<color rgba="1 1 1 1"/>
</material>
</visual>

<collision>
<origin xyz="0 0 -.3" />
<geometry>
<box size=".20 .10 .8" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint12" type="fixed">
<origin xyz="0 .30 0" />
<parent link="link1"/>
<child link="link2"/>
</joint>

<link name="link3">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<origin xyz="0 0 -.3" />
<geometry>
<box size=".20 .10 .8" />
</geometry>
<material name="white">
<color rgba="1 1 1 1"/>
</material>
</visual>

<collision>
<origin xyz="0 0 -.3" />
<geometry>
<box size=".20 .10 .8" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint13" type="fixed">
<origin xyz="0 -.30 0" />
<parent link="link1"/>
<child link="link3"/>
</joint>

<link name="link4">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<origin xyz="0 0 -0.2" />
<geometry>
<cylinder radius=".20" length=".6"/>
</geometry>
<material name="white"/>
</visual>

<collision>
<origin xyz="0 0 0.2" />
<geometry>
<cylinder radius=".20" length=".6"/>
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint14" type="revolute">
<parent link="link1"/>
<child link="link4"/>
<origin xyz="0 0 0" rpy="0 0 0" />
<axis xyz="0 1 0" />
<limit upper="0" lower="-.5" effort="10" velocity="10" />
</joint>

<link name="link5">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<geometry>
<sphere radius=".4" />
</geometry>
<material name="white" />
</visual>

<collision>
<origin/>
<geometry>
<sphere radius=".4" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint45" type="continuous">
<origin xyz="0 0 0.1" />
<axis xyz="0 0 1" />
<parent link="link4"/>
<child link="link5"/>
</joint>

<link name="link6">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<origin xyz="0 0 -.1" />
<geometry>
<cylinder radius=".02" length=".2" />
</geometry>
<material name="gray" />

</visual>

<collision>
<origin/>
<geometry>
<cylinder radius=".02" length=".2" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint56" type="prismatic">
<origin xyz=".12 0 .15" />
<axis xyz="0 0 1" />
<limit upper="0" lower="-.5" effort="10" velocity="10" />
<parent link="link5"/>
<child link="link6"/>
</joint>

<link name="link7">
<inertial>
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
<origin/>
</inertial>

<visual>
<geometry>
<box size=".05 .05 .05" />
</geometry>
<material name="blue" >
<color rgba="0 0 1 1" />
</material>
</visual>

<collision>
<origin/>
<geometry>
<box size=".05 .05 .05" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="joint67" type="fixed">
<origin xyz="0 0 0" />
<parent link="link6"/>
<child link="link7"/>
</joint>

</robot>

<robot name="barrettwam">
<link name="wam0">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam0-geom">
<mesh filename="file:wam0.stl"/>
</geometry>
<material name="wam0-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam0-geom">
<mesh filename="file:wam0.stl"/>
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam1">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam1-geom">
<mesh filename="file:wam1.stl"/>
</geometry>
<material name="wam1-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam1-geom">
<mesh filename="file:wam1.stl"/>
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam2">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam2-geom">
<mesh filename="file:wam2.stl" />
</geometry>
<material name="wam2-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam2-geom">
<mesh filename="file:wam2.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam3">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam3-geom">
<mesh filename="file:wam3_joint_encoder.stl" />
</geometry>
<material name="wam3-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam3-geom">
<mesh filename="file:wam3_joint_encoder.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam4">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam4-geom">
<mesh filename="file:wam4.stl" />
</geometry>
<material name="wam4-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam4-geom">
<mesh filename="file:wam4.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam5">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam5-geom">
<mesh filename="file:wam5.stl" />
</geometry>
<material name="wam5-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam5-geom">
<mesh filename="file:wam5.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam6">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam6-geom">
<mesh filename="file:wam6.stl" />
</geometry>
<material name="wam6-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam6-geom">
<mesh filename="file:wam6.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="wam7">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam7-geom">
<mesh filename="file:wam7_280.stl" />
</geometry>
<material name="wam7-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="wam7-geom">
<mesh filename="file:wam7.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<link name="finger0_0">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_0-geom">
<mesh filename="file:bh_link1.stl" />
</geometry>
<material name="finger0_0-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_0-geom">
<mesh filename="file:bh_link1.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger0_1">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<material name="finger0_1-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger0_2">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_1-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<material name="finger0_1-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger0_1-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<link name="finger1_0">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_0-geom">
<mesh filename="file:bh_link1.stl" />
</geometry>
<material name="finger1_0-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_0-geom">
<mesh filename="file:bh_link1.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger1_1">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<material name="finger1_1-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger1_2">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_2-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<material name="finger1_2-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger1_2-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger2_1">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger2_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<material name="finger2_1-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger2_1-geom">
<mesh filename="file:bh_link2.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>
<link name="finger2_2">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0" />
<mass value="1"/>
<inertia ixx="100" ixy="0" ixz="0" iyy="100" iyz="0" izz="100" />
</inertial>
<visual>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger2_2-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<material name="finger2_2-mat">
<color rgba="0.75 0.75 0.75 1.0"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 0 0" />
<geometry name="finger2_2-geom">
<mesh filename="file:bh_link3.stl" />
</geometry>
<contact_coefficients mu="0" kp="1000.0" kd="1.0"/>
</collision>
</link>

<joint name="wam1" type="fixed">
<parent link="wam0"/>
<child link="wam1"/>
</joint>

<joint name="wam2" type="fixed">
<parent link="wam1"/>
<child link="wam2"/>
</joint>
<joint name="wam3" type="fixed">
<parent link="wam2"/>
<child link="wam3"/>
</joint>
<joint name="wam4" type="fixed">
<parent link="wam3"/>
<child link="wam4"/>
</joint>
<joint name="wam5" type="fixed">
<parent link="wam4"/>
<child link="wam5"/>
</joint>
<joint name="wam6" type="fixed">
<parent link="wam5"/>
<child link="wam6"/>
</joint>
<joint name="wam7" type="fixed">
<parent link="wam6"/>
<child link="wam7"/>
</joint>
<joint name="finger0_0" type="fixed">
<parent link="wam7" />
<child link="finger0_0" />
</joint>

<joint name="finger0_1" type="fixed">
<parent link="finger0_0" />
<child link="finger0_1" />
</joint>
<joint name="finger0_2" type="fixed">
<parent link="finger0_1" />
<child link="finger0_2" />
</joint>

<joint name="finger1_0" type="fixed">
<parent link="wam7" />
<child link="finger1_0" />
</joint>

<joint name="finger1_1" type="fixed">
<parent link="finger1_0" />
<child link="finger1_1" />
</joint>
<joint name="finger1_2" type="fixed">
<parent link="finger1_1" />
<child link="finger1_2" />
</joint>

<joint name="finger2_1" type="fixed">
<parent link="wam7" />
<child link="finger2_1" />
</joint>

<joint name="finger2_2" type="fixed">
<parent link="finger2_1" />
<child link="finger2_2" />
</joint>
</robot>

[Wim Meeussen]

Post by pol.monso
The two nodes not being connected was what I noticed too. I am using
the robot_state_publisher as showed similarly in
http://www.ros.org/wiki/urdf/Tutorials/Using%20urdf%20with%20robot_state_publisher
which I managed to get working.
If the state_publisher is supposed to automatically connect to the
joint_states topic, what could prevent it to do so?

It will automatically connect if the names of the topics match up. You
can check what it is trying to connect to by using "rosnode info
robot_state_publisher". The joint_states topic should be listed as one
of the subscribed topics. Also, the "rostopic info joint_states"
command is useful for debugging this.

Let me know if you have any more questions.

Wim

[pol.monso]

Well, everything seems correct and yet it does not try to connect. The
rosnode info robot_state_publisher output is the same as shown on
rxgraph when mouseovering on the node right?

Since it works with the tutorial urdf model, I'll try to isolate the problem.

2010/11/16 Wim Meeussen [via ROS-Users]

Post by Wim Meeussen

Post by pol.monso
The two nodes not being connected was what I noticed too. I am using
the robot_state_publisher as showed similarly in
http://www.ros.org/wiki/urdf/Tutorials/Using%20urdf%20with%20robot_state_publisher
which I managed to get working.
If the state_publisher is supposed to automatically connect to the
joint_states topic, what could prevent it to do so?

It will automatically connect if the names of the topics match up. You
can check what it is trying to connect to by using "rosnode info
robot_state_publisher". The joint_states topic should be listed as one
of the subscribed topics. Also, the "rostopic info joint_states"
command is useful for debugging this.
Let me know if you have any more questions.
Wim
--
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
________________________________
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913215.html
To unsubscribe from URDF -> robot_state_publisher -> TF confusion, click
here.

[John Hsu]

Hi,
All the joints in your urdf are fixed joints. For robot state publisher to
work, you need a revolute or prismatic joint in your robot.
John

On Tue, Nov 16, 2010 at 1:33 PM, pol.monso

Post by pol.monso
Well, everything seems correct and yet it does not try to connect. The
rosnode info robot_state_publisher output is the same as shown on
rxgraph when mouseovering on the node right?
Since it works with the tutorial urdf model, I'll try to isolate the problem.
2010/11/16 Wim Meeussen [via ROS-Users]

Post by Wim Meeussen

Post by pol.monso
The two nodes not being connected was what I noticed too. I am using
the robot_state_publisher as showed similarly in

http://www.ros.org/wiki/urdf/Tutorials/Using%20urdf%20with%20robot_state_publisher

Post by Wim Meeussen

Post by pol.monso
which I managed to get working.
If the state_publisher is supposed to automatically connect to the
joint_states topic, what could prevent it to do so?

It will automatically connect if the names of the topics match up. You
can check what it is trying to connect to by using "rosnode info
robot_state_publisher". The joint_states topic should be listed as one
of the subscribed topics. Also, the "rostopic info joint_states"
command is useful for debugging this.
Let me know if you have any more questions.
Wim
--
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
________________________________

http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913215.html

Post by Wim Meeussen
To unsubscribe from URDF -> robot_state_publisher -> TF confusion, click
here.

--
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913402.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
https://code.ros.org/mailman/listinfo/ros-users

[pol.monso]

Thanks John!

I'll set them appropiatelly right away, it sounds like it. For the
record, I guess I can alternativelly compute the FK of each joint
myself and publish them to /tf.

Thank you all,

Pol Monsó

2010/11/16 John Hsu [via ROS-Users]

Hi,
All the joints in your urdf are fixed joints.  For robot state publisher to
work, you need a revolute or prismatic joint in your robot.
John

Post by pol.monso
Well, everything seems correct and yet it does not try to connect. The
rosnode info robot_state_publisher output is the same as shown on
rxgraph when mouseovering on the node right?
Since it works with the tutorial urdf model, I'll try to isolate the problem.
2010/11/16 Wim Meeussen [via ROS-Users]

Post by Wim Meeussen

Post by pol.monso
The two nodes not being connected was what I noticed too. I am using
the robot_state_publisher as showed similarly in
http://www.ros.org/wiki/urdf/Tutorials/Using%20urdf%20with%20robot_state_publisher
which I managed to get working.
If the state_publisher is supposed to automatically connect to the
joint_states topic, what could prevent it to do so?

It will automatically connect if the names of the topics match up. You
can check what it is trying to connect to by using "rosnode info
robot_state_publisher". The joint_states topic should be listed as one
of the subscribed topics. Also, the "rostopic info joint_states"
command is useful for debugging this.
Let me know if you have any more questions.
Wim
--
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
________________________________
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913215.html
To unsubscribe from URDF -> robot_state_publisher -> TF confusion, click
here.

--
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913402.html
Sent from the ROS-Users mailing list archive at Nabble.com.
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
________________________________
http://ros-users.122217.n3.nabble.com/URDF-robot-state-publisher-TF-confusion-tp1530752p1913648.html
To unsubscribe from URDF -> robot_state_publisher -> TF confusion, click
here.

[Wim Meeussen]

Post by pol.monso
I'll set them appropiatelly right away, it sounds like it. For the
record, I guess I can alternativelly compute the FK of each joint
myself and publish them to /tf.

Yes, that is correct. This is exactly what the robot_state_publisher
is doing for you.

Wim

[David Lu!!]

Hey Jeff,

I can't answer all of your questions, but robot_state_publisher always
flattens the tree. I assume it's for computational efficiency.

-David!!

Post by Jeff Rousseau
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
----------
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
https://code.ros.org/mailman/listinfo/ros-users

[Lorenz =?utf-8?Q?M=F6senlechner?=]

Hi,

in the TUM ros repository you can find a revamped version of the
robot_state_publisher that publishes the complete tree. You can find it here:

https://tum-ros-pkg.svn.sourceforge.net/svnroot/tum-ros-pkg/robot_model/robot_state_chain_publisher/

Lorenz

Post by Jeff Rousseau
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
----------
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
https://code.ros.org/mailman/listinfo/ros-users