No, this is not supported right now afaik.
I realize it may be unsupported, then consider as a feature request.
posting a feature request on ROS Answers is not going to work.
Please use a more appropriate venue for that, such as the ros2/ros2 Github organisation.
Alternative methods I like to avoid:
1. Splitting up into multiple or an array of messages with full path stamped on every node like the TF implementation.
I've seen people encode graphs in ROS messages by storing vertices/nodes in a list and then combine that with an adjacency matrix. Makes for a pretty efficient serialisation.
Something to realise perhaps (but you may already know this): ROS messages are not intended to be used as data structures directly, nor do they have to represent or mirror (in memory) the exact same structure as the data they carry. The recursive property of the tree you mention would be an example of a characteristic which does not necessarily need to be mapped 1-to-1 to the ROS message used to communicate the information.
Considering ROS messages as an interchange format only would make the requirement for encoding and decoding a vertex + adjacency list on the sending and receiving side less 'strange' I believe.
This is the same approach as used for sensor_msgs/Image and sensor_msgs/PointCloud2 fi. Even geometry_msgs/Pose et al. are not intended to be used directly: they are always supposed to be converted to non-msg types and then used with the libraries that provided those types (hence the to-from-Eigen and to-from-Bullet conversion packages provided).
Originally posted by gvdhoorn with karma: 86574 on 2021-08-27
This answer was ACCEPTED on the original site
Post score: 0
Original comments
Comment by gvdhoorn on 2021-08-27:
Example of an existing package: PickNikRobotics/graph_msgs.
Not a 'standard' package, but an example.
Comment by gvdhoorn on 2021-08-30:
Could you add a comment describing the approach you ended up using?
It would be good to document success or working alternatives.
