You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over in thisros_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:
Over in this
ros_control_boilerplate
PR we found an inconsistency in the handling of aRobotHW
sprepareSwitch()
anddoSwitch()
function between normal operation (i.e. just using acontroller_manager
with 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_manager
directly handles aRobotHW
, it will call theRobotHW
sprepareSwitch
anddoSwitch
functions with astart_list
containing the controller info about the controller.controller_manager
handles multipleRobotHW
s through acombined_robot_hw
, thecombined_robot_hw
will filter thestart_list
andstop_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 emptystart_list
andstop_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
orcontroller_manager
would surely break some working setups. That's why i think adding some documentation for this special quirk ofcombined_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:
controller_manager
:combined_robot_hw
:The text was updated successfully, but these errors were encountered: