[Discourse.ros.org] [ROS-Industrial] Multiple robots in one controller

[Gonzalo Casas]

gonzalocasas May 4

Hi folks,

This might be a very basic question, but I haven’t found a very clear answer posted here (or online in general).

How do people deal with multiple robots connected to one controller? I don’t mean two ROS masters, but more like one linear axis system with two robot arms on it, both controlled by the same controller (in our case, two ABBs connected to one IRC5 controller).

Afaik, the ROS-I interface doesn’t allow to dispatch a joint trajectory to a specific motion task inside the controller, so I’m not sure how others are solving the same. Without digging into the whole multi-master or orchestration approaches (which IMO -correct me if wrong- seem to be aiming at moving the capabilities of multi-robot out of the controller itself and into ROS), I see a couple of -perhaps overly simplistic- approaches (again exemplified with ABB because that’s what I have):

• One driver per robot: install the driver multiple times on the controller, changing the TCP ports or using different IP address/network cards of the robot, so that we end up with pairs of motion/status servers running per robot, and consequently, one node per robot running on ROS. I don’t know if that works very well that can be configured on the ros node side of things to avoid collision, but I assume is doable.
• Add new message types and extend existing drivers: another simple option would be to add a few additional messages that would pre-assign dispatching to a specific motion task (i.e. call set_robot(x) before sending trajectories, so that the driver knows where to dispatch this to.

I’d love to hear there are much better ideas out there, and hopefully be pointed in the right direction

Cheers
Gonzalo

---

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

[gavanderhoorn]

gavanderhoorn May 4

gonzalocasas:

One driver per robot: install the driver multiple times on the controller, changing the TCP ports or using different IP address/network cards of the robot, so that we end up with pairs of motion/status servers running per robot, and consequently, one node per robot running on ROS.

You don’t need different IPs or NICs, different TCP ports would be enough. But yes, this is one of the approaches that is used for this sort of setup.

gonzalocasas:

I don’t know if that works very well that can be configured on the ros node side of things to avoid collision, but I assume is doable.

This setup is no different from any other multi-robot setup (ie: multiple turtlebots, or multiple static robots), so as long as <insert planner infrastructure> is aware of the entire scene this should just work.

gonzalocasas:

Add new message types and extend existing drivers: another simple option would be to add a few additional messages that would pre-assign dispatching to a specific motion task (i.e. call set_robot(x) before sending trajectories, so that the driver knows where to dispatch this to.

That is also an option, but would require changes to the driver on both the robot as well as the ROS side.

Your first approach is a lot less work – and is in fact how some early setups for YuMi worked (ie: consider each arm a separate robot). It will not allow for executing synchronous motions with all robots involved though. For that your second approach would be better suited.

gonzalocasas:

Without digging into the whole multi-master or orchestration approaches

I don’t believe this is needed, at least not for the simple setup you describe / imply in your post.

[Gonzalo Casas]

gonzalocasas May 4

Thank @gavanderhoorn!

gavanderhoorn:

I don’t know if that works very well that can be configured on the ros node side of things to avoid collision, but I assume is doable.

This setup is no different from any other multi-robot setup (ie: multiple turtlebots, or multiple static robots), so as long as <insert planner infrastructure> is aware of the entire scene this should just work.

I don’t know if that works very well that can be configured on the ros node side of things to avoid collision, but I assume is doable.

Sorry, I used the wrong term. I didn’t mean physical collisions, but whether the ROS nodes wouldn’t interfere with each other at the software level, but you answer that already in the rest of your message

Thx!

[gavanderhoorn]

gavanderhoorn May 4

gonzalocasas:

Sorry, I used the wrong term. I didn’t mean physical collisions, but whether the ROS nodes wouldn’t interfere with each other at the software level, but you answer that already in the rest of your message

Ah, those kind of collisions: no, as long as you namespace everything correctly (ie: robot0/joint_states, etc) there are no issues.

[Jonathan Binney]

jon May 4

gonzalocasas:

e if wrong- seem to be aiming at moving the capabilities of multi-robot out of the controller itself and into ROS), I see a couple of -perhaps overly simplistic- approaches (again exemplified with ABB because that’s what I have

Yes, as gavanderhoorn said, namespacing the drivers on the ROS side should work fine, and sounds like the best approach.

My understanding of what happens inside the IRC5 controller is not as good, but I’m curious to hear how it goes for you. As I’m typing this, a festo engineer is helping one of my colleagues connect a festo linear rail to an IRC5 controller so that we can move our ABB arm around on it. We’re working through the electrical and mechanical setup now, but afterwards we’ll have to dive into debugging the RAPID code that is running on the controller and talking to the ROS driver. My plan was to generate combined trajectories for the arm and linear rail, and using one ROS driver. That would probably be overkill for your 2 arm setup though.

[Jeremy Zoss]

JeremyZoss May 16

Sorry that I’m late to this discussion.

Handling multi-robot controllers was one of the design goals when we drafted the design for “Version 2.0” of the ROS-I interface (REP-I0001).

In particular, this interface allows sending/receiving messages with multiple “motion groups” inside them. Each motion group has an associated “group ID” that is used to associate a set of named joints (ROS-side) with a numbered group of joints on the robot side. Multi-robot controllers often represent the individual robots as separate “motion groups”, and the group-ID can be directly associated with each of these motion groups. Group-ID can also be used in some cases to control external axes (such as positioners), without application-specific modifications to the robot-side ROS-I driver.

The definition of this interface is flexible enough to allow for many different scenarios, including sync/async control of multiple arms or planning from 1 or more different ROS-side motion planners. Control can be switched between these modes as needed.

Although we have defined the REP, adoption into the main ROS-I repos has been slow. I have updated the industrial_robot_client library/nodes on the ROS side to support the new protocols. There is also an updated Fanuc driver, but I don’t know that it has been released publicly yet. I don’t know that these “v2.0” protocols have been used anywhere else.

I have successfully used this updated driver for control of a multi-arm Fanuc workcell with a positioner, and things worked well. But that’s a relatively limited use-case, so the code and protocols could certainly benefit from wider testing/usage.

Let me know if you have questions or want to discuss further!