ur5 control not working

[Antoine Rennuit]

Dear all,

I am currently getting up to speed with the universal_robot package and following the mini-tutorial found on the welcome page for simulating a UR5. I have no problem in getting the UR5 into gazebo, as explained into the first lines of the tutorial but things go wrong when it comes to moving the arm to different positions. When run, the test_move.py script displays Waiting for server... and never goes further. I had a look at the test_move.py script and the problem seems to be related to the actionlib package not providing its service, here is the script code:

        client = actionlib.SimpleActionClient('follow_joint_trajectory', FollowJointTrajectoryAction)
        print "Waiting for server..."
        client.wait_for_server()
        print "Connected to server"

I have just downloaded the sources for universal_robot and am working with hydro and precise (12.04 LTS).

Any idea of what is going on?

Thanks,

Antoine.

[Antoine Rennuit]

Hum... Actually it looks to me like the actionlib server (normally created in ur_driver/src/ur_driver/driver.py) is never instantiated as the constructor for the actionlib server is called in the constructor for URTrajectoryFollower (line 474). And it turns out only a single call to URTrajectoryFollower's constructor is made: this is in the driver.py's main()... and a printf told me that the driver.py's main() is never called when running ur5.launch in simulation.

This tends to indicate that test_move.py is not usable in simulation, doesn't it? Can anybody confirm?

Is there any other way to have the ur5 move in simulation?

Thanks ;)

[G.A. vd. Hoorn - 3ME]

On 22-7-2014 20:37, Antoine Rennuit wrote:
> Hum... Actually it looks to me like the *actionlib* server (normally
> created in *ur_driver/src/ur_driver/driver.py*) is never instantiated as
> the constructor for the actionlib server is called in the constructor for*
> URTrajectoryFollower* (line 474). And it turns out only a single call to
> *URTrajectoryFollower*'s constructor is made: this is in the *driver.py*'s

> main()... and a printf told me that the driver.py's main() is never called

> when running* ur5.launch* in simulation.
>
> This tends to indicate that *test_move.py* is not usable in simulation,

> doesn't it? Can anybody confirm?
>
> Is there any other way to have the ur5 move in simulation?

Hi Antoine,

afaik the ur_driver package is never used to communicate with a UR in
simulation, simply because gazebo does not simulate the controller, just
the arm kinematics and dynamics. As such, the standard driver cannot be
used, as it contains code to be executed on the universal robot controller.

Here in the lab, people have been using a UR5 in Gazebo by using
ros_control and the associated action servers. I know of some more
people doing this, and I'm sure they'll provide you with a more
informative answer (ie: how to set this up). I just wanted to clarify to
you why you found what you found.


Gijs

> Thanks ;)
>
>
> Le mardi 22 juillet 2014 19:34:44 UTC+2, Antoine Rennuit a écrit :
>> Dear all,
>>

>> I am currently getting up to speed with the *universal_robot *package and

>> following the mini-tutorial found on the welcome page

>> <https://github.com/ros-industrial/universal_robot> for simulating a UR5.

>> I have no problem in getting the UR5 into gazebo, as explained into the
>> first lines of the tutorial but things go wrong when it comes to moving the

>> arm to different positions. When run, the *test_move.py* script displays *Waiting
>> for server... *and never goes further. I had a look at the* test_move.py*
>> script and the problem seems to be related to the *actionlib* package not

>> providing its service, here is the script code:
>>
>> client = actionlib.SimpleActionClient('follow_joint_trajectory',
>> FollowJointTrajectoryAction)
>> print "Waiting for server..."
>> client.wait_for_server()
>> print "Connected to server"
>>
>> I have just downloaded the sources for universal_robot and am working with

>> *hydro* and *precise* (12.04 LTS).

[Antoine Rennuit]

Hey gavanderhoorn,

And thanks for your quick answer! Can you let me know how you came up with such an important information? Is there some doc somewhere or did you just get to know by practising with the universal_robot package and checking deeply into the code ?

Any information is welcome as so far I don't have much to understand how the package is organized and how things should work... Only code ;)

Thanks,

Antoine.

Le mardi 22 juillet 2014 19:34:44 UTC+2, Antoine Rennuit a écrit :

[G.A. vd. Hoorn - 3ME]

On 22-7-2014 21:14, Antoine Rennuit wrote:
> Hey gavanderhoorn,
>
> And thanks for your quick answer! Can you let me know how you came up with
> such an important information? Is there some doc somewhere or did you just

> get to know by practising with the *universal_robot *package and checking

> deeply into the code ?
>
> Any information is welcome as so far I don't have much to understand how
> the package is organized and how things should work... Only code ;)

Well, partly common sense (no controller simulated, so no controller
code, so no driver needed / possible), and partly understanding based on
reading the code. The ur_driver isn't particularly complicated, but I
admit it helps if you have some experience with these kind of things.

I would also like to draw your attention to the ROS Answers site [1],
which contains some questions & answers about the universal_robot stack
that might be of interest to you. If you post your questions there, they
will not only reach a wider audience, but should also be easier to find
for future users of the packages.


> Thanks,
>
> Antoine.


Gijs


[1] http://answers.ros.org

> Le mardi 22 juillet 2014 19:34:44 UTC+2, Antoine Rennuit a écrit :
>> Dear all,
>>

>> I am currently getting up to speed with the *universal_robot *package and

>> following the mini-tutorial found on the welcome page

>> <https://github.com/ros-industrial/universal_robot> for simulating a UR5.

>> I have no problem in getting the UR5 into gazebo, as explained into the
>> first lines of the tutorial but things go wrong when it comes to moving the

>> arm to different positions. When run, the *test_move.py* script displays *Waiting

>> for server... *and never goes further. I had a look at the* test_move.py*
>> script and the problem seems to be related to the *actionlib* package not

>> providing its service, here is the script code:
>>
>> client = actionlib.SimpleActionClient('follow_joint_trajectory',
>> FollowJointTrajectoryAction)
>> print "Waiting for server..."
>> client.wait_for_server()
>> print "Connected to server"
>>
>> I have just downloaded the sources for universal_robot and am working with

>> *hydro* and *precise* (12.04 LTS).

[Antoine Rennuit]

I see you are on the same side of the world as me (not so far away actually) so thanks a lot for answering so late. This has been helpful.

I will open a new post as for using ros_control to simulate the UR5 (inc. controllers).

Cheers ;)

Le mardi 22 juillet 2014 19:34:44 UTC+2, Antoine Rennuit a écrit :

[Jesus Alfonso]

Hi Antonie

The names of the topics are different in test_move and gazebo nodes. You can see it using rqt->introspection->Node Graph
.

In order to remap the topics, launch the test progam with

roscd ur_driver; ./test_move.py follow_joint_trajectory:=arm_controller/follow_joint_trajectory

Cheers

El 22/07/14 23:04, Antoine Rennuit escribió:

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wojtynek, Michael]

Antoine,

the ur_driver contains following folders:

- ur5/10_moveit_config
This is the moveit config similar to the output of the moveit_setup_assistant. There is some demo.launch for a first starting.

- ur_bringup
Contains the start up launch files for the ur driver. roslaunch ur_bringup ur5_bringup.launch robot_ip:192.168.XXX.XXX
is the command to connect with the ur hardware.

- ur_description
Inside this folder you can find the 3D model of your ur robot. The robot is described by files with the datatype *.urdf and *.xacro. Also you can find a meshes for collision detecting in the CAD format *.dae.

- ur_driver
Contains the driver.py which will promote the joint states to ur hardware to execute some movements.

- ur_gazebo
Outdated simulation, today we use rviz

- ur_kinematics
Here is some code for inverse kinematics solvers. I never used this before, because there exists some openrave ik solver.

If you start the ur5_bringup.launch it will start serveral other launch files in sequence:
- ur5_upload.launch (in ur_description)
- ur_common.launch -> starting the "robot_state_publisher" and tf2_ros node, and also driver.py

I hope you could get an idea how the driver package is organized.

Many Greetings,
Michael Wojtynek

[Felix Messmer (IPA)]

First of all, that me correct a view things in the previous post...

Am Mittwoch, 23. Juli 2014 13:58:20 UTC+2 schrieb Wojtynek, Michael:

Antoine,

the ur_driver contains following folders:

You are describing the content of the universal_robot repository, not the ur_driver package

 

- ur5/10_moveit_config
This is the moveit config similar to the output of the moveit_setup_assistant. There is some demo.launch for a first starting.

NOTE: demo.launch does neither connect to a Gazebo simulation nor to a real hardware, it is just there to test the motion planner settings!

- ur_bringup
Contains the start up launch files for the ur driver. roslaunch ur_bringup ur5_bringup.launch robot_ip:192.168.XXX.XXX
is the command to connect with the ur hardware.

- ur_description
Inside this folder you can find the 3D model of your ur robot. The robot is described by files with the datatype *.urdf and *.xacro. Also you can find a meshes for collision detecting in the CAD format *.dae.

It is advised to go with the *.xacro description! Also there is different versions of both UR5/UR10 to reflect reduced joint_limits which is needed to be able to plan using MoveIt!
 

- ur_driver
Contains the driver.py which will promote the joint states to ur hardware to execute some movements.

 

- ur_gazebo
Outdated simulation, today we use rviz

This is not correct! The package might not be configured optimally, but it is definitely not outdated! This is the package containing the launch files that are used to start the UR5/UR10 in Gazebo simulation! Rviz is not a simulation! It only visualizes the robot state as published by either the real hardware (ur_bringup) or the Gazebo simulation (ur_gazebo)!

- ur_kinematics
Here is some code for inverse kinematics solvers. I never used this before, because there exists some openrave ik solver.

If you start the ur5_bringup.launch it will start serveral other launch files in sequence:
- ur5_upload.launch (in ur_description)
- ur_common.launch -> starting the "robot_state_publisher" and tf2_ros node, and also driver.py

If you start

roslaunch ur_bringup ur5_bringup.launch

you would be trying to connect to the real UR hardware.

(NOTE: You should not use

roslaunch ur_bringup ur5.launch

as it is marked deprecated and will be removed sooner or later.


As the question is about using the UR5 in Gazebo simulation, you should use

roslaunch ur_gazebo ur5.launch

 

[Felix Messmer (IPA)]

...and now some remarks on the actual question:

jalfonso100 is right about remapping the topics of the ActionServer!
The test_move.py was meant to test the communication with the actual UR controller and move the real UR hardware!

gavanderhoorn is right about the Gazebo simulation not using the ur_driver but ros_control!
Because the Gazebo simulation does not use the ur_driver (because the ur_driver is meant to be used with the real hardware only), but uses ros_control, they unfortunately provide the FollowJointTrajectory action under a different namespace. This makes the remapping necesseray!

However, even if you use jalfonso100's suggestion to remap the action, you will probably not be able to move the robot in Gazebo simulation.
This is because the dynamics model of the robot, i.e. masses, inertia, damping, effort limits etc., is currently not perfectly modeled within the URDF.
Due to this, it is almost impossible to find good controller values, i.e. PID, for the ros_control FollowJointTrajectory controller.
Thus, for the time being, both UR5 and UR10 most likely cannot be properly moved in Gazebo simulation until things are sorted out!
Sorry for that!

If you want to give it a try, you can play around with the controller parameters. You can find them in ur_gazebo/controller/arm_controller_ur5.yaml
There is also a tutorial on the Gazebo website that deals with ros_controll and controller tuning: http://gazebosim.org/wiki/Tutorials/1.9/ROS_Control_with_Gazebo

Hope that helps!

[jalfonso100]

Felix, you are right. The simulation model of UR5 in gazebo is not OK.

I published in rosanswers a set of parameters that works well in gazebo.

You can see it in
http://answers.ros.org/question/157261/manipulator-shakeswobbles/

Hope that helps!

[Felix Messmer (IPA)]

In case you got a working simulation setup, please send a PullRequest with your changes to the official github repository!

[Antoine Rennuit]

Dear @jalfonso100, @Michael and @Felix, thanks for your help, things are a little bit more clear. It took me a bit of time to answer as I wanted to test different things since your last message.

My simulation is still wobbly despite of the updated parameters provided by jalfonso100 in his post on ros answer. I will follow the conversation over there.

Thanks.

Le mardi 22 juillet 2014 19:34:44 UTC+2, Antoine Rennuit a écrit :