Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New approach for the tf2::toMsg() hassle #491

Closed
wants to merge 6 commits into from

Conversation

gleichdick
Copy link

The second template parameter of tf2::toMsg() now has a default value,
which is resolved to a ROS message type depending on the non-message datatype.
This allows the deduction of the return value type.

Furthermore, toMsg(), fromMsg(), getTimestamp() and getFrameId() now have a default implementation,
which forwards the calls into structs defined in the impl namespace. Now missing implementations of conversion methods result in compile-time errors, they do not occur during link-time anymore.

A lot of effort was put into the automatic conversion of dataypes with a stamp (tf2::Stamped<T> and the ...Stamped ROS messages) to avoid code duplication. The stamped types now use the conversion methods of the unstamped types and copy the timestamp/frame id informations.

This PR should remain API compatibility, but the ABI will break (as the non-templated functions like toMsg() are removed).

Further TODO's:

  • extend documentation
  • test downstream packages

@seanyen may I ask you to test whether this approach works on Windows?

Related Issues:
#430
moveit/moveit#1785

The conversion is moved into the `ImplDetails` struct
to avoid link-time errors.
As the return value of `toMsg()` can't be deduced,
a default value depending on the first argument will be chosen
from the `defaultMessage` struct.
@gleichdick
Copy link
Author

@tfoote friendly ping

@tfoote
Copy link
Member

tfoote commented Jan 25, 2021

Thanks for this. It's going to take me a bit to review this fully.

As this will break ABI as a core module we generally won't want to roll it out into an active rosdistro for something quite this core without a significant problem. Would it make sense to target this for ROS 2 rolling instead of noetic. If we get it into rolling soon we can also shoot to get it into the upcoming Galactic release.

@gleichdick
Copy link
Author

Okay, thanks. I'm currently porting this to ROS2, see ros2/geometry2#368.

@peci1
Copy link
Contributor

peci1 commented Apr 9, 2023

I guess this ROS 1 PR can be closed.

@tfoote
Copy link
Member

tfoote commented Sep 22, 2023

This is something that we definitely can't change in ROS 1 distributions. I'm going to close this and point to the open PR on the ROS 2 repo: ros2/geometry2#427 for further discussion.

@tfoote tfoote closed this Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants