Array message versions of PoseStamped and TransformStamped

[christian-rauch]

Package geometry_msgs has PoseArray, a list of Poses defined. This is the only Array version of otherwise single message instances, like PoseStamped, TransformStamped, ...

Would it make sense to also add a PoseStampedArray and/or TransformStampedArray?

[tfoote]

I don't think that it makes a lot of sense to create a generic datatype like that which can be represented by a single line of msg format unless it has a strong semantic meaning.

Otherwise just use: PoseStamped[] array versus geometry_msgs/PoseStampedArray array

with geometry_msgs/PoseStampedArray.msg PoseStamped[] array

Which is actually harder to address with the structured datatype as you'll have to use

MyMsg foo;
...
foo.array.array[N]

versus just using the array of PoseStamped datatypes.

MyMsg foo;
...
foo.array[N]

[christian-rauch]

I agree that the Array version of a message usually does not have semantic meaning and that, if you use them in your own message definitions, they can simply be replaced by the list [] of these messages.

Asking for Array versions of e.g. PoseStamped comes from the need to standardise these generic message definitions, so they can be used by others and allow interoperability. I.e. since a PoseStampedArray would be generally usable, it wouldn't make sense for different package sets (e.g. within research groups or robots) to redefine their own incompatible version of this pose list.

To take an example, let's say I want to publish/log the 3D pose of all detected objects in an image. A PoseStampedArray would allow me to log this in a rosbag and exchange it with other people. If I need to create my own message definitions for this, someone that wants to read this bag file would need to hunt down the location of this message definition.

To summarize: Especially because Array version of messages do not have a semantic meaning and are generally applicable, they should be defined in a widely accepted standard package set to prevent multiple incompatible redefinitions of the same message type. On the contrary, if a message carries a semantic meaning, it is more likely that it will be used by only a smaller group of people.

[gavanderhoorn]

To take an example, let's say I want to publish/log the 3D pose of all detected objects in an image. A PoseStampedArray would allow me to log this in a rosbag and exchange it with other people. If I need to create my own message definitions for this, someone that wants to read this bag file would need to hunt down the location of this message definition.

This may be just an unlucky choice of example, but: wouldn't a custom message called PoseDetectionResults.msg make more sense here (or something similar)?

A PoseArray could contain anything. Only by importing knowledge from outside the application (ie: from the developer) can the application "know" that those poses actually represent detected 3D poses.

This is the "lack of semantics" I believe @tfoote is referring to.

[christian-rauch]

I totally agree with the problem of missing semantics for these kinds of message definitions. But this is the same for all the MultiArray versions in std_msgs. I.e. they do not have a meaning but they are widely available and exchangeable.

A PoseDetectionResults message would of course carry a semantic meaning. But it has the before mentioned problem that its message definition would be stored in an non upstream ROS repo and therefore has the chance of vanishing over time. If someone wants to read this bagfile later, he needs to find the exact message definition and might not be able to read the bagfile in the end, even though its message definition is just a trivial list of an already known message definition.

[gavanderhoorn]

I totally agree with the problem of missing semantics for these kinds of message definitions. But this is the same for all the MultiArray versions in std_msgs. I.e. they do not have a meaning but they are widely available and exchangeable.

IIUC the existence of the MultiArray msgs as standard msgs has been widely considered an unfortunate mistake, exactly for the reasons you mention.

Their use is actually discouraged, for almost all intents and purposes.

A PoseDetectionResults message would of course carry a semantic meaning. But it has the before mentioned problem that its message definition would be stored in an non upstream ROS repo and therefore has the chance of vanishing over time. If someone wants to read this bagfile later, he needs to find the exact message definition and might not be able to read the bagfile in the end, even though its message definition is just a trivial list of an already known message definition.

Again, this may be too localised (as in: to your example), but: see vision_msgs (exactly created to avoid the situation you describe). It's currently on a personal account, but is in the works to be hosted on a github.com/ros organisation.

---

Edit: I would say the way forward for these kind of discussions is to standardise msgs where possible, and preferably msgs with semantics. The situation you describe would be remedied by getting the messages that are used standardised, not by extending std_msgs with another set of msgs that doesn't have any semantics.

That may be naive though, instead of pragmatic ..

[christian-rauch]

The usage of PoseStampedArray for detected 3D objects was actually just an example. I am not looking for a solution to this concrete problem.

I basically just wanted to make the point that generic (semantically less meaningful) message definitions are likely more often used and the benefit of standardising them is that e.g. bagfiles can be used at a later time without needing to find their message definitions in some 3rd party repository.

IMHO, message definitions should be used to standardise commonly used messages for communication and logging to prevent multiple incompatible definitions. Semantic meaning is important but not more important than having a standardised interface for communication and logging.

[tfoote]

IMHO, message definitions should be used to standardise commonly used messages for communication and logging to prevent multiple incompatible definitions. Semantic meaning is important but not more important than having a standardised interface for communication and logging.

I agree completely that we want to standardize commonly used messages, but commonly using a message without semantic will lead to errors of interpretation. If I tell you to transform a data structure {1,2,3} do you intepret it as a vector or a point you don't know because they have the same data structure and if all you're recording is the data structure in the message type, you could log either a point or a vector. And then when you go over your log files you don't know which was logged, and your data cannot be operated on automatically without knowing that semantic information about the data type. That's why we have both a Point and a Vector3 datatype. They have the same data structure but different interpretations.

We've made the friction quite low for how to define and share new message datatypes. Anyone can create a package and propose new messages. To become commonly used you need to be able to design it at the right abstraction level for reuse in all the "common" use cases that you expect. Usually a well defined message will start solving the use cases of the first user, then pick up some more users. Maybe evolve a little bit to add or remove data, and eventually become a commonly used message because it's made available and easy to use. There are potentially datastructures that can be defined and used as submessages, but good designs need to understand and respresent not just the structure but the semantics to be easily reusable.

[jccurtis]

Hi all, just wanted to note for any future user searching for a solution to the "missing" PoseStampedArray to check out: nav_msgs/Path.