Performances and change from industrial_robot_client to ros2_control

[LucasLabarussiat]

This is a repost from this thread :

I am just starting working with a Staubli TX2-90, with a CS9 controller. I am more used to universal robots and as such, I'd like to use this with ros2_control instead of industrial_robot_client too.
If I get this right, this means both:

• following ros2_control guidelines to write the hardware interface

I guess UR hardware interface could serve as a reference at some point.

• adding/rewriting part of this VAL3 driver to adapt to ros2_control instead of industrial_robot_client (?)

@gavanderhoorn , do you have any insights as to what would be required on the VAL3 driver side ? Even some vague TODOs would help me figuring out a plan.
I might have the wrong idea that using ros2_control instead of industrial_robot_client would enhance the performance and allow a more deterministic (and higher rate) control loop. Is it true ? At some point I'll need to control my arm with a haptic device, and I'm afraid the rate won't be enough for it to work properply.
I saw in start.pgx that right now:

• the feedback task runs every 20ms (50Hz)
• the motion control task runs every 4ms (250Hz)
• the data reception task runs every 4ms (250Hz)

Are the limitations here due to UDP, or can these values be set higher ? If they are, I guess ros2_control won't change that.

In your opinion, is it worth the work or should I rather use the industrial_robot_client as is, with a ROS1 - ROS2 bridge ?

Sorry, when I originally posted I thought I'd have some time to work on this. I should finally be able to tackle it in a couple of weeks. I'd really like to integrate this driver with ROS2, especially as the robot control is part of a wider project where ROS2 is the primary communication protocol.
Though I am very unfamiliar with VAL3. In his issue, @maxdgaa told me he rewrote his own VAL3 driver, what changes would that imply ?

Thanks for your help.

[gavanderhoorn]

Thanks for starting a new thread.

I would suggest to read #32, as that is probably the kind of functionality you're looking for.

Summarising: industrial_robot_client only provides a communication protocol. Motion performance itself is only partially dependent on that.

The main challenge would be to provide the internal motion pipeline of the CS9 controller with sufficient data at the right times. How that data gets to the controller is really not that important, and industrial_robot_client could be used to do that -- it doesn't have to used of course though.

As to where you'd have to make changes: it's been too long for me to be able to pin-point specific lines, but conceptually, you'd have to provide a network interface to the queue the motion control task uses to temporarily store traj pts in. Then you'd probably have to change the task type of the motion task to be synchronised with the CS9's internal (motion) interpolation clock. I've forgotten how to do that exactly again in VAL3.

And you'd also obviously want to output (joint) state information in the opposite direction, probably at the same rate.

With all that in place, and a very minimal queue of traj pts on the CS9 side (in the VAL3 program), you'd essentially have a network interface to the internal motion controller of the CS9.

And as I wrote: whether you do this with simple_message and/or industrial_robot_client is not important. That just provides you with a network layer/protocol implementation.

I am more used to universal robots and as such, I'd like to use this with ros2_control instead of industrial_robot_client too.

I hope it's now clear this is not really the dilemma you imply it is.

I might have the wrong idea that using ros2_control instead of industrial_robot_client would enhance the performance and allow a more deterministic (and higher rate) control loop. Is it true ?

again, this is not something you can really say.

ros2_control would have no idea how to communicate with your CS9. simple_message has no concept of (ros2_control) controllers, hardware interfaces or anything ROS for that matter. But you could use simple_message to implement the communication from your ros2_control hw interface to the (VAL3) server program running on the CS9.

industrial_robot_client specifically basically provides some nodes which also make use of simple_message to convert ROS messages to representations the VAL3 server program on the CS9 "understands". It also provides a FollowJointTrajectory action server which is a convenient way to execute trajectories on industrial robot controllers. That's probably not something you'd want to use for the kinds of applications you describe.

In your opinion, is it worth the work or should I rather use the industrial_robot_client as is, with a ROS1 - ROS2 bridge ?

I would not immediately recommend using ros1_bridge for applications where control bw and jitter are important.

Are the limitations here due to UDP, or can these values be set higher ? If they are, I guess ros2_control won't change that.

The CS9 evaluates your VAL3 code at 250 Hz -- or more specifically: specific 'threads' or 'tasks' are executed at 250 Hz (the synchronised motion tasks fi). Using ros2_control will not change anything there, as it's just how the CS9 work (and CS8 as well).

As long as whatever communication layer you use is able to ship new data to the controller within 4 ms, you should be able to reach that 250 Hz. But that doesn't mean your control bw will be 250 Hz. There's filtering and queuing internal to the CS9 as well which will influence that. I wouldn't have any nrs for you, as I've not worked on this for a very long time.

In #32 some additional comments around performance and possible communication methods have been posted. You may find those informative as well.

There's also #36 which contributes a velocity control interface by using custom simple_message messages and some additional topics and services -- including changes on the VAL3 side. Perhaps those can be helpful as well.

[gavanderhoorn]

Having written all of that: if you really need determinism and the maximum performance, I believe only uniVAL could offer that on Staublis.

(Edit: on CS8, there used to be something called the Low Level Interface (LLI), which offered really low level access to the drives of a Staubli robot. I don't believe that's available any more though, but you may still occasionally see that being mentioned)

I'm not aware of any ROS integration for that though, but I would be highly interested.

You may want to contact your (local) Staubli dealer/support office for information. They may try to push you towards a 3rd party motion controller (which is what uniVAL is most often used with), but I don't believe there would be anything blocking anyone from using uniVAL from a PC(-like) system to interact with a CS9 in the same way an external, 3rd party motion controller would.

(IIUC and AFAIK, it's "just" a motion interface over powerlink)

Whether Staubli would be comfortable with that, I couldn't say.

---

Edit: Staubli also has an XML-RPC based interface available, but I doubt that would provide sufficient performance for tele-operation using a haptic device.

[LucasLabarussiat]

Hello,

Thank you so much for your detailed answers. I'll need to get through it again once I am back working on the Staubli. I'd like to keep this open in case I have follow-up questions.

[gavanderhoorn]

@LucasLabarussiat: could you comment here on what you did in the end?