tool0_controller/tool0 frame offset

[ros-industrial]

tool0_controller/tool0 frame offset

[ThomasTimm]

When @sepjansen added the tool0 frame, the parent frame was correctly set to base. Apparently, I accidentally changed that in commit adc223
So it should obviously be changed back, thanks for noticing this @achim-k

[ThomasTimm]

I haven't seen it before, no.
Did you follow what is written in the readme, including making sure you have a version of robot_state_publisher that is able to handle floating joint?
Is it possible for you to say which one is correct if you compare it to the info on the teach pendant?
Have you changed anything in the URDF or using any joint offsets?

[gavanderhoorn]

The orientation of the base_link in the UR5 and UR10 models is the mirror (rotated pi over Z) of the orientation of the real robot's Base feature. See also ros-industrial/universal_robot#200. Afaik, this has been the case since the original WG developers created the package.

The base and tool0 frames added in ros-industrial/universal_robot#200 have the correct orientation, and correspond directly to the Base feature and an all-zeros TCP.

A real fix would be to fixup the urdfs in ur_description, but I've seen people just specify the base frame for the base_frame parameter in ur_modern_driver/launch/ur_common.launch.

[achim-k]

Thanks @gavanderhoorn, manually setting the 'base_frame' param to 'base' works for me. Shouldn't this then become the default?

[ThomasTimm]

I agree. Anybody has a good reason why this shouldn't be the default value?

[gavanderhoorn]

I've not been following the development of ur_modern_driver close enough to know why it was set to base_link in the first place. It seems like an odd choice, as that frame has always had that problem. Perhaps knowing that, we (or you, @ThomasTimm) can derive / tell us why it was set to base_link, and then why it should, or shouldn't be changed?