# Developing custom server for industrial Robot mitsubishi-PA10

Hi everyone!

I am developing the packages to integrate our robot Mitsubishi-Pa10 within the ros-Industrial environment. I am using ros-indigo distro and ubuntu 14.04 for this purpose.

I am also trying to develop a proper server on the real controller side of the robot. For hardware requirement of the robot we need to develop it in Windows.

however I am now stucked with the communication protocol of the simple_message used by ROS. Since I have already developed the most part of the server, I now want to understand how the process of enqueing and sending points of a point trajectory works for the industrial_robot_client package.

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.

In the terminal I only get:

 ROS_WARN: Controller handle  reports status ABORTED.


It is not due to an ROS_PATH_GOAL constraint because otherwise it will show the Warning related to that issue.

I have tried looking for the topics of the state of the controller in the ROS side and de goals of the joint_trajectory_action controller. And the main difference between the simulation and the real implementation seems to be that in the real movement the status of the ros controller doesn't pass to Status=1 when it is performing the trajectory, it automatically pass from void to 3 to 4 and aborts.

On the other hand in simulation the status pass from 1 when it is performing the trajectory to 3 (success).

I think it is because when I receive on the server side the trajectory_point from ros as a SERVICE_REQUEST, I answer from the server to the ROS client side as a JOINT_TRAJ_MSG type as a SERVER_REPLY and as a REPLY_SUCCESS. but if I don´t reply the industrial_robot_client don´t send me the next point of the trajectory.

Is this message correct? Should the server only response with the Reply type set to INVALID?

I have found (too late btw) the repository of gavanderhoorn ( https://github.com/gavanderhoorn/rep-... ). But it doesn't answer my question of the which value should I set of the Reply type of the simple_message.

Edit: Hello gvdhoorn! I have already tried what you advice me however it is not working. I don get any message similir to the one you said me :

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


I only get the message that controller aborted:

[ INFO] [1494837002.085272612]: Execution request received for ExecuteTrajectory action.
[ WARN] [1494837003.193947175]: Controller handle  reports status ABORTED
[ INFO] [1494837003.194048098]: Execution completed: ABORTED
[ INFO] [1494837003.194413494]: ABORTED: Solution found but controller failed during execution


Finally I have solved the issue ...

edit retag close merge delete

Sort by » oldest newest most voted

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.

Edit2:

@gvdhoorn as it is now working, what should I do to release it to give the comunity free access the the files?

I would suggest to push all your packages to a github repository and send us a message on the ROS-Industrial mailing list. We can discuss things there more easily than on ROS Answers.

more

Thank you for your quick response, I will check it on monday at the laboratory, and post if I reach to solve it. Since I was still developping the server, I was just performing the trajectory without taking in consideration the velocity or time to perform the action. Will change it and write news.

( 2017-05-14 09:12:14 -0500 )edit

Just to be (extra) clear: STOP_TRAJECTORY msgs may also be send for other reasons, not just when the TEM cancels the trajectory. Proper handling of that sequence nr is required in all cases.

( 2017-05-14 10:27:35 -0500 )edit