External Control URCap never starting the program

ROS
1

Hi all,

We are finding an issue with starting the the external ROS control program on our UR5’s. Our system setup is;

  • Robot: UR5
  • Polyscope version 3.13.1
  • Ubuntu 16.04
  • ROS Kinetic
  • externalcontrol-1.0.2.urcap

The communication between the ROS computer and the UR5 appears to be completely correct, with all ports open as they should and robot state information being read correctly. However, the teach pendant shows Starting Program, please wait... when the program is started and does not seem to clear. Any service calls made to the dashboard results in a timeout error after the program has been started, presumably because the program is stuck.

I would greatly appreciate any support or insight anyone might have in this matter.

Regards,
Andrew

2

It would be interesting to see what your program looks like. Could you please download all program files for that program (program_name.urp, program_name.script, *.installation, etc)

For example, you can do that using a USB stick as described here.

Also: Could you please post the complete output of the driver running on the ROS side?

3

Thanks for your quick reply.
I have attached the programs and installation files for each arm here. These have been made by sshing into the UR controller computer and collecting directly from the programs directory, since we need to dismantle the robot significantly to gain access to USB slots for the computers.

I also attached the output of the terminal with the ROS driver running. I used the rosservice to call the play for the program on the pendant (though the results are similar for when pressing play on the pendant directly). On lines 446 (for left arm) and 449 (for right arm), you can see the driver believing it can begin controlling the robot after the program play service calls for each respective arm. Then on lines 452 and 454, you can see that the service calls to reconnect to the dashboard server works fine and responds appropriately.

programs.zip (12.2 KB)

4

I think, it wold be good to reduce the setup to one robot before further progressing…

In the generated script there are the lines

$ 2 "Control by ripley"
popup("The connection to the remote PC could not be established. ", title ="connection refused")
sync()    # end: URCap Program Node

That looks like either

  • The configured IP address is wrong
  • There is a firewall running on the control PC preventing the network connection (See this issue how to check that)
5

Oh woah…
That is really strange considering that all other comms could be transferred between the Robots and the computer. Or atleast, I assume so since I can get the full robot state translated into ROS messages and published in the system. Plus the ports appear to have opened with the correct services on the companion computer end according the nmap. I believed I configured the IP correctly and I disabled the firewall as per that issue you linked before starting this ticket, but obviously I have missed something.

I will double check the IP and firewall next week. If this isn’t the issue, would you have any ideas on what other permissions could be conflicting?

6

The IP’s are correct for the two arms and the external computer.
I was able to send some simple commands through the socket on port 30001 and it was executing fine.
I should note that I can run the driver with headless=true which bypasses the need for the the ur program running on the pendant computer. It takes all motion commands as desired and I can get the full state. I will be using this for the time being, but would like to find a solution to this problem as the headless mode may be removed in future releases.

I have attached one of the log files I collected from the onboard computer. I have seen that many packages from the urEthernetDriver are being designated as lost, however, the expected values it is getting seem to be offset by a value of one (I am not sure exactly what would cause this or what it is looking for?)
URControl.log.0.pdf (241.9 KB)

7

What did your firewall test result in?

With just using one robot, you can check your port setup by using

ss -atnp | grep 5000

In a default setup that would look something like this

LISTEN     0      1                                        0.0.0.0:50001                                  0.0.0.0:*     users:(("ur_robot_driver",pid=83419,fd=18))
LISTEN     0      1                                        0.0.0.0:50002                                  0.0.0.0:*     users:(("ur_robot_driver",pid=83419,fd=16))
ESTAB      0      32                                  192.168.56.1:50001                           192.168.56.101:44021 users:(("ur_robot_driver",pid=83419,fd=19))

Here you see that my robot (192.168.56.101) has established a connection to my local 50001 port when the program is running, as this is the default reverse port. Without the robot having connected to it, you will only see the LISTEN lines.

While writing this I was looking at your config files again: It seems that you misconfigured the script sender port on the robots. Instead of entering the port number of the script sender port, you entered the reverse port ID into the external control setup.

Your left robot would have to be configured to port 5002, while your right robot needs to be configured to port 5004.

2 Likes
8

Thank you kindly you legend.
It was the port selection.

I appreciate the support in this.