Closed gavanderhoorn closed 4 years ago
Behaviour described in the OP was observed on a YRC1000 with MotoROS v1.9.0
(testing #284).
I'll downgrade to v1.8.2
to see if this behaviour is also present in that version.
@ted-miller: any idea?
On this particular system there is no external e-stop, so I cannot test whether that changes anything, but I don't expect it to.
I see the problem. Ros_Controller_StatusUpdate (Controller.c) doesn't include estop in the decision logic.
I'll work on it this afternoon and push to #284 .
This should be fixed in af3a9c95da5fe7001d7c74562d81b7ee7e56e6b5 Please verify.
Seems to have been fixed. Thanks :+1: .
I'll leave this open until #284 has been merged.
Something I've observed today: the
Motion Motion Control
service request (at the simple message level, packet id:0x7d1
) sometimes appears to return aReply Code
with value1
(which would denoteSuccess
) even if/when the teach pendant e-stop is pressed.The
init_ros
job does not actually get started, neither are the servos enabled, so no motion is possible.As such, this is not a dangerous situation per se, but it is confusing.
Wireshark dissection of the request:
and the reply:
Note also how the
robot_status
topic claims that "motion is possible", even though the e-stop is pressed and thee_stopped
field is also high:Edit: once the system (ie: controller/MotoROS) is in this state, repeated calls to
enable_robot
will not return it to a working state. Even when all alarms have been cleared. Manually enabling servo power does still work, but the job is never started/resumed, leading to an unresponsive system.