I’ve got some fairly heavy parts to load and need to make sure the Payload and COG are good. I used the Measure button in the Installation/Payload tab and moved the robot to random positions with no part loaded before I do the measurements with a part to make sure my base Payload is good.
The top pict is where I’ve had it set for many months when grippers are empty.
Middle pict is first use of the Measure wizard. The numbers looked way different than the original so I did it again.
The bottom pict is the last use of the Measure wizard. The numbers are way different than either the original or the 1st attempt.
Needless to say I’m probably doing something wrong. I use random positions every time I use this wizard. Is there a certain pattern I should try to use or what? These numbers are way too different to plug in and run.
Well I have the same question, COG numbers are changing with the same load. I think different poses of the used-4-points affect the COG numbers. are there some reference poses of the used-4-points to measure the payload?
I haven’t got a good answer but it does look like it depends drastically on which poses you use.
Ironically, I imagine UR already knows this but I don’t see it mentioned anywhere.
My solution was to try and mimic 4 poses that I use in most of my programs. Seemed to get more consistent that way.
I’m sure UR is getting real tired of me picking apart their GUI and program capabilities but c’mon, man! This is Robotics 101 stuff here!
I’m a robot rookie and i know this!
Why wouldn’t UR a) tell us the pose positions will greatly affect our results, b) advise us on a “best practice” scenario on which type of poses to use and c) provide a software solution to use stored poses that we could call up from the Payload Wizard?
They always say payload and COG are important. Why don’t they treat them that way?
I would use the start and end corners of the pallet (opposite corners), the machine clear position and the vise position.
Since those are the positions most of my programs use that would be the best scenario for me and would give me a very consistent way to set payloads for new programs (or even update existing programs that were done before I knew any better).
Just another relative newbie here, but when you were getting inconsistent values, were you using poses which were very similar?
I would expect that you’d want to select poses which have the axes as orthogonal to each other as possible - TCP axis pointing up, down, left, right, etc.
Not sure if it’s better to have the arm extended as far as practical or in close.
I agree - some direction from UR would be very helpful.
So there is a rough example of 4 poses that should result in a decent result shown in the first overview screen of the wizard and you will get an error that will not let you proceed with the wizard if the poses you have chosen are not sufficiently diverse (screenshots of both inserted below). So there has been some effort to provide guidance on this, but perhaps you have found a loophole that was not considered when this was created?
I suppose there are scenarios where a smaller mass at a longer offset and a larger mass at a smaller offset may be indistinguishable, but having multiple different poses should prevent this.
Did you get similar results with multiple different sets of poses? Could you share pictures of your tool and the poses? This might help us to identify where the issue came from and how we can improve our documentation.
There’s also the slight chance that something else is going on here, like the calibration for your force torque sensor being off. I don’t have a real robot to hand, so can’t currently test out the repeatability of the solutions the wizard provides.
Andrew
Thanks for the reply.
The first couple of times I used the wizard I got an error saying the poses weren’t diverse enough. I roughly used the positions pictured but used freedrive to position by hand, and extended the reach and rotated the base each time.
The dozen or so times I did it after that I used my own poses by grabbing the tcp and moving it aimlessly to different poses and never got a diversity error but kept getting payload faults. The values varied considerably as well.
The next few dozen times i used it I mimicked the approximate poses my programs used including over the pallet and inside the machine.
I got less payload faults but the results when using relatively similar poses were vastly different and that’s what prompted this thread.
This morning i mimicked the pictured poses as close as possible and got results about 99% the same 2 times in a row (I took pict’s of the poses the first time and used them as a reference the 2nd time.)
So the $64 million dollar question is this: If the requirements for an accurate reading are so tight (and they are, I’ve shown that over the last 3 years by using the wizard so many times and getting crappy, wildly different results), why doesn’t UR go the extra mile to ensure their customers are getting the best readings possible? That would reduce customer’s downtime AND repair costs related to bad payload settings.
There are several ways to do it, but IMO the best way is provide a set of 4 waypoint slots that we can store and re-use the positions.
Another idea is to change the wording in Step 1 of the wizard to highlight the fact that the poses are critical to getting accurate readings and not just “for inspiration”.
Hi @fuknrekd agree there’s room for improvement in the wording on the first page.
One thing that it has seemingly not made clear is that this payload estimation is completed purely based on the data from the force torque sensor in the robot wrist, therefore base rotation and arm extension have no effect on this.
We talk about positions, where as it’s really orientations that are key. I assume it was decided talking about positions was more straightforward than orientations, but is potentially misleading.
With this information in hand, does it seem easier to get reliable result?
@ajp Thanks for the reply.
I agree with @fuknrekd . The best way is provide a set of 4 waypoint slots that we can store and re-use the orientations.
And, we think we need multiple different sets of orientations to verify the consistency of measurement results and judge if the result is within an available range.
it’s not easy to give a set of poses, that is a reference and unique, for different mass distributions. However, I think there should be one at least for a bar shape tool or load, or tools we normally use.
And, considering the limited accuracy of the force torque sensor, 4N for 5e, smaller mass e.g. less then 1kg, can not be measured inaccurately. is there a guide or specification for that?
Having the option to re-use the 4 waypoints that you had success with previously to measure say the empty gripper vs gripper+product makes sensea lot of sense, instead of choosing 4 new poses every time.
I think those external facing specs for the FT sensor are very conservative, we can expect better results from the payload wizard than those listed on the spec sheet.
Correct. The theory behind setting payload is completely absent.
If you’re going to leave it up to users to set positions, the users need more info.
It wasn’t until yesterday that I realized it is only the f/t sensor doing the calculations based on my testing mentioned above. It completely changes the approach people will use.
Without question. Like i mentioned above, when I repeated the poses as close as I could without physically setting poses i got results that were probably 99% the same. And those values are considerably different than my original values.
Considering we only need to use joints connected to the F/T sensor this should not be a risky endeavor.
Thanks for looking at this issue.
Using other payload identification algorithms with more waypoints ( once I got 9 waypoints) gets more accurate and stable payload result, i suggest to provide a script or urp file to easily measure payload for users. It seems not that much difficult.
Have you ever compared the values to the COG / Mass from the design software?
I also, never knew that only the wrist mattered and have done positions with the arm moves about. But my results were close enough to expected design values that I did not question it further.
Which design software? URSim?
Assuming the EOAT was designed in solidworks or similar 3d model software. You can set material and calculate COG& weight of design.
Oh, gotcha. Yeah, CAD and CAM software typically have the ability to calculate weight via volume and material.
From Gibbs…
I think you would want to go back to the modeling itself not CAM software to get the Mass & Center of gravity. But yeah similar concept.
Gibbs does CAM and CAD (solid modelling).
Not well: It’s an archaic method that is highly cumbersome and requires double/triple/quadruple the amount of work as something like Solidworks but it does model.