The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
What is the difference in between using
std_msgs/Float32 someVariableandfloat32 someVariablein msg files?
The former (std_msgs/Float32) is a message, the latter (float32) is a type. A message can be published. A bare type cannot.
That is the main difference. The messages in std_msgs are essentially bare types wrapped in a message, such that they can be published and received.
I noticed the latter can be accessed by
my_data.someVariable.datawhere the first needs to be accessed bymy_data.someVariable
As the messages in std_msgs are wrappers and not the types themselves, any field that is declared to be of type std_msgs/Float32 essentially embeds a message inside another message. As the base message std_msgs/Float32 already wraps a plain float32, to access the actual data, you first have to go through all the wrappers and finally get to the data field that contains the wrapped data type.
| | 2 | No.2 Revision |
What is the difference in between using
std_msgs/Float32 someVariableandfloat32 someVariablein msg files?
The former (std_msgs/Float32) is a message, the latter (float32) is a type. A message can be published. A bare type cannot.
That is the main difference. The messages in std_msgs are essentially bare types wrapped in a message, such that they can be published and received.
I noticed the latter can be accessed by
my_data.someVariable.datawhere the first needs to be accessed bymy_data.someVariable
As the messages in std_msgs are wrappers and not the types themselves, any field that is declared to be of type std_msgs/Float32 essentially embeds a message inside another message. As the base message std_msgs/Float32 already wraps a plain float32, to access the actual data, you first have to go through all the wrappers and finally get to the data field that contains the wrapped data type.
For normal usage in custom messages, it doesn't make sense to use the wrapped version of these plain types, as the message you are creating already wraps them in a message (that's the whole point of creating the message).
I would go so far as to say: using any message from std_msgs as the type of a field in a custom message is essentially wrong: use the plain type it wraps (so just use float32 instead of std_msgs/Float32 for your field).
Finally: even though it's convenient they are there, the messages in std_msgs should only be used very sparingly if at all. Publishing a std_msgs/Float32 carries no semantics whatsoever.
As a publication, it could be the temperature of your coffee. As a subscription, it could be the desired throttle value of your car. Both of these can be encoded with a float32. But connecting the two (ie: coffee_temperature -> engine_throttle) makes no sense. By using generic messages, there is no way to prevent setting up such connections. If you'd use two different message types with proper semantics, say ThrottleCommand and Temperature:
float32s actually encodes a temperature and the other the desired throttle value and that these represent entirely different things
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.