Analyze problem of AMO reading random joint position values

[MSECode]

As already noticed in some occasions and mentioned in the following issues:

• joint controlled with AMO boards used as incremental encoder  #428
• https://github.com/icub-tech-iit/study-encoders/issues/31
• https://github.com/icub-tech-iit/study-encoders/issues/22#issuecomment-2464924451

we have seen that it might happen that the AMO encoder starts, at a certain point, to read values that are not compliant with the expected ones given by the imposed movement. After some tests, most of which shown in this issue: https://github.com/icub-tech-iit/study-encoders/issues/31, we have observed that this problem verifies deterministically when we move the AMO sensor away from the magnetic disk while it is moving. As a matter of fact, in that configuration, i.e. when the receiver and the magnetic disk are not in the standard location (which should be extremally accurate and with really minimal variations from what written in the documentation), the encoder board is not able anymore to make the transformation mandatory for writing in the registries a meaningful value of the raw position, so that the controller can rescale that to degree inside its working loop.
Therefore, in order to reproduce this behavior, I've moved the encoder in velocity mode quite slowly, thus to add to the reading less disturbances as possible, and then I start to take the receiver far away from the magnetic disk.

Dod

Verifies the behavor documented in the issues and seen on the robot where we start to have "random" readings

[MSECode]

As shown by the logs and image below, if we take the action described in the body of the issue, where we basically move the receiver of the AMO encoder far way from the magnetic disk we can see how the readings tends to varies a lot being meaningless with respect to the expected ones.
Here the joint is moved in velocity without any limit in the position. This has been done in order to be able to let it move freely without going in hw fault for overcoming the sw and/or hw limits in the moment where we modify the position of the AMO encoder receiver.
As shown in detailed by the zoom done to the rightmost section of the whole plot, which is the moment in which we have actually moved the receiver far from the disks the values read (which are in degrees) tends to vary a lot. Moreover, even if we are continuing to feed positive velocity the joint is not moving only forward but also backward.

Furthermore if we take a look to the raw values, first of all we can see how the values written in the registries responsible for keeping the diagnostic errors are different from zero for all the timeframe in which the encoder receiver is not in the standard position anymore (~500 to 540 sec ). Then we can see how the frequency of the variation of the raw values increased.

Thus, said all of this, I would say that the problem related to the "random" (if we wanna call them in this manner) readings of the joint when using the AMO has been identified and I'm quite sure that the cause of this problem is due to a change of the standard position of the AMO receiver with respect to the magnetic disk (thing that theoretically should never happen when using the robot).
On top of this, as shown by the logs, the diagnostic is not labelling this issue as a real problem. As a matter of fact we just say to the user that there are spikes in the position readings. Thus, in my opinion, we can work on this and exploit better all the values that the AMO diagnostic is giving to us in that time frame and generate real errors deciding if it is or not the cause for faulting the joint or continuing to send warnings.
If one is interested, we have already explained the meaning of the diagnostic values here: https://github.com/icub-tech-iit/study-encoders/issues/31#issuecomment-2400377799

Moreover, as you can see from the first logs I'll add below, I've also tried to see what happens if we remove the cable of the AMO encoder from the receiver connect. In this case we have actually an error and the joint is moved to a fault condition.
Finally, I would bring the attention to the fact that, in the case we are not reading well from the AMO encoder, this is the output we are sending to the user:

[WARNING] from BOARD 10.0.1.1 (three-encoders-setup) time=544s 719m 701u :  MC: Absolute encoder has spikes. There is impulsive noise in the measures of the magnetic position sensor of the joint. (Joint=three_encoders_joint (NIB=0), encoderPort=0, encoderType=AMO)

independently to the consecutive errors in the readings that we have. Thus, as already said above, we should work better on the diagnostic, retrieving more info from the HAL of the AMO diagnostic.

logs-amo-goingalone.log

cc: @valegagge

[valegagge]

Hi @MSECode ,
we can close this issue in favor of a new one where we'll check if it is possible can AMO encoder can move outside its housing. https://github.com/icub-tech-iit/study-encoders/issues/37

[MSECode]

Sure, moreover I'll keep in mind that we still need to open an issue to address the problem of the improvement of the low level (HAL) diagnostic of the AMO. Do we prefer to keep this discussion on a separate issue or make it part or continuation of https://github.com/icub-tech-iit/study-encoders/issues/37 ? What do u think?

[valegagge]

Thanks for pointing out this. I suggest opening a new issue in icub-fw and adding it to the epic https://github.com/icub-tech-iit/study-encoders/issues/21. Thanks