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
Comments
and then the title of your issue is "Why does this package suck?". In any case:
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. |
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 |
+1 |
And as this is an issue on a tracker, I'll try to comment on the issues you encountered:
and that is known and stated in the readme and the wiki.
ros-industrial/ur_modern_driver#120
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.
As I wrote earlier, it would be great if we could tell UR this.
To be fair, this is not even a MoveIt issue, but an issue with the robot itself. The joint limits in 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.
True, although slightly exaggerated.
Your OP is going off-topic a bit here, but I understand the frustration.
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.
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
Let's try and make that happen and try to improve things such that future users can avoid the frustration that you experienced. |
I just want to add one comment regarding
The ur_mordern_driver includes a joint speed interface:
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. |
@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. |
This thread just entertained us greatly |
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. |
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". |
Maybe I don't know where to look, but I have not seen much effort from ROS-I's
It's not merged yet. Sorry for this pessimistic declaration, but although our UR5 setup works quite well, |
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.
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.
The fact that
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.
As I wrote earlier: the OP mentioned money, we did not. |
@davetcoleman Could this be a topic for the WorldMoveItDay? |
@NikolasE This is a bit to big to be handled in WMD and it's not unclear how to proceed here exactly. |
@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. |
That's not my nick. There is probably many things to do for UR support, I agree. |
Don't know any detail, but the title by itself already sounds like a great news. |
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. |
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!
The text was updated successfully, but these errors were encountered: