Home› Programming
Discussion
Back to discussions page
Sebastien
Posts: 219 Handy
Vision locate together with path recording |
573 views
|
Answered | |
/ Most recent by matthewd92
in Programming
|
15 comments |
Instead of using a move under a Vision Locate can you use the path recording?
Tagged:
At runtime the Camera Locate node will get the object position. It will then offset the first move reference frame which will move the robot to the path staring point. Then the trajectory will be played relative to that starting point.
Software Designer
[email protected]
Here is an example that I made. You can get the program by clicking the link below. In the program I basically programmed the camera locate as is. Then as suggested by @PierreOlivier_Proulx I added a waypoint relative to the camera feature and then recorded the path making sure it is relative. In the video you will see that the vision system is not able to locate the part at certain locations. I did not troubleshoot this but my guess would be that the shadows created by the part as it was laying to the side of the field of view messed up a bit the vision system. In that case, to solve the issue I would have added an external source of light to eliminate shadows effect. That opens up a whole lot of application. What application do you have in mind?
Application Engineer
Robotiq
[email protected]
[email protected]
[email protected]
[email protected]
In short, there are two different kind of imprecision, Path will be an imprecision on the actual trajectory, multi-directional, depending on your tool, and quite small to be honest, you can estimate it:
Total Path error = UR error + Tool deformation
Remember that the UR error is +/- 0.1 mm, so if you have a stiff tool, your error will be very low.
Camera Locate imprecision will be an offset from the reference frame, uni-directional, this would will be larger then the Path recording imprecision, but I have no numbers to give right now
[email protected]
Has anyone else experienced this sort of "wobbly" path performance? If you used an FTS to teach a linear path, would it improve the precision of a robot with poor moveL performance? I would appreciate any feedback on this, let me know if I can clarify what we're seeing in any way.
Concerning the use of the Path with FTS to improve a linear path, we don't have any numbers to give right now. And one important thing to remember, the human hand usually guide the Path teaching, and I'm pretty sure your hand got much more imprecision then the UR. So unless you plan to use another industrial robot to teach the Path to the UR, it wouldn't make sens from my point of view. But it's still something I will dig in.
[email protected]
Hi @jbahner
I am not surpirsed that path accuracy for a Universal Robot is around 10x of the repeatability. The path accuracy is affected by deformation of robot arm, as the positional error in each joint is amplified due to the kinematic design. The rigidity of the contruction upon where the robot is mounted is important as well.
My own personal experience working with other robot brands, mainly Fanuc and Hyundai, as an integrator is that an accuracy below +/-1 mm was often hard to achieve, at least with their standard software (some brands offer a high accuracy software option available for an additional price, where you can reach btw +/-0.2 and +/-0.5 mm)
There is an interesting article concerning robot accuracy conducted by Nikon Metrology, see attached pdf.
I am very interested in what level of accuracy you are in need of and for what purpose you need it. If there is a big need in the market of a certain accuracy level we will definitely be interested in investigating the options to improve accuracy.
As far as the market for high accuracy path performance, I've seen quite a bit of interest from people that want to use the UR for path-critical applications like laser cutting and 3d-printing, usually seeking a bare minimum of 100 micron precision. They are drawn to the UR for it's price, simplicity, and excellent interface, but as soon as we talk technical specs we run into problems. When a customer reads a spec that says 100 micron repeatability, and then they find out that spec might be 10x worse while the robot is moving, they are pretty disappointed. I think these customers would be willing to pay a premium for a robot that combines the performance of more precision-grade products with the excellent ease-of-use of the UR, but as of now the UR falls short of what they need.
If you use the movel you have to add a radius to keep it from stopping between points but the speed that you see is much slower due to slicing the move into small parts (this is very evident in the speed difference between the path move and the return move)
Would this help to solve the issue with path repeatability?