New Universal Robot driver

[Thomas Timm Andersen]

Hello ROS-Industrial users

 

(Sorry for cross-posting)

 

I am glad to share my new driver for the Universal Robots: https://github.com/ThomasTimm/ur_modern_driver

 

The driver is written in c++ and is designed to replace the old driver transparently, while solving some issues, improving usability as well as enabling compatibility of ros_control.

 

The most noticeable differences for current users will be the ability to use the teach pendant while the driver is connected as well as support for the UR3 and newest firmware versions.

The driver also makes it possible to send URScript commands from ROS to the robot as well as introduces a joint speed interface for doing visual servoing with the UR robots.

 

The driver resides in its own package, so you can install it and test it out without risking your current setup. Just use the included launch files instead of the ones from urX_bringup.

 

I have also included support for ros_control for those who would like to test that out. Note that the use of ros_control will probably require some minor modifications to your existing code if you choose to incorporate this into an existing project. Whether the driver should expose the "old" action interface or be controlled via ros_control is determined by a parameter at launch time. Note that the PID controllers are not optimally tuned at this time.

 

I have tested the driver with all the newest versions of ur-sim (1.6.08725, 1.7.10857, 1.8.16941, 3.0.16471, and 3.1.18024) as well as some real robots (UR5 and UR10, both with a CB2 controller running 1.8.14035).

 

Please try it out and report any issues / incompatibilities so it hopefully can make it into Jade (or indigo?)

 

Best regards

 

Thomas Timm Andersen
PhD student
DTU Electrical Engineering
Technical University of Denmark

 

 

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

On 25/09/15 13:36, Thomas Timm Andersen wrote:
> Hello ROS-Industrial users
>
> (Sorry for cross-posting)
>
> I am glad to share my new driver for the Universal Robots:
> https://github.com/ThomasTimm/ur_modern_driver
>
> The driver is written in c++ and is designed to replace the old driver
> transparently, while solving some issues, improving usability as well as
> enabling compatibility of ros_control.

[..]

> Please try it out and report any issues / incompatibilities so it hopefully
> can make it into Jade (or indigo?)

[..]

Hi Thomas,


thanks for making this available. I had a quick look, and tried to
summarise my understanding of your class hierarchy. I've included it
below this email.

Looking through the code, I got the impression that this driver mimics
the Python driver in quite a few places. Was that intentional? I was
especially surprised by the use of 'driverProg' and seeing
UrDriver::servoj() use the same binary protocol. Is that because there
is no more performant way, and re-using the existing structure is then
convenient, or do you have some other reason for this?

Would it make sense to completely do away with UrDriver::doTraj(), and
only support a ros_control based driver that just uses
UrDriver::setSpeed() for both position and velocity control? Or is the
local loop on the UR controller better suited (accuracy, robustness) for
this?


Gijs


--------------------------------------------------


do_output
- ros log / printf wrappers

robot_state
- C++ implementation of sec iface bin protocol deserialiser

robot_state_RT
- C++ implementation of rt iface bin protocol deserialiser

ur_communication
- thread
- uses robot_state.h
- opens socket to sec iface, deserialises incoming data
- maintains RobotState member

ur_realtime_communication
- thread
- uses robot_state_RT.h
- opens socket to rt iface, deserialises incoming data
- maintains RobotStateRT member
- supports sending speedj() script statements to ctrlr
- supports sending arbitrary urscript statements to ctrlr

ur_driver
- C++ implementation of parts of old Python driver
- addTraj():
- generate complete urscript prog for entire JointTrajectory (servoj())
- interpolates traj segments into N (time)steps
- not a secondary program
- doTraj():
- uploads driverProg on-demand via RT iface
- driver<->ctrlr comm uses old Python driver binary protocol (MULT_*)
- interpolates traj segments with dt=ITP
- runs a servoj() loop over the TCP conx to the ctrlr (open loop),
using local time (ROS PC)
- exposes setSpeed() via ur_realtime_communication
- exposes IO setters via ur_realtime_communication

ur_hardware_interface
- ros_control compatible hw iface implementation
- uses UrDriver instance
- exposes joint_state, force_torque_sensor, joint_position and
joint_velocity ctrlrs
- velocity ctrlr via ur_realtime_communication->setSpeed(): speedj()
statements
- position ctrlr via ur_driver->servoj(): comm with driverProg

ur_ros_wrapper
- uses UrDriver, HwInterface implementations
- exposes FollowJointTrajectoryAction server
- exposes SetIO server
- exposes velocity iface (topic) via ur_driver.setspeed()
- exposes urscript iface (topic) via ur_realtime_communication
- publishes joint_states & wrench via ur_realtime_communication
- publishes io_states via ur_communication
- runs ros_control loop if configured to do so (either / or)

[Thomas Timm Andersen]

On Friday, September 25, 2015 at 2:59:01 PM UTC+2, gavanderhoorn wrote:

On 25/09/15 13:36, Thomas Timm Andersen wrote:
> Hello ROS-Industrial users
>
> (Sorry for cross-posting)
>
> I am glad to share my new driver for the Universal Robots:
> https://github.com/ThomasTimm/ur_modern_driver
>
> The driver is written in c++ and is designed to replace the old driver
> transparently, while solving some issues, improving usability as well as
> enabling compatibility of ros_control.
[..]
> Please try it out and report any issues / incompatibilities so it hopefully
> can make it into Jade (or indigo?)
[..]

Hi Thomas,


thanks for making this available. I had a quick look, and tried to
summarise my understanding of your class hierarchy. I've included it
below this email.

The summary looks about right, except that UrDriver->addTraj() is deprecated.

I'm working on a report on how/why I've made the driver, and the method in addTraj was my first attempt.

A part of the motivation for making this driver is the time it takes from you send a trajectory until the robot start executing it (the delay is +150ms) ; I wanted to see if I could reduce this.

 

The only UrScript command suitable for position-based trajectory control is the servoj command, but just streaming that to the robot makes for very jerky movements. (It is not possible to get a desired velocity other than 0 at key trajectory points with the move* commands without using the blend parameter, but then the robot would not reach the actual points. A tightly optimized trajectory with obstacle avoidance from MoveIt would thus result in collisions).

As the entire trajectory is known ahead of time, I though of just sending it all in one go as a UrScript program. This is what the addTraj() function does.

 

It works really well if it is a short trajectory with only a few waypoint, but as soon as more waypoints are added and/or the trajectory execution time is long, this method is really bad ( addTraj() pads a long trajectory with extra waypoints for smooth execution, making sure there are at most 240 ms between each). At 17 waypoints (including padding, which means anything over 4 seconds), the trajectory was again delayed up to +150 ms, and a long trajectory of 60 seconds was delayed up to 4 seconds before execution started. This is probably due to the fact that the controller parses the entire program before executing it.

 

This method has thus been scrapped, and are only still in the code so I can make the measurements for my report and document that this is not an optimal approach.

Looking through the code, I got the impression that this driver mimics
the Python driver in quite a few places. Was that intentional? I was
especially surprised by the use of 'driverProg' and seeing
UrDriver::servoj() use the same binary protocol. Is that because there
is no more performant way, and re-using the existing structure is then
convenient, or do you have some other reason for this?

 

When I found that the addTraj was not a feasible method, I went back to the method used in the python driver. I've retained a lot of the naming to make it transparent where I've got the inspiration from ;) Still, it is only a very limited part of the old driverProg that I've re-used, and the binary protocol is thus not entirely the same. (I've only implemented the servoj function, thus a msg_type was needless. Instead, I have a keepalive flag, which terminates the driverProg when the trajectory is executed, making it possible to use the teach pendant).

I won't definitely say that there isn't a better-performing way of doing this, but I haven't been able to come up with anything better than oversampling the interpolated trajectory. Note though that with the c++ implementation I've been able to increase the transmission rate to take full advantage of the 125 Hz control cycle on the controller (compared to the old rate of 50 Hz), and I've increased the MULT_joint with a factor 100 for higher resolution as a 32 bit integer could easily accommodate this, seeing that the values are limited to +/- 2pi.

 

Would it make sense to completely do away with UrDriver::doTraj(), and
only support a ros_control based driver that just uses
UrDriver::setSpeed() for both position and velocity control? Or is the
local loop on the UR controller better suited (accuracy, robustness) for
this?

In time, I think that would make sense, yes.

I would guess that a controller that takes dynamics into account would probably be needed before it can compete with the accuracy of the servoj command, but this is purely speculative. Also, I haven't done much to tune the PID gains. But I don't see any reason why it shouldn't be possible to do just as good with speedj as with the servoj command in terms of accuracy.

W.r.t robustness; if anything the speedj is better. speedj commands also executes much faster (in the next control loop after reception as compared to the +150 ms).

Until these things are in place (at least the tuning of the PID gains), I've opted to keep the servoj local loop, also to ensure comparable performance and backwards compatibility with the old driver.

Thanks for looking at it, your feedback is much appreciated!

 

Thomas 

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

On 25/09/15 15:43, Thomas Timm Andersen wrote:
> On Friday, September 25, 2015 at 2:59:01 PM UTC+2, gavanderhoorn wrote:
>>
>> On 25/09/15 13:36, Thomas Timm Andersen wrote:
>>> Hello ROS-Industrial users
>>>
>>> (Sorry for cross-posting)
>>>
>>> I am glad to share my new driver for the Universal Robots:
>>> https://github.com/ThomasTimm/ur_modern_driver
>>>
>>> The driver is written in c++ and is designed to replace the old driver
>>> transparently, while solving some issues, improving usability as well as
>>> enabling compatibility of ros_control.
>> [..]
>>> Please try it out and report any issues / incompatibilities so it
>>> hopefully can make it into Jade (or indigo?)
>> [..]
>>
>> Hi Thomas,
>>
>>
>> thanks for making this available. I had a quick look, and tried to
>> summarise my understanding of your class hierarchy. I've included it
>> below this email.
>
> The summary looks about right, except that UrDriver->addTraj() is
> deprecated.

ok. I left that out, but you're right.

> I'm working on a report on how/why I've made the driver, and the method in
> addTraj was my first attempt.
> A part of the motivation for making this driver is the time it takes from
> you send a trajectory until the robot start executing it (the delay is
> +150ms) ; I wanted to see if I could reduce this.
>
> The only UrScript command suitable for position-based trajectory control is
> the servoj command, but just streaming that to the robot makes for very
> jerky movements. (It is not possible to get a desired velocity other than 0
> at key trajectory points with the move* commands without using the blend
> parameter, but then the robot would not reach the actual points.

Yes, that is something that I believe almost all (industrial) motion
controllers suffer from.

> A tightly optimized trajectory with obstacle avoidance from MoveIt
> would thus result in collisions).
> As the entire trajectory is known ahead of time, I though of just sending
> it all in one go as a UrScript program. This is what the addTraj() function
> does.
>
> It works really well if it is a short trajectory with only a few waypoint,
> but as soon as more waypoints are added and/or the trajectory execution
> time is long, this method is really bad ( addTraj() pads a long trajectory
> with extra waypoints for smooth execution, making sure there are at most
> 240 ms between each). At 17 waypoints (including padding, which means
> anything over 4 seconds), the trajectory was again delayed up to +150 ms,
> and a long trajectory of 60 seconds was delayed up to 4 seconds before
> execution started. This is probably due to the fact that the controller
> parses the entire program before executing it.

I would expect this to be the case as well, yes.

> This method has thus been scrapped, and are only still in the code so I can
> make the measurements for my report and document that this is not an
> optimal approach.
>
>>
>> Looking through the code, I got the impression that this driver mimics
>> the Python driver in quite a few places. Was that intentional? I was
>> especially surprised by the use of 'driverProg' and seeing
>> UrDriver::servoj() use the same binary protocol. Is that because there
>> is no more performant way, and re-using the existing structure is then
>> convenient, or do you have some other reason for this?
>>
>
> When I found that the addTraj was not a feasible method, I went back to
> the method used in the python driver. I've retained a lot of the naming to
> make it transparent where I've got the inspiration from ;) Still, it is
> only a very limited part of the old driverProg that I've re-used, and the
> binary protocol is thus not entirely the same. (I've only implemented the
> servoj function, thus a msg_type was needless. Instead, I have a keepalive
> flag, which terminates the driverProg when the trajectory is executed,
> making it possible to use the teach pendant).

Right, true.

> I won't definitely say that there isn't a better-performing way of doing
> this, but I haven't been able to come up with anything better than
> oversampling the interpolated trajectory. Note though that with the c++
> implementation I've been able to increase the transmission rate to take
> full advantage of the 125 Hz control cycle on the controller (compared to
> the old rate of 50 Hz), and I've increased the MULT_joint with a factor 100
> for higher resolution as a 32 bit integer could easily accommodate this,
> seeing that the values are limited to +/- 2pi.

I'm curious (and a bit confused): whether using C++ or Python should not
matter for the communication rate attainable by the driver. Python can
be made as performant as C++ (especially in small systems like these),
so I'm wondering where the increase in performance is really coming
from. I'd be interested to see some tests with the same minimal
driverProg and a stripped Python driver.

Do you know if there is any difference in execution paths taken by
scripts uploaded through the RT port vs the secondary interface? I would
not expect there to be any, but I seem to remember reports of other
(non-ROS) users that tried to do high-rate speedj() control over the
secondary interface, and never got above ~10 Hz. It's at least a nice
coincidence that the secondary interface broadcasts at the same frequency.

>> Would it make sense to completely do away with UrDriver::doTraj(), and
>> only support a ros_control based driver that just uses
>> UrDriver::setSpeed() for both position and velocity control? Or is the
>> local loop on the UR controller better suited (accuracy, robustness) for
>> this?
>
> In time, I think that would make sense, yes.
> I would guess that a controller that takes dynamics into account would
> probably be needed before it can compete with the accuracy of the servoj
> command, but this is purely speculative. Also, I haven't done much to tune
> the PID gains. But I don't see any reason why it shouldn't be possible to
> do just as good with speedj as with the servoj command in terms of
> accuracy.
> W.r.t robustness; if anything the speedj is better. speedj commands also
> executes much faster (in the next control loop after reception as compared
> to the +150 ms).

If I understand you correctly: _any_ command other than speedj() will
have this 150ms+ delay before it is executed?

Or is it just the current driverProg based implementation?

> Until these things are in place (at least the tuning of the PID gains),
> I've opted to keep the servoj local loop, also to ensure comparable
> performance and backwards compatibility with the old driver.

Ok, that makes sense.


thanks for your reply.


Gijs

[Wouter Caarls]

On 09/25/2015 11:15 AM, G.A. vd. Hoorn - 3ME wrote:
> On 25/09/15 15:43, Thomas Timm Andersen wrote:
>> On Friday, September 25, 2015 at 2:59:01 PM UTC+2, gavanderhoorn wrote:
>>>
>>> On 25/09/15 13:36, Thomas Timm Andersen wrote:

<snip>

>> I won't definitely say that there isn't a better-performing way of doing
>> this, but I haven't been able to come up with anything better than
>> oversampling the interpolated trajectory. Note though that with the c++
>> implementation I've been able to increase the transmission rate to take
>> full advantage of the 125 Hz control cycle on the controller (compared to
>> the old rate of 50 Hz), and I've increased the MULT_joint with a
>> factor 100
>> for higher resolution as a 32 bit integer could easily accommodate this,
>> seeing that the values are limited to +/- 2pi.
>
> I'm curious (and a bit confused): whether using C++ or Python should not
> matter for the communication rate attainable by the driver. Python can
> be made as performant as C++ (especially in small systems like these),
> so I'm wondering where the increase in performance is really coming
> from. I'd be interested to see some tests with the same minimal
> driverProg and a stripped Python driver.
>
> Do you know if there is any difference in execution paths taken by
> scripts uploaded through the RT port vs the secondary interface? I would
> not expect there to be any, but I seem to remember reports of other
> (non-ROS) users that tried to do high-rate speedj() control over the
> secondary interface, and never got above ~10 Hz. It's at least a nice
> coincidence that the secondary interface broadcasts at the same frequency.

Indeed, in my experiments going over 20Hz using speedj() control over
the secondary interface caused trouble. We did write a ROS node to do
this, but did not integrate it with the ROS planning/control ecosystem.

https://github.com/wcaarls/ur_arm

Great to hear there's progress on this front!

Cheers,

Wouter.

[Thomas Timm Andersen]

I agree that there should not be a difference, but unfortunately the world seems to disagree. I have previously tried to change the 'rate' of the driver.py (line 647) and started to see jerky motion even at a rate of 0.166 (calling _update at 60 Hz). I just tried again to re-confirm, this time I could push rate to 0.004 without problems (this is multiplied with 4, so servoj runs with t=0.16), but started to have some problems at rate=0.002. It's been a while since I last tried this, so maybe something has changed either in the driver (although I can't spot anything that should give a performance boost) or in the controller.

 

The c++ loop is executed with an equivalent rate of 0.002 . I would be surprised if the improved performance comes from the stripped down driverProg, as the only thing left out is an if-statement (and all the code that wouldn't get executed due to that if statement) and that I only do 1 socket-read per loop instead of 2.

 

Do you know if there is any difference in execution paths taken by
scripts uploaded through the RT port vs the secondary interface? I would
not expect there to be any, but I seem to remember reports of other
(non-ROS) users that tried to do high-rate speedj() control over the
secondary interface, and never got above ~10 Hz. It's at least a nice
coincidence that the secondary interface broadcasts at the same frequency.

 

I haven't tested that, no. Given that UR themselves reference port 30003 as the "realtime" or "matlab" interface, I would always assume that would be the intended port for doing control. 

 

>> Would it make sense to completely do away with UrDriver::doTraj(), and
>> only support a ros_control based driver that just uses
>> UrDriver::setSpeed() for both position and velocity control? Or is the
>> local loop on the UR controller better suited (accuracy, robustness) for
>> this?
>
> In time, I think that would make sense, yes.
> I would guess that a controller that takes dynamics into account would
> probably be needed before it can compete with the accuracy of the servoj
> command, but this is purely speculative. Also, I haven't done much to tune
> the PID gains. But I don't see any reason why it shouldn't be possible to
> do just as good with speedj as with the servoj command in terms of
> accuracy.
> W.r.t robustness; if anything the speedj is better. speedj commands also
> executes much faster (in the next control loop after reception as compared
> to the +150 ms).

If I understand you correctly: _any_ command other than speedj() will
have this 150ms+ delay before it is executed?

Or is it just the current driverProg based implementation?

 

I think the delay comes from the controller trying to interpolate between two servoj commands, but that is purely speculative. That is probably wrong, but it's the least ridiculous explanation that I can come up with :)

The only command I have examined in depth is the speedj; I can see that command is reflected in the returned status msg target_qd in the next sample, so I know using speedj is as fast as it is possible.

 

> Until these things are in place (at least the tuning of the PID gains),
> I've opted to keep the servoj local loop, also to ensure comparable
> performance and backwards compatibility with the old driver.

Ok, that makes sense.


thanks for your reply.


Gijs

 

I'd still love to hear from anybody who has actually tried it, especially those that had problems using it with v3.x of the firmware (i.e. those related to issue #191, #199 and #182 in the universal_robot repo.)

[Thomas Timm Andersen]

Gijs, I am glad to report that the world actually does agree to some extend. :) I've just tested out Shaun's ROSCon15 demo (which stresses the arm a fair bit more than I ever have in my development), and with that demo my driver also started jerking a bit with a rate of 0.002. I needed to change the rate to 0.004 (equivalent of a servoj_time of 0.016) to make it possible to run the demo with the new driver smoothly.

The only thing is, I couldn't get the old python-based driver to run the same demo smoothly with a rate of 0.004. I tried a rate of 0.004 and 0.006 (servoj_time of 0.016 and 0.024) but ultimately had to change it to 0.008 for it to run the demo. With the lower rates the old driver continuously wrote  "out: breaking" until the controller fired a jerk violation, which suggests to me that the python loop can not run that fast and thus the servo values are not updated in time. It puzzles me, though, that this in any way should be affected by what trajectory is sent to the robot, so there is still something weird going on.

It could be down to a network load issue, but that seems inconsistent with the fact that I get a different performance from the two drivers(as they are run on the same computer, switching back and forth as fast as roslaunch can shut down one driver and start the other)

[Teresa Seco]

Hello,

First of all, congratulation for this new ur driver implementation. I am using it with an UR10 and it works really well. I send different trajectories using the action server with no problems.

I have a problem when I try to stop the robot movement by sending an empty trajectory, the driver crashes. This is a piece of my code:

        trajectory_msgs::JointTrajectory empty;
        empty.joint_names.push_back("shoulder_pan_joint");
        empty.joint_names.push_back("shoulder_lift_joint");
        empty.joint_names.push_back("elbow_joint");
        empty.joint_names.push_back("wrist_1_joint");
        empty.joint_names.push_back("wrist_2_joint");
        empty.joint_names.push_back("wrist_3_joint");
       
         empty.header.stamp = ros::Time::now();

       //Create goal and send it to the controller
        control_msgs::FollowJointTrajectoryGoal goal;
        goal.trajectory = traj;
        ac_->sendGoal(goal);

ac_ is previously created as:

   ac_=new actionlib::SimpleActionClient<control_msgs::FollowJointTrajectoryAction> ("follow_joint_trajectory", true);


I suppose that there is something wrong in the empty trajectory creation.
Any suggestions?

Thanks in advance,

[Thomas Timm Andersen]

Teresa,

Thanks for your feedback. I'm glad to hear now from several people that the driver works out of the box.

The correct way to stop the robot while executing a trajectory is not to send another goal with an empty trajectory. Rather you should cancel your previous goal request with a call to ac_->cancelGoal(); .

Nevertheless, your call should not make the driver crash, but rather it should be rejected by the driver. Thanks for the bug report, I have pushed a new version to github that should fix this.

/Thomas

[Teresa Seco]

Hello again,

Thank you very much for your answer. I tried to use ac-->cancelGoal() as you suggested but it does not work properly. I send a trajectory and during the movement of the robot I call to cancelGoal but the robot does not stop and when finishes this error arises:

[ INFO] [1444373239.506545332]: on_cancel
[ERROR] [1444373239.506628723]: To transition to a cancelled state, the goal must be in a pending, recalling, active, or preempting state, it is currently in state: 3

Any suggestions?

[Thomas Timm Andersen]

Teresa,

Try pulling the latest version from github now. I've just found a few bugs in my goal handling, but that should be sorted out.
If it still doesn't work, could you please share your full code? That way I can hunt down what is wrong.

Best
Thomas

---

From: swri-ros...@googlegroups.com [swri-ros...@googlegroups.com] on behalf of Teresa Seco [tse...@gmail.com]
Sent: Friday, October 09, 2015 08:50
To: swri-ros-pkg-dev
Subject: [ROS-Industrial] Re: New Universal Robot driver

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

[Teresa Seco]

I've just check the new version and it works!

Thank  you very much Thomas. We need to move the UR10 robot as fast as we can and I have some issues about stopping the robot at higher speeds. I will come back to you if I had some doubts or other issues about the driver (if you don't mind).

Best regards,

Teresa

[Michael Wojtynek]

Hello Tim,

thank you for contributing the new modern ur driver. I played around a bit and I like that it is possible to move the robot in freeride mode while the driver is running. Great Job!

As I can see there three ways to control the robot:

1) via MoveIt! on follow_joint topic...
2) via ros_control
3) vis movej and movel from the ur_script

Which way would you recommend to use your driver, if I like to read the joint angles, do some computation and set new joint angles after computation? In this case I would like to reduce, or let us say exclude, ROS dependencies as much as possible.

Another question that I'd like to ask is about ROS control. What are you using on the server side (ur control box)? Is it the ur-c-api stack from Kelsey Hawkins?

King regards,
Michael

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

-- 
M.Sc. Michael Wojtynek
Phone +49-521-106-2931
Research Institute for Cognition and Robotics (CoR-Lab)
Bielefeld University                 

[Thomas Timm Andersen]

Hello Michael,

 

Thanks for your feedback. It is nice to hear from several people that the driver works in the wild :)

 

You are almost correct; the /follow_joint_trajectory topic can be used both with and without MoveIt. This small difference is key to you I guess, as publishing to this ActionLib topic will allow you to do what you describe.

 

I am uncertain, though, if what you actually want to do is to send joint speed instead of position; it sounds like you want to do visual servoing. If that is the case, you should use the fourth control way, which you missed: publishing velocity commands to the /joint_speed topic.

 

Also, which method to recommend depends on your application. How often you expect to send new positions (or speed?) is the key parameter.

• If you want to read joint angles, compute and then send a trajectory and wait to do new calculations until the robot is at a standstill again, you should as said use the /follow_joint_trajectory topic
• If you want to do visual servoing, you should use the /joint_speed topic
• If you want to stream positions to the controller without waiting for the robot to stop, you should use the position based ros_control approach. This might require that you write your own controller. I haven't played that much around with ros_control, so without more knowledge of what you want to achieve, I can't say.

 

It is not necessary to install anything on the ur control box to use ros_control and the driver has nothing to do with the ur-c-api. It exclusively relies on URScript commands and thus can be used on a stock controller without any setup (except network obviously)

 

 

Best regards

 

Thomas Timm Andersen

 

[Teresa Seco]

Hello again,

We are working with the new driver and it works properly. In our application we need to use the configurable inputs/outputs  . The state of general inputs/outputs is accesible with the topic /ur_driver/io_states and the service /ur_driver/SetIO provides the ability to set the outputs. Does the new driver provide any service/topic to access  the configurable i/o? 

Best regards,

Teresa

[Thomas Timm Andersen]

Hello Teresa

The states of the configurable I/Os are also available on the /ur_driver/io_states topic, it is digital pin 10 - 17.

You were supposed to be able to change the configurable IO with the service as well, but apparently that doesn't work.
I'll fix that in the next update, but until then you can toggle the configurable I/O by publishing the string "set_configurable_digital_out(x, True)", where x is the output nr (0-7), to the topic /ur_driver/URScript.
Remember that URScript is based on Python, so True/False should be written with a capital starting letter.

Let me know if you need further help

Best regards
Thomas

---

From: swri-ros...@googlegroups.com [swri-ros...@googlegroups.com] on behalf of Teresa Seco [tse...@gmail.com]

Sent: Thursday, December 03, 2015 08:58
To: swri-ros-pkg-dev
Cc: mwoj...@cor-lab.uni-bielefeld.de
Subject: Re: [ROS-Industrial] New Universal Robot driver

[Thomas Timm Andersen]

FIY

I've pushed a new version to github, so now it should be possible to change the configurable outputs by using the set_io service (use pin 0-7 for standard output, pin 8-9 for tool output and pin 10-17 for configurable output)

best regards
Thomas

---

From: swri-ros...@googlegroups.com [swri-ros...@googlegroups.com] on behalf of Thomas Timm Andersen [tt...@elektro.dtu.dk]
Sent: Thursday, December 03, 2015 10:39
To: swri-ros...@googlegroups.com
Subject: RE: [ROS-Industrial] New Universal Robot driver

[Teresa Seco]

Thank you very much Thomas, it works!

Best regards,

Teresa

[Hemes]

Hey Thomas,

First of all, thanks for sharing your work.  I have a 3.1.16916 UR10 and am happy to see the serialization stuff get addressed.

I am, however, having an issue in getting the robot to move using MoveIt/RViz with the motion planning plugin.  Everything starts up OK and I can drag the goal around and plan but when I hit 'Execute' the driver outputs the text "on_goal" and then just sits there unresponsive.  The Run tab on the UR pendant shows a status of 'Running' as soon as the trajectory execution is requested but then nothing.

This is my first attempt at using ROS with the real robot so maybe I am doing something wrong?

Thanks,
Brett

The exact commands I used to start everything are:
1) > roslaunch ur_modern_driver ur10_bringup.launch limited:=true robot_ip:=IP_OF_THE_ROBOT
2) > roslaunch ur10_moveit_config ur5_moveit_planning_execution.launch limited:=true
3) > roslaunch ur10_moveit_config moveit_rviz.launch config:=true

And the outputs from the various terminal windows is as follows:
Window 3:
...
ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[rviz_ubuntu_15648_8205002294007409301-1]: started with pid [15666]
[ INFO] [1451421488.223678436]: rviz version 1.11.10
[ INFO] [1451421488.223790030]: compiled against OGRE version 1.8.1 (Byatis)
[ INFO] [1451421488.446035939]: Stereo is NOT SUPPORTED
[ INFO] [1451421488.446972992]: OpenGl version: 2.1 (GLSL 1.2).
[ INFO] [1451421493.594535994]: Loading robot model 'ur10'...
[ INFO] [1451421493.594657015]: No root joint specified. Assuming fixed joint
[ INFO] [1451421493.976187208]: Loading robot model 'ur10'...
[ INFO] [1451421493.976275737]: No root joint specified. Assuming fixed joint
[ INFO] [1451421494.249431537]: Starting scene monitor
[ INFO] [1451421494.257448572]: Listening to '/move_group/monitored_planning_scene'
[ INFO] [1451421495.646130624]: Constructing new MoveGroup connection for group 'manipulator' in namespace ''
[ INFO] [1451421496.495152767]: Ready to take MoveGroup commands for group manipulator.
[ INFO] [1451421496.495363693]: Looking around: no
[ INFO] [1451421496.495491887]: Replanning: no


Window 2:
...
[ INFO] [1451421507.112102575]: ParallelPlan::solve(): Solution found by one or more threads in 0.003420 seconds
[ INFO] [1451421507.112798188]: SimpleSetup: Path simplification took 0.000365 seconds and changed from 3 to 2 states
[ INFO] [1451421508.430444586]: Received new trajectory execution service request...

Window 1:
...
core service [/rosout] found
process[robot_state_publisher-1]: started with pid [14644]
process[ur_driver-2]: started with pid [14645]
[ INFO] [1451421508.432895672]: on_goal

[Hemes]

I tried this with the simulator (3.1.18024) and it works fine. Maybe the issue is related to my robot's software version? If I upgrade, what version would you recommend? I was thinking either the newest 3.1 or the newest 3.2.

Thanks
Brett

[Thomas Timm Andersen]

As noted in the readme for the ur_modern_driver, the driver has only been tested with version 3.1.18024, not with anything in the 3.2 range (yet)

Also, on the UR support firmware download page, UR recommends that users only update to 3.2 if they absolutely needs it.

So yes, I would recommend that you update your robot's firmware to version 3.1.18024 and see if that fixes your problem. (prior 3.1.xx versions are known to have bugs in the network communication)

Best regards
Thomas

-----Original Message-----
From: swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com] On Behalf Of Hemes
Sent: 2. januar 2016 16:03
To: swri-ros-pkg-dev
Subject: [ROS-Industrial] Re: New Universal Robot driver

[Hemes]

Thomas,

I updated and got the same error.  After some digging I found that the driver was hanging on the accept() call waiting for the return port connection after downloading the URScript code.  The underlying issue was with the URScript socket_open() command in the downloaded code.  The way my network was setup (ROS running in virtual machine on the guest OS), the driver could see the robot but the robot could not see ROS.  I added a network adapter to my virtual machine with the same subnet as the controller and now everything works.  Perhaps a quick check of the socket_open return value to test for success and respective popup on error would be a good addition?

That said, I have the driver working using real hardware with 3.1.18024 but the update wasn't the root cause of the issue.

Thanks,
Brett

[ryan....@gmail.com]

Dear Thomas,

Thanks for your work. I am quite new to ROS and I have the following questions.

1. is that I can just use your ur_modern_driver to drive my real ur3 robot arm to move?

2. If yes, could you provide some guidelines to me to get it work since I am stuck in the step of
  
    roslaunch ur3_moveit_config ur3_moveit_planning_execution.launch limited:=true
   
    and don't know what to do next (though I have found the tutorial of old ur driver
   
    (http://wiki.ros.org/universal_robot/Tutorials/Getting%20Started%20with%20a%20Universal%20Robot%20and%20ROS-Industrial).
   
    But, it seems that some of files mentioned in that tutorial does not exist in the package you provide, such as

  
  the text_move.py file in rosrun ur_driver test_move.py

3. If no, could you kindly provide a simple tutorial for us to know how to execute your ur_modern driver.

Thanks.

Thomas Timm Andersen於 2015年9月25日星期五 UTC+8下午7時36分58秒寫道：

[Thomas Timm Andersen]

Hello

 

1: Yes, you can use the ur_modern_driver to control your real UR arm. It works with both UR3, UR5 and UR10 robots.

 

2. The initial idea was to use the test_move.py file from the old driver. As the new driver is more strict towards requiring properly defined trajectories, the old test_move.py script doesn’t work.

Therefore I have just added a test_move.py file to my repository.

 

So start by updating your clone by typing roscd ur_modern_driver;git pull;roscd;cd ..;catkin_make;source devel/setup.bash in a terminal.

 

Then, to start using the arm, make sure you have two terminals open.

 

In the first terminal, you execute roslaunch ur_modern_driver ur3_bringup.launch robot_ip:= IP_OF_THE_ROBOT

 

In the second terminal, you execute rosrun ur_modern_driver test_move.py

Once you have verified that the robot can move to the specified poses, press y, then enter, and the robot should start to move.

 

 

If you want to follow along in the tutorial that you have linked to (or any other tutorials written for the old driver), you should just use ur_modern_driver instead of ur_driver or ur_bringup whenever these names are specified. Everything else is the same as they don’t depend on the driver (i.e. you should still use the ur5_moveit_config package).

 

Best regards

 

Thomas

 

From: swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com] On Behalf Of ryan....@gmail.com
Sent: 19. februar 2016 04:22
To: swri-ros-pkg-dev
Subject: [ROS-Industrial] Re: New Universal Robot driver

 

Dear Thomas,

--

[ryan....@gmail.com]

Dear Thomas,

Thanks for your instruction. 

I have tried to implement the ur_modern_driver in this afternoon, and found that it seems to be work quite well in the simulation. 

Indeed, my controller version is 3.2x. Hence, I am not sure if the robot arm can be commanded by ur_modern_driver package. 

Anyway, I will have a try tomorrow! Hopes everything goes smooth.

Best Regards,

Ryan

Thomas Timm Andersen於 2016年2月19日星期五 UTC+8下午7時21分13秒寫道：

[ryan....@gmail.com]

Dear Thomas,

Thanks for your advice. Now, real robot arm ur3 with controller 3.2.19293 can be driven by ur_modern_driver. 

Keep in touch!

Best Regards,

Ryan

ryan....@gmail.com於 2016年2月19日星期五 UTC+8下午9時59分08秒寫道：

[ryan....@gmail.com]

Dear Thomas, 

Thanks for your help last time. Now, I just completed verifying the inverse kinematics of UR3 and I would like to write some code in cpp for driving the robot. Yet, I see the demo code is written in py. Then, I have tried to search through the internet and find the following link which is written in cpp. 

http://clopema.felk.cvut.cz/redmine/projects/clopema/wiki/Sending_trajectory_to_the_controller

However, I am not sure whether this set of code work well with your new driver. Could you provide me some directions if I want to drive the robot arm in cpp environment? Thanks.

Best Regards,

Ryan

[Thomas Timm Andersen]

Ryan,

 

There are a few different options.

 

The link you’ve found gives some useful information, but is quite out-dated.

 

Generally, I would recommend you look at how actionlib works ( http://wiki.ros.org/actionlib_tutorials/Tutorials ) The driver has an action server, so you need to write an action client.

 

ROS-I have many great tutorials, you should have a look at http://aeswiki.datasys.swri.edu/rositraining Note that it is written for the old driver, but (just like with the other examples) just remember to substitute ur_driver with ur_modern driver, and you should be good. I haven’t gone through them myself, but they seem to be focused around MoveIt, so not the simplest way to do things.

 

Finally, you could take the python file and try to understand how it works and then converting it to cpp. This approach will probably give you the best foundation to work from.

 

I don’t have any cpp code at hand, so you’ll have to do the grunt work yourself. Just remember, joint positions are available on the /joint_states topic as sensor_msg/JointState message type, and the action interface is available as control_msgs/FollowJointTrajectoryAction action type on the /follow_joint_trajectory topic.

 

Best regards

Thomas

 

From: swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com] On Behalf Of ryan....@gmail.com
Sent: 23. februar 2016 11:25
To: swri-ros-pkg-dev
Subject: [ROS-Industrial] Re: New Universal Robot driver

 

Dear Thomas, 

--

[ryan....@gmail.com]

Dear Thomas,

Thanks for your advice. I have tried to follow your advice and have a look on the tutorial you suggested. 

Now, I am trying to write my own code in cpp or py. 

But, I am struggling how to link my code to ur_modern_driver as the test_move.py done.

I know that if I want to use rosrun for executing my code, I need to add add_executable(example example.cpp) something like that in CMakeLists.txt.

But, I have checked the CMakeLists in ur_modern_driver, I even cannot find a keyword "test_move.py". What should I do to link up my code to your driver? Could you give me some directions?

Many Thanks.

Best Regards,

Yu Hoi Fai

Thomas Timm Andersen於 2016年2月23日星期二 UTC+8下午6時39分50秒寫道：

[Thomas Timm Andersen]

Yu Hoi Fan,

 

Please have a look at the getting started tutorials for ROS (http://wiki.ros.org/ROS/Tutorials ).

As stated in these, you don’t have to add anything to the CMakeList-file when using python files.

 

The tutorials also teaches you all you need to know about writing ROS nodes in cpp and adding them to the CMakeList-file.

 

Note that you shouldn’t link your code to ur_modern_driver. Make your own package that run_depends on ur_modern_driver, have your node subscribe to joint_states and send actions to the follow_joint_trajectory interface.

 

Best

[ryan....@gmail.com]

Dear Thomas,

Thanks for your advice again. After about millions of trials, I would like to seek your help. I try to follow your advice and make my package run depends on ur_modern_driver in CMakeLists.txt (attached in this e-mail). I try to use cmd catkin_make for compiling the cmake file. However, it keeps on telling me that

  Could not find a package configuration file provided by "ur_modern_driver"
  with any of the following names:

    ur_modern_driverConfig.cmake
    ur_modern_driver-config.cmake

I also have tried to include the following before project()
SET(CMAKE_INSTALL_PREFIX <home/astri/ur_modern_driver-master/devel/share/ur_modern_driver/cmake>)

nothing can help. it drives me crazy. Thanks

Best Regards,
Ryan

Thomas Timm Andersen於 2016年2月25日星期四 UTC+8下午4時21分31秒寫道：

[Teresa Seco]

Hello Thomas,

I have been working with your driver and it works really well but now I am facing another issue. We need to send another pose while the trajectory of the previous one has still been executed, but an error arises:

[ERROR] [1435841315.524423483]: Cannot push a new trajectory while another is being executed

If the execution is asynchronous (asynExecute(plan) , why it is not possible to send a different trajectory before finishing the previous one?

Does the ur10 driver allow this?

Best regards,

Teresa

[Thomas Timm]

Hi Teresa.

The driver does indeed support it, and I am fairly sure that the error you see is not from the driver, but rather from whatever node is bulldog and sending the trajectory to the driver, i.e Moveit!
The reason being that I dont recall having that error in the driver (like I said, you can send a new trajectory while another is executed, so such a message wouldn't make sense to have), but I am out of office the rest of the month, so I cant verify it at the moment.

I'm afraid I can't help you any further, not wothout knowing what you use to build and publish your trajectory.

Best regards
Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swri-ros-pkg-dev/qo9pu4PbEJY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.

[Teresa Seco]

Hi Thomas,

I am using moveit, so I sent a message to the moveit group too, but  I wanted to ensure that this was not a driver issue.

This is the link of my post to moveit group, with the piece of code I use to send the target:

https://groups.google.com/forum/#!topic/moveit-users/ZkXCZT7M_gA

If you need more information about the anything, please let me now and I would try to do a detailled description of the code.

Thank you very much for your help!

Teresa

[np0...@bristol.ac.uk]

Hello Thomas,

Thank you for your work!

I would like to be able to implement force control on the UR5. Is this a possibility with your driver? Specifically I'd like the end effector to exerted specified linear forces.

Currently I'm using moveit to control the robot although I can't see that this has the capabilities to perform force control. It seems to me that perhaps the way to do it is by sending urscript commands to the robot;

The driver also makes it possible to send URScript commands from ROS to the robot

I have read that force control can be done with URScript.

Would this be your advice? Would you mind advising me on how to set it up?

Many thanks,

Nick

[Thomas Timm Andersen]

Nick,

 

You are right in that it is not possible in MoveIt!.

 

There are two methods for doing force control

 

1.       Use the internal force sensor and URScript, as you suggested
I don’t have much experience with this, try have a look at http://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/seek-using-force-16117/ and http://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/urscript-dynamic-force-control-20571/
Then use the URScript interface on the ur_modern_driver to publish your URScript commands to the robot.

This is probably the easiest way, especially if you don’t have a good understanding of control theory.

 

 

2.       Write your own controller and control the robot with velocity commands.
This approach has the advantage of not depending on the internal force torque sensor, although it is possible.
With this approach, you subscribe to a topic with WrenchStamped data (either from the robot or from other FT sensor manufactures like Robotiq or ATI), compare the actual force with the desired in the directions you want force control and then calculate the inverse jacobian to get the target velocities.
These are then either sent directly to the joint_speed interface or sent to a ros_control joint_velocity velocity_controller interface.
We’ve had different students succeed in this approach (not using ros_control though).

 

Best regards,

Thomas

 

 

 

From: swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com] On Behalf Of np0...@bristol.ac.uk
Sent: 9. maj 2016 11:44
To: swri-ros-pkg-dev
Subject: [ROS-Industrial] Re: New Universal Robot driver

 

Hello Thomas,

--

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.

[Nick Pestell]

Thanks for the quick response and great advice.

Perhaps this is a rather obvious question but why is its particularly advantageous not to rely on the internal force torque sensor?

Cheers,

Nick 

[khayrd...@gmail.com]

Hi Thomas Timm Anderse,

I'm triying tu use the ur_modern_driver, The Problem that i developed a controller work good with gazebo but when i shift to the real robot i've noticed that in the ur_hardware_interface there is no <hardware_interface::EffortJointInterface>, So i can't run my own controller.

I'm triying to add this class (<hardware_interface::EffortJointInterface>) in the hardware_interface but i don't know how can i add it in the (void UrHardwareInterface::write()).

Please give me some advices about this.

 

Best regards

[ravip...@gmail.com]

Hello Timm

As you mention that we can do visual servoing dorectly using the ros topic

• /joint_speed : Takes messages of type trajectory_msgs/JointTrajectory. Parses the first JointTracetoryPoint and sends the specified joint speeds and accelerations to the robot. This interface is intended for doing visual servoing and other kind of control that requires speed control rather than position control of the robot. Remember to set values for all 6 joints. Ignores the field joint_names, so set the values in the correct order.

But in this way how do you give the streaming joint velocity values for movement because as far as i know the message type trajectory_msgs/JointTrajectory needs number of waypoints to be known beforehand.
How do i give streaming joint velocity values

[Nick Pestell]

Hi Thomas,

Is there an easy way to implement velocity control in Cartesian space using your driver, short of writing my own controller? Similarly I'd like to be able to execute a constant linear velocity.

Currently I'm using moveit and sending joint trajectories to the robot using the followjointtrajectory action server, however I can't seem to achieve a constant Cartesian velocity using this method. I'm only able to achieve a desired average velocity using the time_from_start field in JointTrajectoryPoint.msg.

Thanks,

Nick

[diarodr...@googlemail.com]

Hi Thomas and Nick,

I am also interested in implementing force control with the UR5, more specifically hybrid force/motion control. I would like to write my own controller but for me it is not clear how can I transform the forces into velocities using the inverse of the jacobian, using the transpose of the jacobian I can get the joint torques and using the direct dynamics I could get accelerations and consequently velocities, however direct dynamics is computationally expensive and probably it is not the way to go.

@Tim could you please tell me how to get the target velocities to send them to the joint_speed interface?

@Nick, did you succeed implementing the force control?

Thanks in advance,

Diego

[Yalun Wen]

Hey,

I wonder if you could share some code on how to send velocity message to the joint_speed interface. I tried different method but it didn't work well, I have to include accelerations as well in the message. Is there a way I can keep a constant velocity here?

在 2015年9月25日星期五 UTC-5上午6:36:58，Thomas Timm Andersen写道：

[ravip...@gmail.com]

Hey mitch 

I also was trying out similar thing to publish velocity to joint_speed interface.....

The one solution i found was publishing the string on /ur_driver/URScript

try it

[Mitch]

Hey,

Do you get any luck publishing to joint_speed interface?

在 2017年6月26日星期一 UTC-5上午8:31:47，RAVI PRAKASH写道：

[9uh...@gmail.com]

Hy Teresa

We recently purchased a brand new UR 10 (Firmware newer than 3.x) which we control over ros with the modern driver. We are able to command the robot, but only for extreme slow movements. our problem is, that there is some kind of lag in the motion which at some point is corrected with enormeous velocities and accelerations. The "correction movement" can be so fast, that the ur-controller goes into protective stop.

The end poses of the effector if a trajectory is executed whitout protective stop are accurate (we measured them with a 6D Tracker from creaform)
In a week we need to perform a demo for our Investors, and start to worry seriously. till now we tried the following:

-changed the host Computer to a Xeon with 12cores and 32Gigs of ram

-added a additional Network Card which s dedicated to speak to the Robot, over direct cabling, the other is used for communication with our Software on anoter host

-we played around with the pid values-> nearly no effect

-we played around with the update rate of the ros Controller of modern Driver: from 1Hz to 125Hz nothing helped

-we played around with the load and center of mass on the ur Controller, this helped marginal

-we made our trajectories more coarse: from hundret points down to two --> a lot of points seems to make the problem worse

By the way: The ros Setup in concern, is the same which we use for working with a Kuka kr16. only difference is the Controller, and the ur driver

Do you have an idea for the underlying Problem, or may be a solution to it?

If you like we can pay you for your support. The solution is worth a lot for us!

Ivo Aschwanden

Leader Smart Industries

Super Computing Systems AG

Zürich/Swiss

ivo.asc...@scs.ch

Am Donnerstag, 8. Oktober 2015 12:59:10 UTC+2 schrieb Teresa Seco:

Hello,

First of all, congratulation for this new ur driver implementation. I am using it with an UR10 and it works really well. I send different trajectories using the action server with no problems.

I have a problem when I try to stop the robot movement by sending an empty trajectory, the driver crashes. This is a piece of my code:

        trajectory_msgs::JointTrajectory empty;
        empty.joint_names.push_back("shoulder_pan_joint");
        empty.joint_names.push_back("shoulder_lift_joint");
        empty.joint_names.push_back("elbow_joint");
        empty.joint_names.push_back("wrist_1_joint");
        empty.joint_names.push_back("wrist_2_joint");
        empty.joint_names.push_back("wrist_3_joint");
       
         empty.header.stamp = ros::Time::now();

       //Create goal and send it to the controller
        control_msgs::FollowJointTrajectoryGoal goal;
        goal.trajectory = traj;
        ac_->sendGoal(goal);

ac_ is previously created as:

   ac_=new actionlib::SimpleActionClient<control_msgs::FollowJointTrajectoryAction> ("follow_joint_trajectory", true);


I suppose that there is something wrong in the empty trajectory creation.
Any suggestions?

Thanks in advance,

El viernes, 25 de septiembre de 2015, 13:36:58 (UTC+2), Thomas Timm Andersen escribió:

[Neda]

Hello Thomas.
I am UR5 user and after using different communication way (recommended by UR) I decided to change to your driver through ROS kinetic, and it was great. But my main problem is that I have G-code file as a path and I want to interpret it for UR5 to move using ur_modern_driver. I know there is Descartes package in ROS-I for the path following but I am not sure how can I embed it in ur_modern_driver. Do you have any suggestion for defining G-code path in your driver?