Investigate Robot retargeting termination with real robot

[lrapetti]

Reporting private discussion relative to human-to-robot retargeting experiments performed with real iCub robot.

From: @S-Dafarra

On Thursday evening, while testing the demo, we noticed that the robot was behaving very weirdly. It was not following the references and it was very jerky. We then tried to close the yarprobotinterface but it crashed without going to the "parking" position. The same happened the morning of the demo. After rebooting the whole robot, things were better. I have never seen this behavior before, so I guess it may be related to the specific demo (even if not limited to). My best guess would be that the retargeting demo does not close all its devices correctly, leaving the boards in some weird states.

From: @lrapetti

The problem in that case might be that the crash of the RobotStateProvider device stopped the yarprobotinterface and then RobotPositionController didn't terminate correctly leaving the robot in a weird state?

Maybe separating the StateProvider and the RobotPositionController in two yarprobotinterface (as introduced with #204) might prevent this type of unstable termination? Investigating further the yarprobotinterface crash at this point is a bit difficult without any logging information.

From: @S-Dafarra

A small note, in my comment by yarprobotinterface I meant, the robot one, just in case it was not clear.

Investigating further the yarprobotinterface crash at this point is a bit difficult without any logging information.

Yes, it is unfortunate not to have logs. How do you think we may proceed? Eventually, we can also start opening an issue to collect this type of failure and jumpstart the discussion. I just want to avoid this problem to get forgotten once we close this issue.

[lrapetti]

I experience some strange behaviour also in simulation, that might be related, that I will document here.

I noticed that by opening the yarpmotorgui, some joints seems to be in hardware fault (even if they are moving, not sure if retargeting is active or not on them). Then when terminating those joints clearly remain in hardware fault.

@S-Dafarra @Yeshasvitvs @kouroshD Is this behaviour similar to what you experience with real robot? In case we can investigate further in simulation.

[yeshasvitirupachuri]

I experience some strange behaviour also in simulation, that might be related, that I will document here.

Which configuration parameters are you using for RobotPositionController

[lrapetti]

I experience some strange behaviour also in simulation, that might be related, that I will document here.

Which configuration parameters are you using for RobotPositionController

I am using the file RobotStateProvider_iCub_Pole.xml (changing the robot prefix in order to use the model in Gazebo)

[yeshasvitirupachuri]

Can you check again if this behaviour is present in position control mode

[lrapetti]

Can you check again if this behaviour is present in position control mode

No it is not happening

I found out that, when in positionDirect the joints in simulation go to hardware fault due to the following error (shown i Gazebo terminal):

[ERROR]An hardware fault occurred on joint  0  torque too big! (  5123.83  ) 
[ERROR]An hardware fault occurred on joint  1  torque too big! (  -5147.98  ) 
[ERROR]An hardware fault occurred on joint  3  torque too big! (  -7857.33  ) 
[ERROR]An hardware fault occurred on joint  6  torque too big! (  2898.85  ) 

So probably due to the fact that at the startup it is required a torque that is too big (probably due to the fact the the initial configuration is much different from the desired one) This should not happen since there is the smoothing trajectory at the startup right?

Anyway, this is probably unrelated to the problem we observe with real-robot. we might move this discussion somewhere else.

[claudia-lat]

Any update @lrapetti ? Otherwise we can close it.

[lrapetti]

I don't think this issue has been happening lately. I think we can close and eventually re-open if it happens again.