UniversalRobots / Universal_Robots_ROS_Driver

Universal Robots ROS driver supporting CB3 and e-Series
Apache License 2.0
750 stars 401 forks source link

Imposible to launch multiple robots from the same machine in recent updates. #429

Closed ignacioDeusto closed 4 months ago

ignacioDeusto commented 3 years ago

Summary

Your issue may already be reported! Please search on the issue track before creating one.

Introduction to the issue

Versions

Impact

What is the impact of the issue. Try to describe it well enough, in order for us to prioritise the issues. Due to a recent change in the Universal Robots Client Library its impossible to launch 2 or more instances of the driver to control multiple robots from a single machine.

Issue details

This part is important in order to clarify the severity of the issue. The trajectory_port (Recently added to the Universal Robots Client Library) is hardcoded to 50003. In earlier versions of the driver the same thing happened with reverse_port and script_sender_port (hardcoded to 50001 and 50002) until they where implemented as parameters and configurable from launchfiles. Until the implementation of the trajectory_port everything worked fine in our setup.

Use Case and Setup

What does the setup look like and what are the objectives? Our setup include two UR3e which are meant to work in simultaneous tasks.

Project status at point of discovered

When did you first observe the issue?

Steps to Reproduce

Make simple example to reproduce the issue. Try to remove dependencies to other hardware and software components, if it is possible. Currently we've a separate launchfile for each robot and a global launchfile to launch both of them at the same time.

robot_1_bringup.launch:

<launch>
  <arg name="debug" default="false" doc="Debug flag that will get passed on to ur_common.launch"/>
  <arg name="robot_ip" doc="IP address by which the robot can be reached." default="10.172.21.203"/>
  <arg name="reverse_port" default="50001" doc="Port that will be opened by the driver to allow direct communication between the driver and the robot controller."/>
  <arg name="script_sender_port" default="50002" doc="The driver will offer an interface to receive the program's URScript on this port. If the robot cannot connect to this port, `External Control` will stop immediately."/>
  <arg name="tf_prefix" default="robot_1_" doc="tf_prefix used for the robot."/>
  <arg name="controllers" default="joint_state_controller scaled_pos_joint_traj_controller speed_scaling_state_controller force_torque_sensor_controller" doc="Controllers that are activated by default."/>
  <arg name="stopped_controllers" default="pos_joint_traj_controller joint_group_vel_controller" doc="Controllers that are initally loaded, but not started."/>
  <arg name="controller_config_file" default="$(find ur_robot_driver)/config/robot_1_controllers.yaml" doc="Config file used for defining the ROS-Control controllers."/>
  <arg name="robot_description_file" default="$(find ur_description)/launch/ur3_upload_robot_1.launch" doc="Robot description launch file."/>
  <arg name="kinematics_config" default="$(find laboratorio_robotica)/config/ur3_default.yaml" doc="Kinematics config file used for calibration correction. This will be used to verify the robot's calibration is matching the robot_description."/>
  <arg name="limited" default="true" doc="Use the description in limited mode (Every axis rotates from -PI to PI)"/>
  <arg name="headless_mode" default="false" doc="Automatically send URScript to robot to execute. On e-Series this does require the robot to be in 'remote-control' mode. With this, the URCap is not needed on the robot."/>

  <include file="$(find ur_robot_driver)/launch/ur_common.launch" pass_all_args="true">
    <arg name="use_tool_communication" value="false"/>
    <arg name="tf_prefix" value="robot_1_"/>
  </include>
</launch>

robot_2_bringup.launch:

<?xml version="1.0"?>
<launch>
  <arg name="debug" default="false" doc="Debug flag that will get passed on to ur_common.launch"/>
  <arg name="robot_ip" doc="IP address by which the robot can be reached." default="10.172.21.204"/>
  <arg name="reverse_port" default="50000" doc="Port that will be opened by the driver to allow direct communication between the driver and the robot controller."/>
  <arg name="script_sender_port" default="50005" doc="The driver will offer an interface to receive the program's URScript on this port. If the robot cannot connect to this port, `External Control` will stop immediately."/>
  <arg name="tf_prefix" default="robot_2_" doc="tf_prefix used for the robot."/>
  <arg name="controllers" default="joint_state_controller scaled_pos_joint_traj_controller speed_scaling_state_controller force_torque_sensor_controller" doc="Controllers that are activated by default."/>
  <arg name="stopped_controllers" default="pos_joint_traj_controller joint_group_vel_controller" doc="Controllers that are initally loaded, but not started."/>
  <arg name="controller_config_file" default="$(find ur_robot_driver)/config/robot_2_controllers.yaml" doc="Config file used for defining the ROS-Control controllers."/>
  <arg name="robot_description_file" default="$(find ur_description)/launch/ur3_upload_robot_2.launch" doc="Robot description launch file."/>
  <arg name="kinematics_config" default="$(find laboratorio_robotica)/config/ur3_default.yaml" doc="Kinematics config file used for calibration correction. This will be used to verify the robot's calibration is matching the robot_description."/>
  <arg name="limited" default="true" doc="Use the description in limited mode (Every axis rotates from -PI to PI)"/>
  <arg name="headless_mode" default="false" doc="Automatically send URScript to robot to execute. On e-Series this does require the robot to be in 'remote-control' mode. With this, the URCap is not needed on the robot."/>

  <include file="$(find ur_robot_driver)/launch/ur_common.launch" pass_all_args="true">
    <arg name="use_tool_communication" value="false"/>
    <arg name="tf_prefix" value="robot_2_"/>
  </include>
</launch>

global_bringup.launch:

<?xml version="1.0"?>
<launch>
  <arg name="transmission_hw_interface" default="hardware_interface/PositionJointInterface" />
  <arg name="kinematics_config" default="$(find laboratorio_robotica)/config/ur3_default.yaml"/>
  <!-- <arg name="kinematics_config" default="/home/ignacio/calibrations/robot_1_calibration.yaml"/> -->
  <!-- <arg name="robot_ip" doc="IP address by which the robot can be reached." default="10.172.21.203"/> -->
  <include file="$(find ur_robot_driver)/launch/robot_1_bringup.launch" ns="robot_1"/>  
  <include file="$(find ur_robot_driver)/launch/robot_2_bringup.launch" ns="robot_2"/>  

  <!-- send robot urdf to param server -->
  <param name="robot_description" command="$(find xacro)/xacro --inorder '$(find laboratorio_robotica)/urdf/ur3_2_robots.urdf.xacro'
    transmission_hw_interface:=$(arg transmission_hw_interface)
    kinematics_config:=$(arg kinematics_config)" />

  <node name="joint_state_publisher_general" pkg="joint_state_publisher" type="joint_state_publisher">
    <rosparam param="source_list">["/robot_1/joint_states","/robot_2/joint_states"]</rosparam>
  </node>
</launch>

When launching each robot separately everything works fine, but when launching both at the same time the following error appears: imagen

Launching a robot separately and checking the ports we got this for both cases: imagen

Expected Behavior

What did you expect and why? Both robots launching from the same machine.

Actual Behavior

What did you observe? If possible please attach relevant information. The fact that there's a socket hard coded makes impossible to launch more than one robot from the same machine.

Workaround Suggestion

If a workaround has been found, you are welcome to share. The only workaround is to launch each robot from a different machine. The suggestion to fix this issue is to include the trajectory_port as a parameter like in the reverse_port and the script_sender_port cases. We believe that this error is also affecting the ROS 2 drivers users as mentioned in: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/issues/134

fmauch commented 3 years ago

Thanks for reporting this!

As the library version containing the trajectory port has not been synced for melodic, we did not want to change the driver's master branch to require those features, yet. This situation is something we did not have in mind and I apologize for any inconvenience caused. We'll provide a branch addressing this asap, so that can be used as a workaround until the next melodic sync happened (which I expect to happen rather soon, as the last sync was on June, 4th).

fmauch commented 3 years ago

See #431 as a workaround.

fmauch commented 4 months ago

This should be resolved by now.