Revision history [back]

My error occurs when I send a trajectory from de Rviz plugin of moveit throughout the industrial_robot_client package. The server accepts de communication decodes de message and starts to perform the trajectory, it performs 2 of the points of the trajectory and suddenly the ROs side aborts the trajectory and sends a trajectory of 0's to all the joints.

MoveIt has something called a Trajectory Execution Monitor (TEM) that is in charge of making sure that there is not too much tracking error (both in time and space).

I'm guessing that your driver is not performant enough and causes the robot to move too slow. It cannot keep up with the trajectory MoveIt planned, and the TEM then cancels execution of the trajectory. Right above the ROS_WARN: Controller handle reports status ABORTED. you should see something like (this is from the wiki/fanuc/Troubleshooting page about the same thing):

Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was X.Y seconds). Stopping trajectory.

The action goal is then cancelled, which is communicated -- via the nodes in industrial_robot_client -- to your server implementation running on the controller using a JOINT_TRAJ_PT message with its sequence field set to special sequence number value -4 (== STOP_TRAJECTORY). The rest of the message is all-zeros.

Server implementations are expected to execute a controlled stop after receiving such a message.

It is mentioned in the Special Sequence Numbers section, but you are right that this could perhaps be explained more clearly.

For the rest of your questions regarding values of REPLY_TYPE, please see Message Layout - Header.

PS: we always recommend someone wanting to implement a new server to contact us on the ROS-Industrial mailing list. That way we can make sure we avoid things like your current confusion.

My error occurs when I send a trajectory from de Rviz plugin of moveit throughout the industrial_robot_client package. The server accepts de communication decodes de message and starts to perform the trajectory, it performs 2 of the points of the trajectory and suddenly the ROs side aborts the trajectory and sends a trajectory of 0's to all the joints.

MoveIt has something called a Trajectory Execution MonitorManager (TEM) that is in charge of making sure that there is not too much tracking error (both in time and space).

I'm guessing that your driver is not performant enough and causes the robot to move too slow. It cannot keep up with the trajectory MoveIt planned, and the TEM then cancels execution of the trajectory. Right above the ROS_WARN: Controller handle reports status ABORTED. you should see something like (this is from the wiki/fanuc/Troubleshooting page about the same thing):

Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was X.Y seconds). Stopping trajectory.

The action goal is then cancelled, which is communicated -- via the nodes in industrial_robot_client -- to your server implementation running on the controller using a JOINT_TRAJ_PT message with its sequence field set to special sequence number value -4 (== STOP_TRAJECTORY). The rest of the message is all-zeros.

Server implementations are expected to execute a controlled stop after receiving such a message.

It is mentioned in the Special Sequence Numbers section, but you are right that this could perhaps be explained more clearly.

For the rest of your questions regarding values of REPLY_TYPE, please see Message Layout - Header.

PS: we always recommend someone wanting to implement a new server to contact us on the ROS-Industrial mailing list. That way we can make sure we avoid things like your current confusion.

My error occurs when I send a trajectory from de Rviz plugin of moveit throughout the industrial_robot_client package. The server accepts de communication decodes de message and starts to perform the trajectory, it performs 2 of the points of the trajectory and suddenly the ROs side aborts the trajectory and sends a trajectory of 0's to all the joints.

MoveIt has something called a Trajectory Execution Manager (TEM) that is in charge of making sure that there is not too much tracking error (both in time and space).

I'm guessing that your driver is not performant enough and causes the robot to move too slow. It cannot keep up with the trajectory MoveIt planned, and the TEM then cancels execution of the trajectory. Right above the ROS_WARN: Controller handle reports status ABORTED. you should see something like (this is from the wiki/fanuc/Troubleshooting page about the same thing):

Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was X.Y seconds). Stopping trajectory.

The action goal is then cancelled, which is communicated -- via the nodes in industrial_robot_client -- to your server implementation running on the controller using a JOINT_TRAJ_PT message with its sequence field set to special sequence number value -4 (== STOP_TRAJECTORY). The rest of the message is all-zeros.

Server implementations are expected to execute a controlled stop after receiving such a message.

It is mentioned in the Special Sequence Numbers section, but you are right that this could perhaps be explained more clearly.

For the rest of your questions regarding values of REPLY_TYPE, please see Message Layout - Header.

PS: we always recommend someone wanting to implement a new server to contact us on the ROS-Industrial mailing list. That way we can make sure we avoid things like your current confusion.

My error occurs when I send a trajectory from de Rviz plugin of moveit throughout the industrial_robot_client package. The server accepts de communication decodes de message and starts to perform the trajectory, it performs 2 of the points of the trajectory and suddenly the ROs side aborts the trajectory and sends a trajectory of 0's to all the joints.

MoveIt has something called a Trajectory Execution Manager (TEM) that is in charge of making sure that there is not too much tracking error (both in time and space).

I'm guessing that your driver is not performant enough and causes the robot to move too slow. It cannot keep up with the trajectory MoveIt planned, and the TEM then cancels execution of the trajectory. Right above the ROS_WARN: Controller handle reports status ABORTED. you should see something like (this is from the wiki/fanuc/Troubleshooting page about the same thing):

Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was X.Y seconds). Stopping trajectory.

The action goal is then cancelled, which is communicated -- via the nodes in industrial_robot_client -- to your server implementation running on the controller using a JOINT_TRAJ_PT message with its sequence field set to special sequence number value -4 (== STOP_TRAJECTORY). The rest of the message is all-zeros.

Server implementations are expected to execute a controlled stop after receiving such a message.

It is mentioned in the Special Sequence Numbers section, but you are right that this could perhaps be explained more clearly.

For the rest of your questions regarding values of REPLY_TYPE, please see Message Layout - Header.

PS: we always recommend someone wanting to implement a new server to contact us on the ROS-Industrial mailing list. That way we can make sure we avoid things like your current confusion.

Edit:

I have already tried what you advice me however it is not working.

it would be nice if you could explain what "is not working".

Could you please describe what you changed exactly, what you expect to happen and what is actually happening?

The fact that you don't get the timeout WARN implies that the controller is stopping the execution of the trajectory for some other reason.

Do you think you could make your files available somewhere? Without seeing what you have it's rather difficult to help you.

Also: in case of the driver it would be really helpful if you could record a Wireshark capture and provide it to us. See ros-industrial/packet-simplemessage for a Wireshark dissector for the ROS-Industrial Simple Message protocol.