Skip to content
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

Are there any weird quirks with this driver compared to the universal robot driver (ur_robot_driver) in terms of operation and stability? #385

Closed
madhan001 opened this issue Feb 3, 2021 · 5 comments

Comments

@madhan001
Copy link

Hi, Sorry if this isn't the right place for this query. We are looking to purchase a GP-12 for use with ROS in a production environment. We are really familiar with the ur_robot_driver and have found it to be satisfactory for our use but we haven't used ROS with Yasakawa-Motoman robots.

Are there any strange quirks with the motoman driver that doesn't exist in the ur_robot_driver ?

In other words, does the motoman driver lack any feature which the ur_robot_driver supports on UR series robots ?

Does the motoman driver have anything similar to the dashboard client in the ur_robot_driver that can be used to perform teach pendant actions from ROS ? For example, reconnecting to the robot if disconnected and setting the robot speed directly from ROS.

Is there any potential issue that could prevent usage with FZI's cartesian_controllers ? We have used different aspects of this controller and have found this to be extremely useful when used correctly with a UR10. We are mostly interested in the compliance controller and will be using an external FT sensor with the robot if compliance is required for the application.

Can someone familiar with ROS on both robot vendors help us, as we have never worked with motoman robots using ROS ?

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Feb 3, 2021

This is almost impossible to answer, unless someone here has extensive experience with both drivers.

I'll try to answer the questions you've included in your OP.

Does the motoman driver have anything similar to the dashboard client in the ur_robot_driver that can be used to perform teach pendant actions from ROS ? For example, reconnecting to the robot if disconnected and setting the robot speed directly from ROS.

No.

But MotoROS works differently from ur_robot_driver, in that it doesn't need to be started/enabled as a separate program or job. It's always active (without violating safety).

Is there any potential issue that could prevent usage with FZI's cartesian_controllers ?

yes: the fact that motoman_driver is not ros_control based. You cannot use it with ros_control controllers, which is what the cartesian_controllers you link to are.

(you could theoretically port the work linked in #359 to ROS 1 ros_control, but there's no guarantee you'll be able to achieve the same performance you're used to with ur_robot_driver. See also #219)

Can someone familiar with ROS on both robot vendors [..]

this is going to be pedantic, but neither ur_robot_driver, nor motoman_driver run on the controller. They're both talking to the controller using (largely) ROS-agnostic interfaces.

@gavanderhoorn
Copy link
Member

As this is not an issue with the packages in this repository, I'm going to close it.

Feel free to keep commenting on it of course.

@madhan001
Copy link
Author

Thanks for your insight. I've got answers for the major questions I had

@madhan001
Copy link
Author

Putting this query here as I don't want to create a new issue for this.
@gavanderhoorn Is there a way to perform conveyor tracking through ROS on motoman robots without using FZI's cartesian_controllers as ros_control isn't supported ? The task is similar to painting a moving object. Am I correct that this isn't possible as motoman_driver can take only end to end trajectories but not dynamic cartesian targets ?

@EricMarcil
Copy link
Contributor

If you are wanting to use the ROS for conveyor tracking, you will need to resolve and synchronize the motion on the ROS side.
The Yaskawa controller does have a build in conveyor tracking function but you will not be able to directly access it throught ROS since the MotoRos driver is bypassing the controller higher level motion planner. The only way to use the build in conveyor tracking would be to either generate a job in INFORM language and then downloaded it to the controller or have a generic job using position variables that get updated by ROS. In either case, the MotoRos driver would not be used, you could the High-Speed Ethernet-Server communication to send either the job or update position variables,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants