ROS Message (.msg)

A ROS Message is a strictly typed data structure defined in a .msg file. Its primary purpose is serialization—converting complex data into a flat byte stream for transmission over a network or storage in a ROS Bag. The .msg file serves as a contract between publishing and subscribing nodes, ensuring data integrity. For example, a common sensor message like sensor_msgs/Image serializes header information, image height/width, encoding, and raw pixel data into a single byte array for efficient transport.

ROS Messages are composed of primitive field types that map directly to programming language primitives. The core built-in types include:

• Numeric types: int8, uint32, float64
• Boolean: bool
• String: string
• Time/Duration: time, duration
• Raw byte array: byte, char These types ensure predictable memory layout and cross-language compatibility. For instance, a float64 in a .msg file will deserialize to a double in C++ and a float in Python.

Messages support complex field modifiers for flexible data structuring.

• Unbounded Arrays: Defined with [] (e.g., float32[] ranges), these are variable-length sequences.
• Bounded Arrays: Defined with a fixed size [N] (e.g., float64[3] position), which serializes to a known, fixed block of bytes, improving memory predictability.
• Constants: Allow defining immutable values within the message (e.g., uint8 SUCCESS=0). These constants are compiled into the generated code and are accessible to nodes using the message type.

Messages can be composed of other message types, enabling hierarchical and complex data structures. This is a key mechanism for code reuse and standardization.

• Field Composition: A message can have a field of another message type (e.g., geometry_msgs/Pose pose).
• Standard Message Definitions: The ROS ecosystem provides common package libraries (like std_msgs, geometry_msgs, sensor_msgs) with widely adopted message definitions. For example, sensor_msgs/LaserScan composes a std_msgs/Header, float arrays for ranges and intensities, and scan parameters.

The .msg file is not used directly in code. Instead, the ROS build toolchain (colcon) uses a message generator to produce language-specific source code.

• C++: Generates a header and source file defining a class with getter/setter methods for each field.
• Python: Generates a Python module with a class definition.
• Other Languages: Support for Rust, Java, etc., via additional generators. This process ensures that a node written in C++ can seamlessly exchange a Twist message with a node written in Python, as both use the same binary on-the-wire format.

Messages are the payload for ROS's core communication mechanisms.

• Topics: Use messages for asynchronous, one-way streaming (publish/subscribe).
• Services: Use a pair of messages: one for the request and one for the response, defined in a .srv file.
• Actions: Use three message types defined in an .action file: a Goal, a Result, and periodic Feedback. This unified typing system means a geometry_msgs/Twist message can be published to a /cmd_vel topic for robot control, or used as part of a service call, with identical serialization.

A message for expressing velocity in free space, broken into linear and angular components. It is the primary command message for mobile robot base control.

• Linear: A 3D vector (x, y, z) for velocity in meters per second. For a differential-drive robot, typically only linear.x is used for forward/backward motion.
• Angular: A 3D vector (x, y, z) for rotational velocity in radians per second. For a differential-drive robot, typically only angular.z is used for turning (yaw).

Example: Commanding a TurtleBot3 to move forward at 0.2 m/s while turning left at 0.5 rad/s would set {linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.5}}.

The standard message for transmitting raw or compressed image data from cameras. It contains critical metadata alongside the pixel array.

• Header: Includes a timestamp and frame ID for synchronization and transformation (tf).
• Height/Width: Image dimensions in pixels.
• Encoding: A string defining the pixel format (e.g., rgb8, bgr8, mono8).
• is_bigendian: Byte order of the data.
• step: Full row length in bytes (width * num_channels * bytes_per_channel).
• data: The actual pixel array as a sequence of bytes.

This message is consumed by vision nodes for tasks like object detection, visual SLAM, and semantic segmentation.

A message that estimates the position and velocity of a robot in a coordinate frame (often odom or map). It is a core output of localization systems.

• Header: Timestamp and child frame ID (typically the robot's base frame, e.g., base_link).
• Pose: Contains the estimated position (pose.pose.position) and orientation (pose.pose.orientation as a quaternion) along with a covariance matrix (pose.covariance).
• Twist: Contains the estimated linear and angular velocity (twist.twist) with its own covariance matrix (twist.covariance).

Related Topic: Often published on the /odom topic and used by the navigation stack for feedback control.

A single scan from a planar range-finder (e.g., a 2D LiDAR). It represents distance measurements at fixed angular intervals in a plane.

• angle_min/max: The start and end angles of the scan (in radians).
• angle_increment: The angular distance between measurements.
• time_increment: Time between measurements (if scanning is sequential).
• scan_time: Time between complete scans.
• range_min/max: Valid range limits for the sensor.
• ranges: An array of measured distances. Values outside [range_min, range_max] are considered invalid.
• intensities: Optional array of reflection intensity values.

This is a primary input for obstacle avoidance, SLAM, and 2D mapping algorithms.

A Pose (position and orientation) with a Header, allowing it to be associated with a specific coordinate frame and timestamp. It is used for specifying goals and publishing localized poses.

• Header: Contains stamp (ros::Time) and frame_id (string, e.g., map).
• Pose: A geometry_msgs/Pose object containing:
  • position: A Point (x, y, z coordinates).
  • orientation: A Quaternion (x, y, z, w components).

Common Use Cases:

• Sending a navigation goal to move_base.
• Publishing the estimated robot pose from a localization filter.
• Defining waypoints in a task plan.

Not a standalone message, but a critical sub-message included in almost all sensor and state messages. It provides essential metadata for data synchronization and transformation.

• seq: A consecutively increasing sequence ID (deprecated in ROS 2 in favor of timestamps).
• stamp: A ros::Time or builtin_interfaces/Time object representing the acquisition time of the data. This is crucial for sensor fusion.
• frame_id: A string identifying the coordinate frame in which the data is expressed (e.g., base_link, camera_color_optical_frame). This is essential for the TF2 transform library to correctly interpret the data's spatial context.

Understanding the Header is fundamental to building robust, temporally consistent robotic systems.

A named bus for the asynchronous, many-to-many exchange of ROS Messages using a publish-subscribe model. Nodes publish messages to a topic, and any number of subscribing nodes can receive them, enabling decoupled, streaming data flow (e.g., sensor data, velocity commands).

• Primary use: Streaming data where timing is critical but immediate acknowledgment is not required.
• Example: A /camera/image_raw topic publishing sensor_msgs/Image messages.

A synchronous, request-response communication mechanism. A client node sends a service request message and blocks until it receives a service reply message from the server node. Services are defined by a pair of .srv files (request and reply).

• Primary use: Remote procedure calls (RPC) for operations that require a direct, blocking response.
• Example: A /get_map service where the request is empty and the reply is a nav_msgs/OccupancyGrid message.

An asynchronous interface for long-running, goal-oriented tasks. Built on topics, it uses three message streams: a client sends a goal, the server streams periodic feedback, and finally sends a result. Defined by a .action file.

• Primary use: Tasks like navigation or manipulation that take time and require progress updates or preemption.
• Example: A MoveBase action for sending a navigation goal and receiving feedback on the robot's progress.

A configuration value (integer, string, boolean, etc.) stored on a central or node-specific parameter server. Parameters are not messages but are a key-value store for runtime configuration that nodes can retrieve, set, and monitor.

• Primary use: Tuning system behavior without recompiling code (e.g., control gains, timeout values).
• Contrast with Messages: Parameters are for configuration; messages are for dynamic data flow between nodes.

The collective term for the definition file formats (.msg, .srv, .action) that specify the data structures for ROS communication. These files are the source of truth from which language-specific code (e.g., C++, Python classes) is automatically generated.

• Core Files: .msg for topics, .srv for services, .action for actions.
• Process: The rosidl toolchain parses these files to create bindings, ensuring type safety across the entire ROS graph.

The core technical process enabled by the ROS Message definition. Serialization (marshalling) converts an in-memory message object into a compact byte stream for network transmission or recording. Deserialization (unmarshalling) reconstructs the object from the byte stream on the receiving end.

• Mechanism: The generated message code includes methods for these operations.
• Critical For: Network communication (ROS topics/services) and data logging (ROS bags).