Support for UR firmware 3.2

[ThomasTimm]

The introduction of firmware 3.2 adds a new field to the real time interface data stream.[1]
From the release notes:[2]

• Added digital outputs (address 131) to RealTimeClientInterface (if you use port 30003, it may affect your software)
• Added program state (address 132) to RealTimeClientInterface (if you use port 30003, it may affect your software)

This needs to be implemented.
At the same time it is worth considering a plan for handling the increasing fragmentation between versions, i.e. what should a getter return if an attempt is made to get a value which an older robot does not publish.

[1] http://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/remote-control-via-tcpip-16496/
[2] http://www.universal-robots.com/how-tos-and-faqs/faq/ur-faq/release-note-software-version-32xxxxx/

[VictorLamoine]

Can anybody give an update status on running this package with the Polyscope 3.2.* versions?

I successfully connect to the robot and the rosrun ur_modern_driver test_move.py works perfectly but when planning trajectories using MoveIt the robot stops before finishing the trajectory.

Beginning of the discussion: (+ log)
https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/LwcFK44vmKI

My demo package is here: universal_robot_motion

[nick-pestell]

I am also running with 3.2* version and it sounds as though I was experiencing the same problem as you @VictorLamoine. In which case it is related to #43.

I am guessing you are tying to use moveit_commander or the equivalent c++ API?

Try lowering the maximum joint velocities in joint_limits.yaml. I found that setting them all to around 0.15 solved the problem, though I'm really not sure why...

I'm inclined to believe that the reason test_move.py works is because it only publishes a single goal state on the follow_joint_trajectory/goal topic, whereas when using the functions from moveit_commander a new goal state is published at a frequency of around 4hz. Perhaps the premature ending of the trajectory at higher joint speeds could be related to #36. I.e. somewhere throughout the trajectory the new goal start falls out of line with the current pose?

[ThomasTimm]

It sounds very strange that moveit_commander is publishing a new goal state at ~4 hz. What is the purpose of continuously publishing new goals? (unless the goal keeps changing, but then it wouldn't make sense to talk about a trajectory ending prematurely)

[gavanderhoorn]

Closing as I believe 3.2 is already supported by the kinetic-devel refactor.

Any additional issues should be reported and tracked in a new issue.