0
$\begingroup$

Gazebo Answers logo

Hi All,

I've been developing a model that has hydraulic actuators that are as a result very stiff in that a small change to either the load on the actuator or on the valve spool will result in a relatively instant and relatively large change in the states of the actuator. These motors are represented by a class hydmotor;

//Hydraulic motor models
    private:
        hydmotor motor_joint1, motor_joint2, motor_joint3, motor_joint4, motor_joint5, motor_joint6, motor_joint7, motor_gripper;

during the update of the plugin the motors are run through a simulation step of their own based on their own states for pressureload using Gazebo provided dt (from get sim time) and GetVelocity(), returning the result (the force on the joint) via SetForce(axis, value):

    motor_joint1.dt=dt;
    //motor_joint1.u = 0.5;
    motor_joint1.thetaspeed =joint1->GetVelocity(0)*motor_joint1.gearratio;
    //Calculate the Motor Dynamics
    motor_joint1.updateinput();     
   
    
    joint1->SetForce(0, (motor_joint1.getTorque()*motor_joint1.gearratio));

dt is calculated from sim_Time. the method:

motor_joint1.updateinput();

Is basically where the next state iteration is calculated for the motor (where the states are pressureload, and rotationalspeed and the input is the valve position.

These have been incorporated into a Gazebo model via a plugin so that it can talk to ROS. To get it to work required a dt value of around 0.1 ms in the solver. Anything larger and the model ( a serial robot made of a number of links) would end up as a jumbled heap. I tried increasing the iter value about 100 times and can see that the model works for a short time before becomming unstable and flying apart.

My question is why would stability be affected if I only add an additional variable of type hydmotor?

I would expect it to run slower sure, but not to affect the overall stability.

The stability issue can be corrected by making the solver timestep even slower. at the moment it sits at about dt = 0.000044 with iters = 95.

Cheers


Originally posted by PMilani on Gazebo Answers with karma: 203 on 2012-12-20

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Gazebo Answers logo

Okay, the reason why the model was failing was due to hydmotor::updateinput returning NaN. This was due to part of the modelling algorithm where the change in Pressureload would mean that the next iteration in the pressure would be greater than the supply pressure and result in a sqrt(-x) in the algorithm.This was due to the stiffness of the algorithm where the change in pressureload could push the pressure beyond the supply pressure. This would routinely happen and could only be overcome by making dt small.

However another solution could also be used where if Pressureload were greater than supply pressure, then we could accept that was a anomaly of the simulation (quite small dt showed that the Pressureload actually assymptotes to supply pressure). So to make the calculation more efficient when Pressureload was beyond supply pressure we would simply make it slightly less.

Problem was I wasn't picking up all cases of this in my updateInput, and once I modified it to pick up all cases I could easily increase dt a 100-fold with no ill effect. The simulation now runs at least in real time.

cheers

Peter


Originally posted by PMilani with karma: 203 on 2012-12-26

This answer was ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.