How to reconfigure controller

[firesurfer]

Is your feature request related to a problem? Please describe.

I would like to reconfigure controller which already has been active at some point in order to change a parameter which is read in the on_configure method of the controller.

In particular I want to change the compliance_ref_link of the the cartesian_compliance_controller to another link:

https://github.com/fzi-forschungszentrum-informatik/cartesian_controllers/blob/752a6a928f6584597ea4b8bace047ec7fdc2314d/cartesian_compliance_controller/src/cartesian_compliance_controller.cpp#L97

Describe the solution you'd like

Allow setting controller state to configured via cli.

Describe alternatives you've considered

Having a separate controller per ref_link. But this becomes quickly quite ugly when having multiple robot arms with multiple tools which have to be compliant at some point.

[firesurfer]

As there weren't any answers yet I guess this functionality is not implemented yet?

[destogl]

Hi @firesurfer,

you have two options here. Use controller lifecycle to again configure the controller, or you can use dynamic reconfigure. generate_parameter_library that we use integrated this by default. Then you can update parameters in any state – which might be possible depending on the controller or use-case.

You should be able to set controller state via CLI, either using set_controller_state service (not sure if fully integrated yet) or calling switch_controllers to deactivate it and then cleanup to unconfigure it.

[firesurfer]

Hi @destogl sorry for my really late answer. For some reason I sometimes do not get a notification email from github.

I currently worked around the issue by simply having multiple controllers for all configurations that I need. I recently revisited that part of the setup and I still think it is a very ugly solution. As it will be unlikely that the cartesian compliance controllers will be changed soon I come back to this issue.

So to recap the initial issue:

The cartesian compliance controller setup their kinematic chains in the on_configure method.
Ideally the workflow would then be: Bring the controller into unconfigured state set the parameters configure and activate it again.

As far as I can see there is no way currently of having the controller run on_configure again once it has been loaded with the provided cli tools?
I am note sure how I am supposed to call cleanup via the cli or a ros service?

[christophfroehlich]

Is it feasible to do that in on_activate instead of on_configure? Our current best-practice is afaik

• declare parameters in the on_init
• parse all parameters and check read-only parameters in on_configure manually, if not done already by generate_parameter_library like combination of parameters
• if parameters changed, parse them again in on_activate and check dynamic parameters manually, if not done already by generate_parameter_library like combination of parameters
• if desired, do that again in the update method, e.g., controller gains.

[firesurfer]

That is basically what I implemented in: fzi-forschungszentrum-informatik/cartesian_controllers#129

Unfortunately this introduces some rather heavy load in the on_activate method. Additionally it doesn't look like @stefanscherzinger will find anytime soon to review that PR.

Nevertheless I think it would be a great addition to ros2control if we were able to rerun on_configure in a controller!.

[saikishor]

That is basically what I implemented in: fzi-forschungszentrum-informatik/cartesian_controllers#129

Unfortunately this introduces some rather heavy load in the on_activate method. Additionally it doesn't look like @stefanscherzinger will find anytime soon to review that PR.

Nevertheless I think it would be a great addition to ros2control if we were able to rerun on_configure in a controller!.

Hello!

Right now, the only way to configure a controller is by deactivating the controller and calling again the configure_controller service

ros2_control/controller_manager/src/controller_manager.cpp

Lines 735 to 750 in c4affe4

	auto new_state = controller->get_state();
	if (state.id() == lifecycle_msgs::msg::State::PRIMARY_STATE_INACTIVE)
	{
	RCLCPP_DEBUG(
	get_logger(), "Controller '%s' is cleaned-up before configuring", controller_name.c_str());
	// TODO(destogl): remove reference interface if chainable; i.e., add a separate method for
	// cleaning-up controllers?
	new_state = controller->get_node()->cleanup();
	if (new_state.id() != lifecycle_msgs::msg::State::PRIMARY_STATE_UNCONFIGURED)
	{
	RCLCPP_ERROR(
	get_logger(), "Controller '%s' can not be cleaned-up before configuring",
	controller_name.c_str());
	return controller_interface::return_type::ERROR;
	}
	}

(or)

deactivate the controller -> unload the controller -> load the controller -> configure the controller

However, @destogl and @bailaC are working on a new service called cleanup_controller or unconfigure_controller, where you can unconfigure the controller and configure it again through services. This will make it upstream soon

[firesurfer]

That sounds good.
But in case of cleanup being called will the changed parameters survive?

This is the problem with unloading the controller in this case and reloading it again because in this case the node is destroyed and on reload populated with the parameters from the controller.yaml.

[saikishor]

But in case of cleanup being called will the changed parameters survive?

I'm not sure about this part, please try it out and let us know. It would be really helpful

Thank you

[firesurfer]

So I just tested it and it seems to be successful (apart from the fact that the cartesian controller checks if it was already configured and then returns immediately - but this is another problem)

What I did was:

a) Load one one of the cartesian controllers
b) Changed one of the parameters via ros2 param set
c) Deactivated the controller
d) Ran ros2 service call /controller_manager/configure_controller controller_manager_msgs/srv/ConfigureController "{name: cartesian_motion_controller_top}"
e) Activated the controller again
f) Checked if the changed param is the same via ros2 param get

[saikishor]

@firesurfer Thanks good to know about this
So, once you fix that m_configured parameter, I think it should work straight out of the box

[firesurfer]

Would be nice if this call could be integrated in the cli tooling.
But I close this issue as it is solved!