Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem to bring up UR3 #192

Closed
anton-brinster opened this issue Jun 11, 2020 · 6 comments
Closed

Problem to bring up UR3 #192

anton-brinster opened this issue Jun 11, 2020 · 6 comments

Comments

@anton-brinster
Copy link

Summary

Using external control with corresponding IP address shows problem to bring up the robot (UR3) at the point of Quick start.

Versions

  • ROS Driver version: ubuntu18.04+melodic
  • Affected Robot Software Version(s): 3.8.0
  • Affected Robot Hardware Version(s): UR3
  • URCaps Software version(s): external control 1.0.1

Impact

Able to extract calibration extraction but no communication/ control possible anymore.

Issue details

roslaunch ur_robot_driver ur3_bringup.launch robot_ip:=192.168.0.104

[ INFO] [1591898747.271193712]: Initializing dashboard client
[ INFO] [1591898747.272970281]: Waiting for controller manager service to come up on /controller_manager/switch_controller
[ INFO] [1591898747.275401545]: waitForService: Service [/controller_manager/switch_controller] has not been advertised, waiting...
process[ur_hardware_interface/ur_robot_state_helper-6]: started with pid [6162]
[ INFO] [1591898747.280759121]: Connected: Universal Robots Dashboard Server
[ INFO] [1591898747.314250031]: Initializing urdriver
[ INFO] [1591898747.314691425]: Checking if calibration data matches connected robot.
[ WARN] [1591898747.315075169]: No realtime capabilities found. Consider using a realtime system for better performance
[ERROR] [1591898747.345328007]: The calibration parameters of the connected robot don't match the ones from the given kinematics config file. Please be aware that this can lead to critical inaccuracies of tcp positions. Use the ur_calibration tool to extract the correct calibration from the robot and pass that into the description. See [TODO Link to documentation] for details.
[INFO] [1591898747.721934]: Controller Spawner: Waiting for service controller_manager/load_controller
[INFO] [1591898747.729005]: Controller Spawner: Waiting for service controller_manager/load_controller
[ WARN] [1591898748.349168591]: No realtime capabilities found. Consider using a realtime system for better performance
[FATAL] [1591898749.369510158]: Could not get urcontrol version from robot. This should not happen!
[ERROR] [1591898749.369625180]: Could not correctly initialize robot. Exiting

REQUIRED process [ur_hardware_interface-2] has died!
process has died [pid 6140, exit code 1, cmd /home/labor/catkin_ws/devel/lib/ur_robot_driver/ur_robot_driver_node __name:=ur_hardware_interface __log:=/home/labor/.ros/log/7eeea532-ac09-11ea-ab71-e0cb4e92bc7c/ur_hardware_interface-2.log].
log file: /home/labor/.ros/log/7eeea532-ac09-11ea-ab71-e0cb4e92bc7c/ur_hardware_interface-2*.log
Initiating shutdown!

[ur_hardware_interface/ur_robot_state_helper-6] killing on exit
[controller_stopper-5] killing on exit
[ros_control_stopped_spawner-4] killing on exit
[ros_control_controller_spawner-3] killing on exit
[ur_hardware_interface-2] killing on exit
[robot_state_publisher-1] killing on exit
[WARN] [1591898749.777375]: Controller Spawner couldn't find the expected controller_manager ROS interface.
[WARN] [1591898749.794556]: Controller Spawner couldn't find the expected controller_manager ROS interface.
[controller_stopper-5] escalating to SIGTERM
shutting down processing monitor...
... shutting down processing monitor complete
done

On TP
"The connection to the remote PC could not be established."

Use Case and Setup

  • robot and PC are on the same network
  • ethernet connection to the UR3 control station
  • no RT kernel

Project status at point of discovered

  • In first couple of tries.

Steps to Reproduce

following the instruction up to step "Quick start"

@fmauch
Copy link
Contributor

fmauch commented Jun 11, 2020

Thanks for reporting this. I'll check whether we missed something regarding protocol changes as 3.8 is an older software version than we usually use for testing.

@fmauch
Copy link
Contributor

fmauch commented Jun 12, 2020

After having a second look into this: I cannot reproduce this on a 3.8 URSim. Also, since this is concerning RTDE communication, protocol changes aren't very likely.

@anton-bristner could you please check this branch? This should give a clearer indication what's going on.

Edit: I just merged the mentioned branch, so using the latest master would also work.

@anton-brinster
Copy link
Author

Hello, @fmauch . Thank you for your reply. Actually this is not a bug but a misconception on mine. Regarding https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/191 it is necessary to disable "EtherNet/IP" so protocol of External Control has unobstracted access.
Issue will be closed.

@gavanderhoorn
Copy link
Contributor

Actually this is not a bug but a misconception on mine.

Could you explain a bit more about what was unclear?

@anton-brinster
Copy link
Author

Could you explain a bit more about what was unclear?

I did not know that I have to disable "EtherNet/IP" for the program of the External Control. The result was that the UR3 could not be initialized. I do not know the complete context of this behavior. So if I disable "EtherNet/IP" the interface is working fine.

Moreover calibration has been successful and the robot model is showing the correct parameters for the joints in RVIZ, also if I am moving the robot arm. But for now I'm still not able to execute planning movement to control real robot:

"Solution found but controller failed during execution"

This would be an other issue possibly but I am trying to find the solution for it.

@gavanderhoorn
Copy link
Contributor

I did not know that I have to disable "EtherNet/IP" for the program of the External Control.

That should not actually be required, but it seems like there is something of a conflict caused by the current implementation. See #191.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants