# Inertia matrices and double precision ODE

Hi All,

I have a problem with the precision of ODE.

The environment that I'm trying to use is:

• Ubuntu trusty
• ROS Indigo
• Gazebo 6

The model of my robot (about 0.4 metre tall) has links as small as this and mass of 0.025kg:

  <geometry>
<box size="0.045 0.022 0.0325"/> // Units in metre
</geometry>


And this is the inertial element, with the real values, for the same link:

   <inertial>
<pose frame=''>0 0 0 0 -0 0</pose>
<mass>0.0243577</mass>
<inertia>
<ixx>3.12641e-06</ixx>
<ixy>0</ixy>
<ixz>0</ixz>
<iyy>6.25435e-06</iyy>
<iyz>0</iyz>
<izz>5.09279e-06</izz>
</inertia>
</inertial>


So the problem that I have is that the moments of inertia are too small and the model becomes unstable.

I have tried scaling the values for the inertia matrix, but no the geometry, collisions, mass, etc. This had some reasonable behaviour with Gazebo 2.2, but with Gazebo 6 the inertial values are too big and the robot bounces with any slight movement.

I also was thinking in increasing the precision on ODE to double, but I haven't find any tutorial to do this.

I know that converting the measurement units to millimetres consistently across the model and ROS could fix the problem, but I'd prefer some more transparent solution rather than converting units back and forth and managing different units for the physical robot and the simulation.

Do you have any recommendation to deal with this?

EDIT: After applying debz and hsu recommendations, I also realised that my joint controller was using incorrect method to control the joint position. With all the corrections the model works without problems.

Thanks, Germán

edit retag close merge delete

Sort by » oldest newest most voted

I think it is a recurrent problem. I faced the same instability with a recent project. What might happen is not that ODE can't handle small doubles variable as many previous topics suggest (inertial e-06 is quite OK). But the way your joints are defined might be the cause. If the inertials are small, then your links are easy to move. One link moves, disturb an other one through the joint that links them, and so on. This happens because your joints are too perfect, they transfer too much energy. At the end your robot shakes and can even explode. I solved my case by playing with these parameters (not all of them are necessarily relevant). Increasing damping limits the mutual physical actions between your links. Increasing friction set up a lower limit for velocity before the joints actually transfer the energy coming from the action of one of the links.

  <axis>
<xyz>0 0 1</xyz>
<dynamics>
<friction>friction</friction>
<damping>damping</damping>
</dynamics>
</axis>
<physics>
<ode>
<cfm_damping>cfm_damping</cfm_damping>
<implicit_spring_damper>implicit_spring</implicit_spring_damper>
</ode>
</physics>


I use these parameters (my damping is that hight because I use strong PID controllers on my joints. You'd better take a value between 0 and 1):

friction = 0.01
damping = 6
cfm_damping = 1
implicit_spring = 1


I hope this helps.

more

Some of those values help a bit, specially when applied to the world, not just to the joint. But I still can't get a stable model. I'm trying to model some Dynamixel servos, but given the size (small moments of inertia) and torque (<limit effort="2.5" velocity="5.6548668"/>), gazebo doesn't like it... The parameter that seems to work the best is reducing max_step_size between 0.0001-0.00001, but still get some jitter in the joints.

( 2016-01-14 01:08:02 -0500 )edit
1

The only small things I can suggest: - verify your inertials (using the gazebo client, view->inertials). They should fit to the collision geometry of your links. If only one link hasn't right inertial, the entire robot gets shaky. - I use the following parameters: max_step_size = 0.002, solver type = quick, sor = 1.4, constraints cfm = 0, erp = 1.

( 2016-01-14 11:35:49 -0500 )edit

Original values fit with the collision. But when using gazebo 2.2 I gave up and ended scaling them by 100, which even if it is wrong had acceptable stability/performance. Now, with gazebo 6, I'm trying to get rid of the scaling. MOIs are calculated using basic shapes (box, cylinder, sphere) from here https://en.wikipedia.org/wiki/List_of_moments_of_inertia

( 2016-01-14 16:59:12 -0500 )edit

As debz said, 1e-6 kg m^2 should be fine for inertia values specified in doubles. In addition to the damping tip from debz, the instability also has to do with inertia ratio across joint constraints than the actual magnitude of the inertia. The instability can occur if the link is connected to another link with moment of inertia of 2+ orders of magnitude difference (for example moi in the same constrained direction that is >1e-4 or <1e-8 kg m^2). If this is the case, more inner iterations are needed if you are using the default solver.

more

I'll check this, there is definitely a difference of order 1e3 or 1e4 between some links. The base link is: <box size="0.102 0.109 0.106"/><mass value="0.97559947"/><inertia ixx="0.00187941032723" ixy="0.0" ixz="0.0" iyy="0.0017593303405" iyz="0.0" izz="0.00181176879104"/>. While a child links is: <box size="0.045 0.022 0.0325"/><mass value="0.024357719"/><inertia ixx="3.12641347358e-06" ixy="0.0" ixz="0.0" iyy="6.25434930399e-06" iyz="0.0" izz="5.0927910438e-06"/>

( 2016-01-14 17:15:31 -0500 )edit

Is this with the default build packages from osrfoundation? I haven't do anything yet to change the precision of ODE. I understand that for previous releases ODE is set to single precision (float), not sure if this is still the case.

( 2016-01-14 17:21:40 -0500 )edit

This post is a wiki. Anyone with karma >75 is welcome to improve it.

The problem also occurs on me , I wonder if you have solved it yet. Thanks!

more

The decimal keyword denotes a 128-bit data type. Compared to floating-point types, the decimal type has a greater precision and a smaller range, which makes it suitable for financial and monetary calculations. Precision is the main difference where double is a double precision (64 bit) floating point data type and decimal is a 128-bit floating point data type.

Double - 64 bit (15-16 digits)

Decimal - 128 bit (28-29 significant digits)

So Decimals have much higher precision and are usually used within monetary (financial) applications that require a high degree of accuracy. But in performance wise Decimals are slower than double and float types. Double Types are probably the most normally used data type for real values, except handling money. In general, the double type is going to offer at least as great precision and definitely greater speed for arbitrary real numbers. More about...Double vs Decimal

George

more