iCub simulator (in Gazebo), Eyes-Version cannot be controlled in torque mode

[neurohari]

I am experimenting on the dynamic control of humanoid neck-eye system. Since the real iCub robot does not yet support torque control on eye-neck joints, I have been using the iCub simulator. While the torque mode is working on eyes-tilt motor, it is behaving weirdly by exceeding it's joint limits and giving an offset in eyes-version movements.
Could you please help me solve this issue as I haven't found any workaround myself. Thank you very much.

Regards,
Hari.

UPDATE: the problem arises when the eyes-version movement takes the eyes until joint-limit. Once this limit is touched, the eyes start rotating in a random motion for unknown reason.

[pattacini]

Hi @hteja

Out of sheer curiosity, why do you aim to control the head (even the eyes) in torque mode?

[neurohari]

Hi @pattacini

I am implementing a bioinspired optimal feedback control (OFC) for fast gaze shifts in a single plane (in head-free condition). I have selected fast gaze shifts as my test-bed for OFC because they have less complexity to address compared to multi-DOF arm. Basically, if this control mode works, I would be able to model fast gaze shifts through force/torque control.

[pattacini]

To obtain fast gaze shifts, torque control is not really necessary since you can rely on position-direct mode.

However, I understand that your framework — OFC — might have some peculiarities and you need to get access directly to the torque delivered to the motors. In this respect, I don't know what is the status on the real robot and on Gazebo, honestly. Let me call for @randaz81 too.

At worst, you might consider implementing a linear relation that maps torques in velocities.

[neurohari]

Thank you very much Ugo. This would help. I will wait for @randaz81 to see what is the status.

[pattacini]

@hteja please try to avoid assigning issues to people 😉

You can certainly summon specific developers using the mentioning mechanism 👋 but triaging the issues is a maintainers' job.

[neurohari]

Hi Ugo, I'm really sorry. I didn't go through carefully the details of how this works. Next time I'll surely take care of. Thanks for letting me know Regards, Hari.

[pattacini]

Never mind @hteja 👍

[neurohari]

I have found out that the eyes-version movement is behaving controllable in torque mode until the eyes touch their joint-limits. Once they touch the joint-limits, they are closing inward furiously and never to respond to any other torque commands.

Has this behavior been observed anytime before in any other joints? @randaz81

[randaz81]

No, it happens only on eyes joints because they are coupled.
After an accurate analysis I can say that this issue is pretty complicated to be solved, because controlling the eyes in torque mode was never tested and it is currently (partially) working only by chance.
However, it requires a major code refactoring in gazebo simulator (probably next month).
I recommend to use another control mode in the meanwhile.

[neurohari]

@randaz81

In the meantime, I have worked around the problem by disconnecting one eye from the eyes_tilt_joint. This is eliminating the coupling effect of one eye on the other eye. I am sharing the 'sdf' hack:

    <joint name='right_eye' type='revolute'>
      <child>**eyes_tilt_link**</child>
      <parent>**eyes_tilt_link**</parent>
      <axis>
        <xyz>0.0 0.0 1.0</xyz>
        <limit>
          <lower>-1.5708</lower>
          <upper>1.5708</upper>
          <effort>84</effort>
          <velocity>100</velocity>
        </limit>
        <dynamics>
          <damping>1</damping>
          <friction>0</friction>
          <spring_reference>0</spring_reference>
          <spring_stiffness>0</spring_stiffness>
        </dynamics>
        <use_parent_model_frame>1</use_parent_model_frame>
      </axis>
      <physics>
        <ode>
          <implicit_spring_damper>1</implicit_spring_damper>
          <cfm_damping>1</cfm_damping>
          <limit>
            <cfm>0</cfm>
            <erp>0.2</erp>
          </limit>
        </ode>
      </physics>
    </joint>

I hope that this won't effect the overall torque behavior of the neck-eye system.