Feature idea: add freedrive_mode as interface

[fmauch]

Adding an interface for activating the freedrive mode would probably be beneficial especially in situations where you don't have a teach pendant available.

As activating and deactivating freedrive_mode is available in ur_script, this could be easily added.

I suggest using a topic interface with a keepalive mechanism, so a user would have to regularly send a message to activate it. If input on that topic times out, it should be deactivated. The reason for that would be that it would have the same "deadman" mechanism as on the TP.

By providing a custom message and not only a simple bool topic we could restrict the freedrive functionality to only certain axes. It would probably be best to use URs feature notation for that.

It should be fairly easy to get a proof of concept running with this.

A few culprits to keep in mind:

• This would only work if the robot is in remote_control mode
• Activating this will stop script execution of other scripts, meaning users would have to restart external control afterwards. (Same goes for using the teach button on the TP, though)
• The URScript function teach_mode has been migrated to freedrive_mode. We should check from which version on

@fmessmer, @floweisshardt FYI

[floweisshardt]

+1 for enabling this feature through a ROS interface!

Thanks @fmauch for wrapping this up.

[shuobh]

+1 This would be really useful! I currently ran into an issue when switching between freedrive (with URScript) and remote control. The way I do so is:

• rosservice call stop -> wait 0.5s -> publish urscript to change to freedrive
• rosservice call stop -> wait 0.5s -> rosservice call play -> wait 0.5s -> start publishing trajectory using actionlib

If I do not have the 0.5s delay in between, although rosservice returns success in stop and play, it is not really ready to run new commands. 0s delay fails consistently and 0.2s delay fails randomly. So far 0.5 is the magic number. If freedrive_mode is implemented, then I assume it wouldn't be necessary to add delays anymore.

However, the open question here is why UR is not immediately ready after the rosservice call? If there is a determined delay, why can't that be checked within the rosservice and only return when it is really ready to operate?

[t-schnell]

546 offers a first, prototype implementation of this feature. Feel free to try it out and please let us know if this would work for your requirements - or what type of changes you would like/need for the feature to be useful.