Wrong direction of gravity

edit

Thanks for sharing the model. After inspecting it a bit, I noticed the weird movement happens on joint joint_right_shoulder_upperarm:

<joint name='joint_right_shoulder_upperarm' type='revolute'>
  <parent>link_right_shoulder</parent>
  <child>link_right_upperarm</child>
  <pose frame=''>0 0 0 0 -0 0</pose>
  <axis>
    <xyz>0 1 0</xyz>
    <use_parent_model_frame>0</use_parent_model_frame>
    <limit>
      <lower>-1.79769e+308</lower>
      <upper>1.79769e+308</upper>
      <effort>-1</effort>
      <velocity>-1</velocity>
    </limit>
    <dynamics>
      <spring_reference>0</spring_reference>
      <spring_stiffness>0</spring_stiffness>
      <damping>100</damping>
      <friction>200</friction>
    </dynamics>
  </axis>
  <physics>
    <ode>
      <limit>
        <cfm>0</cfm>
        <erp>0.2</erp>
      </limit>
      <suspension>
        <cfm>0</cfm>
        <erp>0.2</erp>
      </suspension>
    </ode>
  </physics>
</joint>

So I went ahead and cleared all the not required settings and left it like this:

<joint name='joint_right_shoulder_upperarm' type='revolute'>
  <parent>link_right_shoulder</parent>
  <child>link_right_upperarm</child>
  <axis>
    <xyz>0 1 0</xyz>
  </axis>
</joint>

This way, the weird motion stops. So I guess when you copied the joint from one side to the other, you probably forgot to change the sign for some gain. I would try change these parameters one by one to see what's at fault.

Please provide sdf with realistic inertia. It's better if we debug the real robot to figure out what the issue is.

== respond to comment below ==

I personally prefer starting with a realistic model, find out why dynamics is not behaving correctly (deal with all the problem such as "exploded all over the place" is fixable). You'll be surprised the issues you saw before changing inertia might not be a completely different problem at all; as numerical errors have a strange way of exposing themselves sometimes.

Normally, in addition to realistic inertia, I'd ask for realistic estimates of friction, joint damping, actuation details, etc. Those things are optional because we can estimate them to the right order of magnitude by simple assumptions for now. But provide them as a bonus if you have them.

With a working as-realistic-as-possible model as a baseline, we can then make additional trade-offs for performance by tweaking the model physically.

I personally don't think debugging a brand new robot with physically non-realistic parameters is a good approach. The direction of gravity issue might come from various unexpected side effects of numerical updates for one

Thanks.