TRAJ_STOP doesn't appear to work as expected

[gavanderhoorn]

Two reasons:

1. "JointTrajectoryStreamer does not send TRAJ_STOP if in IDLE state" (robot_client: JointTrajectoryStreamer does not send TRAJ_STOP if in IDLE state ros-industrial/industrial_core#175)

2. there is no support in the current industrial_robot_client for a server to signal a client to send the next traj point. The client will always send a next point upon receiving an ACK to the previously sent point. This leads to the situation where ROS_TRAJ -- with a full point buffer -- will not send out ACKs, which makes industrial_robot_client hang in sendAndRecieve(..). Any pending TRAJ_STOP JOINT_TRAJ_PTs will be blocked at this point.

   For sparse trajectories with long (joint space) distances between subsequent traj pts this will lead to the driver first having to 'finish' a (potentially long) segment until it can ACK again, and only then the TRAJ_STOP will be received.

[gavanderhoorn]

To address 2, the fanuc_driver nodes could adopt the approach the motoman_driver is using, with explicit BUSY responses to incoming JOINT_TRAJ_PTs if the buffer is full, and the client node retrying every so often.

That would allow TRAJ_STOP msgs to be multiplexed into the message stream.

Ideally this would be integrated into industrial_robot_client itself to avoid duplication of code/effort, etc.

[gavanderhoorn]

ros-industrial/industrial_core#199 should address ros-industrial/industrial_core#175.

[jediofgever]

The PR partially helped indeed, but when robot is close to get to the given goal, stop() function does not take effect, on the teach pendant I see the trajectory points are already been pushed while robot is still on the move, is there any suggestion to address this ?

[gavanderhoorn]

on the teach pendant I see the trajectory points are already been pushed while robot is still on the move

I don't really understand what you mean by this.

Network handling and motion are decoupled in this driver. The ROS side could push 100 pts, with the robot still not moving, depending on what buffer length is configured.

is there any suggestion to address this ?

Without checking this myself it's hard to provide you with any advice.

There is no way to really CANCEL a motion right now with the way the driver is implemented. The problem is essentially similar to ros-industrial/fanuc#93.

You could add a SKIP condition to the J statement and trigger that somehow, or perhaps implement a general ABORT upon receiving a stop.

Another alternative: create something that drops HOLD and then reset ROS_TRAJ.

---

Edit:

stop() function

please note: there is no "stop() function" anywhere in the driver. You are referring to the MoveIt side of things here, I believe.

[jediofgever]

I don't really understand what you mean by this.

I meant, once the controller received all the trajectory points that are going to be executed, the TRAJ_STOP doesn't stop robot anymore, and all points received points are executed, after that TRAJ_STOP is being executed.

stop() function
yes I was referring to move_group->stop()

unfortunately I could not understand the alternatives you listed above as I have no experience in KAREL programming

[jediofgever]

so after some head scratching and getting lost in fanuc's not so clever documentations, I found a temporary solution using your fanuc_ros_cgio. But as you described in the project, the timing is not that desirable. I still hope to get some more reliable solution for this.

in ros-industrial/fanuc#93 you said;

This will not be addressed any more in fanuc_driver - other developments will take priority.

But this issue is still open here, is there any willingness to go on this issue in future ?

[gavanderhoorn]

I found a temporary solution using your fanuc_ros_cgio. But as you described in the project, the timing is not that desirable. I still hope to get some more reliable solution for this.

Switching to an actual fieldbus would immediately reduce latency and increase determinism.

in ros-industrial/fanuc#93 you said;

This will not be addressed any more in fanuc_driver - other developments will take priority.

But this issue is still open here, is there any willingness to go on this issue in future ?

I would be OK with PRs being submitted to address this issue, but I don't have time in the foreseeable future to work on it myself.

The easiest way to integrate this would probably be something I described in my previous comment:

1. add a SKIP condition to the motion instruction in ROS_TRAJ
2. make that condition evaluate to true based on an IO signal that is triggered using a fieldbus (or similar) or by sending a message to ROS_TRAJ

Unfortunately using ROS_TRAJ and industrial_robot_client will run into bullet nr 2 in the OP of this thread.

[gavanderhoorn]

ros-industrial/industrial_core#175 was fixed. I expect this to work now here in fanuc_driver_exp as well.

Closing.