search

UniversalRobots / Universal_Robots_ROS_Driver

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

Robot Does not Move with rqt_joint_trajectory_controller GUI #28

Closed c-keil closed 4 years ago

c-keil commented 5 years ago

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

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.

fmauch commented 5 years ago

I'll definitely investigate this, but is there a particular reason you want to use the pos_traj_controller? The scaled_pos_traj_controller works the same except it respects speed scaling limitations by the controller, while the pos_traj_controller will run away as soon as speed scaling kicks in.

fmauch commented 5 years ago

Unfortunately, I'm not able to reproduce this issue (At least with a simulated robot). I will try on the real robot later today. Would it be possible for you to check again with the current master branch? There were made quite a few changes, recently (Although they should not affect this, but this shouldn't be happening anyway...)

carlosjoserg commented 5 years ago

@w-kyle The rqt_joint_trajectory_controller plugin requires a robot_description parameter to be set, see here to obtain the position limits, and render the sliders properly. In fact, the crash error you mention surely says KeyError: 'robot_description' at the bottom?

From the steps you mention above, I don't see where you set it, and as far as I can see, the ur5e_bringup does not set it either. Or maybe you missed steps. This might explain the crash.

Side note: rqt recalls your last setup, which you can find in ~/.config/ros.org/rqt_gui.ini. Remove that file and you'll have a fresh rqt window, and it should crash with any controller if you don't set robot_description. This might explain why it does not crash with pos_traj_controller, because you might have used it before succesfully, but still nothing will happen as you experience.

fmauch commented 5 years ago

@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.

c-keil commented 5 years ago

Ok, I'm currently trying a few things and I will update the issue when I have more information. Is it possible that this is an issue with ROS Kinetic?

fmauch commented 5 years ago

I've tested it both, on kinetic and melodic.

c-keil commented 4 years ago

As a followup, I am still not able to get the robot to move. I have also tried Movit with rviz and had no progress there either. My only leads are as follows:

  1. When I run the external control URCap program it throws an error "C207A0" that initiates a protective stop on the pendant, and I have to re-enable it to turn off the protective stop. Details: When I run the external control URCap program I see the following error: IMG_5494 I'm not sure how to interpret this because we are trying to use external control. The ROS driver prints out: [ INFO] [1573673093.322336741]: Robot's safety mode is now PROTECTIVE_STOP [ INFO] [1573673098.423245720]: Robot requested program [ INFO] [1573673098.423425240]: Sent program to robot I press enable on the teach pendant and ROS prints: [ INFO] [1573673109.264337697]: Robot's safety mode is now NORMAL At this point the robot is not ready to receive commands, the controllers are not running and the driver throws errors if you try to send any commands, so I start the ExternalControl program again on the teach pendant and the robot enters a protective stop again with this error: IMG_5497 When I hit enable on the pendant ROS prints: [ INFO] [1573670968.472654679]: Robot requested program [ INFO] [1573670968.472898253]: Sent program to robot [ INFO] [1573670968.497648682]: Robot ready to receive control commands. [ INFO] [1573670968.599256460]: Robot's safety mode is now PROTECTIVE_STOP [ INFO] [1573670969.399633218]: Robot's safety mode is now NORMAL This seems to indicate that the robot is ready to command, and the controllers have all started in the driver. It is not clear to me why these errors are being thrown, but maybe they are a clue.

  2. When I try to use the RQT gui with the scaled position trajectory controller, the following error is thrown as soon as I press the "On" button on the gui: rosrun rqt_joint_trajectory_controller rqt_joint_trajectory_controller Traceback (most recent call last): File "/opt/ros/kinetic/lib/python2.7/dist-packages/rqt_joint_trajectory_controller/joint_trajectory_controller.py", line 416, in _update_cmd_cb pos = self._joint_pos[name]['position'] KeyError: 'position'

Does anyone have any thoughts?

fmauch commented 4 years ago

This protective stop should not happen.

To debug this any further. Could you please

and attach the following files from the robot to this issue:

You can copy the files using scp with user: root, pw: easybot

c-keil commented 4 years ago

These are the requested files: Google Drive Link

fmauch commented 4 years ago

I copied your files to a ursim UR5e and I could not reproduce the error.

However, from looking at your files I can see that you have the Robotiq Gripper URCap installed, which you didn't mention before. That does insert a lot of stuff into the URScript.

As being said: I cannot reproduce the errors in my simulated robot, however with the Robotiq URCap installed there seems to be running at the beginning of the program consuming some time before starting the actual external control parts.

Would it be possible to remove the URCap from the robot temporarily to reduce the number of components being involved?

If that helps, you could try adding it again and removing the RS485 URCap instead. As both are as far as I can see using fieldbus communication, they might be conflicting in a way and thereby causing those protective stops.

If all that doesn't help, please tell me a little more about your hardware setup: Do you have anything connected to the wrist? Is there any other hardware connected to the robot, e.g. through any IO ports?

c-keil commented 4 years ago

I removed the Robotiq URCap when I first got this error and have not put it back on, but it still shows up in the files I sent? It doesn't show up in the listed URCaps in settings. Is there a way to double check that? I'll try removing the rs485 Cap.

fmauch commented 4 years ago

You see in the generated script code, that there is still something left. It might work creating a new program and saving it. Check the generated script code (the *.script file) for anything pointing to the URCap.

c-keil commented 4 years ago

I was able to generate a new program without the other URCaps. The script is much shorter now and does not contain the references to the gripper or the RS485 URCap, however I am still seeing the protective stop.

c-keil commented 4 years ago

I have solved the problem. To get this error to go away I needed to go to the "Installation" tab, check the "Fieldbus" menu and make sure that "EtherNet/IP" is disabled. This is a little non-intuitive since we are in fact using ethernet to communicate, but that solved it. The robot is now moving.

gavanderhoorn commented 4 years ago

This is a little non-intuitive since we are in fact using ethernet to communicate, but that solved it

I'm not @fmauch, but from what I know needing to disable EtherNet/IP is not intended, so it would be good to figure out why that is needed.

The EtherNet/IP implementation on UR controllers afaik also uses RTDE, so perhaps there is some sort of resource contention or starvation causing your problems.

What are you using EtherNet/IP for?

c-keil commented 4 years ago

My statement may have ben a little misleading. I meant that the ROS computer is communicating over an Ethernet cable.

gavanderhoorn commented 4 years ago

EtherNet/IP != ethernet.

So you're not using EtherNet/IP with your UR right now?

Still, the fact that it needed to be disabled is surprising and not as it should be I believe.

fmauch commented 4 years ago

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?

gavanderhoorn commented 4 years ago

Ah, this definitely makes sense, and I agree, would be expected behaviour.

Although this is already documented in UR's manuals, it would be good to add a warning/notice about this in the driver's documentation as well, just to avoid confusion such as reported by @w-kyle.

Barry-Liang commented 4 years ago

As a followup, I am still not able to get the robot to move. I have also tried Movit with rviz and had no progress there either. My only leads are as follows:

  1. When I run the external control URCap program it throws an error "C207A0" that initiates a protective stop on the pendant, and I have to re-enable it to turn off the protective stop. Details: When I run the external control URCap program I see the following error: IMG_5494 I'm not sure how to interpret this because we are trying to use external control. The ROS driver prints out: [ INFO] [1573673093.322336741]: Robot's safety mode is now PROTECTIVE_STOP [ INFO] [1573673098.423245720]: Robot requested program [ INFO] [1573673098.423425240]: Sent program to robot I press enable on the teach pendant and ROS prints: [ INFO] [1573673109.264337697]: Robot's safety mode is now NORMAL At this point the robot is not ready to receive commands, the controllers are not running and the driver throws errors if you try to send any commands, so I start the ExternalControl program again on the teach pendant and the robot enters a protective stop again with this error: IMG_5497 When I hit enable on the pendant ROS prints: [ INFO] [1573670968.472654679]: Robot requested program [ INFO] [1573670968.472898253]: Sent program to robot [ INFO] [1573670968.497648682]: Robot ready to receive control commands. [ INFO] [1573670968.599256460]: Robot's safety mode is now PROTECTIVE_STOP [ INFO] [1573670969.399633218]: Robot's safety mode is now NORMAL This seems to indicate that the robot is ready to command, and the controllers have all started in the driver. It is not clear to me why these errors are being thrown, but maybe they are a clue.
  2. When I try to use the RQT gui with the scaled position trajectory controller, the following error is thrown as soon as I press the "On" button on the gui: rosrun rqt_joint_trajectory_controller rqt_joint_trajectory_controller Traceback (most recent call last): File "/opt/ros/kinetic/lib/python2.7/dist-packages/rqt_joint_trajectory_controller/joint_trajectory_controller.py", line 416, in _update_cmd_cb pos = self._joint_pos[name]['position'] KeyError: 'position'

Does anyone have any thoughts?

Would you please teach me how to solve this second error? I got the same error with 'position'. Thanks.