-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Lock teach pendant when under ros_control #5
Comments
I tried this out and after sending the command "setUserRole restricted" the pendant returned to welcome screen and the move tab was no longer present on subsequent menus. |
…/realtime_io Feature/realtime io
I'm closing this as we've officially deprecated this package. Refer to the announcement on ROS Discourse. |
There is also Dashboard server integration available, with a ROS API. |
With the dashboard server, it is possible to lock the teach pendant from firmware version 3.1.17something by setting the user role to 'restricted' (http://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/dashboard-server-port-29999-15690/)
This can prevent the user from trying to use the screen and accidently crash the controller. ros_control is always controlling the robot when the controller is running, so moving the robot with the teach pendant will cause that input to struggle against ros_control, which doesn’t get the new target pose. The resulting conflicting motion will cause the controller to crash.
The enhancement should also display a message on the teach pendant to let them know that they are locked out.
The enhancement could be extended to be active whenever the driver is executing something on the robot (whether under ros_control or action interface). This would probably improve the stability of the driver.
Nevertheless it is quite important that the driver always unlocks the screen when the driver shuts down! Perhaps opening a new connection to the dashboard server, unlocking everything when the driver is killed, is the best way to go.
As I haven't tried it out, I am uncertain on how this works. The documentation says that it prevents the user from pressing the 'move' tab. If this is indeed the case and it is thus not possible to read the joint states and end effector position from the screen, then this enhancement should be made dependent on a parameter in the driver, allowing the user to turn it off.
The text was updated successfully, but these errors were encountered: