driver: published WrenchStamped msg does not set frame name

[gavanderhoorn]

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.

[gavanderhoorn]

Ping

[abubeck]

We will work on this during merging of PR #78, but we want to wait until #92 is merged (tests pending).

[fmessmer]

@Equanox @gavanderhoorn
Is it correct that the robot base coordinate system is ${prefix}base_link in our case?

[gavanderhoorn]

yes, well, sort of. See ros-industrial/ros_industrial_issues#24 for some discussion.

The UR urdfs don't have the additional base link yet (#95), which means that base_link does not necessarily have the correct orientation wrt the real robot. Setting base_link as the header.frame link would then not work (I think).

@abubeck and @ipa-fmw should recognise this. See also this discussion on the ROS-Industrial mailing list about it.

I have seen some discussion with UR about this, but I don't know whether we have been able to resolve this yet.

[gavanderhoorn]

@ipa-fxm wrote:

Is it correct that the robot base coordinate system is ${prefix}base_link in our case?

As #200 has been merged, we should now be able to consider ${prefix}_base as the robot base coordinate system.

[gavanderhoorn]

ur_driver is deprecated and will not see further development.

Closing.