Retrieve latest joint fault state from firmware for exposition towards client

[mfussi66]

This PR aims to complement the work done to address: robotology/community#561 , in which the feature request involved communicating the latest fault to the yarpmotorgui. To address it, a new interface was created in YARP to retrive the latest fault code and a message string.
Here, the implementation of the fault state retrieval is proposed by adding the definition of getLastJointFaultRaw in embObjMotionControl. The exposed error code and message string corresponds to the errors in the category Motion Control:

  {eoerror_value_MC_motor_external_fault,  "MC: exernal fault button pressed."},
    {eoerror_value_MC_motor_overcurrent,     "MC: overcurrent. The motor has been turned off to prevent it from being damaged by an impulsive spike of current. par16 = ID of joint."},
    {eoerror_value_MC_motor_i2t_limit,       "MC: i2t limit exceeded. The motor has been turned off to prevent it from being damaged by overheating due to a continuous high current. par16 = ID of joint."},
    {eoerror_value_MC_motor_hallsensors,     "MC: 2FOC hall sensors fault. Invalid sequence in motor Hall effect sensors, please check motor hall cable connections. par16 = ID of joint."},
    {eoerror_value_MC_motor_can_invalid_prot,"MC: 2FOC CAN invalid protocol. The EMS and 2FOC firmware versions are incompatible, please update. par16 = ID of joint."},
    {eoerror_value_MC_motor_can_generic,     "MC: 2FOC CAN generic error. Errors happened in the CAN bus between the EMS and the 2FOC board. par16 = ID of joint."},
    {eoerror_value_MC_motor_can_no_answer,   "MC: 2FOC CAN no answer. The communication between the EMS and the 2FOC board has been lost for more than 50 ms. par16 = ID of joint."},
    {eoerror_value_MC_axis_torque_sens,      "MC: torque sensor timeout. The joint is in a compliant interaction mode or torque control mode, and data from torque sensor have been unavailable for more than 100 ms. par16 = ID of joint."},
    {eoerror_value_MC_aea_abs_enc_invalid,   "MC: AEA encoder invalid data. Hardware problem in the magnetic position sensor of the joint caused invalid position readings. par16 = AEA port (msb) and ID of joint (lsb)."},
    {eoerror_value_MC_aea_abs_enc_timeout,   "MC: AEA encoder timeout. No answer from the magnetic position sensor of the joint (cable broken?). par16 = AEA port (msb) and ID of joint (lsb)."},
    {eoerror_value_MC_aea_abs_enc_spikes,    "MC: AEA encoder has spikes. There is impulsive noise in the measures of the magnetic position sensor of the joint. par16 = AEA port (msb) and ID of joint (lsb)."},
    {eoerror_value_MC_motor_qencoder_dirty,  "MC: 2FOC quadrature encoder dirty. The number of thicks in a complete revolution of the motor was lower than expected, the optical disks need to be cleaned. In par64 0xFF is the mask of raw encoder value. par16 = ID of joint."},
    {eoerror_value_MC_motor_qencoder_index,  "MC: 2FOC quadrature encoder index broken. The reference special thick was not detected during a complete revolution of the motor, please check motor encoder cables. In par64 0xFF is the mask of raw encoder value. par16 = ID of joint."},
    {eoerror_value_MC_motor_qencoder_phase,  "MC: 2FOC quadrature encoder phase broken. The motor encoder is not counting even if the motor is moving, please check motor encoder cables. In par64 0xFF is the mask of raw encoder value. par16 = ID of joint."},
    {eoerror_value_MC_generic_error,         "MC: generic motor error (see 64 bit mask parameter)."},
    {eoerror_value_MC_motor_wrong_state,     "MC: 2FOC wrong state. The 2FOC motor controller is in a control state different from required by the EMS. In par64 0xF0 is the mask of requested state, 0x0F is the mask of actual state. par16 = ID of joint."},
    {eoerror_value_MC_joint_hard_limit,      "MC: hard limit reached. The joint position is outside its hardware boundaries. par16 = ID of joint."},
    {eoerror_value_MC_motor_qencoder_phase_disappeared, "MC: qenc error has disappeared, warning counter has been reset."}

See the attached video for a small demo:

145057677-9b9af4e4-94ae-497c-a74e-dec12718574f.mp4

Related PRs:

icub-firmware:robotology/icub-firmware#224
icub-firmware-shared: robotology/icub-firmware-shared#52

[pattacini]

cc @S-Dafarra

[pattacini]

Waiting robotology/icub-firmware-shared#52 to be merged and the CI to complete before proceeding.

[traversaro]

Probably we may want to bump https://github.com/robotology/icub-main/blob/master/CMakeLists.txt#L18 to 3.5.100 to give a clear error if people try to build devel icub-main against YARP 3.5.1 . Note that in this form this PR creates a strict dependency on YARP 3.6 being released before we can make a new feature release of icub-main.

[pattacini]

My idea was also to ask @randaz81 to cherry pick the change on yarp-3.5 branch to avoid depending on yarp@master.

[marcoaccame]

Probably we may want to bump https://github.com/robotology/icub-main/blob/master/CMakeLists.txt#L18 to 3.5.100 to give a clear error if people try to build devel icub-main against ......

What we surely need is to create a dependency of icub-main from the latest version of icub-firmware-shared to prevent versions mismatches. I will address the issue in this associated PR.

[marcoaccame]

Pls set up dependency from a specific version of icub-firmware-shared. See in here how to do it.

[pattacini]

Regarding #779 (comment), I've just pushed a commit into @mfussi66's fork to enforce the dependency from yarp@master.

Regarding #779 (comment), I've just talked to @randaz81 who recommended that we do a test on a fork where we cherry-pick the relevant changes as there's the feeling that something could go wrong.

I would postpone this latter check after we merge this PR.

cc @traversaro

[pattacini]

@mfussi66, as soon as robotology/icub-firmware-shared#52 is merged, I'll proceed with this PR.

[randaz81]

Please also note that you need to update the robot XML files to use the interface because it's implemented only in the new NWS, (tested by @mfussi66)

[pattacini]

Please also note that you need to update the robot XML files to use the interface because it's implemented only in the new NWS, (tested by @mfussi66)

Ok, we would need to have robotology/robots-configuration#297 merged finally, and then extend those changes to the other robots, somehow.

At any rate, @randaz81, are the missing XML blocking (in the sense they would cause run-time errors) or could we merge this PR anyway and then deal with the XML?

[randaz81]

You can proceed because PR and XML files are completely independent: no compiler errors nor run time issues.
If the XML files are old, the feature is only disabled 'cause old wrappers are used.

[pattacini]

Sister PR's have been merged, hence I've got the CI started over.

[pattacini]

Hi @mfussi66

There's a compilation problem under Windows:

Creating library D:/a/icub-main/icub-main/build/lib/Release/embObjMotionControl.lib and object D:/a/icub-main/icub-main/build/lib/Release/embObjMotionControl.exp
2021-12-15T16:35:06.6715731Z embObjMotionControl.obj : error LNK2019: unresolved external symbol eoerror_code_dummy referenced in function "public: virtual bool __cdecl yarp::dev::embObjMotionControl::getLastJointFaultRaw(int,int &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)" (?getLastJointFaultRaw@embObjMotionControl@dev@yarp@@UEAA_NHAEAHAEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) [D:\a\icub-main\icub-main\build\src\libraries\icubmod\embObjMotionControl\embObjMotionControl.vcxproj]
2021-12-15T16:35:06.7288058Z D:\a\icub-main\icub-main\build\lib\iCub\Release\embObjMotionControl.dll : fatal error LNK1120: 1 unresolved externals [D:\a\icub-main\icub-main\build\src\libraries\icubmod\embObjMotionControl\embObjMotionControl.vcxproj]

Could you please fix it?