Over in this ros_control_boilerplate PR we found an inconsistency in the handling of a RobotHWs prepareSwitch() and doSwitch() function between normal operation (i.e. just using a controller_manager with a single RobotHW) and usage inside a combined_robot_hw.
A scenario where the inconsistency is visible is the loading of a controller that does not claim any resources (e.g. a joint_state_controller):
- If a
controller_manager directly handles a RobotHW, it will call the RobotHWs prepareSwitch and doSwitch functions with a start_list containing the controller info about the controller.
- If a
controller_manager handles multiple RobotHWs through a combined_robot_hw, the combined_robot_hw will filter the start_list and stop_list based on the claimed resources. As no hardware interface has any resources that are claimed by the controller (obviously), the same functions get called with empty start_list and stop_list.
I can't think of any use case where this would be a real problem - and changing the behavior of either combined_robot_hw or controller_manager would surely break some working setups. That's why i think adding some documentation for this special quirk of combined_robot_hw would be best.
I'd be happy to provide a PR with this documentation, but hope to first get some feedback on this - Am i just overlooking something really obvious / is there any obvious change that would remove this inconsistency?
For completeness, here are some examples from the linked PR showing the described behavior:
- Loading a hardware interface directly in a
controller_manager:
[...]
Loaded 'joint_state_controller'
Loaded 'position_trajectory_controller'
[ INFO] [1608059009.336061045]: prepareSwitch (nh: /rrbot):
[ INFO] [1608059009.336108133]: + joint_state_controller
[ INFO] [1608059009.339490340]: doSwitch (nh: /rrbot):
[ INFO] [1608059009.339531124]: + joint_state_controller
Started ['joint_state_controller'] successfully
[ INFO] [1608059009.343537246]: prepareSwitch (nh: /rrbot):
[ INFO] [1608059009.343579910]: + position_trajectory_controller
[ INFO] [1608059009.346152074]: doSwitch (nh: /rrbot):
[ INFO] [1608059009.346195179]: + position_trajectory_controller
Started ['position_trajectory_controller'] successfully
[...]
- Two hardware interfaces are managed through a
combined_robot_hw:
[...]
Loaded 'joint_state_controller'
Loaded 'position_trajectory_controller'
[ INFO] [1608063130.022795073]: prepareSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_1_hw):
[ INFO] [1608063130.022841212]: prepareSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_2_hw):
[ INFO] [1608063130.026187157]: doSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_1_hw):
[ INFO] [1608063130.026236738]: doSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_2_hw):
Started ['joint_state_controller'] successfully
[ INFO] [1608063130.029357874]: prepareSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_1_hw):
[ INFO] [1608063130.029399325]: + position_trajectory_controller
[ INFO] [1608063130.029440723]: prepareSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_2_hw):
[ INFO] [1608063130.029463272]: + position_trajectory_controller
[ INFO] [1608063130.029528641]: doSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_1_hw):
[ INFO] [1608063130.029575905]: + position_trajectory_controller
[ INFO] [1608063130.029625720]: doSwitch (nh: /rrbot/rrbot_combined_hardware_interface/joint_2_hw):
[ INFO] [1608063130.029667801]: + position_trajectory_controller
Started ['position_trajectory_controller'] successfully
[...]
Over in this
ros_control_boilerplatePR we found an inconsistency in the handling of aRobotHWsprepareSwitch()anddoSwitch()function between normal operation (i.e. just using acontroller_managerwith a singleRobotHW) and usage inside acombined_robot_hw.A scenario where the inconsistency is visible is the loading of a controller that does not claim any resources (e.g. a
joint_state_controller):controller_managerdirectly handles aRobotHW, it will call theRobotHWsprepareSwitchanddoSwitchfunctions with astart_listcontaining the controller info about the controller.controller_managerhandles multipleRobotHWs through acombined_robot_hw, thecombined_robot_hwwill filter thestart_listandstop_listbased on the claimed resources. As no hardware interface has any resources that are claimed by the controller (obviously), the same functions get called with emptystart_listandstop_list.I can't think of any use case where this would be a real problem - and changing the behavior of either
combined_robot_hworcontroller_managerwould surely break some working setups. That's why i think adding some documentation for this special quirk ofcombined_robot_hwwould be best.I'd be happy to provide a PR with this documentation, but hope to first get some feedback on this - Am i just overlooking something really obvious / is there any obvious change that would remove this inconsistency?
For completeness, here are some examples from the linked PR showing the described behavior:
controller_manager:combined_robot_hw: