Lecture#

Prerequisites#

One-time workspace and environment setup required before running any code in this lecture.

Parameters#

A parameter is a configurable value that can be used to customize the behavior of a node at runtime without modifying the code. Parameters allow nodes to store and retrieve data, such as tuning constants, file paths, or robot-specific settings.

Resources

Sensor Node Parameters – Real-World Example

Sensor nodes in robotics typically expose many parameters to control hardware behavior. The table below shows example parameters for a camera node and a LiDAR node, along with their update behavior:

Camera Node Parameters

Parameter	Type	Default	Update
`camera_name`	`str`	`"front_cam"`	Freely writable
`camera_frame_id`	`str`	`"cam_link"`	Freely writable
`fps`	`int`	`30`	Timer rebuild
`exposure_auto`	`bool`	`True`	Freely writable
`exposure_time_us`	`int`	`10000`	Freely writable
`brightness`	`int`	`128`	Freely writable
`image_width`	`int`	`1920`	Node restart
`image_height`	`int`	`1080`	Node restart
`encoding`	`str`	`"bgr8"`	Node restart
`camera_info_url`	`str`	`""`	Node restart

LiDAR Node Parameters

Parameter	Type	Default	Update
`lidar_name`	`str`	`"top_lidar"`	Freely writable
`lidar_frame_id`	`str`	`"lidar_link"`	Freely writable
`min_range`	`float`	`0.1`	Freely writable
`max_range`	`float`	`100.0`	Freely writable
`min_angle`	`float`	`-3.14159`	Freely writable
`max_angle`	`float`	`3.14159`	Freely writable
`intensity_threshold`	`float`	`0.0`	Freely writable
`scan_frequency`	`int`	`10`	Timer rebuild
`port`	`str`	`"/dev/lidar0"`	Node restart
`return_mode`	`str`	`"strongest"`	Node restart

Update categories:

Freely writable – the parameter can be changed at runtime and takes effect immediately.
Timer rebuild – the parameter requires canceling and recreating the timer to change its frequency.
Node restart – the parameter is read only during initialization and requires restarting the node to apply changes.

Declaring Parameters#

Parameters must be explicitly declared before they can be accessed within a node. If you try to access a parameter without declaring it first, ROS 2 will throw an error.

Retrieving Parameters#

After declaring a parameter, you might want to retrieve its value with get_value() for several reasons:

Initialization: Parameters are often declared with default values, but you may need to retrieve the actual value to initialize parts of your node or its functionalities based on this configuration.
Dynamic reconfiguration: Parameters can be changed at runtime. Retrieving the parameter allows your node to react to changes and adjust its behavior dynamically.
Operational tuning: Parameters are frequently used for tuning algorithms or adjusting settings for sensors and actuators.

Using Parameters#

Once parameters are stored in class attributes, use them to control node behavior and to provide meaningful context.

Setting Parameters#

Parameters can be set before or during node execution, allowing dynamic configuration without modifying or recompiling the source code.

There are several ways to set parameters:

Pass individual values on the command line (-p).
Hardcode values in a launch file.
Load a YAML parameter file.
Dynamic updates with set_parameters() or ros2 param set.
Expose values as overridable launch file arguments.

Custom Interfaces#

Custom interface definitions allow you to create domain-specific message, service, and action types beyond what std_msgs, geometry_msgs, and sensor_msgs provide.

Resources

Defining a Custom Message (.msg)#

A .msg file defines the fields of a topic message. Each line contains a type and a field name.

Defining a Custom Service (.srv)#

A .srv file defines a request and response separated by ---.

Defining a Custom Action (.action)#

An .action file has three sections separated by ---: goal, result, and feedback.

Services#

Services implement request/response communication between nodes. Unlike topics (continuous data streams), services are used for discrete, one-shot operations that return a result. The client can wait for the response synchronously or asynchronously.

Resources

Service Communication Model

The server advertises the service and waits for requests. When a request arrives, it executes a callback and returns a response.
The client sends a request and waits for the response. The wait can be synchronous (blocking) or asynchronous (non-blocking).
A service is defined by its type (the .srv definition) and its name (e.g., /compute_trajectory).

When to use services vs. topics:

	Topic	Service
Pattern	Publisher/subscriber (1:N)	Client/server (1:1 per call)
Timing	Continuous, periodic	On-demand, one-shot
Examples	Sensor data, `cmd_vel`	Spawn model, compute IK
Blocking?	No	`call()`: yes; `call_async()`: no

Writing a Service Server#

A service server registers a callback that runs when a client sends a request. The callback receives the request, performs computation, populates the response, and returns it.

In this demo we simulate trajectory computation – the server logs the request and returns a success message without actually computing a path.

Writing a Service Client#

A service client creates a connection to a named service, sends a request, and handles the response. Two calling patterns are available:

Asynchronous (call_async()): returns a Future immediately and handles the response in a callback. The node continues spinning while waiting. This is the recommended pattern.
Synchronous (call()): blocks the calling thread until the response arrives. Simpler, but requires a MultiThreadedExecutor and a separate callback group to avoid deadlocks.

Tip

You can call a service directly from the CLI without writing a client node.

Asynchronous Calls#

The asynchronous client sends a request and continues processing other callbacks while waiting for the response. This is the recommended pattern.

Synchronous Calls#

The synchronous client blocks the calling thread until the response arrives. This is simpler but requires careful executor and callback group setup to avoid deadlocks.

Asynchronous vs. Synchronous Comparison

	Async (`call_async()`)	Sync (`call()`)
Blocking	No	Yes, until response arrives
Response	In `_response_callback`	Inline after `call()`
Deadlock risk	None	Yes, without proper setup
Executor	Any	`MultiThreadedExecutor`

Asynchronous (call_async())

Returns a Future immediately (the node keeps spinning).
Response is handled in _response_callback when it arrives.
No risk of deadlock (no thread is ever blocked).
No special executor or callback group required.
Recommended for most use cases.

Synchronous (call())

Blocks the calling thread until the response arrives.
Response is handled inline (no callback needed).
Deadlock-prone if client and timer share the same callback group.
Requires a MutuallyExclusiveCallbackGroup for the client and a MultiThreadedExecutor.
Use only when blocking behavior is explicitly required.

Actions#

Actions extend services with feedback and cancellation for long-running tasks: navigation, arm motion, image processing pipelines, etc.

Note

All demos are text-based – robot movement is simulated with log messages and time.sleep(). No robot or simulator needed.

Resources

When to Use Actions vs. Services

	Service	Action
Duration	Short (< 1 s)	Long (seconds to minutes)
Feedback	None	Periodic progress updates
Cancellation	Not possible	Built-in cancel request
Examples	Spawn model, get map	Navigate to goal, pick & place

Writing an Action Server#

An action server handles incoming goals, publishes feedback during execution, and returns a result.

In this demo we simulate navigation with a countdown loop – no actual robot is moving.

What is goal_handle (Server Side)?

The framework passes a ServerGoalHandle to the execute callback. It is the server’s interface to a specific goal.

Attribute / Method	Purpose
`goal_handle.request`	Access the goal data sent by the client
`goal_handle.publish_feedback(fb)`	Send a feedback update to the client
`goal_handle.succeed()`	Mark the goal as succeeded
`goal_handle.canceled()`	Mark the goal as canceled
`goal_handle.abort()`	Mark the goal as aborted (failure)
`goal_handle.is_cancel_requested`	`True` if a cancel request was accepted

Note

You must call exactly one of succeed(), canceled(), or abort() before returning from the execute callback. This sets the terminal state the client receives.

Goal Handling and Cancellation#

By default, every incoming goal is automatically accepted. Override goal_callback and cancel_callback for finer control over which goals to accept and whether cancellation requests are honored.

Writing an Action Client#

An action client sends a goal, receives feedback updates, and retrieves the final result. The entire flow is asynchronous: each step returns a Future and the node continues spinning.

Tip

You can call an action directly from the CLI without writing a client node.

What is goal_handle (Client Side)?

On the client, future.result() from send_goal_async returns a ClientGoalHandle. This is a different type from the server’s ServerGoalHandle (it is the client’s reference to a specific goal).

Attribute / Method	Purpose
`goal_handle.accepted`	`True` if the server accepted the goal
`goal_handle.get_result_async()`	Request the final result (returns a `Future`)
`goal_handle.cancel_goal_async()`	Send a cancellation request (returns a `Future`)

Warning

Store self._goal_handle = goal_handle in your goal response callback. Without it, you cannot request the result or cancel the goal later.

Communication Pattern#

A summary to help decide when to use each ROS 2 communication mechanism.

Decision Guide

Mechanism	Pattern	Duration	Feedback	Example
Topic	Pub/Sub (1:N)	Continuous	N/A	Sensor data, `cmd_vel`
Service	Req/Resp (1:1)	Short	None	Spawn entity, compute IK
Action	Goal/Feedback/Result	Long	Periodic	Navigate, pick-and-place
Parameter	Get/Set on node	Instant	Callback	Tuning gains, thresholds

Rules of thumb:

If data flows continuously and multiple consumers may need it, use a topic.
If you need a one-shot request with an immediate response, use a service.
If the task takes noticeable time and you need progress or cancellation, use an action.
If you are configuring node behavior without changing its code, use a parameter.

Lecture#

Prerequisites#

Parameters#

Declaring Parameters#

Retrieving Parameters#

Using Parameters#

Setting Parameters#

Custom Interfaces#

Defining a Custom Message (.msg)#

Defining a Custom Service (.srv)#

Defining a Custom Action (.action)#

Services#

Writing a Service Server#

Writing a Service Client#

Asynchronous Calls#

Synchronous Calls#

Actions#

Writing an Action Server#

Goal Handling and Cancellation#

Writing an Action Client#

Communication Pattern#

This Page