Creating an array/list of existing message type without defining custom message type?
Is there a way to create an array of an existing message type without defining another message type?
As a use-case, say you have many .bag files, each with a username. You compile them into a summary bag file and would like all unique usernames in a metadata topic for convenience. Is there any way to accomplish something like this without a custom message type?
users = get_unique_users() # a function returns a list of strings: [user1, user2, ..., userN]
outbag = rosbag.Bag('/path/to/file.bag', 'w')
outbag.write('/metadata/unique_users', std_msgs.msg.String(users))
It seems that an array of an existing message is such a simple extension that I'd figure such a mechanism exists. My current approach was to create a new package, std_msgs_array with:
$ rosmsg show std_msgs_array/StringArray
string[] data
$ rosmsg show std_msgs_array/Float64Array
float64[] data
Is this expected or am I overlooking something? I do note the following from the ROS Wiki:
...it's usually "better" (in the sense of making the code easier to understand, etc.) when developers use or create non-generic message types
Perhaps the intention is to force more project-specific message creation rather than relying on built-in, canned examples. This use-case might be somewhat fringe where I truly am looking for a "throwaway"; all I care about is getting a list of very basic values into the output .bag vs. something like sensor data specific to a more complicated process.
Asked by jwhendy on 2019-02-04 17:16:01 UTC
Answers
You already cite the correct wiki page about the purpose of std_msgs.
For integer/float values, there are the MultiArray messages, which could suite your needs for numbers. For strings, you either have to create a new custom message, or wriggle your way through something like adding a seperator between all users concatenated into a single string...
In short: There is no way to create a message type to be sent over ROS or written to the bag file without properly creating a .msg file. This is required for creation of the language specific representations, such that you can #include or import them.
Asked by mgruhler on 2019-02-05 01:42:43 UTC
Comments
[..] such that you can
#includeorimportthem.
I would go one step further: being able to #include or import them is an implementation detail. The main point of having to be explicit about message types (ie: having to create them) is to make sure both syntax and semantics are ..
Asked by gvdhoorn on 2019-02-05 03:05:14 UTC
.. properly encoded/stored somewhere.
@jwhendy: how would we do that without having a message type defined?
Asked by gvdhoorn on 2019-02-05 03:05:57 UTC
@gvdhoorn: agreed!
Asked by mgruhler on 2019-02-05 04:12:44 UTC
@gvdhoom: the question was prompted by the fact that a foo msg corresponding to some Foo.msg can be used as a foo[]. Is a foo[] a "custom message type" in your mind? My question asks if one must use a custom message to consume or provide an array of an existing message.
Asked by jwhendy on 2019-02-09 21:18:20 UTC
It seems that answer is "Yes," so now I know. For this particular scenario it seemed "heavy" to do this when I really just want a list of strings or floats. Still, it seems this is the way, so now I know for sure.
Asked by jwhendy on 2019-02-09 21:19:24 UTC
No: foo[] is not a custom message.
The message containing a field named foo that is an arbitrary length array (ie: a list) would be a custom message.
Pedantic perhaps, but two very different things.
re: heavy: thing is, a list of floats is not semantically meaningful. Unless ..
Asked by gvdhoorn on 2019-02-10 15:09:49 UTC
.. you give the message a semantically meaningful name. That is what you should create a custom message.
Besides, it's technically impossible to send, receive or store message data without an associated message type, so even if you see it as a lot of overhead, there wouldn't be any other way.
Asked by gvdhoorn on 2019-02-10 15:11:39 UTC
Thanks for the reasoning. This is indeed a narrow use case. For the purpose of storing metadata, the field name doesn't matter to me as it's named by the topic (e.g. /metadata/foo) I assign. Again, pretty fringe use case.
Asked by jwhendy on 2019-02-10 16:01:26 UTC
Comments