`/reset_error` returns `success` when estop is engaged

[ted-miller]

I would expect that if reset_error returns OK, that I can enable the robot.

root@ted-Ubuntu:/home/ted/motoros2_moveit2_config_packages# ros2 service call /reset_error motoros2_interfaces/srv/ResetError
requester: making request: motoros2_interfaces.srv.ResetError_Request()

response:
motoros2_interfaces.srv.ResetError_Response(result_code=motoros2_interfaces.msg.MotionReadyEnum(value=1), message='success')

root@ted-Ubuntu:/home/ted/motoros2_moveit2_config_packages# ros2 service call /start_traj_mode motoros2_interfaces/srv/StartTrajMode
requester: making request: motoros2_interfaces.srv.StartTrajMode_Request()

response:
motoros2_interfaces.srv.StartTrajMode_Response(result_code=motoros2_interfaces.msg.MotionReadyEnum(value=103), message='The controller is in E-Stop')

[jimmy-mcelwain]

I personally think that it makes sense how it is now/I don't really think this is a bug. It resets errors and alarms, I feel like that is different from checking if the robot is capable of enabling servos at the moment

[ted-miller]

IIRC though, you must call this service after an estop. So, that would technically make estop an error.

[gavanderhoorn]

@jimmy-mcelwain wrote:

It resets errors and alarms, I feel like that is different from checking if the robot is capable of enabling servos at the moment

indeed. IIRC, reset_error just attempts to reset active errors and/or alarms.

Checking whether the robot can be enabled should be done using robot_status -- but is of course also reported by start_*_mode.

@ted-miller: does M+ mpResetAlarm(..) fail if called with an active e-stop? reset_error essentially just wraps that.

[ted-miller]

does M+ mpResetAlarm(..) fail if called with an active e-stop?

No. It's just concerned with the alarms.