Joints Drift when they are not being driven or have a set velocity of zero

Question

hi all,

I've a model that represents a serial manipulator, with hydraulic actuators. I've modelled the actuation of the joints in two ways:

1. one using a hydraulic actuator model that is calculated every call to update() in my plugin. It gets joint velocity from the gazebo model, a valve setting from a ros topic and outputs a torque which is applied to the joint. and
2. Simply applying the valve setting as a velocity directly to the joint using joint::SetVelocity(). ensuring that joint::SetMaxForce() is a non-zero (and quite large) value of 10000.

However when my valve setting is zero, a particular joint in the arm always seems to drift regardless of method. Now this would be realistic if the joint were truly undriven, however if I set my joint velocity to zero, it would help if it stayed zero (within the bounds of the SetMaxForce() parameter). I cant seem to find a method to set the joint to static as this would accurately model counterbalance valves with zero leakage, but it doesn't seem to be implemented yet.My preference is for an open loop solution to this problem to replicate the real world.

Any ideas or workarounds?

---

Originally posted by PMilani on Gazebo Answers with karma: 203 on 2013-09-09

Post score: 0

---

Original comments

Comment by hsu on 2013-09-09:
if the valve setting is zero (closed) with zero leakage, can you model the joint as if it's being held in place by a very stiff spring?

Comment by PMilani on 2013-09-09:
Okay I've implemented a spring to be evaluated when the valve is zero. The current hold angle is updated every time the valve is not zero and acts as a reference. The spring constant is large 1E9 Nm/rad, and is the same across all joints. By implementing this every joint has the same "actuator" dynamics but it is only joint 5 that has a problem of drift. This seems strange as in a serial manipulator, it is not the most heavily loaded. Previous joints should exhibit similar problems but do not.

Answer 1

The drift problem went away after I fixed one of the inertia terms.

The drift problem was predominately in joint 5, which joins link 4 (parent) and link 5 (child) together. The Inertia terms in link 5 onwards were correct and the error was actually in link 4 (which is closer to the base). The link elements have a rather square boxy weight distribution, but my Izz component was about 100 times less than my Ixx and Iyy. I think this must have been a typo. Suffice to say, when the inertia was bought up to be around Ixx and Iyy, the drift problem went away and all my actuator modelling worked as it should have.

I still don't understand why inertia in a parent link should affect a child joint, but it seems it does.

So if you are having issues with drift I suggest re-examine your inertias including those you don't think will have an effect.

cheers

Peter

---

Originally posted by PMilani with karma: 203 on 2013-09-09

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by fjmorenom on 2014-08-11:
Hi Peter, I'm also having the same issue. I'm working with a robotic arm, trying to implement velocity controllers with velocity interface (effort_controllers/JointVelocityController) using ROS and Gazebo. gazebo_ros_control internally uses Joint::SetVelocity in this case, but for some reason the model stays up for a minute and then falls. I'll try to check the inertias, but it's also weird that if I send a sine velocity profile, it can't keep up either. Could it be too because of the inertias?

Comment by PMilani on 2014-10-23:
Sorry for the late reply, I guess you're using ROS Control right? Effectively Gazebo seems to work in a dynamic environment, so when you go to apply an instantaneous change in velocity, this means that acceleration therfore force needs to be very large. If you are having problems try adjusting your joint effort limits in gazebo so they can take large numbers. Alternatively, implement a control loop for velocity using the gazebo joint effort interfaces to control velocity.