Gazebo ROS control plugin for multiple robots

[YoshuaNava]

Hi everyone,
This is a question that I've had for quite some time, and I think it's the right time to find an answer for it, with your help.

Background

Multi-robot case

At RPL we have ridgeback_yumi, a robot we built by combining an ABB YuMi and a Clearpath Ridgeback mobile platform. We have developed some custom ROS packages for Ridgeback and specially for ridgeback_yumi. The end goal is to emulate as much as possible the qualities of the PR2 as a mobile-manipulator with multiple sensors.

When we received our ridgeback I noticed that the mobile platform was running a controller manager, and we were loading one too! with YuMi. For convenience, I ended up namespacing the controller manager for YuMi ROS controllers, such that we would not mess with the one that governed the mobile platform movement. I did this in real life:

https://github.com/kth-ros-pkg/yumi/blob/f48325509fc2f156d6b7c8c1960d8546fe3f7b89/yumi_launch/launch/yumi_traj_vel_control.launch#L11

And in simulation:

https://github.com/kth-ros-pkg/yumi/blob/f48325509fc2f156d6b7c8c1960d8546fe3f7b89/yumi_description/urdf/Gazebo/gazebo.urdf.xacro#L6

Simplicity, ease of use

Adding to that, during my time working with YuMi I have tried to make easy for people to use YuMi. Our lab specializes in grasping, planning and AI, and many researchers seldomly run their tests on the real robots. One of the things I did for simplifying use is to separate the arm joint states from gripper joint states, which are finally joined together with a joint state publisher:

https://github.com/kth-ros-pkg/yumi/blob/f48325509fc2f156d6b7c8c1960d8546fe3f7b89/yumi_launch/launch/yumi_traj_vel_control.launch#L45

This was useful specifically for people who have developed their code having in mind that they could get the robot joint states by listening to "/yumi/joint_states", without any extra processing, or without the need or filtering out joint states from other robots (as in a multi-robot case)

Question

I'm sure that what I've done is not a good practice, because namespacing hides the expected interfaces for the controller manager and the robot. However, in the case that we wanted to have multiple robots (Ridgeback+YuMi, or even multiple YuMis), what would be the best practice?

Thank you very much in advance.

Kind regards,
Yoshua

[diogoalmeida]

In an integrated robotic system (say, the PR2), what I'm used to seeing is a joint states message with all the joints in the robot. This includes the manipulators, grippers, wheels and whatever other joints may be in the system.

I guess that the good practice would be to have a joint states message with all the joint states in the robot, but I'm not experienced enough to tell you that's what we should have. However, if you want to implement a full body controller, for instance, it would be weird to have it relying on multiple joint states. But this should be a minor issue, as in principle the controller should not have to rely on a message topic to get the joint states.

[diogoalmeida]

On another note, is this a relevant question for this package? I thought that the end goal here is to have a core package that is independent (and common to all) robots that use yumi, so that question is an issue for whatever robot ends up implementing this interface. Or did I miss something?

[YoshuaNava]

Hello Diogo,
Thank you for your feedback. This package (abb_irb14000_description) corresponds to the core YuMi URDFs, meshes and other dependencies. In the URDF itself we have a declaration of the ROS controllers gazebo plugin for which this namespacing aspect is relevant.

What you say sounds solid. I will focus on having one full joint state message.

For a multi-robot case it might be a good idea to consider if we need to add (maybe a prefix?) to the joint names. But this is something I won't do now.

[diogoalmeida]

Keep up with the good work :)