joint controlled with AMO boards used as incremental encoder

[maggia80]

Description

We noticed it on the left pitch and roll shoulder in ergoCub1.1 S/N:001. The two joints are controlled in position and after a while even if there aren't any position commands the joint goes toward an HW limit. While moving the AMO reading seems to be blocked.
Sometimes the joint doesn't reach the HW limit, but it remains quite far from the previous position while reading a similar angular position.

Hypothesis

The AMO stops reading for some reason and the PID to reduce the error from the setpoint and the current position generates a PWM that moves the joint trying to reduce the error, but since the AMO is stuck to a fixed value, the error remains constant and the motor keeps moving.

Possible reasons:

1. the reading of the AMO is interpreted as a spike and the value is kept constant for a long period of time.
2. the AMO is not reading for some cable issues
3. the position of the AMO is too far or not well aligned with the magnetic target causing spikes.

[maggia80]

cc: @AntonioConsilvio, @ale-git @valegagge

[maggia80]

@AntonioConsilvio would be very helpful if you could log the encoder and motor position while this phenomenon occurs.

[MSECode]

After all the analysis done here: https://github.com/icub-tech-iit/study-encoders/issues/37 and in other issues collected in this epic: https://github.com/icub-tech-iit/study-encoders/issues/21 we can say that during normal uses cases of the ergoCub robot the AMO encoder should never read random values otherwise there are some problems that we have for now identified in the following points:

• the behaviour of the AMO reading random values while moving has only been reproduced by loosing the screws of the encoder connector and moving it far from the magnetic disk. Moreover we saw that the encoder does not read properly if it is not exactly in the standard position.
• However, this problem is still not 100% clear since, as we already said above, we were able to reproduce that behavior only by moving the AMO encoder board far from the magnetic disk while the joint is moving but this condition should never happen and looking at the mechanics of the joint that cannot happen when the robot is used properly (if that happen it means that the joint is actually broken)
• if we have problem on the cabling such as one of the signal cables is broken or detached or we disconnect the AMO encoder connector the joint is SET in HW FAULT and it stops
• if the AMO encoder is not fixed at its standard position or if the magnetic disk is damaged the fw will send on the upper level plenty of warnings about reading of spikes and thus this might be seen as the behaviour described in the body of the issue.

cc: @valegagge