Enable fail-safe mode - Githubissues

roboticslab-uc3m / yarp-devices

A place for YARP devices

https://robots.uc3m.es/yarp-devices/

9 stars 7 forks source link

Enable fail-safe mode #185

Closed jgvictores closed 4 years ago

jgvictores commented 6 years ago

In light of issues such as this (private ref), which will continue to occur, I'm proposing some fail-safe mode for TechnosoftIpos.

I'm not sure if this is something like an on-line self-recovery in line of #2, or something completely different such as allowing joints to be blocked easily for demos. Very open to suggestions!

PeterBowman commented 6 years ago

Related: #120 (recovery from fault state).

Edit: actually switch to quick stop state.

PeterBowman commented 5 years ago

Related: https://github.com/roboticslab-uc3m/yarp-devices/issues/215 (map fault state to YARP control modes).

PeterBowman commented 5 years ago

Per 5.4.9, Object 605Eh: Fault reaction option code (P091.063.iPOS.STO.UM.0219, 2019):

This object determines what action should be taken if a non-fatal error occurs in the drive. The non-fatal errors are by default the following:

Under-voltage

Over-voltage

I2t error –when the internal register ASR bit1 is 0 in setup.

Drive over-temperature

Motor over-temperature

Communication error (when object 6007h option 1 is set)

Accepted values:

-1 = "No action"
0 = "Disable drive, motor is free to rotate"
2 = "Slow down with quick stop ramp" (default)

PeterBowman commented 4 years ago

I'm not sure if this is something like an on-line self-recovery in line of #2

This can't be automated, we want to let motors cool down in case a I2t event occurs, for instance. Therefore, fault state reset needs to be a manual operation. See https://github.com/roboticslab-uc3m/yarp-devices/issues/2#issuecomment-538367522.

or something completely different such as allowing joints to be blocked easily for demos. Very open to suggestions!

This no longer happers, faulted joints do not interfere with the rest of the chain and demos may carry on. @jgvictores suggests that checkMotionDone could spoil this behavior. I need to check whether the target reached bit in statusword is set/reset on a fault event and, if deemed necessary, handle this special state in the implementation (just test against current drive state, which is only meaningful in OPERATION_ENABLED).

PeterBowman commented 4 years ago

If you look closely, there are two "Target reached" bits with distinct interpretation:

Ensayo_frenos_-_eje_3_-_28 02 17_-_230s

In Statusword, "Target reached" is interpreted accordingly to the mode of operation. In "Position profile", it means "target position reached/not reached" (when halt bit is not set).
In Status Register High (SRH), which apparently translates to object 1002h, Manufacturer Status Register (MSR), "Target reached" is defined in the iPOS CAN user manual as "Target command reached". As I see it, this could refer to the fact that the CAN command has been received and acknowledged, having nothing to do with the actual motion status.

PeterBowman commented 4 years ago

I need to check whether the target reached bit in statusword is set/reset on a fault event and, if deemed necessary, handle this special state in the implementation (just test against current drive state, which is only meaningful in OPERATION_ENABLED).

Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/11b9115598f5331683974e309de363b2d7d1528f. Again, this is probably mode-of-operation-dependent, but it's a good start.

Closing as INVALID, we just can't fix the world.