Add free drive mode support

[schmid-jn]

Suggested implementation of a free drive mode capability.
ref: #525

[HannesBachter]

tested on AMC-H 👍

[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 #546 and #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

• Implemented ROS topic to enable the freedrive mode. #546
• Added freedrive mode functionality to ROS #573

already have been working for us - as commented - but were not merged due to #546 (comment) and the work done in UniversalRobots/Universal_Robots_Client_Library#138

now #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 UniversalRobots/Universal_Robots_Client_Library#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.