joint_trajectory_action/status always returns ACTIVE

[asierfernandez]

We are having some issues when using joint_trajectory_action interface to command sda10f robot.

When we send a goal to the /joint_trajectory_action server, the goal is processed, the robot moves but /joint_trajectory_action/status always returns status: 1, which means ACTIVE, but never sends a SUCCEEDED. Moreover, the /joint_trajectory_action/result, topic is never published.

We've made a similar test with /sda10f/sda10f_r1_controller interface, and it works as expected: /sda10f/sda10f_r1_controller/joint_trajectory_action/status is properly updated and it also returns the correct result

Any idea about what's happening?

[gavanderhoorn]

I think I do, but I'm not sure about a resolution.

Do you get a warning/error about goals being LOST as well?

[marip8]

I'm running into a similar issue on the current kinetic-devel branch of this repository. I have a robot+rail system (i.e. 2 motion groups) with a DX100. When I call the joint trajectory action with a trajectory that includes all 7 DoF, the robot and rail will move (and appear to complete the trajectory) but the action client reports that the goal is LOST and the downstream application fails (both my custom application and the MoveIt Rviz planning panel). The last I hear from the driver is this line from the streamer that reports that streaming is complete and that it enters the IDLE state. Attaching a debugger to the joint_trajectory_action node shows that it never hits a line where the action server calls setCanceled, setSucceeded, or setAborted, and I don't see any of the associated log messages where these call occurs. Increasing the goal constraint tolerance doesn't seem to solve the issue either

Any recommendations on how to track down this issue?

[gavanderhoorn]

For your particular system there is #179.

There are a couple of open PRs trying to address it in a more generic fashion: #259, #488 and kinetic-devel...jmarsik:motoman:kmr-multigroup.

[marip8]

I was previously using a modified version of #179, but had updated to the kinetic-devel branch to utilize the motoman_es_support package and found that the driver seemed to work as expected after some minimal testing. When I tried to rebase #179 on the latest changes there were conflicts, so I wasn't sure if this problem had been fully resolved. Thanks for the links