Universal_Robots_ROS_Driver: Robot Does not Move with rqt_joint_trajectory_controller GUI

Summary

The robot does not move at all with the rqt_joint_trajectory_controller GUI. Note, I am using kinetic with Ubuntu 16.04.

I am able to run the driver, complete the steps to run the remote control program, switch the controller to “joint_traj_controller”, and launch the rqt gui, but when I move the sliders for joints, nothing happens on the real robot.

Versions

  • ROS Driver version: master
  • Affected Robot Software Version(s): polyscope 5.3.1
  • Affected Robot Hardware Version(s): ur5e
  • Robot Serial Number:
  • UR+ product(s) installed:
  • URCaps Software version(s): External Control V 1.0.1

Impact

The robot does not move while using the rqt_joint_trajectory_controller gui. Also note that the gui crashes if you attempt to use it with the scaled_joint_traj_controller.

Issue details

After starting the driver, running the remote control URCaps program, and putting the teach pendant into remote control mode, I have not been able to make the robot move using the rqt gui. The rqt joint trajectory gui crashes if you attempt to use it with the “scaled_pos_traj_controller”. The program does not crash, but the ur5e does not move when using the “pos_traj_controller”. The speed slider on the trajectory controller seems to have no effect. The rqt gui is definitely publishing on the “/position_traj_controller/command” topic". I haven’t been able to debug why there is no movement. There are no obvious error or warning messages, and the rqt_graph looks normal. rqt_graph

Use Case and Setup

General arm movement. No special setup.

Project status at point of discovered

While attempting to experiment with using the new driver.

Steps to Reproduce

  1. Launch the driver with: $ roslaunch ur_robot_driver ur5e_bringup.launch robot_ip:=<robot ip>
  2. On the teach pendant run the external control program as described in the GIT readme. The driver outputs “Robot ready to receive control commands.”
  3. Put the teach pendant in remote control mode.
  4. In a second terminal switch the controller with: rosservice call /controller_manager/switch_controller "start_controllers: - 'pos_traj_controller' stop_controllers: - 'scaled_pos_traj_controller' strictness: 1" Service responds “ok: True”
  5. Run the rqt gui with: $ rosrun rqt_joint_trajectory_controller rqt_joint_trajectory_controller
  6. The gui pops up with the pos_traj_controler selected (it is the only option), click the start button on the gui, then move any of the sliders to move joints… nothing happens. The robot does not move.

Expected Behavior

I expect some visible movement, but the joint_state topic remains constant (except for noise) and the robot does not move.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (3 by maintainers)

Most upvoted comments

Hooray! With EtherNet/IP enabled I was able to reproduce the error!

Understanding the source of the error I think, this is actually desired behavior. In the respective Installation screen you can select the action that is being executed upon a loss of EtherNet/IP Scanner connection. If I select “None”, save installation and program, then everything works as before with having EtherNet/IP being activated. Only when selecting “Pause” or “Stop” the shown ProtectiveStop is raised. So, in fact, this would happen with any program running on the TP, not only our driver. If EtherNet/IP Fieldbus connection is required, a ProtectiveStop is raised when trying to execute a program without an EtherNet/IP Scanner connected.

Edit: I’ve been thinking whether there’s some lack of documentation on our side about this. In my opinion, that’s not the case as this is actually designed behavior. Now that we have this issue we have a solution if someone searches for the “C207A0” error, but I consider it too much of an edgecase to add this to some FAQ section or similar in the documentation. @w-kyle @gavanderhoorn would you agree?

@carlosjoserg The robot description is launched inside ur_common.launch.

@w-kyle Sorry, I missed the mentioned crash with the scaled_pos_traj_controller. This should also not happen and I can’t reproduce that.

I can’t reproduce the reported behavior with the real robot, either.