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

Why does this package suck? #318

Closed
ghost opened this issue Sep 6, 2017 · 17 comments
Closed

Why does this package suck? #318

ghost opened this issue Sep 6, 2017 · 17 comments

Comments

@ghost
Copy link

ghost commented Sep 6, 2017

Not to come of rude or anything, but this meta-package does not support the newest ur firmware. The ur-modern driver does not run on kinetic ant it is loaded with bugs regarding moveit!. My conclusion is to not use a ur robot, the support for ros is the worst I have ever experienced. You didnt even get the joint limits right (witch is a moveit issue, but still the "robot takes all kinds of strange paths = useless with ros"). A lot of people are struggling with all sorts of issues, and my impression of moveit is that the tough was good, but the people behind it didn't plan anything out before designing it. Did I mention that it lags like crazy, unstable with joystick input, arm looses connection all the time on wifi and I can go on and on. Please get some money from ur in order to fix this driver, Im not the first person who stopped using the ur robot because of this crappy driver!

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Sep 6, 2017

Not to come of rude or anything [..]

and then the title of your issue is "Why does this package suck?".

In any case:

Please get some money from ur in order to fix this driver, Im not the first person who stopped using the ur robot because of this crappy driver!

You're absolutely right, these packages could use some work. The thing is: UR is not interested in users like you, and doesn't want to support people that want to use ROS with URs. According to UR, there is no money in this, so they will not spend any money.

I would be obliged if you could direct your frustration towards your UR sales representative, or even better, to UR itself directly. If enough users do that, we can perhaps get things to change.

@robinsonmm
Copy link
Member

I would be happy to participate or lead an effort to collect "voice of the community/user base" to try to put some numbers and "opportunity cost" that we could use in communication with our friends at UR. In some cases it helps to talk in terms of lost sales/revenue. I'm open to ideas for how to collect this information, the issue tracker seems like a great place to start, but I'm sure there are others out there that may not be commenting specifically here. (i.e. google group).

Thanks

MR

@ipa-mirb
Copy link

ipa-mirb commented Sep 6, 2017

+1
Please keep also in mind that some ROS users wishing to see better support for a specific make and model, ideally through more active involvement of the manufacturer, are not going to comment on this publicly (e.g., because their corporate policy prohibits it).

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Sep 6, 2017

And as this is an issue on a tracker, I'll try to comment on the issues you encountered:

but this meta-package does not support the newest ur firmware.

and that is known and stated in the readme and the wiki.

The ur-modern driver does not run on kinetic

ros-industrial/ur_modern_driver#120

is loaded with bugs regarding moveit!

I don't know what this means. Anecdotal, but we use it in our lab almost daily, as are other people. It's more than possible that there are things that don't (always) work, but it does work.

If you can be more specific then we could perhaps see if there is something that we can do about it.

My conclusion is to not use a ur robot, the support for ros is the worst I have ever experienced.

As I wrote earlier, it would be great if we could tell UR this.

You didnt even get the joint limits right

To be fair, this is not even a MoveIt issue, but an issue with the robot itself. The joint limits in ur_description and urX_moveit_config are exactly as UR specs them.

The work-around that is needed to compensate for this 'design feature' of the robot is in #268 fi. Admittedly, we should have merged that earlier.

(witch is a moveit issue, but still the "robot takes all kinds of strange paths = useless with ros")

True, although slightly exaggerated.

A lot of people are struggling with all sorts of issues, and my impression of moveit is that the tough was good, but the people behind it didn't plan anything out before designing it.

Your OP is going off-topic a bit here, but I understand the frustration.

Did I mention that it lags like crazy, unstable with joystick input,

It's not entirely clear, but I'm getting the impression that you tried using the joystick interface to jog the robot like you would with the teach pendant. That is not what that is for.

The joystick launch files essentially allow you to control the interactive MoveIt marker with a joystick - like you would with a mouse - and then plan towards that goal pose - like you would with a mouse.

It is not meant to be a jogging interface.

The "lagging" that you refer to is probably the time the planners need to find a new, collision free, path to your goal. That is going to take time.

Again, this is off-topic for this issue tracker, but I wanted to provide a possible explanation for what you were seeing.

arm looses connection all the time on wifi and I can go on and on.

Well .. using any wireless connection between you and an industrial robot is not recommended in any case, using any framework or remote control interface.

To be honest, I don't think we can hold this against either ur_driver or ur_modern_driver, as without any ROS involved, I think you'll run into the same issues if you were just manually spamming the secondary or matlab interface with TCP packets. TCP just isn't well suited for lossy links over which you want to do low-latency, low-jitter work.

Please get some money from ur in order to fix this driver, Im not the first person who stopped using the ur robot because of this crappy driver!

Let's try and make that happen and try to improve things such that future users can avoid the frustration that you experienced.

@philip-long
Copy link

I just want to add one comment regarding

The joystick launch files essentially allow you to control the interactive MoveIt marker with a joystick - like you would with a mouse - and then plan towards that goal pose - like you would with a mouse.

The ur_mordern_driver includes a joint speed interface:

/joint_speed : Takes messages of type trajectory_msgs/JointTrajectory. Parses the first JointTracetoryPoint and sends the specified joint speeds and accelerations to the robot. This interface is intended for doing visual servoing and other kind of control that requires speed control rather than position control of the robot. Remember to set values for all 6 joints. Ignores the field joint_names, so set the values in the correct order.

We have previously used this in conjunction with inverse kinematics to have the "jogging function" as a virtual teach pendant, additionally with visual servoing which works perfectly as is very reactive. Maybe this method suits your purposes more.

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Sep 6, 2017

@philip-long: thanks for the comment.

There are definitely ways to implement a jogging interface using the same pieces of infrastructure, true.

My comment was about the likely mis-use / misunderstanding of the joystick interface that the MoveIt configuration currently provides.

@davetcoleman
Copy link
Contributor

This thread just entertained us greatly

@mbharatheesha
Copy link

but still the "robot takes all kinds of strange paths = useless with ros".

tl;dr: MoveIt! may have other issues (and I don't intend to endorse or condone MoveIt!), but is perhaps not primarily responsible for strange paths. In the context of this issue, with a 6-DOF UR trying to plan to a 6-DOF pose using random motion planners is generally a hard motion planning problem unless one is happy to use linear interpolation in the joint space to get from a start point to a goal point.


MoveIt! is made to use a planning library of a user's choice to plan motions. "Off-the-shelf", it is configured to work with OMPL as the planning library. The strange paths that are commonly seen, come from one of the planners in the planning library and of course, that is expected from non-optimized random sampling-based planners (if you are using one of them). MoveIt! manages the part of processing the path received from a planning library to a trajectory that a robot can execute (for ex: time parameterizing a path, collision checking and so forth.)

If there is too much concern about the kind of paths that the robot is taking, some additional tuning needs to be done. See Section III B in Tuning Parameters of RRT-Connect for example. It provides a nice analysis of the impact of planning parameters on the "default planner" used by most users, namely RRTConnect. Another option would be to use a planner which optimizes the paths such as RRTStar (also available "off-the-shelf" from OMPL+MoveIt!), but optimization takes time, and it is not clear from the issue here as to what the application is.

@davetcoleman
Copy link
Contributor

I should follow up by saying that yes, we need everyone to get the message to Universal Robotics that supporting open source drivers, especially ROS, is important to their customer base. UR's policy of changing their firmware API without notifying or helping the volunteer maintainers of this open source has caused so many new UR users great frustration. I've seen it repeatedly in many companies who think that "the most popular robot arm surely has good ROS support".

@v4hn
Copy link

v4hn commented Sep 12, 2017

The ur-modern driver does not run on kinetic
ros-industrial/ur_modern_driver#120

Maybe I don't know where to look, but I have not seen much effort from ROS-I's universal_robot repository to support the ur_modern_driver or the new kinetic version.
You still see people trying to use the ur_driver package until they are told that ur_modern_driver exists.
It is a shame that the "real" driver for indigo+ is in a personal git repository instead of with the ros-i initiative that aims to support it.
ros-industrial/ur_modern_driver#120 discusses that the new code should be merged into this repository and should replace the current ur_driver. I would like to see that happen in kinetic.
Given that there are 18 open pull-requests - more than one fixes actual bugs or improves compatibility with other modules - I wonder who will stand up to merge it there because apparently no maintainer is willing to review contributor's work unless UR pays for it.
This pretty much defeats the purpose of OpenSource software development.
In the end we all want to see our robots work, or don't we?

The work-around that is needed to compensate for this 'design feature' of the robot is in #268 fi. Admittedly, we should have merged that earlier.

It's not merged yet.

Sorry for this pessimistic declaration, but although our UR5 setup works quite well,
I do agree with some of the concerns people raised with this repository in the past.

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Sep 12, 2017

I believe there is some confusion here: the previous comments should not be taken as "ROS-Industrial is not doing anything until UR pays for it".

The OP suggested asking UR for financial support. I merely explained that there is no point in doing that without (much) more involvement from the ROS community - ie: the actual users and buyers of Universal Robot's robots, as UR has made it pretty clear that they are not interested in supporting their customers who want to use ROS with their robots in the past.

Maybe I don't know where to look, but I have not seen much effort from ROS-I's universal_robot repository to support the ur_modern_driver or the new kinetic version.

The implication that we're not doing anything is incorrect, but I agree with you that it may seem that way. There are various efforts currently underway to improve the situation, but they are unfortunately not very visible.

You still see people trying to use the ur_driver package until they are told that ur_modern_driver exists.

The fact that ur_modern_driver should be used with CB3 and up is documented in the tutorial, the wiki and in the repository readme itself. We can always improve things, but it cannot be said that this is not made clear.

It is a shame that the "real" driver for indigo+ is in a personal git repository instead of with the ros-i initiative that aims to support it.
ros-industrial/ur_modern_driver#120 discusses that the new code should be merged into this repository and should replace the current ur_driver. I would like to see that happen in kinetic.

There are a number of reasons this hasn't happened yet. That is unfortunate, but it's not a lack of interest on our side. Again: we are working on this, but haven't been able to complete the migration.

Given that there are 18 open pull-requests - more than one fixes actual bugs or improves compatibility with other modules - I wonder who will stand up to merge it there because apparently no maintainer is willing to review contributor's work unless UR pays for it.
This pretty much defeats the purpose of OpenSource software development.
In the end we all want to see our robots work, or don't we?

As I wrote earlier: the OP mentioned money, we did not.

@NikolasE
Copy link

NikolasE commented Oct 2, 2017

@davetcoleman Could this be a topic for the WorldMoveItDay?

@v4hn
Copy link

v4hn commented Oct 2, 2017

@NikolasE This is a bit to big to be handled in WMD and it's not unclear how to proceed here exactly.
For the moment, let's leave this with @gavanderhoorn . He promised me something will happen from ROS-I's side in the foreseeable future.

@NikolasE
Copy link

NikolasE commented Oct 2, 2017

@v4hn There are also smaller topics that could be solved. The trajectory execution function for example does not check if the robot is following fast enough (e.g. due to a maximal velocity set on the teach panel) so that the robot state differs more and more from the sent joint commands. A simple check and abort of the trajectory execution could be done in a short time.

@v4hn
Copy link

v4hn commented Oct 2, 2017

That's not my nick.

There is probably many things to do for UR support, I agree.
If you know of smaller issues, please file new issues for them with the respective repository.
If they're small enough (can be done in one day), we can put them on the list for WMD.
I believe all new patches for ur_driver should build on ros-industrial/ur_modern_driver#120 though.
This is supposed to be the replacement for the driver code in this repository (we already use that branch in our lab).

@130s
Copy link
Member

130s commented Jun 2, 2018

Don't know any detail, but the title by itself already sounds like a great news.
Let's welcome @Universal_Robot to the ROS-I family! Thank you for your support!.

@gavanderhoorn
Copy link
Member

Unfortunately the original poster's account is no longer around. Otherwise he would probably be happy to hear about UR joining the consortium and their future involvement.

For now I'm going to close this issue. It was a valid concern raised by the OP, but the issue itself does not contain any directly actionable tasks. I believe many of the implied ones (if not all) have been captured in other issues.

If anyone wants to keep commenting on this, please feel free to do so.

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

No branches or pull requests

9 participants