Custom message definition in ROS - Step-by-Step Execution

Concept Flow - Custom message definition

Create .msg file

↓

Define fields with types

↓

Build package to generate code

↓

Use message in publisher/subscriber

↓

Send and receive structured data

You write a .msg file with fields, build the package to generate code, then use the message in ROS nodes to send structured data.

Execution Sample

ROS

string name
int32 age
float64 height

Defines a custom message with a string, an integer, and a float field.

Execution Table

Step	Action	Input/Code	Result
1	Create .msg file	Person.msg	File created with fields
2	Define fields	string name int32 age float64 height	Fields set in message definition
3	Build package	catkin_make or colcon build	Code generated for message
4	Use message	Publisher publishes Person message	Message sent with structured data
5	Subscribe message	Subscriber receives Person message	Data accessible in subscriber node
6	Exit	All steps done	Custom message ready and used in ROS nodes

💡 All steps complete, custom message defined and used successfully

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Person.msg	Not created	Created with fields	Code generated	Used in publisher	Used in subscriber

Key Moments - 3 Insights

Why do I need to build the package after creating the .msg file?

Building generates the code needed to use the custom message in ROS nodes, as shown in execution_table step 3.

Can I use the custom message before building the package?

No, because the message code does not exist until after building, so publisher or subscriber cannot use it (see step 4).

What happens if I change the .msg file after building?

You must rebuild the package again to update the generated code, otherwise nodes use old message definitions.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the message code generated?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Result' column for step 3 in execution_table

According to variable_tracker, what is the state of Person.msg after step 4?

A Used in publisher

B Not created

C Created with fields

D Code generated

💡 Hint

Look at the 'After Step 4' column for Person.msg in variable_tracker

If you skip building the package, what will happen when you try to publish the custom message?

A Subscriber will receive default messages

B Message will publish correctly

C Publisher will fail due to missing message code

D Message fields will be empty but no error

💡 Hint

Refer to key_moments about why building is necessary

Concept Snapshot

Custom message definition in ROS:
- Create a .msg file with field types and names
- Build the package to generate message code
- Use the message in publisher and subscriber nodes
- Rebuild after any .msg changes
- Enables sending structured data between nodes

Full Transcript

In ROS, to define a custom message, you create a .msg file listing fields with their types. Then you build your package to generate the necessary code for that message. After building, you can use the message in your publisher and subscriber nodes to send and receive structured data. If you change the .msg file, you must rebuild again to update the code. This process ensures your nodes communicate using your custom data structure.

Practice

1. What is the main purpose of defining a custom message in ROS?

easy

A. To send specific data types tailored to your robot's needs

B. To create new robot hardware components

C. To write Python scripts for robot control

D. To install ROS packages automatically

Solution

1. Step 1: Understand the role of custom messages

   Custom messages allow you to define exactly what data your robot nodes exchange.

2. Step 2: Compare with other options

   Options B, C, and D relate to hardware, scripting, or package management, not message definition.

3. Final Answer:

   To send specific data types tailored to your robot's needs -> Option A

4. Quick Check:

   Custom messages = tailored data [OK]

Hint: Custom messages define data, not hardware or scripts [OK]

Common Mistakes:

• Confusing message definition with hardware setup
• Thinking custom messages are scripts
• Assuming messages install packages

2. Which of the following is the correct syntax to define a field named speed of type float32 in a ROS .msg file?

easy

A. speed float32

B. float32 speed

C. float speed32

D. float speed

Solution

1. Step 1: Recall ROS message field syntax

   In ROS .msg files, the type comes first, then the field name, e.g., float32 speed.

2. Step 2: Check each option

   float32 speed matches the correct syntax. Options B, C, and D have incorrect order or wrong types.

3. Final Answer:

   float32 speed -> Option B

4. Quick Check:

   Type before name in .msg files [OK]

Hint: Type first, then field name in .msg files [OK]

Common Mistakes:

• Swapping field name and type order
• Using incorrect type names
• Omitting the type or name

3. Given this custom message definition in RobotStatus.msg:

bool is_active
float32 battery_level
string status_message

What will be the default value of is_active when a new message is created in a ROS node?

medium

A. false

B. 1

C. null

D. true

Solution

1. Step 1: Understand default values in ROS messages

   Boolean fields default to false when a message is created without explicit initialization.

2. Step 2: Evaluate options

   false is false, which matches the default. Options A and B represent true values, and C is invalid for bool.

3. Final Answer:

   false -> Option A

4. Quick Check:

   Boolean default = false [OK]

Hint: Boolean fields default to false unless set [OK]

Common Mistakes:

• Assuming booleans default to true
• Confusing null with default values
• Using numeric 1 instead of boolean true

4. You wrote this in your SensorData.msg file:

int32 temperature
float64 humidity
string location

But when building your ROS package, you get an error. What is the likely cause?

medium

A. Using float64 instead of float32 is invalid in ROS messages

B. Field names cannot be lowercase

C. Missing blank line at the end of the file

D. No error; the message definition is correct

Solution

1. Step 1: Check ROS message type validity

   ROS supports float64 as a valid type, so Using float64 instead of float32 is invalid in ROS messages is incorrect.

2. Step 2: Verify field naming and formatting

   Lowercase field names are allowed, and no blank line is required at the end.

3. Final Answer:

   No error; the message definition is correct -> Option D

4. Quick Check:

   Valid types and names mean no error [OK]

Hint: ROS supports float64 and lowercase names [OK]

Common Mistakes:

• Thinking float64 is invalid
• Assuming field names must be uppercase
• Expecting blank line at file end

5. You want to define a custom message RobotCommand.msg that includes a nested message Header from the standard ROS messages and a custom field command of type string. Which is the correct way to define this?

hard

A. Header header
string command

B. header Header
command string

C. std_msgs/Header header
string command

D. Header: std_msgs/Header
string command

Solution

1. Step 1: Understand nested message syntax in ROS

   To use a message from another package, you must prefix the type with the package name, e.g., std_msgs/Header.

2. Step 2: Check each option

   std_msgs/Header header string command correctly uses std_msgs/Header header. Header header string command misses the package prefix, C reverses type and name, D uses invalid syntax.

3. Final Answer:

   std_msgs/Header header string command -> Option C

4. Quick Check:

   Use package/type for nested messages [OK]

Hint: Prefix nested types with package name [OK]

Common Mistakes:

• Omitting package name for nested messages
• Swapping field name and type
• Using colon syntax incorrectly