PyKDL tf2_ros.Stamped broken

[MatthijsBurgh]

In the migration of PyKDL from SIP to pybind11 the tf2_ros.Stamped function got broken for PyKDL classes. As dynamic attributes are not enabled for the pybind version.

geometry2/tf2_ros_py/tf2_ros/buffer_interface.py

Lines 232 to 238 in 9e9bfc5

	def Stamped(
	obj: TransformableObject,
	stamp: Time,
	frame_id: str
	) -> TransformableObject:
	obj.header = Header(frame_id=frame_id, stamp=stamp)
	return obj

We can enable this again in the original PyKDL repo. Though I will only do this, when it is also rolled out to the vendor packages.

Please let me know what you want.

[clalancette]

There are a few different things going on here.

The first is that we have a test for this situation in https://github.com/ros2/geometry2/blob/rolling/test_tf2/test/test_convert.py , but we aren't actually running it. We probably should enable that, though that is orthogonal to this working.

The second is that when I run the following code, it does indeed fail:

>>> import tf2_ros
>>> import PyKDL
>>> import builtin_interfaces
>>> v = PyKDL.Vector(1, 2, 3)
>>> t = builtin_interfaces.msg.Time(sec=0)
>>> p = tf2_ros.Stamped(v, t, 'my_frame')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ubuntu/new_ros2_ws/install/tf2_ros_py/lib/python3.10/site-packages/tf2_ros/buffer_interface.py", line 237, in Stamped
    obj.header = Header(frame_id=frame_id, stamp=stamp)
AttributeError: 'PyKDL.Vector' object has no attribute 'header'

Presumably this means that the PyKDL.Vector class is using the equivalent of __slots__, which is why we can't assign to it. But I guess my question is: does it make sense at all for this function to work for an arbitrary class? It seems like the Stamped function should really only work for msg-style classes that have a Stamped version. But maybe I'm wrong about this.

Finally, even if we do figure out that we should do this and we should fix it in PyKDL, fixing it there won't actually fix it on Linux, at least. There, the vendor package first attempts to see if PyKDL is already available, and if it is, it skips building the vendor package. Since python3-pykdl is indeed available in Ubuntu, we don't build it there. I think currently the only place we actually build is on Windows.

So I think we need to answer the question of whether we expect this to work at all. Once we decide on that, we can figure out a way forward.