Param dump on slam node not working if `stack_size_to_use` is not specified

[MarcoMagriDev]

Required Info:

• Operating System:
  • Ubuntu 24.04
• Installation type:
  • Both
• ROS Version
  • ROS2 Jazzy
• Version or commit hash:
  • Tag 2.8.2
• Laser unit:
  • Simulated

Steps to reproduce issue

ros2 launch slam_toolbox online_async_launch.py slam_params_file:=./my_params.yaml 

where my_params.yaml does not contain a specific value for stack_size_to_use

ros2 param dump /slam_node

Expected behavior

The dump output should contain parameters

Actual behavior

/slam_toolbox:
  ros__parameters: {}

Additional information

After investigating, I suspect the issue is related to how parameters with unspecified values are handled. Specifically, in the code, here:

slam_toolbox/src/slam_toolbox_common.cpp

Line 52 in bf1da76

"stack_size_to_use", rclcpp::ParameterType::PARAMETER_INTEGER, descriptor);

It seems that the /slam_node/get_parameters service returns an empty list when requesting a parameter with an unspecified value.
I'm not sure if this is a ROS-level issue or specific to this package, but the issue might stem from the handling of the stack_size parameter.
The value for stack_size, defined here, will never be used unless you modify this line as follows:

this->declare_parameter(
-      "stack_size_to_use", rclcpp::ParameterType::PARAMETER_INTEGER, descriptor);
+      "stack_size_to_use", stack_size, descriptor);

This would ensure the stack_size value is used properly.

---

If you’d like, I can submit a pull request to fix this. Let me know!

[SteveMacenski]

I believe this is a ROS level issue with dumping that it assumes that all parameters that are listable are also gettable. That is actually not guaranteed and this is an example of somewhere that is not true.

I suggest filing a ticket with the ros2 rcli repository with the param dumping utility mentioning that unset parameters cause dumping to return empty -- that may actually be preferred behavior to those maintainers, I'm not sure. I could see a rational for both cases.

We wouldn't want to set our stack limit from the program default unless a user specified a different value, so I don't think the code change suggestion you provided is the best. I suppose, instead, we could find the program's current value and use that as the default value when declaring the parameter. That would get around the issue on all accounts -- if you wanted to submit a PR and verify that you can obtain the program stack size