WIP: Prefix description

[fmauch]

The current husky description does not allow to add a tf_prefix to the robot.

In certain situations, however, this might be desired, e.g. when setting up multi-master systems with a shared /tf topic to contain data from all robots.

I've hacked together tf prefixes in all places where they were relevant for my current use case, the state of this PR should be considered as "works for me".

I would love to go the extra mile to finish this in a quality that could be merged into this repository, but first I wanted to clarify whether this is desired or not. An opinion from the maintainers would be welcome here :-)

I tried to follow the scheme of using environment variables to parameterize everything instead of using xacro macros with arguments as I would be used to from other descriptions I've worked with.

[fmauch]

Note: One has to adapt the control.yaml file, as well to respect the new joint and link names.

In our use case we have our own bringup package, anyway, so we copied it and adapted it there.

[civerachb-cpr]

Thanks for submitting this. I've assigned our senior software dev to take a look. I don't know if we'll be merging this directly into the noetic-devel branch, but it's certainly a feature improvement that merits a discussion on our end.

[fmauch]

Nice to hear that there is interest in this topic. A bit off-topic but related: we're currently doing the same for the spot driver/description. I can open a PR there, as well.

[fmauch]

Finally working with this again I'd like to finish this PR. We've been using that setup successfully in a multi-robot scenario and it worked out really fine for us.

I also took the liberty to implement launchfile tests with loading the description. I found this quite useful while developing since there are a lot of switches in the URDF and I wanted to make sure that every component combination would work as expected when defining a tf_prefix.

From my point of view this is now ready to get reviewed. @tonybaltovski as you have been asked to review this by @civerachb-cpr it would be nice if you could find the time to have a look at this.

[mikepurvis]

I feel like we used to have tf_prefix in Husky a long time ago and ended up dropping support for it, partly on the basis of this guidance from upstream:

http://wiki.ros.org/tf2/Migration#Removal_of_support_for_tf_prefix

Are people doing multiple Husky instances in a single simulation/tf-tree? You certainly can do that, but another popular method is to run one ROS Master and Gazebo instance per robot, and then sync the positions between them as "ghosts" so that the lasers and cameras and so on see each other.

[rgariepy]

Yeah, there was a whole mess after that: ros/robot_state_publisher#147 ros/robot_state_publisher#139 ros/robot_state_publisher#159

…

On Wed, Jun 15, 2022 at 2:08 PM Mike Purvis ***@***.***> wrote: I feel like we used to have tf_prefix in Husky a long time ago and ended up dropping support for it, partly on the basis of this guidance from upstream: http://wiki.ros.org/tf2/Migration#Removal_of_support_for_tf_prefix Are people doing multiple Husky instances in a single simulation/tf-tree? You certainly can do that, but another popular method is to run one ROS Master and Gazebo instance per robot, and then sync the positions between them as "ghosts" so that the lasers and cameras and so on see each other. — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN7JDEWQG35K6TYQVQK2VTVPIL2JANCNFSM5HQEXQUA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[fmauch]

Are people doing multiple Husky instances in a single simulation/tf-tree? You certainly can do that, but another popular method is to run one ROS Master and Gazebo instance per robot, and then sync the positions between them as "ghosts" so that the lasers and cameras and so on see each other.

This is not only intended for simulation, but we use a multi-robot setup (Husky, Spot, ANYmal) on a collaborative planetary exploration scenario. We do in fact use a multi-master system, but since our robots are not only mere clumps of metal floating around in space, synchronizing their poses only doesn't really fulfill everything. For example, one robot might detect an object that needs to be inspected / manipulated by another robot, which requires localizing this object in a common coordinate system. TF is simply the right tool to handle this IMHO.

Since ros/robot_state_publisher#169 it would also be possible to implement this using the joint_state_publisher's tf_prefix parameter which would still require adapting things like the frames used for the EKF. I guess, this should be sufficient for most situations.