Left arm moving in impedance velocity mode suddenly switches to fixed position and crashes

[serena-ivaldi]

Hello,
we have a problem with iCubDarmstadt01.
We were moving the left arm with the tutorial_cartesian_interface module, where the robot is making a circle with its left arm. The arm was in impedance velocity mode, set by demoForceControl (medium compliance). While moving, suddenly the arm stops and the whole left_arm basically crashes: the robotMotorGui shows "fixed position" mode (but the tutorial was still sending velocities commands), and then crashed, meaning that re-launching the robotMotorGui was not possible as the left_arm interface was not responding.
We tried to restart the robot; for two times when we launched the robotInterface, the robot did not calibrate the left arm, but the robotInterface was not giving any error or warning.
What happened? It looks like a hardware_fault problem. We see this error frequently in the first 3 joints of the left_arm. Sometimes it happens that the first 3 joints blocks (robotMotorGui says "hardware_fault" while the 4th joint is idle). We have no idea why...

[randaz81]

I think that this issue can be split in two different problems:

1. the left_arm interfaces crashes. robotInterface is still running (I suppose) but the interface ports are not responding anymore and robotMotorGui cannot connect to them.

2. During the startup phase an hardware fault occurs (most likely an overcurrent on one (or more) 2FOC boards).

In both cases the right way to understand what is going on is to analyze the robotInterface log.
If you have Qt5 installed on the console and you have set the environment variable YARP_FORWARD_LOG_ENABLE=1 on the pc104, you can use the yarplogger gui to export the robotInterface logfile (since github does not allow file attachments in the comments, you can upload it somewhere and post here a link).

NOTES:
The following two suggestions are based on hypothesis only.

• for problem 1) I recommended to restart the boards every time it occurs, just restarting robotInterface is (probably) not sufficient if a board is hanged up (reason still to be discovered)
• for problem 2) I suggest the opposite: do not turn off the boards, just clear the fault with the robotMotorGui (click on the idle button), then close and restart robotInterface. If the fault is really an overcurrent it will not happen again.
• your yarp/icub installation (and firmware) may be not updated in order to display all possible diagnostic messages. I recommend to keep yarp and icub always updated. For the firmware, your current version is already several releases behind the master. However, since we are about to publish a new release in the very next days, my suggestion is to wait for the mailing list announcement and get the latest improvements.

[pattacini]

As clarification, for what concerns the cartesian control, the responsibility of selecting commands type (velocity, position), and thus the corresponding control mode, is in the hands of the low level cartesian controller. In fact, at each time step the controller checks the joints status (look here) and set them to work in the desired mode as per configuration file. By default, the controller should be running in Position Direct.