Frame_id and controlled_frame for FollowCartesianTrajectory has no use?

[Makuh17]

Summary

According to this documentation, the work frame and tool frame can be set when sending a trajectory which is very handy. However, the included test_move script does not utilise this. Therefore I modified test_move to define these frames, but seemingly it has no impact. Instead, it seems that the control fully adheres to the frames (base and tip) defined in urXX_controllers.yaml. Furthermore, pose_based_cartesian_traj_controller and forward_cartesian_traj_controller use as tip tool0_controller which does not follow the actual tcp. (EDIT: this was due to an error on my side)
I am not sure if I am misusing or misunderstanding what these are supposed to do. Can you let me know if what i observe is expected behavior?

Versions

• ROS Driver version: Universal_Robots_ROS_Driver 2.0.0
• URCaps Software version(s): External Control 1.05

Impact

Not having the the abstraction of user defined work- and tool frames severely reduces the usefulness of the Cartesian controllers in my opinion.

Issue details

Use Case and Setup

I wish to control the motion of the end effector in a user defined frame.

Project status at point of discovered

At first test

Steps to Reproduce

1. Modify test_move to include the lines

       goal.trajectory.header.frame_id = "test_work_frame"
       goal.trajectory.controlled_frame = "test_tool_frame"

2. Set up transform broadcaster to ensure these frames exist
3. Connect to robot (In my case URSim)
4. Run test_move and select one of the Cartesian controllers
5. Repeat with the added lines commented out and observe no difference in the movement

Expected Behavior

I expected the inclusion of a work frame (frame_id) to shift the position of the targets.

Actual Behavior

No change regardless of definition of frame_id

[stefanscherzinger]

@Makuh17 thanks for taking the time and opening the issue!

I am not sure if I am misusing or misunderstanding what these are supposed to do. Can you let me know if what i observe is expected behavior?

Your understanding of this proposed feature is correct. Unfortunately, this feature hasn't been implemented so far. To implement it, there are further transformation lookups required. here's more information in an issue of the controllers' repository.

I'm not totally sure about the preference of the upcoming features, but maybe there are some resources to tackle this soonish @fmauch ?

@Makuh17 If you want to specify a custom end-effector, you might also consider this approach

[Makuh17]

Hi Stefan
Thank you very much for the incredibly swift reply! Since I am not dealing with moving work frames, creating a temporary work-around should be fairly straight forward. However, I do believe that this is an important feature as I often in ROS miss the simplicity and abstraction level of trajectory definition available on pendants. This feature would help bridge that gap and allow for a better symbiosis of ROS and OEM software.

Is it possible to elaborate on the function of the tool0_controller frame?

[stefanscherzinger]

@Makuh17

This feature would help bridge that gap and allow for a better symbiosis of ROS and OEM software.

Yes, that would be the vision. I hope we find time to work on this soon.

Is it possible to elaborate on the function of the tool0_controller frame?

I'm not completely sure of its function (as in purpose), but maybe #174 and the answer from here add some detail..