Custom message definitions let you create your own data types to send between parts of a robot system. This helps you share exactly the information you need.
You want to send sensor data that is not covered by standard messages.
You need to communicate complex information like robot status with multiple fields.
You want to define a message with custom units or formats.
You are building a new robot feature that requires special data.
You want to organize related data together for easier handling.
Syntax
ROS
# Example of a custom message file (MyMessage.msg)
int32 id
string name
float64[] values
bool is_active
Each line defines one field with its type and name.
Use standard ROS message types like int32, string, float64, bool, or arrays with [].
Examples
A simple message with a number and a text label.
ROS
int32 count
string label
A weather message with numbers and a true/false value.
ROS
float64 temperature
float64 humidity
bool is_raining
A message with lists of strings and numbers.
ROS
string[] names
int32[] scores
Sample Program
This example shows a custom message called MyRobotStatus with three fields. The Python node publishes this message every second with example data. The log shows the sent values.
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
Step 1: Understand default values in ROS messages
Boolean fields default to false when a message is created without explicit initialization.
Step 2: Evaluate options
false is false, which matches the default. Options A and B represent true values, and C is invalid for bool.
Final Answer:
false -> Option A
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
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.
Step 2: Verify field naming and formatting
Lowercase field names are allowed, and no blank line is required at the end.
Final Answer:
No error; the message definition is correct -> Option D
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
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.
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.
Final Answer:
std_msgs/Header header
string command -> Option C
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.