Universal Robots+

Dynamically changing gravity vector


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 https://github.com/UniversalRobots/Universal_Robots_ROS_Driver. 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. https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/169


1 Like

Hi @benjamin.maidel,

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

I hope these two examples will help you:

set_gravity([9.82, 0, 0])

set_gravity([0, -9.82, 0])


thanks for the reply!
I’m working with @benjamin.maidel on this issue

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


You are welcome! That makes sense. You can see it in the picture below:

The wire in the animation is a good reference.

so the wire is aligned with the positve y-axis of the gravity reference coordinate system?

1 Like

Yes, the wire is aligned with y-axis of the robot base coordinate system.

thanks for the confirmation - we’ll do more tests and report back here

is there a way to debug the gravity vector within UR script - like e.g. a get_gravity function?

There is no get function for the gravity configuration.
Will give you there actual reading in the tool frame. And
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.

1 Like

@felixmessmer that sounds like quite an application. Any videos for us to nerd out?