Any plans to support doTransform() with non-stamped message types?

[mitsudome-r]

Feature request

In ROS1, we used to have doTransforms for message types without Headers, but they are missing in ROS2. Are there any reasons why will omitted these functions in ROS2?

Example with geometry_msgs/Point ROS1 ROS2

Feature description

Transforms geometry messages without timestamps.

Implementation considerations

[clalancette]

The original commit that added those to https://github.com/ros/geometry2 is here. That was added after we forked this repository off from that one.

No fundamental objection to having those. Contributions to add it are very welcome.

[adamkrawczyk]

Hi,

I'm doing this and create PR but wondering whether adding PoseWithCovariance without timestamp makes sense?

Best

[aprotyas]

wondering whether adding PoseWithCovariance without timestamp makes sense?

You don't necessarily need headers for all types of applications. For example, I can think of a planar path planner that would not care much about the timestamp/reference frame of goal queries expressed as PoseWithCovariances.

[adamkrawczyk]

Made changes at: https://github.com/ros2/geometry2/pull/452

Please take a look and share your thoughts

[galou]

Isn't it actually misleading to have doTransform<geometry_msgs::msg::PoseStamped> because two PoseStamped that have the same coordinates but different frames, i.e. that are supposed to express two different poses, are transformed into the same PoseStamped. Generally, the poses' frame is ignored completely. Removing doTransform<geometry_msgs::msg::PoseStamped> would break the API though.

[aprotyas]

Isn't it actually misleading to have doTransform<geometry_msgs::msg::PoseStamped> because two PoseStamped that have the same coordinates but different frames, i.e. that are supposed to express two different poses, are transformed into the same PoseStamped. Generally, the poses' frame is ignored completely. Removing doTransform<geometry_msgs::msg::PoseStamped> would break the API though.

@galou wouldn't that be valid behavior though? As in, if you're performing a transformation, you're expressing the geometric data (pose) in a different frame, so the frame ID of the stamped pose should be updated accordingly?

[galou]

@aprotyas I agree that the resulting frame_id should be the same for both PoseStamped but the coordinates should vary. The current implementation of doTransform<geometry_msgs::msg::PoseStamped completely ignores t_in.header.frame_id.

[aprotyas]

@galou I might be misunderstanding the math here, but I'm thinking that if you do a transformation on a stamped pose, then the output of that transformation should be in the same frame as the transformation (and not the input pose), which is what's happening in the current implementation of doTransform<geometry_msgs::msg::PoseStamped>.

On a tangent, I will say the choice of t_in might not be the best input parameter name given t could also stand for transform...