ros-industrial / universal_robot Goto Github PK

The CMakeLists.txt of some packages in the groovy-dev branch are missing install targets. This makes it impossible to use them in a install space.

Packages:

• ur_bringup
• ur_description
• ur_driver
• ur_gazebo
• ur_kinematics

Rviz shuts down immediately after it comes up in hydro with little information about the problem. Turning on debug gets:
Program received signal SIGSEGV, Segmentation fault. 0x00007fff987983b3 in dynamics_solver::DynamicsSolver::DynamicsSolver(boost::shared_ptr<moveit::core::robotmodel const=""> const&, std::string const&, geometry_msgs::Vector3_std::allocator const&) () from /opt/ros/hydro/lib/libmoveit_dynamics_solver.so

I have found that removing the base_link from the planning group in the setup_assistant makes this function properly. However this was not necessary in groovy.

There are two versions of URDFs for the Universal robots. The bringup scripts automatically load the URDFs based on a limited argument. If set to true the URDF with limited joint motions (-PI to PI) are loaded. These joint limits address path planning limitations in MoveIt.

See #44 for more info.

If the driver launches before the arm is ready, it will crash. It must be launched manually after the arm has been powered up and initialized. This is inconvenient when integrating the arm onto a mobile platform that is controlled by a single power switch.

If the arm is not ready when the ROS master boots, the driver should instead sit idle until the arm is ready to begin accepting commands. The driver could first ping the IP address of the arm at regular intervals, and once ping is successful attempt some sort of handshake.

Command "$ roslaunch ur_bringup ur5.launch robot_ip:=..." starts without any error and connects to UR5.

When doing "$ ./test_move.py" roslaunch server replies:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
...
TypeError: Invalid number of arguments, args should be ['positions', 'velocities', 'accelerations', 'effort', 'time_from_start'] args are (...).

Hello,

I am trying to generate 'ur5_robot.urdf' from xarco since the version of the 'ur5_robot.urdf' that is in the repo is not current (e.g., contains references to 'libgazebo_ros_controller_manager.so' when it should contain the updated reference to 'libgazebo_ros_control.so' in the latest version of 'gazebo.urdf.xacro'). When I run the following command:

rosrun xacro xacro.py ur5.urdf.xacro > ur5_robot.urdf

I get unexpected output contained in 'ur5_robot.urdf'.

Thanks in advance.

--Noob

Maybe a separate issue for this is better...

Maybe @jrgnicho was right in #92 when he reported a "shaking" of the robot.
For me it is more of a twitching/creaking of the joints, not really constantly shaking with large motion. It's rather very short ticks occuring very infrequently and irregularly (besides the normal humming of the motors).
@jrgnicho: Does this description fit the observations with your hardware?

Could someone third please check and confirm?
As I am out of the office for this week now, I cannot really confirm wether:

• the behavior was there before IO-support was added
• the behaviour is introduced in IO-support set_io service
• the behaviour is introduced in IO-support io_states publishing
• the behaviour is introduced by something else

The ur5 moveit package contains only the "raw/generated" move it files. It should be updated to include ROS-I specific files as specified here: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot

This will allow users to immediately start using the UR5 in moveit.

hey,
I am currently using the URDF file of the UR5 robot from this repository for a gazebo simulation. For the simulation I edited the files to use the new controllers from the ros_controllers package (hydro).

Now the problem/question: Why is each joints effort limited to "10"? This doesn't make any sense. With a limit of 10N the robot isn't even able to lift its own weight. I edited this values so I could move the robot properly in the simulation. I am just curious about this number. Why is it limited to 10?

As per title.

Probably only necessary for UR10 meshes.

Just documenting here (discussion in #88).

The UR10 URDF created by Georgia Tech (Kelsey Hawkins) is visually more impressive than the current version submitted by Fraunhofer IPA. The current version is kinematically and dynamically(maybe) correct so the only improvement would be visual. The UR10 URDF and models can be found here: http://code.google.com/p/gt-ros-pkg/source/browse/?repo=cpl&name=kelsey_sandbox#git%2Funiversal_robot_cpl%2Fur10_description

From this ROS Answers question:

The package.xml file of ur_driver seems to be missing the Python module dependencies required for its execution.

Adding them also allows users installing from source to use rosdep to install all needed dependencies.

I opened this issue in order to record the discussion on the mailinglist on github as well:
https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/1e3A_1BTQWQ

Running hydro-devel @ba8e2270 against ursim results in continuous printing of Warning: 32 is no a valid flag number (sic).

It would appear that the URScript program tries to access flag 32 (see here). As flags run from [0, 31] (according to the v1.8 scripting manual), that is an invalid index.

It does not appear to influence the rest of the driver, but should be fixed none-the-less.

Kelsey Hawkins (Georgia Tech) and Mathias (IPA) have created an analytic solution to the UR arm configuration. The solution is specific to the UR10 but could easily be generalize to all URs with similar arm configurations.

The Care-O-Bot implementation can be found here: https://github.com/ipa-mdl/cob_manipulation/blob/moveit/cob_kinematics/ikfast/src/ikfast_ur10.cpp

The KDL IK struggles to find IK solutions sometimes, so porting this code to the ROS-I version would improve functionality.

As discussed in ros-industrial/ros_industrial_issues#24.

The recently merged WrenchStamped publisher does not seem to initialise the header.frame field to any value. The scripting manual (v1.8, aug 2013) of the UR says:

get_tcp_force()
[..]
The function returns ”p[Fx (N), Fy(N), Fz(N), TRx (Nm), TRy (Nm), TRz (Nm)]”. where Fx, Fy, and Fx are the forces in the axes of the robot base coordinate system measured in Newtons, and TRx, TRy, and TRz are the torques around these axes measyred in Newton times Meters.

(sic).

If done on purpose (not setting the frame name), then this should probably be documented. Otherwise, the correct frame should be set by the publisher.

Hi everyone, I have some troubles working with my UR5, I'm trying to work using the Universal_Robot stack, but until today I'm unable to move it. I cloned the Universal_Robot and Industrial_Core stacks into my catkin work space and after to compilation I followed these instructions:

"To check that the package works with a UR5, set up a catkin workspace and clone the repository into the src/ folder. It should look like ~/catkin_ws/src/universal_robot. Don't forget to source the setup file ($ source ~/catkin_ws/devel/setup.*sh), then use catkin_make to compile. You can then start the driver with the following commands (start new terminals, don't forget to source the setup shell files):

$ roslaunch ur_bringup ur5.launch robot_ip:=IP_OF_THE_ROBOT

$ roscd ur_driver; ./test_move.py"

However when I launched the roslaunch ur_bring the calibration offset doesn't work, even though the UR5 is in home position, furthermore, when i execute the test_move script doesn't do anything else that wait for the connection server.

Somebody knows if I need to do anything else?

I'm working on ROS hydro, and the software on the Robot is version 1.7.10857.

I leave the screen shots of the process.

Greetings and Thanks in advance.

This is certainly not a software issue but I'd like to pose this question to the general UR research community.

I'm currently frustrated with a problem which causes my robot to trigger a high force warning when the arm is in a particular configuration/motion. The stop seems to happen when joints 2-4 are in the configuration shown, the 1st joint is moving around somewhat fast, and often the end effector is moving upwards. You can see some videos of it stopping under the regular controller here:
https://www.dropbox.com/sh/y847lrdxc23pssu/IvN_edc7Ju
It stops under the C API as well. Messing with the TCP weight doesn't help.

Have any of you had any problems like this? Is it reasonable to be moving the robot at this speed?

It's not available in Ubuntu until Raring—that aside, it's way overkill for just parsing urdf. Given the minimal functionality being employed, almost anything would work, but ElementTree has been standard since Python 2.5.

The ideal solution would be if the urdf package provided a Python parser, but that is not the case. Taking this step would make universal_robot releasable into Hydro.

I'm unsure if these exist and I just can't find them, or if they need to be created— either way, the ROS package pages on the wiki should contain (or link to) some basic getting started info, especially for the simulator. I started by adding some skeletal content (based on what I could figure out) to the following:

http://wiki.ros.org/ur_description
http://wiki.ros.org/ur5_moveit_config
http://wiki.ros.org/ur_gazebo

With the instructions I've currently placed on the gazebo page, I can get to gazebo arm, rviz visualization, and planning, but I can't get the gazebo arm to actually execute the plan. Is there a step I'm missing here? If so, it'd be great to have that page made complete.

I am using the UR5 in Gazebo fixed to the ground (and/or fixed to a cylinder fixed to the ground). When doing so, the model wobbles a lot. (The wobbling fades as time goes by.) Is this correct behaviour? Or is it related to rigidly fixing it to the ground? Is there anything I can do to stabilize the simulated model.

<?xml version="1.0"?>
<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="cr_ur5_mounted" >

  <xacro:include filename="$(find ur_description)/urdf/gazebo.urdf.xacro" />
  <xacro:include filename="$(find ur_description)/urdf/ur5.urdf.xacro" />

  <xacro:ur5_robot prefix=""/>

  <link name="world"/>

  <joint name="grouding" type="fixed">
    <parent link="world"/>
    <child link="base_link"/>
  </joint>

</robot>

See also #58: apparently somewhere during the merging of the latest set of pull requests, the updates to the urdfs were not properly merged. They are now not in-synch with the current xacros.

This should be fixed, as people expect those to describe the same robot.

When I attempt to spawn the URDF generated from XACRO (hyrdo-devl), Gazebo hangs and I see an INFO trace indicating that the plugin is waiting on the param server.

:~/catkin_ws/src/universal_robot/ur_description/urdf$ rosrun gazebo_ros spawn_model -file /home/user/catkin_ws/src/universal_robot/ur_description/urdf/ur5_robot.urdf -urdf -z 1 -model ur5

Console trace:

[ INFO] [1397671984.537825418, 611.414000000]: gazebo_ros_control plugin is waiting for model URDF in parameter [robot_description] on the ROS param server.

However, if I load the URDF into the param server under the parameter 'robot_description' prior to spawning, the model appears to spawn as expected.

I use the following to load the param server:

<launch>
 <param name="robot_description" textfile="$(find ur_description)/urdf/ur5_robot.urdf"/>
</launch>

The program that runs on the UR controller reads too many bytes from the socket connection for setting digital outputs. See here. Most times this is not an issue because multiple commands are not typically in the socket buffer (the reference read command only returns the 2 values used for setting digital IO). However, when trajectories and IO are driven from the ROS side simultaneously (i.e. from multiple threads), this can occur. When this does, part of the next message in the buffer is read. This results in several unrecognized command messages being reported in the ROS log (although a more critical failure could be misinterpreting the data as a valid command).

I will submit a PR to address this within the week...but I wanted to document it in the near term.

See ros-industrial/ros_industrial_issues#23.

Just noticed that the Electric and Fuerte versions of the wiki page of the universal_robot stack refers to https://kforge.ros.org/ros_industrial/universal_robot in the Source entry under the Package Summary. AFAIK that host has been taken down quite some time ago (or at least: isn't accesible anymore).

Not sure what it should be, or if we can actually change this though.

If I run roslaunch ur_gazebo ur5.launch there is no joint_state published (rostopic echo /joint_state). Tf only broadcasts one transform. This makes it difficult to test the arm navigation. I am using gazebo (1.0) on Fuerte, I know this stack is for later versions but this probably there also a problem.

Also the link: https://kforge.ros.org/login/?returnPath=/ros_industrial/universal_robot redirects to a login page and the project is not in the list.

The ability to perform manual moves via the teach pendant or move the robot by dragging the end-effector is disabled by the ROS driver. This capability is convenient and should not be disabled when under ROS control. Other ROS-I drivers allow control via the teach pendant. This is actually implemented at the controller level, but functionally the UR should act the same.

Hello,

I am trying to use my UR5 through ROS with this package, and I cannot make it work. The software on the UR5 is version 1.7.10074. When I launch driver.py, an exception is thrown, then "Waiting to program" is repeatedly printed (see below).

I have not found much information in either the UR wiki or URScript doc on whether anything needs to be done on the robot side to enable remote script execution. At the moment, I simply start the robot and leave it in its default state.

I'd be grateful for any sort of pointer that would help me progress.

Copy of terminal output (ur5 is an alias for 192.168.0.2, the IP of the robot. Pinging ur5 does work):

$ ./driver.py ur5
Setting prefix to
Disconnected. Reconnecting
[INFO] [WallTime: 1375956449.773380] Programming the robot
Waiting to program
Exception in thread UR5Connection:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 504, in run
self.__target(_self.__args, *_self.__kwargs)
File "./driver.py", line 183, in __run
self.__on_packet(packet)
File "./driver.py", line 137, in __on_packet
state = RobotState.unpack(buf)
File "/opt/ros/groovy/stacks/universal_robot/ur5_driver/deserialize.py", line
220, in unpack
raise Exception("Unknown package type: %i" % ptype)
Exception: Unknown package type: 7
Waiting to program
Waiting to program
Waiting to program

Hi all,

The behaviour of the simulated UR5/10 does not replicate the behaviour or the real robots. This is due to 3 problems at least:

1. The parameters of the simulation (geometric and dynamic) do not replicate the real robot's params
   • e.g. the dynamic parameters of the ur5/10 which are currently used for the simulation (in files ur5.urdf.xacro and ur10.urdf.xacro) do not mimic the real robots' parameters. They were found making simple assumptions of the robot (i.e. the inertia are computed as the inertia of homogeneous cylinders...)
2. The low-level control of the simulation does not replicate the low-level control of real robots
   • The simulation uses PID based on ros_control, but it is not sure what low-level control method is used by the real robots
3. The simulation may not fully reproduce the behaviour of the real world's physics
   • This is especially true as the physics engines used by gazebo (ODE, bullet...) are RT engines not aimed at accuracy (they trade accuracy off for speed of computation)
   • This question relates to this post in ROS answers

This is a complex problem which outreached the boundaries of the UR world, and we cannot expect to solve it all here. Though we can certainly improve the situation and this is what this post is aimed at.

Kind regards,

Antoine.

The original UR driver was written with several references to the UR5 specifically. These include variable and class names. The actual UR driver is independent of the type of robot (at least the two current types, ur5 & 10). The names of classes and variables should be changed to reflect this robot Independence.

As per subject:

socket_send_int(get_analog_out(0)*1000000)

A new MULT_something should be added.

Hello!

I'm trying to automatize installing process for Fraunhofer IPA robots with ROS hydro (for groovy exists). So I forked this repo and made new hydro-dev branch, so if you are interested in this please open new branch so I can make pull request and than people will pull things from this (upstream) repo during installation.

Thanks!

The tool0 frame should be added to the UR10 & 5 URDFs. See ros-industrial/ros_industrial_issues#24.

The default moveit acceleration values in the move config packages (here) do not allow the universal to reach full speed (even in very long moves). Some limited testing shows that increasing the allowed acceleration results in much faster motion. However, safety stops result at higher acceleration limits (10 x current values).

Has anybody encountered this, and if so, Is there a way to address this issue, as the current acceleration values result in very slow motion?

I believe I can duplicate this bug, I'm posting the conversation from earlier below for reference.

https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/i5iBOdwMP5E

Hello,

I'm trying to set up a simple_message connection between my workstation and UR10 according to documentation. I compiled the server's side on the controller box and I'm trying to connect from my workstation. Unfortunately, I get this on the client's side:

[ INFO] [1391695157.810595--------------------------------------------------------621]: UDP client connected
[ERROR] [1391695157.810629757]: Failed to receive message
[ERROR] [1391695157.810663254]: Failed to receive incoming message
[ WARN] [1391695157.810695275]: Send failure, no callback support
[ INFO] [1391695157.810729612]: Connection failed, attempting reconnect

I could see the packets coming and going (see the screenshot) and I'm puzzled why simple_message reports it sees none. What does it mean when the data field is just "FF"?
I'm using the latest hydro on my PC and the latest C-API (1.8) on the controller box.

Thanks,
Nikita

@gavanderhoorn
Nikita,

I'm not sure what is causing your problem, but there is a wireshark dissector for simple message that may help. See http://wiki.ros.org/simple_message#Wireshark_Protocol_Dissector

I know there are others on this list that are more familiar with the C-driver. Hopefully they will respond.

@shaun-edwards

The screenshot shows that the datagrams contain only a single byte of
data. The dissector is not going to be much help here.

Additionally, it seems the ur driver uses port 11003, which is not in
the standard set of ports for which the dissector registers itself.
You'll have to right click on a packet on that port and select 'Decode
As', then scroll down and select 'SIMPLEMESSAGE' from the list.

I'll create an issue to add the port.
Shaun

@shaun-edwards
Nikita,

It sounds like a network configuration issue. Could describe your setup. What is the PC IP address, the controller address. What versions of the software are you using (source-branch or debian).

The UDP server/client initiate a handshake as part of the connection (see https://github.com/ros-industrial/industrial_core/blob/hydro-devel/simple_message/src/socket/udp_client.cpp#L109 ). This might be the communications that you are seeing.

There are some debug messages in the udp client/server that may help solve the problem. On the ROS side, you would just need to enable debug logging. On the controller side you would have to recompile and enable the logging here ( https://github.com/ros-industrial/industrial_core/blob/hydro-devel/simple_message/include/simple_message/log_wrapper.h ).

Shaun

@kphawkins
Have you set the desktop's IP on the tablet interface to be the default gateway? I've only ever used a direct line as the configuration. If you're running things through a router/network, you might run into issues.

This does look like a networking problem, those packets are not consistent size-wise with any of the UR simple messages, so I'd bet they're the handshake pings.

For the record, my network setup has the tablet as having:
IP: 192.168.5.100
Netmask: 255.255.255.0
Gateway: 192.168.5.101

And the desktop:
Manual Config
IP: 192.168.5.101
Netmask: 255.255.255.0
No gateway

Then, when running, I use the robot_ip 192.168.5.100 .

You might try disabling any other network adapters before trying again, there might be a routing problem.

Well, it's all in the same network (10.7.7.0/24), hence no routing is taking place, only switching. So, does ur_c_api_bringup work for you with a crossover cable?

@shaun, thanks. I'll try turning on debug messaging. There is nothing extraordinary in my setup. Controller has an IP .13 and the PC is running Ubuntu 13.04 and has an IP .145 (from the screenshot).

Sorry for a late reply,
Nikita

There are several launch files that have been marked as deprecated (see #51). We should verify that they have been marked deprecated for at least one release cycle and then remove them.

Invalid character in ForeArm.dae mesh file makes it unreadable under the "UTF-8" character encoding.

The test command from the readme file which runs the moveit_planning_execution.launch file does not work because this file does not exist. Is there a version of this file somewhere which allows for control of a UR5 arm through rviz?

According to the description this stack is for versions above Hydro. But I think the gazebo version is not changed yet.

The world launch should be changed to:
<include file="$(find gazebo_ros)/launch/empty_world.launch" />

The spawn script should be changed to:

<node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-param robot_description -urdf -model ur5" />

The plugins should be changed also (investigating that now):

Error [Plugin.hh:127] Failed to load plugin libgazebo_ros_controller_manager.so: libgazebo_ros_controller_manager.so: cannot open shared object file: No such file or directory
Error [Plugin.hh:127] Failed to load plugin libgazebo_ros_power_monitor.so: libgazebo_ros_power_monitor.so: cannot open shared object file: No such file or directory

These were recently added and should not have been there. Replacements have been added to the launch subdirectory in 328498b.

Switching to Hydro, the default planner doesn’t seem to work that well. It takes much longer to come up with solutions if it does at all, where in Groovy this wasn’t an issue. Perhaps the default constraints have changed from Groovy

Just a quick question. I'm not able to easily test it out myself, but does the package support multiple arms? Naturally I'd create a custom launcher that separately names the topics published by the two arms.

The warning message introduced in 0419780 is impossible to disable in the current implementation. Ideally, the user would be able to suppress it using a configuration parameter (either via a launchfile or through support for dynamic reconfigure).

Perhaps warning interval should also be configurable (currently hard coded at 1 second).

Hi,

I recently tried to utilise this package on a UR5 Robot running V1.8.11281 of their software which was released on Aug 07 2013. The result was very similar to that described in issue 9, caused by changes between V1.6 and V1.7 so it appears this is similar. It also reported an unknown package type, so I guess more have been added.

#9

Has anyone else tried running the package on a V1.8 robot? This was the first time I'd tried this package, I assume I would have had more luck on a robot running V1.7.

Here is the console output:

linux@ubuntu:~$ roslaunch ur_bringup ur5.launch robot_ip:=192.168.0.102
... logging to /home/linux/.ros/log/4e12e310-2033-11e3-8faa-b888e3f3f398/roslaunch-ubuntu-3991.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://ubuntu:48369/

SUMMARY
========

PARAMETERS
 * /robot_description
 * /robot_ip_address
 * /rosdistro
 * /rosversion
 * /tf2_buffer_server/buffer_size

NODES
  /
    robot_state_publisher (robot_state_publisher/state_publisher)
    tf2_buffer_server (tf2_ros/buffer_server)
    ur_driver (ur_driver/driver.py)

ROS_MASTER_URI=http://localhost:11311

core service [/rosout] found
process[robot_state_publisher-1]: started with pid [4013]
process[ur_driver-2]: started with pid [4030]
process[tf2_buffer_server-3]: started with pid [4031]
Setting prefix to 
[WARN] [WallTime: 1379489595.494830] No calibration offset for joint "shoulder_pan_joint"
[WARN] [WallTime: 1379489595.496176] No calibration offset for joint "shoulder_lift_joint"
[WARN] [WallTime: 1379489595.497629] No calibration offset for joint "elbow_joint"
[WARN] [WallTime: 1379489595.499230] No calibration offset for joint "wrist_1_joint"
[WARN] [WallTime: 1379489595.501033] No calibration offset for joint "wrist_2_joint"
[WARN] [WallTime: 1379489595.503084] No calibration offset for joint "wrist_3_joint"
[ERROR] [WallTime: 1379489595.503234] Loaded calibration offsets: {}
Disconnected.  Reconnecting
[INFO] [WallTime: 1379489595.508918] Programming the robot
[INFO] [WallTime: 1379489595.511157] Programming the robot at 192.168.0.102
Exception in thread UR5Connection:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/linux/catkin_ws/src/universal_robot/ur_driver/driver.py", line 199, in __run
    self.__on_packet(packet)
  File "/home/linux/catkin_ws/src/universal_robot/ur_driver/driver.py", line 146, in __on_packet
    state = RobotState.unpack(buf)
  File "/home/linux/catkin_ws/src/universal_robot/ur_driver/deserialize.py", line 245, in unpack
    raise Exception("Unknown package type: %i" % ptype)
Exception: Unknown package type: 9

Handling a request
[2013-09-18 15:33:16.045235] Out: hello
[INFO] [WallTime: 1379489596.076069] Robot connected
The action server for this driver has been started
[2013-09-18 15:34:07.472608] on_goal
[2013-09-18 15:34:47.601144] Out: Braking
^C[tf2_buffer_server-3] killing on exit
[ur_driver-2] killing on exit
[robot_state_publisher-1] killing on exit
Traceback (most recent call last):
  File "/home/linux/catkin_ws/src/universal_robot/ur_driver/driver.py", line 697, in <module>
    if __name__ == '__main__': main()
  File "/home/linux/catkin_ws/src/universal_robot/ur_driver/driver.py", line 658, in main
    time.sleep(0.2)
KeyboardInterrupt
shutting down processing monitor...
... shutting down processing monitor complete
done

Here is a list of updates in V1.8, not sure which need to be added though:

URScript:

    Commands for Conveyor Tracking
        track_conveyor_linear(direction, ticksPerMeter) makes robot motions follow a linear conveyor
        track_conveyor_circular(center, ticksPerRevolution,rotate_tool) makes the robot motions follow a circular conveyor (round table)
        stop_conveyor_tracking() returns to normal robot control
        set_conveyor_tick_count(value) sends the value of an absolute encoder to the controller
        get_conveyor_tick_count() returns the estimated conveyor tick count, using interpolation
        conveyor_pulse_decode(type,A,B) makes controller decode pulses (edges or quadrature pulses with less than 50Hz frequency) as input to the conveyor tracker 
    Tutorials for conveyor tracking at http://support.universal-robots.com/Technical/ConveyorTracking
    Added string comparison operators ( ==,!=, <, >, <=, >=) e.g. to check whether a string is empty (eg. str == "")
    Added a "norm" operator for arrays "norm(myArray)"
    Arrays can no longer change length at runtime
    Script function textmsg() can now take two arguments, so you can write for instance a string and a variable to the log-tab
    Script functions get_target_tcp_pose(), get_actual_tcp_pose(), get_target_tcp_speed(), and get_actual_tcp_speed() now uses the specified tcp position in the calculations (Note! it may change behaviour of programs that use these script functions) 

Hope this is useful, I plan to try downgrading the robot to V1.7 to try it again. Please let me know if there's anything I can do to help.

Thanks,

Andy

The current UR python driver has a bug that causes it to lockup. The root cause seems to be due to the python driver not detecting that that robot has reached its goal point or the driver never sending the last point (not sure which).

From the Mailinglist (https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/i5twnmpf2ws), I learned that there is another version of the universal_robot stack that is used for the ROS-I training (https://github.com/ros-industrial/industrial_training/tree/hydro/training/supplements/src/universal_robot).
The thread mentions that this version also provides services for setting and getting I/Os from the UR.

Two questions:

• Why is there a different repo? Would it be possible to combine them? Or at least sync them?
• How mature is the I/O interface? Should it be integrated into this repo as well?

Because I noticed that the I/O messages there got the same define value (https://github.com/ros-industrial/industrial_training/blob/hydro/training/supplements/src/universal_robot/ur_driver/src/ur_driver/driver.py#L43) as the TCP force message from here #77 and #78
Also the location for defining services diverges!