# ros msg definitions, difference between std_msgs/TYPE and type

Hello,

What is the difference in between using

std_msgs/Float32 someVariable


and

float32 someVariable


in msg files?

I noticed the latter can be accessed by my_data.someVariable.data where the first needs to be accessed by my_data.someVariable

I am sending these messages over rosserial, so what differences are there when using std_msg/Type in a msg file

Best, C.

edit retag close merge delete

Sort by » oldest newest most voted

What is the difference in between using std_msgs/Float32 someVariable and float32 someVariable in 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.data where the first needs to be accessed by my_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:

1. it becomes impossible to easily connect them (ie: by remapping fi), and
2. it's immediately clear that one of the float32s actually encodes a temperature and the other the desired throttle value and that these represent entirely different things
more