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

Documentation on convert/transform registration in Python #515

Open
MatthijsBurgh opened this issue Aug 8, 2021 · 7 comments
Open

Documentation on convert/transform registration in Python #515

MatthijsBurgh opened this issue Aug 8, 2021 · 7 comments

Comments

@MatthijsBurgh
Copy link
Contributor

Is there any documentation on the convert/transform registration in Python?

@MatthijsBurgh
Copy link
Contributor Author

ping ;)

@MatthijsBurgh
Copy link
Contributor Author

@tfoote ping ;)

@tfoote
Copy link
Member

tfoote commented Sep 27, 2021

There's no significant docs. You can find examples here and here

For converting:
You write a to and from message and register them with tf2_ros.ConvertRegistration()

For transforming:
You write the function to add it and then register it using the tf2_ros.TransformRegistration()

@MatthijsBurgh
Copy link
Contributor Author

For me it is unclear why all the to_msg and from_msg functions can just return the same message.

I would expect that if I have class A and I want to transform to class B, but there is no direct conversion from A to B, it will use the to_msg and from_msg way. So I have to go from A to a msg. Lets call it X. And then convert msg X to class B.

In my mind, msg X has to be ONE type of msg. As a random pair of to_msg and from_msg aren't compatible, unless the to_msg functions outputs a type, which the from_msg functions accepts. Otherwise AttributeError are doomed to happen IMO.

Maybe I am missing something, please explain.

@tfoote
Copy link
Member

tfoote commented Oct 6, 2021

The first example I sent isn't the best as those datatypes are already messages. So the convert to and from message is an identity transform which is why they return themselves.

For the KDL datatypes you can see a more complex version https://github.com/ros/geometry2/blob/noetic-devel/tf2_kdl/src/tf2_kdl/tf2_kdl.py

The logic is to chain the conversions if they exist via a star topology. Any datatype X trying to go to Y look to apply from_msg<Y>(to_msg(X). Thus if X is already a msg it can return itself.

@MatthijsBurgh
Copy link
Contributor Author

What happens in the following situations?

  1. to_msg returns a PointStamped, but the from_msg can only handle PoseStamped as input.
  2. Again to_msg returns a PointStamped, but Y is a PoseStamped and its from_msg functions just returns the input msg. Just like
    def from_msg_msg(msg):
    return msg
    tf2_ros.ConvertRegistration().add_from_msg(Vector3Stamped, from_msg_msg)
    tf2_ros.ConvertRegistration().add_from_msg(PoseStamped, from_msg_msg)

@tfoote
Copy link
Member

tfoote commented Feb 5, 2022

  1. The registrations are keyed on the datatype. A Vector3Stamped converter and a PoseStamped converter will never be chained.

  2. Those theto_msg and from_msg will not be paired like you said because they have different datatype keys.

The noop returns are required because in python we can't detect what the datatype is so we don't know if the datatype matches the input datatype. So convert always triggers to_msg then from_msg to make the conversion. If either end of that goal is already a message it will be the noop.

ooeygui pushed a commit to ms-iot/geometry2 that referenced this issue Oct 12, 2022
With this change in place, I can do a complete local build
on RHEL.

Signed-off-by: Chris Lalancette <[email protected]>
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

No branches or pull requests

2 participants