ros-industrial / motoman

ROS-Industrial Motoman support (http://wiki.ros.org/motoman)
145 stars 192 forks source link

motoros: Start Traj Mode can return 'success' when e-stop is pressed #287

Closed gavanderhoorn closed 4 years ago

gavanderhoorn commented 5 years ago

Something I've observed today: the Motion Motion Controlservice request (at the simple message level, packet id: 0x7d1) sometimes appears to return a Reply Code with value 1 (which would denote Success) 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:

ROS-Industrial SimpleMessage, Motoman Motion Ctrl (0x7d1), 68 bytes, little-endian
    Prefix
        Packet Length: 64
    Header
        Message Type: Motoman Motion Ctrl (0x000007d1)
        Communications Type: Service Request (2)
        Reply Code: Unused / Invalid (0)
    Body
        Robot ID: 0
        Sequence Number: 0
        Command: Start Traj Mode (200121)
        Data (reserved)
            J0:    0,000000000
            J1:    0,000000000
            J2:    0,000000000
            J3:    0,000000000
            J4:    0,000000000
            J5:    0,000000000
            J6:    0,000000000
            J7:    0,000000000
            J8:    0,000000000
            J9:    0,000000000

and the reply:

ROS-Industrial SimpleMessage, Motoman Motion Reply (0x7d2), 76 bytes, little-endian
    Prefix
        Packet Length: 72
    Header
        Message Type: Motoman Motion Reply (0x000007d2)
        Communications Type: Service Reply (3)
        Reply Code: Success (1)
    Body
        Robot ID: -1
        Sequence Number: -1
        Command: Unknown (2001)
        Result: Success/True (0)
        Subcode: Unknown (0)
        Data (reserved)
            J0:    0,000000000
            J1:    0,000000000
            J2:    0,000000000
            J3:    0,000000000
            J4:    0,000000000
            J5:    0,000000000
            J6:    0,000000000
            J7:    0,000000000
            J8:    0,000000000
            J9:    0,000000000

Note also how the robot_status topic claims that "motion is possible", even though the e-stop is pressed and the e_stopped field is also high:

ROS-Industrial SimpleMessage, Status (0x0d), 44 bytes, little-endian
    Prefix
        Packet Length: 40
    Header
        Message Type: Status (0x0000000d)
        Communications Type: Topic (1)
        Reply Code: Unused / Invalid (0)
    Body
        Drives Powered : False (0)
        E-Stopped      : True (1)
        Error Code     : 0
        In Error       : False (0)
        In Motion      : False (0)
        Mode           : Auto (2)
        Motion Possible: True (1)

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.

gavanderhoorn commented 5 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.

gavanderhoorn commented 5 years ago

@ted-miller: any idea?

gavanderhoorn commented 5 years ago

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.

ted-miller commented 5 years ago

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 .

ted-miller commented 5 years ago

This should be fixed in af3a9c95da5fe7001d7c74562d81b7ee7e56e6b5 Please verify.

gavanderhoorn commented 5 years ago

Seems to have been fixed. Thanks :+1: .

I'll leave this open until #284 has been merged.

gavanderhoorn commented 4 years ago

284 was merged, so closing.