David_Levasseur
@ModernDave, could you post a video of the behavior you describe please?
David_Gouffe
Hi, Robotiq is now into packaging, palletizing and sanding applications. Learn more about our new Vacuum Grippers and the Robotiq Sanding Kit. 1-888-ROBOTIQ #275 (762-6847) 1-418-380-2788 #275 (Outside US and Canada) 1-418-655-9221 (Cell) Follow us on
This topic is here since a moment, but I might have some tricks for you.
I guess you are using moveL and they are great.
There is 2 down points with moveL, however, the brand of robot.
-It must be possible to keep the orientation of the tooling across the path
--the robot calculate all of his movement to respect it
---If the robot can't find it, it return an error (at the calculating time or at the runtime when axis can't keep the orientation across the path)
-It goes by the shortest trajectory to the tool orientation required.
--The robot goes the shortest side (A turn between 180 degrees and 360 degrees can go reverse)
--The robot will not respect the axis configuration (1 turn, 2 turn or flipped on the last 3 axis or flipped on the base and axis 2).
The work around is to go to target positions with a moveJ.
The moveJ respect the angles and configurations.
The down point of the moveJ is that it moves in the shortest path joint per joint.
The Tool Center Point(TCP) will travel more and move non-linear.
It is to avoid near surfaces or obstacles without testing or with dynamic path.
To go somewhere reliably, use a few moveJ position and test the sequence.
Then you can start a moveL sequence to get in contact with the part and move it around.
The moveJ command is also used to move the robot between work station.
As you are manually testing path on the part, I would suggest you get a look at Force Copilot for recording a path and replaying it.
As you are finishing surface, I would suggest you get a look at Finishing Copilot that adds Path generation for covering surface with a process.
Finishing Copilot is included in the Finishing kit (That you may not need as you already have a sanding device.).
If you use a CB3.1, get a look at the FT300 force sensor.
On the eSeries, Force Copilot or Finishing Copilot is the way to use the built-in sensor.
Note that passing near singularities or near axis limits or too near to the base of the robot or too far from the base of the robot might also trigger errors at runtime.
Hope this helps.
Hope it is in time for you.
Regards,
David Gouffé
Integration Coach
Coach en intégration
We are using our UR10 (Holding a grinder/sander with a Robotiq 2f Gripper) for basic deburr, grinding, sanding, and polishing operations.
The robot seems to have a very difficult time determining a path to take. We are essentially sanding in a square pattern. (Sanding a flat surface on a square with a cut out interior. Think of it as a large flat picture frame around 2ft by 3ft.)
Before starting to program; I release the brakes on the robot, move the tooling all around the part, and touch every angle I need to get to, and follow the general path I know I want the arm to make and confirm that I am able to touch all of the product with the sander without being close to a bind. sometimes, even when everything appears good. I can make the movements that the robot needs to make, manually. But then when I go to program the robot I am constantly (8/10 times) told that it is 'unable to calculate a path' when I am able to manipulate the arm into the position and path manually. Sometimes; when a path does work, its very inefficient. I have to run at a very slow speed to prevent it from 'snapping' into a bind. The positioning of the arm during the path seems to be what cause most binds and calculation errors. Sometimes I feel that there is a better\more efficient positioning available that is further from the binding positions.
When I program a path using the move command and waypoints, I can choose my own robot positioning...and it goes to the same arm positions every time.
Unfortunately; when im using the force control UR, I am limited to the multipath command. When I program movements using the 'multipath' commands, the arm positioning is determined by the program, instead of by me. I can have the arm facing the direction I want it to start and end, and then when I press play, the arm will choose its own position and path dependent only on tool position and not on any elbows or bends.
Not only does the arm take an unintended path, but if I add or even slightly edit any of the points in my multipath, it can have a huge impact on arm placement before and after the point I have edited. Evades and movements I have programmed in, that worked for the position the arm WAS in, will no longer work, causing the robot to crash during an improper evade.