visose
commented
2 years ago See https://github.com/visose/Robots/wiki#coordinate-systems for how to orient the tool in the plugin, which is different from the UR convention.
This was done on purpose, if it was a good idea or not is debatable, I guess there are pros and cons.
The justification at the time was that the plugin was an abstraction over all the different robots we had at the workshop. Each robot manufacturer uses different conventions (including the coordinate system at the flange), but users would only need to learn one set of conventions (the plugin's). If they switch between different robots, everything behaves the same, the tool doesn't switch to a different orientation, because internally everything is converted to the robot's convention.
If you are only using robots from a single manufacturer (in this case UR), it's understandable that you don't find value in this and would like that the nominal values between plugin and the generated code to match.
Although, you also mention that the visualization doesn't match the path of the real robot. If you convert the the TCP from the UR convention to the plugin's convention (from memory, I believe its rotating 90 degrees around Z), is the simulation still incorrect?
Is there an existing issue for this?
What Robots version are you using?
1.5.2
What Rhino version are you using?
Rhino 7 on MacOS
Current Behavior
When creating a TCP for a tool in Grasshopper, the order of the X,Y and Z offsets are switched when the TCP is created in the program code. See this image:
The tcp is set with one point with the coordinates 1, 2, 3. The resulting code has a TCP of -2, 1, 3. This results in a lot of unexpected behaviour in robot movement. We usually use the TCP-wizard on the robot pendant to get an accurate tcp-location. But when transferring the values to Grasshopper we need to change the order to have the TCP match the real world, which creates a mismatch between the grasshopper visualisation and the real world.
Where does the discrepancy come from? Is there some transformation between reference frames that causes this?
Expected Behavior
I would expect the TCP that is sent to the robot to match the point/plane origin that was used to set it.
Steps To Reproduce
See this definition for an example TCP_Descrepancy_01.gh.zip
Anything else?
No response