ABB IRB-2400 joint 3 not reported correctly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Turn on robot
2. rosparam set robot_ip_address <ip_address>
3. rosrun industrial_robot_client robot_state
4. rosrun echo /joint_states
5. Move joint 2 with the pendant

What is the expected output? What do you see instead?

Joint 3 (i.e. the angle between link 2 and 3) moves with joint 2 due to the 
parallel linkage.  This isn't reflected in the joint values.

Original issue reported on code.google.com by shaun.ed...@gmail.com on 9 Nov 2012 at 11:22

[GoogleCodeExporter]

This is a similar to an issue we had with the different motoman robots.  In 
that case we were able to modify the server side to account for the joint 
coupling.  I don't think that is possible on the ABB side (atleast not 
generically).  We could add this capability to the ROS nodes, similar to how 
the Motoman does it, except with parameters.  The other option is to implement 
abb specific nodes that inherit from the base generic nodes.

Original comment by shaun.ed...@gmail.com on 9 Nov 2012 at 11:26

[GoogleCodeExporter]

For our ABB 2400, Actual J3 = reported_J3 - 1.0 * reported_J2.

Looking at ABB's current product line, several robots have a similar J2/J3 
linkage.  It appears that some robots may also have a linkage to some risk 
axes, but it's unclear.  It's also unclear whether all linkages are 1:1, or 
whether some linkages have some sort of transmission ratio.

I plan to create a generic ABB driver node that accepts a parameter to control 
this linkage calculation.  Users can modify the launch file to supply the 
relevant linkage parameter(s) for their specific robot model.

Original comment by jz...@swri.org on 12 Nov 2012 at 4:46

[GoogleCodeExporter]

Fanuc arms seem to exhibit the same behaviour. According to the information I 
got from Fanuc, 'all' their arms compensate the J3 joint angle with respect to 
J2 (to 'prevent the J3-J4 link from being driven into the ground').

Currently, the ros_state KAREL program corrects the angle reported for J3, I 
might move this to the robot_state / JointRelayHandler ROS node and make it 
configurable -- similar to the mentioned ABB node -- with 'enabled' being the 
default configuration.

Original comment by colaed11 on 3 Dec 2012 at 9:15

[GoogleCodeExporter]

FYI:

We are currently working on a generic "fix" for this type of behavior.  Current 
work in progress is under the tag "industrial_robot_client_dev", package 
"industrial_robot_client".

This work re-structures the generic industrial_robot_client to provide 
modular/extensible classes for ROS-side state-publisher and 
command-download/streaming nodes.  We then implemented ABB-specific nodes using 
derived classes and a minimum of code (see abb_common) to provide the 
joint-coupling compensation described above.

We decided on a ROS/client-side approach rather than a robot/drive-side method, 
to allow easier configuration by ROS users.  The initial concept also supported 
different joint-coupling ratios, but this was not required for ABB robots, in 
the end.

If you'd like to use this approach, rather than roll-your-own, I can help 
address any questions you may have.  The current work is not quite done, but 
it's mostly functional.  I hope to have the new modular architecture merged 
back into the trunk in the next day or two.

Original comment by jz...@swri.org on 3 Dec 2012 at 3:20

[GoogleCodeExporter]

Fixed in r819.  ABB ROS node now supports the required joint-coupling using a 
launch-file parameter J23_coupled:=true/false.  A similar approach could be 
used for other robots that also have joint-coupling issues.

Original comment by jz...@swri.org on 12 Dec 2012 at 3:14

• Changed state: Fixed