Parameters: Dynamic Node Configuration

Parameters are key-value pairs used to configure node behavior at runtime. Each parameter consists of a string name and a value of supported types: bool, int64, float64, string, or byte. Unlike topics or services, parameters are not used for data exchange but for tuning node settings dynamically. To inspect available parameters of a running node: ``` ros2 param list

For detailed metadata about a specific parameter: ```
ros2 param describe /turtlesim background_b

This reveals the parameter’s name, type, description, and constraints such as min/max bounds. To retrieve its current value: ``` ros2 param get /turtlesim background_b

To modify a parameter value temporarily: ```
ros2 param set /turtlesim background_b 200

These changes are volatile—they vanish when the node restarts. To persist them, export the current parameter set to a YAML file: ``` ros2 param dump /turtlesim > turtlesim.yaml

On subsequent launches, restore the configuration: ```
ros2 param load /turtlesim turtlesim.yaml

Alternatively, start the node directly with a preloaded configuraton: ``` ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml

### Implementing Parameters in C++

In a custom node derived from `rclcpp::Node`, parameters are declared and accessed using built-in methods: | Method | Description |
|---|---|
| `declare_parameter` | Declare and initialize a single parameter |
| `declare_parameters` | Declare multtiple parameters at once |
| `get_parameter` | Retrieve a parameter’s current value |
| `get_parameters` | Fetch all parameters matching a prefix |
| `set_parameters` | Update multiple parameters atomically |

In a book-selling node, to allow dynamic pricing: ```
class BookSellerNode : public rclcpp::Node
{
public:
    BookSellerNode(const std::string& name) : Node(name)
    {
        // Declare parameter with default value
        this->declare_parameter<int64_t>("book_price", 1);
    }

private:
    int64_t book_price_ = 1;

    void handle_purchase_request(
        const village_interfaces::srv::SellBook::Request::SharedPtr request,
        const village_interfaces::srv::SellBook::Response::SharedPtr response)
    {
        // Fetch updated price at time of request
        this->get_parameter("book_price", book_price_);

        int64_t quantity = request->money / book_price_;
        response->books_given = quantity;
    }
};

After compiling and launching the node, external tools can adjust pricing in real time: ``` ros2 param set /book_seller book_price 3

The node immediately responds to the new value without restarts. ### Actions: Managing Long-Running Tasks

Actions are designed for tasks that take time to complete, require progress feedback, and may be canceled. Unlike services—which return a single response—actions provide a three-part interaction model: - **Goal**: Client sends a target (e.g., rotate turtle to 1.5 radians).
- **Feedback**: Server periodically reports progress (e.g., "30% complete").
- **Result**: Final outcome upon task completion or cancellation.

Under the hood, an action is implemented via three services and two topics: - *Goal service*: Accepts new tasks
- *Result service*: Returns final outcome
- *Cancel service*: Terminates ongoing tasks
- *Feedback topic*: Streamed progress updates
- *Status topic*: Tracks task state (active, pending, completed)

List available actions: ```
ros2 action list

View the interface structure: ``` ros2 interface show turtlesim/action/RotateAbsolute

Output: ```
# Request
float32 theta
---
# Response
float32 delta
---
# Feedback
float32 remaining

To initiate a rotation: ``` ros2 action send_goal /turtle1/rotate_absolute turtlesim/action/RotateAbsolute "{theta: 1.57}"

Add real-time feedback by appending `--feedback`: ```
ros2 action send_goal /turtle1/rotate_absolute turtlesim/action/RotateAbsolute "{theta: 1.57}" --feedback

To cancel a running action: ``` ros2 action cancel /turtle1/rotate_absolute

In the `turtlesim` keyboard controller, keys like `G`, `B`, `V` trigger rotation goals, while `F` cancels them—demonstrating action-based control. ### Choosing the Right Mechanism

- **Topics**: High-frequency, one-way streaming (e.g., sensor data)
- **Services**: Synchronous, one-off requests with immediate responses (e.g., "get map")
- **Parameters**: Static or infrequently changed configuration (e.g., max speed, color themes)
- **Actions**: Long-running, cancellable tasks with progress (e.g., navigation, arm movement)

Template functions like `declare_parameter<T>` enforce strict type safety. Using an unsupported type (e.g., `double` instead of `float64`) results in compile-time or runtime errors. Always match parameter types to ROS 2’s defined schema. </div>