Hi Jeff, <div><br></div><div>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.  </div>

<div><br></div><div>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&#39;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.  </div>

<div><br></div><div>Tully</div><div><br></div><div>Re: fake_localization.  It simply republishes odometry at whatever frequency it receives odometry.  You&#39;ll want to slow down the odometry publishing from within gazebo.  </div>

<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><div class="gmail_quote">On Mon, Sep 20, 2010 at 11:55 AM, Jeff Rousseau <span dir="ltr">&lt;<a href="mailto:drzaiusx11@gmail.com">drzaiusx11@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi All,<br>
<br>
Attached is the output of &#39;rosrun tf view_frames&#39; showing the<br>
transforms being published by robot_state_publisher based on the URDF<br>
for my iRobot Create (also attached) as well the output of &quot;rosrun<br>
urdf urdf_to_graphiz irobot_create_full.urdf.xacro&quot; showing the links<br>
and joints that make up my URDF.<br>
<br>
I&#39;m a bit confused as to why these two trees don&#39;t match. Why is<br>
&#39;robot_state_publisher&#39; flattening the URDF tree and rearranging some<br>
connections when outputting to TF? According to the URDF base_link<br>
should be the parent of base_link_left/right_motor_link and the motor<br>
links should be the parent of the wheel links...<br>
<br>
I think this is related, but not entirely sure: when I add the model<br>
to rviz I get the following warnings:<br>
----------<br>
caster_wheel_link<br>
No transform from [caster_wheel_link] to [/map]<br>
<br>
base_caster_support_link<br>
No transform from [base_caster_support_link] to [/map]<br>
----------<br>
<br>
Any input, ideas as to whats going wrong/what I&#39;m doing wrong?<br>
(my guess is that I&#39;m making an incorrect assumption that there is a<br>
1-to-1 correspondence between how gazebo and ros handle coordinate<br>
frames)<br>
<br>
PS on a slightly unrelated note: tf_frames.pdf shows gazebo publishing<br>
the /odom topic at 100hz, is there a way to change this rate? I&#39;m<br>
trying to squeeze as many cycles out of my old hardware as I can, so<br>
I&#39;m trying to avoid over-publishing on my topics to cut down CPU usage<br>
(as it is now gazebo in &#39;top&#39; is claiming 90-100% of my cpu).  I tried<br>
adding a &lt; param name=&quot;publish_frequency&quot; type=&quot;double&quot; value=&quot;10.0&quot;<br>
/&gt; to fake_localization node in my launch file, but it didn&#39;t take...<br>
<font color="#888888"><br>
Jeff<br>
</font><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com">tfoote@willowgarage.com</a><br>(650) 475-2827<br>
</div>