<div dir="ltr"><p dir="ltr">The number of actual subscriptions would not change. For every node->robot_state_publisher connection there would be a node->joint_states to replace it. Only difference would be that there might be different topics for different joint_states. This is easily overcome by making the tf rosparam a list like this:<br>
<rosparam><br>
robot_urdfs:<br>
- urdf: /robot_description<br>
joint_state: /joint_states<br>
- urdf: /sim/robot_description<br>
joint_state: /sim/joint_states<br>
</rosparam></p><p>Since the parameter could be global, every tf would know which parameters to look at to find URDF/JointState topic pairs. You could even potentially customize a node to only look at specific joint states, so that it only has access to certain sections of the tree. Most of all, by just eliminating the parameter all together you can make this feature totally optional, /tf acts like normal.</p><p>Although its an interesting idea to integrate it as a ros-controller, it still doesn't tackle the bandwidth issue.<br></p><p>Just a quick test on my 7DOF system with 32 tf frames:</p><p>/tf Bandwidth: 186 KB/s, 100 Hz<br></p><p>/joint_states Bandwidth: 33 KB/s, 100 Hz<br></p><p>This is a 6x increase in information, all of which must be deserialized in tf::TransformSubscriber. Although I'm sure ROS 2.0 will help, I'm not sure it's an excuse for just ignoring lazy ROS communication. If you want to continually rosbag a robot system you often want to keep data throughput low. Actually what got me thinking about this was the web-interface talk, where tf throttling becomes necessary when sending it through web-sockets. For remote control, you'd like the communication to be efficient as possible.<br></p><p><br></p>
<div class="gmail_quote">On Sep 17, 2014 9:40 AM, "Mike Purvis" <<a href="mailto:mpurvis@clearpathrobotics.com" target="_blank">mpurvis@clearpathrobotics.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>In a complex system, you're likely to have multiple nodes producing joint info, and multiple nodes consuming TF, so it makes sense to have a central clearinghouse for that info to avoid everything subscribing to everything. It's also a logical abstraction to have hardware deal in joints, and higher-level code deal in transforms.</div><div><br></div>Three further thoughts on this—<div><br></div><div>- First, robot_state_publisher is embeddable as a library, so if you don't like the separate process and serialization overhead, you could consider compiling it directly into whatever hardware node you have primarily producing joint information.</div><div>- Along the same lines, there's already a joint_state_controller which publishes joint_states from the ros_control framework. It's not hard to imagine that it could optionally also publish tf, eliminating the need for a separate node doing this job.</div><div>- Finally, with ROS 2.0 offering the option to run all your nodes in a single process as a launch-time decision, much of the overhead here becomes an optional switch you can throw— if the abstraction costs nothing, it makes that much more sense to have it in place.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2014 07:49, Kelsey Hawkins <span dir="ltr"><<a href="mailto:kphawkins@gmail.com" target="_blank">kphawkins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'd bet that 90-100% of transform requests in typical ros systems run through a chain delivered through robot_state_publisher. Wouldn't it make sense to optionally allow tf::TransformListener to parse a URDF and subscribe to /joint_states in addition to /tf? The advantage is that you can do proper interpolation between joint configurations and you vastly reduce the bandwidth of /tf. Plus, you eliminate a processor intensive node which is mostly relaying redundant information easily read from the URDF.</p>
<p dir="ltr">I'm sure this isn't a novel idea, but are there any plans to integrate this behavior into ROS core? Any caveats?</p><span><font color="#888888">
<p dir="ltr">-Kelsey</p>
</font></span><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div>
</div>