Add free drive mode support

[schmid-jn]

Suggested implementation of a free drive mode capability. ref: https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/525

[fmauch]

Hi, thank you for contributing to this project. However, there are already two PRs open with that functionality. If you have anything to add there, please comment in those.

[schmid-jn]

@fmauch I could find https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/546 and https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/573. Both prs are open since two years and no one is working on it. Also this prs are using a different approach enabling free drive via ur script and not with the new function in the client library. Why do you close this active one and not the others?

[fmessmer]

@fmauch please provide a strategy for timely support of adding the free-drive feature we really would like to see this feature merged and released

the initial prs/drafts

• https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/546
• https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/573

already have been working for us - as commented - but were not merged due to https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/546#issuecomment-1405140173 and the work done in https://github.com/UniversalRobots/Universal_Robots_Client_Library/pull/138

now https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/718 makes use of said URCL extension and still was closed in favor of the older, declined PRs above...

[fmessmer]

@fmauch please help us understand why free-drive mode does not get supported by the official repo - no matter what concept is provided?

[fmauch]

@fmauch please help us understand why free-drive mode does not get supported by the official repo - no matter what concept is provided?

One problem is time. We are currently following up on this and plan to get it to a mergeable state until ROSCon. @VinDp will mainly work on this.

Also this prs are using a different approach enabling free drive via ur script and not with the new function in the client library. Why do you close this active one and not the others?

I mainly closed this one because it was the third one and id didn't mention looking at the others. I've taken a closer look at #546, #573 and this one and indeed, this one seems to have the best approach. Sorry for not looking at this in more detail before.

That being said, I see one main concern about this approach:

Since this is using the freedrive support of the ur_driver, the reverse_interfaces is being kept active, so any other controller will stay active. From my understanding that would mean that the JTC will keep sending the last position of the latest trajectory all the time. Once freedrive mode is exited, the program running on the robot will return to reading the commands being sent on the reverse interface which will still be the old ones, I suppose.

@VinDp will test this on a real robot later this week to confirm / disprove my assumption.

I would much more love to have this into an own controller that can actually claim the command interfaces, so the JTC has to be deactivated and re-activated explicitly. We'll do that for ROS 2 as we don't have the option to advertise ROS interfaces from the hardware interface directly.

[fmessmer]

thanks @fmauch @VinDp for getting back at this @schmid-jn already used this significantly on one or our URs and - as far as I know - did not observe anything weird, but I haven't been directly involved we are curious about @VinDp findings and proposal and are happy to test once something is available...

[fmauch]

We've just tested things and unfortunately my assumption was correct.

The robot didn't jump in our faces because of https://github.com/UniversalRobots/Universal_Robots_Client_Library/pull/184 but it would have moved back to the place where it was before activating freedrive, as the joint controller keeps setting the same command.

I think the only way to get around this safely is to enforce not having a controller active while freedrive is active. The most reliable way for doing that would be to wrap the freedrive functionality into a separate controller as we plan to do in ROS 2.

[urfeex]

This will probably not get merged unless somebody picks up the work of moving this to a separate controller so that resource management can be done properly.

This feature exists in the ROS 2 driver, we recommend to switching to that by now.

I'll leave this PR open, as the feature as such is working and usable if precautions are taken (stop JTC before using this feature).