ROS irb2400 No Connection to Controller
Hi,
I’m having some issues establishing a connection to an ABB irb2400 robot with ROS-industrial. All rapid files are installed and run on the IRC5 controller according to these tutorials: abb/Tutorials/InstallServer and abb/Tutorials/RunServer.
I can ping the ip-adress of the robot successfully and I can run the needed tasks on the controller from the flex-pendant. According to this tutorial: Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot the following command should launch the required connections.
roslaunch abb_irb2400_moveit_config moveit_planning_execution.launch sim:=false robot_ip:=192.168.66.167
This launches Rwiz containing the simulated robot and I hoped it would connect to the real robot but nothing happens and the tasks on the controller still state: Waiting for connection
. There are no error messages for a while but after a couple of minutes this message appears in the terminal:
[ERROR] [1450276166.709455488]: Failed to connect to server, rc: -1. Error: 'Connection refused' (errno: 111)
I have been looking on the network with wireshark and no communication attempts are made from the computer. Maybe the launch file is not the right one to run for establishing a connection to the robot?
Does anyone have an idea of why this is not working?
Regards, Markus Malmros
Can you check and see whether
roslaunch abb_irb2400_support robot_state_visualize_irb2400.launch robot_ip:=192.168.66.167
does work? If it doesn't see ifnc 192.168.66.167 11002
starts dumping data to the console. If that doesn't work, there is something wrong with your network and / or ctrlr.have you tried using robotstudio in a windows computer? on the other hand, are you running the modules on manual or automatic mode? I work with an ABB irb140, and, I recommend you to run it on automatic mode (don't forget "PP to main", and, Run the program, sometimes one forgets this step).
Thanks for your comments. roslaunch abb_irb2400_support robot_state_visualize_irb2400.launch robot_ip:=192.168.66.167 did not work and neither did nc 192.168.66.167 11002. We ran a wireshark and came to the conclusion that there probably is a firewall somewhere in the network.
Yes, that might be the case. ICMP is often allowed to pass, but other ports are not. You'd get this kind of behaviour then.