Robot not enabled not causing joint_trajectory_action to fail

[akashjinandra]

motoman/motoman_driver/src/joint_trajectory_streamer.cpp

Line 429 in 4c5e6af

ROS_ERROR_RETURN(false, "Failed to initialize MotoRos motion, trajectory execution ABORTED. If safe, call the "

Hello I'm wondering if anybody else see's this. I'm running Ubuntu 18 with ROS melodic. But if you are sending a trajectory and the robot is not enabled. I.E you didn't call the robot_enable service. It doesn't seem like the joint trajectory action actually stops running, it just hangs. The only solution seems to be having moveit monitor the trajectory and then it catches this issue.

Is there anyway to know catch this happening besides using the moveit trajectory execution manager?

[gavanderhoorn]

It's a bit of a work-around (from the action client / MoveIt perspective), but RobotStatus.motion_possible will not be true unless you've called robot_enable first.

To make the action server deal with this a bit more intelligently, we'd have to see whether ros-industrial/industrial_core#271 already solves this (as motoman_driver depends on it), or whether we need to port that PR over to the motoman_driver-specific versions of the involved files.

That would make the action server reject goals unless MotoROS reports it's ready to execute them.

---

Edit: I believe the driver(s) (as this applies to more than just motoman_driver) were designed such that clients could/should check the /robot_status topic and take that into account when deciding to send new goals (or not). Personally, I would prefer the action server to also be able to inform clients as to whether or not it was/would be able to execute new goals, hence ros-industrial/industrial_core#271. But that was not how it was implemented "back then".

/robot_status also includes information about e-stops and other OEM error situations (via the error_code field).