we are trying to operate an UR5 as part of an extended manipulator, i.e. it’s mounted as part of a kinematic chain with additional movable joints prior to the UR5.
Those joints change the orientation of the UR5’s base and thus have an impact on the gravity vector of the UR’s internal controller.
When moving the joints of the kinematic chain e.g. tilting the UR5’s base, the protective stop of the UR kicks and stops the movement.
For commanding the UR we use the official ROS driver GitHub - UniversalRobots/Universal_Robots_ROS_Driver: Universal Robots ROS driver supporting CB3 and e-Series. We’ve patched the driver to be able to send a gravity vector from ros to the urscript. In the urscript we then call the set_gravity function within a new thread.
To test setting the gravity vector we’ve mounted the UR5 on a table and used a correct gravity vector (0, 0, 9.82) which leads to successful movements, as well as an incorrect one (0, 0, -9.82) which leads to protective stops. So far so good.
But now mounting the UR5 onto our robot at a wall mounted configuration leads to protective stops. We are not sure how to correctly calculate the gravity vector. Is the mounting setting on the teach pendant influencing the gravity vector calculation? How would a correct gravity vector look like if the UR is wall mounted?
We do not know with respect to which (internal) coordinate system the gravity vector should be expressed and whether the configuration of the mounting on the teach pendant changes those reference coordinate systems?
We’ve also started a discussion on the official github ros driver repository, where you can find more insights to our problem. operate ur5 with dynamically changing gravity vector · Issue #169 · UniversalRobots/Universal_Robots_ROS_Driver · GitHub
The GUI on the teach pendant basically helps the user calculating the gravity vector, in the same way that you need to do.
From the script manual:
Set the direction of the acceleration experienced by the robot. When the robot mounting is fixed, this corresponds to an acceleration of g away from the earth’s center
To be on the save side:
What is the joint configuration of the UR in the screenshots you posted?
I guess for the gravity vector only the first joint matters…
So we can compare that against our coordinate systems in the ROS model
There is no get function for the gravity configuration. get_tool_accelerometer_reading()
Will give you there actual reading in the tool frame. And get_actual_tool_flange_pose()
gives you the transformation from the base to the tool. But it does not tell you anything about the current configuration.
Another approach you could take is to make the configuration in the installation part of Polyscope on the teach pendant. And the take a look at the generated script code, that will also be your initial state before your thread is setting it.
I’m reporting back the results form our latest tests:
firstly, thanks @Ebbe, your hints helped us verify the coordinate systems to be used and how to send the dynamic gravity vector
in the end, we were able to dynamically update the gravity vector based on the orientation of the reference coordinate system without interrupting ongoing motion, without the protective stop kicking in and without any other gravity related fault situation
while it works for our proof-of-concept use-case we found various reasons for this to be possibly dangerous and unsafe as it is highly sensitive to the initial config of the mounting on the panel and what is being sent as the current gravity vector
in the current state, we don’t consider the driver extension ready for the open public
also, the part that calculates the current dynamic gravity vector is specific to our use-case and thus closed-source.
I’m working on a project in which I have the exact same situation, the orientation of the robotic arm changes continuosly and I haven’t been able to solve the problem of setting the gravity.
I understand you cannot make the code public, however, could you explain or pseudocode how to do it?
