While working on #14, I ran into a situation where I had at least one major alarm active and as part of testing tried to use the reset_error service to reset the controller.
As major alarms can't be reset (that way), this didn't work -- as expected.
But the service result returned by MotoROS2 wasn't very informative:
motoros2_interfaces.srv.ResetError_Response(
result_code=motoros2_interfaces.msg.MotionReadyEnum(value=101),
message='Robot has an active ALARM'
)
while technically true -- there is still, at least, one active alarm -- we might perhaps try to provide a better message in case someone tries to reset major alarms.
The PP shows "can't reset major alarm" in the message area whenever you try to reset those. Not sure whether we can pick up on that, or whether we could perhaps check the type of alarm(s) that remain(s) and return a different motoros2_interfaces.msg.MotionReadyEnum value in cases where some alarms can't be reset.
While working on #14, I ran into a situation where I had at least one major alarm active and as part of testing tried to use the
reset_errorservice to reset the controller.As major alarms can't be reset (that way), this didn't work -- as expected.
But the service result returned by MotoROS2 wasn't very informative:
while technically true -- there is still, at least, one active alarm -- we might perhaps try to provide a better message in case someone tries to reset major alarms.
The PP shows "can't reset major alarm" in the message area whenever you try to reset those. Not sure whether we can pick up on that, or whether we could perhaps check the type of alarm(s) that remain(s) and return a different
motoros2_interfaces.msg.MotionReadyEnumvalue in cases where some alarms can't be reset.