Implemented ROS topic to enable the freedrive mode.
Implements a basic way to enable freedrive_mode via a ROS topic.
To test: send a message to the "enable_freedrive_mode" topic with a float value specifying seconds to be in freedrive mode.
Using "0.0" will enter freedrive_mode until the robot stops being moved continously (and at least 3 seconds to allow for start of the movement).
As a script is sent to the robot directly, the External Control program will be stopped and thus has to be restarted before regular ROS control can resume.
This is not a final implementation of this feature.
Thanks for the feature draft! We'll definitely try this - once our HW is free for testing
What's the motivation for topic activation - over e.g. service/action? I think an action interface would be nice as the driver/server could deny to switch to freedrive mode or abort in case of error...also the client could cancel freedrive mode early if no longer needed...and the duration could still be set in the goal resulting in a succeeded case to achieve the same behavior as with the plain topic-based interface...
I've added a code block below for enter_freedrive_node service that we use. It is defined after set_payload_srv in hardware_interface.cpp.
// Setup freedrive mode through a ROS service
enable_freedrive_mode_srv_ = robot_hw_nh.advertiseService<std_srvs::TriggerRequest::Request, std_srvs::TriggerResponse::Response>(
"enable_freedrive_mode", [&](std_srvs::TriggerRequest& req, std_srvs::TriggerResponse& res) {
std::stringstream cmd;
cmd << "def enterFreedrive():" << std::endl
<< " while (True):" << std::endl
<< " freedrive_mode()" << std::endl
<< " sync()" << std::endl
<< " end" << std::endl
<< "end";
resp.success = this->ur_driver_->sendScript(cmd.str());
return true;
});
Our client code calls /ur_hardware_interface/dashboard/stop before calling this enter freedrive service (with delay of 0.5s in between) to enter freedrive mode from remote control, and go back to remote control by calling /ur_hardware_interface/dashboard/stop -> sleep 0.5s -> /ur_hardware_interface/dashboard/play.
Finally, I was able to test this feature on our HW and it worked out of the box :+1: So far, we don't have any explicit requirements for what the interface (topic, service, action) should be - as we are still experimenting... Thus, I'd be ok to get this merged and modify/extend the interface lateron....
Before merging, I think at least some basic documentation should be added.
This PR hasn't made any progress for quite some time and will be closed soon. Please comment if it is still relevant.
@ github-actions I'm still interested in this feature! (hope this keeps it open :wink:)
This is currently being worked on in https://github.com/UniversalRobots/Universal_Robots_Client_Library/pull/138 and is not forgotten ;-)
This PR hasn't made any progress for quite some time and will be closed soon. Please comment if it is still relevant.
this github-actions is really annoying!
This PR hasn't made any progress for quite some time and will be closed soon. Please comment if it is still relevant.