UR5: trajectory execution aborted (controller failed)

asked 2019-03-20 19:57:01 -0500

sisko gravatar image

updated 2019-03-21 10:14:13 -0500

Please excuse me for asking a really newbie question.

My problem is 2 fold.

[1] My python package is a moveit generated package for the UR5. In gazebo simulation I can get the manipulator to move using the get_random_poses() function.

I am also creating a static-transform-listener between the UR5 and a turtlebot simulated in gazebo. Then I'm reading poses , and repositioning the UR5, from a lookup_transform between the wrist_1_link of the UR5 and the base_footprint of the turtlebot. Again, this works in gazebo but not in the real world.

When I try the real robot, I get the following log output for the transform(), random_poses() and terminal messages:

Log[transform]:

[rospy.client][INFO] 2019-03-21 08:07:16,971: init_node, name[/ur5bot], pid[29113]
[xmlrpc][INFO] 2019-03-21 08:07:16,971: XML-RPC server binding to 127.0.0.1:0
[rospy.init][INFO] 2019-03-21 08:07:16,971: ROS Slave URI: [http://localhost:43445/]
[xmlrpc][INFO] 2019-03-21 08:07:16,971: Started XML-RPC server [http://localhost:43445/]
[rospy.impl.masterslave][INFO] 2019-03-21 08:07:16,972: _ready: http://localhost:43445/
[xmlrpc][INFO] 2019-03-21 08:07:16,972: xml rpc node: starting XML-RPC server
[rospy.registration][INFO] 2019-03-21 08:07:16,972: Registering with master node http://localhost:11311
[rospy.init][INFO] 2019-03-21 08:07:17,072: registered with master
[rospy.rosout][INFO] 2019-03-21 08:07:17,072: initializing /rosout core topic
[rospy.rosout][INFO] 2019-03-21 08:07:17,074: connected to core topic /rosout
[rospy.simtime][INFO] 2019-03-21 08:07:17,076: /use_sim_time is not set, will not subscribe to simulated time [/clock] topic
[rosout][INFO] 2019-03-21 08:07:17,082: ======== init responding
[rospy.internal][INFO] 2019-03-21 08:07:18,414: topic[/rosout] adding connection to [/rosout], count 0
[rospy.internal][INFO] 2019-03-21 08:07:18,446: topic[/tf_static] adding connection to [http://localhost:45507/], count 0
[rospy.internal][INFO] 2019-03-21 08:07:18,447: topic[/tf] adding connection to [http://localhost:45507/], count 0
[rospy.internal][INFO] 2019-03-21 08:07:18,456: topic[/tf_static] adding connection to [http://localhost:40525/], count 1
[rospy.internal][INFO] 2019-03-21 08:07:18,520: topic[/collision_object] adding connection to [/move_group], count 0
[rospy.internal][INFO] 2019-03-21 08:07:18,527: topic[/attached_collision_object] adding connection to [/move_group], count 0
[rospy.core][INFO] 2019-03-21 08:07:22,333: signal_shutdown [signal-2]
[rospy.internal][INFO] 2019-03-21 08:07:22,339: topic[/collision_object] removing connection to /move_group
[rospy.internal][INFO] 2019-03-21 08:07:22,340: topic[/attached_collision_object] removing connection to /move_group
[rospy.internal][INFO] 2019-03-21 08:07:22,340: topic[/rosout] removing connection to /rosout
[rospy.internal][INFO] 2019-03-21 08:07:22,340: topic[/tf_static] removing connection to http://localhost:45507/
[rospy.internal][WARNING] 2019-03-21 08:07:22,342: Unknown error initiating TCP/IP socket to localhost:52137 (http://localhost:45507/): Traceback (most recent call last):
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/rospy/impl/tcpros_base.py", line 558, in connect
    self.local_endpoint = self.socket.getsockname()
AttributeError: 'NoneType' object has no attribute 'getsockname'

[rospy.internal][INFO] 2019-03-21 ...
(more)
edit retag flag offensive close merge delete

Comments

I think you may be misunderstanding things: planning works, it's the execution of the plan that gets aborted when you use the real robot.

It would help if you could include more log lines. Right now there isn't sufficient information to help you.

In general: don't paraphrase errors and also please provide a little context (ie: lines before and after the line that you believe shows a relevant error).

gvdhoorn gravatar image gvdhoorn  ( 2019-03-21 01:15:01 -0500 )edit

I assumed both robots would be connected to each other using ip addresses on the same network. Then they would be "aware" of each other.

That would be nice, but that's not how things work.

I'll ignore the "aware" part (as that implies cognisance), but by just having two robots (ie: ROS applications) on the same IP network nothing is going to happen. Unless those robots are part of the same ROS node graph (ie: use the same master) or you have explicitly set up a multi-master configuration, no data is going to be exchanged.

Furthermore: even if all of that was in place, only by writing a node (ie: program) yourself would you be able to add the behaviour you are after to the system (ie: your program "ties" everything together).

In essence: just by bringing too ROS-enabled robots together nothing will happen. It's always the ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2019-03-21 01:31:04 -0500 )edit

@gvdhoom: I take your point :-). Just for the record, I wasn't suggesting robotic cognisance but you are right in that they need to be connected to a common roscore. Apologies for the vagueness of my facts. I included some more log output and some code in the hope it will help. I can include more when I get access to the UR5.

sisko gravatar image sisko  ( 2019-03-21 06:15:03 -0500 )edit

Not an answer, but why are you planning for wrist_1_link and not ee_link or tool0?

Also: is this the output in the terminal where you run your script? Because I would expect to see much more lines from MoveIt itself, when it is planning.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-21 07:01:58 -0500 )edit

I'm using wrist_3_joint because it's physically the last link on the robot. It currently has no attached end effector.

sisko gravatar image sisko  ( 2019-03-21 09:06:01 -0500 )edit

Your code (shown above) uses wrist_1_link, not wrist_3_link.

Also: the urdf for the UR5 (and UR3 and UR10) already contains a default tool0 frame (here). I'd use that, and not a "random" frame.


Edit: and looking at your code: you're asking for the transform between wrist_1_link and base_footprint. base_footprint is "on the floor", below the turtlebot. We don't know how your UR is mounted, but it's unlikely the robot can actually plan to that position: either because it's out of reach, or because the turtlebot is occupying that space.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-21 09:11:13 -0500 )edit

The ur5 is mounted on a Clearpath Husky robot but the task is not to actually reach the turtlebot especially if it can't do so. The robots should be placed close enough to make it possible for the ur5 to reach it. But in the event it can't, it is possible to achieve a pose that would get it as close as possible? I apologise for overwhelming you. I added log output for both functions.

sisko gravatar image sisko  ( 2019-03-21 09:59:12 -0500 )edit