ROS2 Pose control ignores message frame

[Fireronin]

Opened per @michalpelka request. I don't think it's a problem, but it can be changed to filter out only matching frames or something if this is needed

[michalpelka]

Thanks for opening up, but I strongly disagree with your judgment on a minority of the issue. It is a problem since every ROS 2 tool should perform the transformation of stamped messages.

Let's assume that some system will give commands to move the robot one meter forward. In this case, it would send a message with "base_link" frame_id and translation [1,0,0]. In the current code, it will set it in the scene at [1,0,0] permanently. This tool should be aligned with transform components existing in ROS 2 gem. Please provide a detailed plan of implementation here.

[michalpelka]

Context : https://github.com/RobotecAI/robotec-o3de-tools/pull/20/files/2b1b7dda6b593a3b294d19844b7ae5b0e30fc287#r1611747489

[Fireronin]

I think this is supported by TF2 API, you just create map(at 0,0)->anchor(at custom start point)->base_link

[michalpelka]

Could you provide an exact API to do that? It looks like a workaround to not fully implemented functionality.

[Fireronin]

So I think there are 2 ways this can be handled and they have different benefits and drawbacks:

Solution 1: Change type of message received from PoseStamped to Pose.

• Dose not require understanding of tf2
• Provides easy to use interface to move things around in engine, and combined with starting offset, this should give user a simple way to use ros2 interface to move things around in engine.
• Makes it bit harder to use it to teleport things to relative positions

Solution 2: Resolve the position of frame_id in the message, using tf2 interface then move the object to position relative to frame_id. This gives more control. But very similar things can be achieved by using TF2 mode, and interacting directly with tf2 tree in ros2.

Tell me what you need and I will implement it. 🙂

[pijaro]

We should use frame_id from the PoseStamped. As a first implementation (and a default), we should use the map frame as the (0,0,0) of the level.

If there is another transform living on the /tf, ie map -> poi, then we need to be able to spawn with PoseStamped.Header.frame_id=poi in the correct position.

[michalpelka]

I like @pijaro idea.

[Fireronin]

Here is branch that implements this, it's waiting for base branch for merge https://github.com/RobotecAI/robotec-o3de-tools/tree/frame-header-consideration