Custom message definition in ROS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output when publishing a custom message with an uninitialized field?

Consider a ROS custom message defined as:

int32 id
string name
float64 value

If a node publishes this message but does not set the value field, what will be the value received by a subscriber?

A The subscriber will receive a random float value in <code>value</code>.

B The <code>value</code> field will be <code>None</code> causing a runtime error.

C The <code>value</code> field will be 0.0 by default.

D The message will fail to publish due to missing <code>value</code>.

💡 Hint

Think about how ROS initializes primitive fields in messages.

In ROS, primitive fields like float64 are initialized to zero if not explicitly set. So the value field will be 0.0 by default.

📝 Syntax

intermediate

Which custom message definition is syntactically correct?

Select the valid ROS custom message definition syntax:

A

int32 id
string name
float64[] values

B

int32 id
string name
float64 values[];

C

int32 id
string name
float64 values[]

D

int32 id;
string name;
float64[] values;

💡 Hint

ROS message definitions do not use semicolons or brackets after the type name.

ROS message files list fields as type name without semicolons. Arrays use type[] name syntax.

🔧 Debug

advanced

Why does this custom message fail to build?

Given this message definition:

int32 id
string name
CustomType data

and CustomType is defined in another package but not imported, why does the build fail?

A The build fails because <code>int32</code> cannot be used with other custom types.

B The build fails because <code>string</code> is not a valid ROS message type.

C The build fails because the message file is missing a semicolon after <code>CustomType data</code>.

D The build fails because <code>CustomType</code> is not imported or referenced properly in the package manifest.

💡 Hint

Check how ROS handles dependencies between message types across packages.

ROS requires that custom message types from other packages be declared as dependencies in the package manifest and imported properly. Missing this causes build errors.

❓ state_output

advanced

What is the value of the array field after publishing this message?

Given the message definition:

int32[] numbers

and the publisher sets numbers = [1, 2, 3], what will the subscriber receive if the publisher later sets numbers = [] and publishes again?

A The subscriber receives the previous array [1, 2, 3].

B The subscriber receives an empty array [].

C The subscriber receives null causing an error.

D The subscriber receives an array with a single zero [0].

💡 Hint

Think about how ROS messages handle empty arrays.

When a publisher sends an empty array, the subscriber receives exactly that empty array.

🧠 Conceptual

expert

What happens if you change a custom message definition after building and do not rebuild dependent packages?

You modify a ROS custom message by adding a new field but do not rebuild the packages that use it. What is the likely outcome when running nodes that use the old build?

A Nodes may crash or behave unpredictably due to message definition mismatch.

B Nodes automatically detect the new field and handle it gracefully.

C The new field is ignored but nodes continue working without issues.

D The ROS master prevents nodes from running until all packages are rebuilt.

💡 Hint

Consider how message serialization depends on exact definitions.

ROS messages are serialized based on their definitions. Changing a message without rebuilding dependent packages causes mismatches leading to crashes or errors.

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