Can't accept new action goals. Controller is not running
Affected ROS Driver version(s)
ROS noetic
Used ROS distribution.
Noetic
Which combination of platform is the ROS driver running on.
Linux with realtime patch
How is the UR ROS Driver installed.
Build the driver from source and using the UR Client Library from binary
Which robot platform is the driver connected to.
UR E-series robot
Robot SW / URSim version(s)
5.12.4
How is the ROS driver used.
Headless without using the teach pendant
Issue details
Summary
I use Moveit! and socket communication to send joint commands to my UR5e. Although the connection initially establishes successfully, it drops after a while, and I have to restart the UR packages
Issue details
- With the teach pendant (TP) in remote mode, I establish socket communication with the robot and send commands via MoveIt!. However, the connection drops after a while, preventing the continuous transmission of commands until the UR packages are restarted.
- I have set headless to true in teh launch file
<arg name="headless_mode" default="true" 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."/>
Steps to Reproduce
- Set the teach pendant (TP) to remote mode.
- Launch
roslaunch ur_robot_driver ur5e_bringup.launch, I get the output
[ INFO] [1712951600.822167206]: Robot mode is now RUNNING
[ INFO] [1712951600.824217714]: Robot's safety mode is now NORMAL
[INFO] [1712951600.831808]: Loading controller: joint_state_controller
[INFO] [1712951600.849943]: Loading controller: forward_cartesian_traj_controller
[INFO] [1712951600.853748]: Loading controller: speed_scaling_state_controller
[INFO] [1712951600.867894]: Loading controller: pos_joint_traj_controller
[INFO] [1712951600.871950]: Loading controller: force_torque_sensor_controller
[INFO] [1712951600.905931]: Loading controller: joint_group_vel_controller
[INFO] [1712951600.909740]: Controller Spawner: Loaded controllers: pose_based_cartesian_traj_controller, scaled_pos_joint_traj_controller, joint_state_controller, speed_scaling_state_controller, force_torque_sensor_controller
[INFO] [1712951600.915689]: Controller Spawner: Loaded controllers: joint_based_cartesian_traj_controller, forward_cartesian_traj_controller, pos_joint_traj_controller, joint_group_vel_controller
[INFO] [1712951600.918094]: Started controllers: pose_based_cartesian_traj_controller, scaled_pos_joint_traj_controller, joint_state_controller, speed_scaling_state_controller, force_torque_sensor_controller
- Launch
roslaunch ur5e_moveit_config moveit_planning_execution.launchandroslaunch ur5e_moveit_config moveit_rviz.launch, respectively. - After a while, I observe that the interface running
roslaunch ur_robot_driver ur5e_bringup.launchreports
[ERROR] [1712953299.523320658]: Sending data through socket failed.
[ERROR] [1712953314.468088268]: Can't accept new action goals. Controller is not running.
and I have to restart the programs
Expected Behavior
The program should run continuously without experiencing connection drops
Actual Behavior
The connection drops, and I have to restart the program
Kindly assist me with this issue
Relevant log output
No response
Accept Public visibility
- [X] I agree to make this context public
It would be beneficial to see more output. I guess, you see the Connection to reverse interface dropped. output.
Do you have a lot of load inside your control PC? On ROS 2 we mitigated this by enabling non-blocking read by default, that might be a good way to proceed for ROS 1, as well.
Nevertheless, you can also re-establish the connection by calling
rosservice call /ur_hardware_interface/resend_robot_program "{}"
This is only a workaround, hence I'm not going to close this issue, but it is probably a better alternative to restarting things.
Hi @fmauch , thank you for your reply. Yes, I see Connection to reverse interface dropped.
I tried to run rosservice call /ur_hardware_interface/resend_robot_program "{}" as suggested, but it does not work. I always have to restart the terminals running the command
Could you please elaborate on "but it doesn't work"?
@Yeesha-R coming back to my question: What does "but it doesn't work" mean? Do you get any output on either the shell where you make the service call or where the driver is running?
Thanks @fmauch. I got the issue resolved already.