Skip to content

[spawner] Controller spawner assumes parameter file is on the target machine #2403

@SuperJappie08

Description

@SuperJappie08

Describe the bug
The spawner (for controllers) assumes (undocumented) that the controller is spawned from the machine running the controller manager.
This is causes issues when providing a parameter file, since it might not exists on the other machine.

I see this is either a bug or an undocumented limitation.

To Reproduce
Steps to reproduce the behavior:

  1. Have a controller manager running on another machine A
  2. Spawn a controller from machine B providing a parameter file that does not exist on machine A
  3. Controller fails to load due to un

The controller manager logs (The warning about the remapping is unrelated).

[ros2_control_node-2] [INFO] [1752830505.928806575] [controller_manager]: Loading controller : 'front_left_response_controller' of type 'wheel_response_controller/WheelResponseController'
[ros2_control_node-2] [INFO] [1752830505.929912864] [controller_manager]: Loading controller 'front_left_response_controller'
[ros2_control_node-2] [WARN] [1752830505.946571654] [controller_manager]: The use of remapping arguments to the controller_manager node is deprecated. Please use the '--controller-ros-args' argument of the spawner to pass remapping arguments to the controller node.
[ros2_control_node-2] [INFO] [1752830505.949093981] [controller_manager]: Controller 'front_left_response_controller' node arguments: --ros-args --params-file /tmp/launch_params_6s26l6mz --params-file /tmp/launch_params_qwvtkivj -r /mirte_base_controller/cmd_vel_unstamped:=/mirte_base_controller/cmd_vel -r ~/tf_odometry:=/tf --params-file ./real_sys_test_controller.yaml
[ros2_control_node-2] [ERROR] [1752830505.956355879] [controller_manager]: Caught exception of type : N6rclcpp10exceptions22RCLInvalidROSArgsErrorE while initializing controller 'front_left_response_controller': failed to parse arguments: Couldn't parse params file: '--params-file ./real_sys_test_controller.yaml'. Error: Error opening YAML file, at ./src/parser.c:271, at ./src/rcl/arguments.c:415

The controller spawner output:

user@MACHINE-B:~/robot_ws$ ros2 run controller_manager spawner front_left_response_controller -p ./real_sys_test_controller.yaml 
[INFO] [1752830495.023721220] [spawner_front_left_response_controller]: waiting for service /controller_manager/list_controllers to become available...
[WARN] [1752830505.776741387] [spawner_front_left_response_controller]: Failed getting a result from calling /controller_manager/list_controllers in 10.0. (Attempt 1 of 3.)
[INFO] [1752830505.827286521] [spawner_front_left_response_controller]: Setting controller param "params_file" to "['./real_sys_test_controller.yaml']" for front_left_response_controller
[INFO] [1752830505.936433316] [spawner_front_left_response_controller]: Setting controller param "type" to "wheel_response_controller/WheelResponseController" for front_left_response_controller
[FATAL] [1752830505.979532973] [spawner_front_left_response_controller]: Failed loading controller front_left_response_controller
[ros2run]: Process exited with failure 1

Expected behavior
The parameters get loaded from machine B, or it is documented that this is a technical limitation.
Furthermore it should probably also be defined that fully qualified paths need to be given (since the controller manager looks relative to its own working directory).

Environment (please complete the following information):

  • OS: Ubuntu 24.04
  • Version Jazzy (but also effects, Kilted and Rolling)
  • It is a custom controller, but it works locally (if the full path is specified since controller_manager is not started from the same folder).

Additional context
It should probably also be clarified that fully qualified paths need to be given (since the controller manager looks relative to its own working directory).
This is probably the result of the parameter files being passed via ros-args, which could make this a technical limitation since parameters cannot be loaded on a node that does not exist.

However, if it is a limitation, it would be nice if it is clearified in the documentation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugpersistentIssue won't get marked as stale

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions