Can this be used in combination with MoveIt?

[maxdgaa]

I've looked at this repository, as well as the ros_industrial industrial_robot_client but I'm having trouble seeing if this can practically be used in combination with MoveIt.

[gavanderhoorn]

Just about anything which exposes a FollowJointTrajectory action interface can be used with MoveIt.

That includes the driver in this repository -- although the action server used is the one in industrial_robot_client.

That's MoveIt and ROS 1 btw. Not 2.

[gavanderhoorn]

There's no way to send a "command" to a single joint, if that's what you're asking.

But in general you can do this by taking the current state, updating the joint value for the joint you want to change and using that as a trajectory point.

Please be aware of the fact staubli_val3_driver implements a trajectory-interface. Not a generic joint position or joint velocity interface (although there are PRs for that, see #36 fi).

[maxdgaa]

I am trying to control a Staubli TX2-90L with MoveIt 2. So far I've implemented this using ros2_control. As I see it now (correct me if I'm wrong), I have three options:|

1. Write my own VAL3 driver such that I can set individual joint positions and try to re-write parts of the industrial_robot_client to get them to work with this driver.
2. In my ros2_controller do as you suggested, namely sending the new joint positions as a trajectory point (I'd have to re-write industrial_robot_client to work with ROS2).
3. Switch to MoveIt1 (I'd rather not do this).

In your opinion, what would be best?

[LucasLabarussiat]

Hello @maxdgaa,

I was wondering if you did any progress on this. 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 ?

If you prefer, I can post this in a new discussion just let me know.

[maxdgaa]

Hi @LucasLabarussiat,
Yes, I was actually able to get my Staubli TX2-90L working with ros2_control (I chose to implement the first option i originally suggested). I would publish the code but unfortunately I wrote it for a company I no longer work at and the code is their IP so I cannot.

My implementation was pretty primitive and worked well at low speeds, but at higher speeds the movement of the robot was very jerky.

If I recall correctly this was actually due to the nature of ros2_control "streaming" the trajectory points one by one. The internal queue of the arm would start to get empty, the robot would decelerate because it had no other choice than to assume that this last point its queue was its final point, and then suddenly it would get another movej command causing it to accelerate again. You might be able to fix this by adjusting control loop parameters but I'm not sure as I haven't tested that. @gavanderhoorn might be able to elaborate on that further.

Another option that I wanted to try but didn't get around to was trajectory downloading. In this implementation, that doesn't use ros2_control, you can send the entire JointTrajectory to the Staubli at once instead of "streaming" the points one by one (which is what ros2_control does). This might be a little bit more work but I think it would work very well. You'd need to do the following to get this working:

• Write your own action server, replacing the JointTrajectoryController, and have MoveIt send the trajectory to it.
• Come up with protocol to send the entire Trajectory to the Staubli at once
• Push all JointTrajectoryPoints to Staublis queue at once so it has a clear final destination.

Hope this pretty vague answer helps you a little.

[gavanderhoorn]

@LucasLabarussiat wrote:

If you prefer, I can post this in a new discussion just let me know.

that may indeed be nice.

[LucasLabarussiat]

@LucasLabarussiat wrote:

If you prefer, I can post this in a new discussion just let me know.

that may indeed be nice.

Hi, thanks for your answer @maxdgaa.
I just reposted my question in a new discussion. I suggest we take it there.