<> <> == Message generation == Like all ROS [[Client Libraries]], `rospy` takes [[msg]] files and generates Python source code for them. The pattern for this is: `package_name/msg/Foo.msg` → `package_name.msg.Foo` Similarly, [[srv]] files also have Python source code generated. The pattern for this is: `package_name/srv/Bar.srv` → `package_name.srv.Bar` The source for the generated files are in the `src` directory of `package_name`. Thus, to use the `std_msgs/String` message in your code you would use one of the following `import` statements:{{{ import std_msgs.msg msg = std_msgs.msg.String() }}}or {{{ from std_msgs.msg import String msg = String() }}} == Message initialization == There are three ways to initialize a new Message instance: in-order arguments (`*args`), keyword arguments (`**kwds`), no arguments. '''No arguments''' In the no-arguments style you instantiate an empty `Message` and populate the fields you wish to initialize. For example {{{ msg = std_msgs.msg.String() msg.data = "hello world"}}}Message fields are given default values, which means you can do direct field assignment into embedded messages like a `Header`: {{{ msg = sensor_msgs.msg.Imu() msg.header.stamp = rospy.Time.now() }}} '''In-order arguments (`*args`)''': In the ''in-order'' style, a new `Message` instance will be created with the arguments provided, in order. The argument order is the same as the order of the fields in the `Message`, and you must provide a value for all of the fields. For example, `std_msgs.msg.String` only has a single `string` field, so you can call:{{{ msg = std_msgs.msg.String("hello world") }}}`std_msgs.msg.ColorRGBA` has four fields (`r`, `g`, `b`, `a`), so we could call:{{{ msg = std_msgs.msg.ColorRGBA(255.0, 255.0, 255.0, 128.0) }}} '''Keyword arguments (`**kwds`)''' In the ''keyword'' style, you only initialize the fields that you wish to provide values for. The rest receive default values (e.g. 0, empty string, etc...). For `std_msgs.msg.String`, the name of its lone field is `data`, so you can call:{{{ msg = std_msgs.msg.String(data="hello world") }}}`std_msgs.msg.ColorRGBA` has four fields (`r`, `g`, `b`, `a`), so we could call:{{{ msg = std_msgs.msg.ColorRGBA(b=255) }}}which would publish a `ColorRGBA` instance with `b`=255 and the rest of the fields set to 0.0. Each style has benefits and trade-offs. The ''keywords style'' is the recommended approach. It is resilient to many types of [[msg]] changes (new fields, field re-ordering) and is often more concise than other approaches. The ''in-order style'' is beneficial when you ''want'' your code to be brittle to [[msg]] changes, such as with regressions tests or other code that you wish to notice message changes. The ''no arguments'' style requires more lines of code but is useful if your message has embedded `Message` instances: after instantiation, these embedded messages will have been instantiated and you can do direct field assignments into them (e.g. setting the timestamp of a `Header`).