Open YoshuaNava opened 6 years ago
Hey @gavanderhoorn @jontje @diogoalmeida @rtkg, Right now our RWS HW interface relies only on industrial sockets for connecting with YuMi. Until recently, this allowed users that didn't have access to librws to actually connect to the robot via RWS.
However, I have seen that there are functions in the new librws that we could support in this new driver, to give better feedback to the user when launching it, such as: isAutoMode() isMotorOn isRAPIDRunning())
Furthermore, there are new functions to start/stop rapid scripts execution, set the program pointer to main, and set the motors on/off:
startRapidExecution() stopRAPIDExecution() resetProgramPointer() setMotorsOn() setMotorsOff()
I think it could be useful to integrate these functions into the new rws HW interface, specially for the purpose of starting/re-starting the rapid modules remotely. We at KTH normally do grasping experiments in which the robot switches off due to load/collisions/joint limits reached, and it is cumbersome to stop the ROS nodes, take the FlexPendant, set motors On again, reset the program painter and execute the scripts every time.
Implementation-wise, I would start by making the automatic execution of the nodes optional, with a boolean parameter set by the user. I would also add a function to reset currently saved joint values. Finally, I would need to consider as well resetting the controllers, maybe through a ROS service call to the controller manager.
What do you think? Should I integrate these new functions or leave the HW interface as it is now?
Thank you for your feedback.
My initial reaction would be to say "sure, add convenience where it makes sense", but after thinking about it a bit, I'd like to suggest to first focus on porting to the new abb_libegm
and abb_librws
.
After you have that done, we can look at improvements like the one you mention.
We would have to be a bit cautious though: auto-reset of faults and restarting of programs can quickly interfere with the 'normal' workflow when working with industrial robots and that could lead to safety issues.
Not saying we shouldn't do it at all, just that we need to think about it.
@gavanderhoorn sounds good.
Then my focus for now will be on migrating the RWS interface present in yumi_hw_egm to the new version.
I agree with @gavanderhoorn's assessment
Merged #6
The HW interface, as it is now, supports the old version of librws that we have at KTH (delivered to us in January of 2017). Support for the new, open-source version of librws is on the way.