After reading through the descriptions in the URScript manual, I was a little confused about the behavior of calling set_payload() with a COG specified.
The manual states:
The CoG argument is optional - if not provided, the Tool Center Point
(TCP) will be used as the Center of Gravity (CoG). If the CoG argument
is omitted, later calls to set tcp(pose) will change CoG to the new TCP.
The CoG is specified as a vector, [CoGx, CoGy, CoGz], displacement,
from the toolmount.
Specifically, can someone clarify the behavior if the COG is specified and then a subsequent call to set_tcp() is made? Does the COG remain relative to the tool mount or is it updated to the new TCP? Also, if set_payload() is called again, is the COG relative to the tool mount or the new TCP?
Did you consider to use the functions
set_payload_cog([cogx, cogy, cogz]) instead, as they allow you to set either of the two parameters individually instead?
That may be a work around, but I would really prefer clear documentation from UR on the actual expected behavior of set_payload().
Also, can you confirm that if you have a TCP set, that calling set_payload_cog() is always relative to the toolmount and not relative to your currently set TCP?
The documentation you quoted is correct.
set_payload(m, CoG) in respect to Center of Gravity:
- If providing both arguments,
The CoG will be set to the given value, and TCP changes have no impact on CoG.
- If not providing the
The at any time active TCP will be working as CoG. Hence if you change TCP later, this will change CoG,
Is there a way to retrieve maximum payload?