Reset quadrature encoder counter via HW

[ale-git]

This PR solves a synchronisation problem in the quadrature encoder conter reset by index.
In the previous version the conter was reset by a interrupt service routine activated by the index, affected by response delay, while now the conter is reset by hardware.

[valegagge]

please see here for more details about the diagnostic.

[valegagge]

We already did some tests using this new feature and we obtained very good results.
#446

We'll put the PR in ready after we addressed #452

[valegagge]

Hi @ale-git ,
just one thought: I noticed that now in the case of encoder-dirty or index-broken you call the QE_RISE_ERROR macro that calls the fault handler. The last sets the motor at fault.

#define QE_RISE_ERROR(e) gEncoderError.e=TRUE; SysError.EncoderFault=TRUE; FaultConditionsHandler()

Is this correct?

If yes, in this way we are much more strict than before, when the index broken and the encoder-dirty are only warnings.
Are we sure we want to be so severe?

[ale-git]

Hi @ale-git , just one thought: I noticed that now in the case of encoder-dirty or index-broken you call the QE_RISE_ERROR macro that calls the fault handler. The last sets the motor at fault.

#define QE_RISE_ERROR(e) gEncoderError.e=TRUE; SysError.EncoderFault=TRUE; FaultConditionsHandler()

Is this correct?

If yes, in this way we are much more strict than before, when the index broken and the encoder-dirty are only warnings. Are we sure we want to be so severe?

I think that if the diagnostics is reliable they should be errors and not warnings, at least the index broken. We can make the encoder dirty just a warning, but people should be forced to clean encoders when they are dirty because they spoil the performance of the control.

[valegagge]

Hi @ale-git , just one thought: I noticed that now in the case of encoder-dirty or index-broken you call the QE_RISE_ERROR macro that calls the fault handler. The last sets the motor at fault.
#define QE_RISE_ERROR(e) gEncoderError.e=TRUE; SysError.EncoderFault=TRUE; FaultConditionsHandler()

Is this correct?
If yes, in this way we are much more strict than before, when the index broken and the encoder-dirty are only warnings. Are we sure we want to be so severe?

I think that if the diagnostics is reliable they should be errors and not warnings, at least the index broken. We can make the encoder dirty just a warning, but people should be forced to clean encoders when they are dirty because they spoil the performance of the control.

After a discussion with @ale-git e @MSECode,
we decided to set the index-broken as a warning even if we agree with @ale-git that it is an error and not a simple warning, but for now, we want to avoid the robot falling while it is walking or doing other activities.

We planned to define the index-broken as critical notifying the user of the problem and letting him/her find a "safe" position as soon as possible because an index broken means that the controller doesn't work properly.

[ale-git]

Tested on ErgoCub2 arm.

dirty and index_broken encoder faults are managed as warnings. In case of index_broken the warning is generated and the counter is resetted by software matching it to QE_RESOLUTION until the synchronicity is lost. In case of dirty the motor continues to run compatibly with reduced performance.

Executable here robotology/icub-firmware-build#128

[valegagge]

well done!!! 🚀

[marcoaccame]

ok, thanks