Controller restart

[mhubii]

Hi All, and thanks for the great work you put into this project. I have a question regarding restarting the controllers. In the previous ros_control, the controller manager was capable of restarting the controllers, see https://github.com/ros-controls/ros_control/blob/83a392bafa1ec01dc77ec2a592f3b74a783f3faa/controller_manager/src/controller_manager.cpp#L70.

So if the hardware signals the SystemInterface it was restarted, how would one reload/reset the controllers, ie how would the ControllerManager be notified? Is there a simple way to achieve this?

[mhubii]

Closing this and asking in the forum..

[mhubii]

following a discussion here https://discourse.ros.org/t/ros2-control-controller-restart/24662, a temporary solution to restarting the controllers can be achieve through #677.

I am now facing the following issue: On re-loading the controllers, it appears to me that the commanded states are not updated to the current state.

Let me elaborate. I am controlling a KUKA LBR robot through the Fast Robot Interface. The robot may change the position without the user being able to send commands. When sending commands becomes possible again, the current state is not equal to the previously commanded state. ros2_control then tries to immediately bring the robot back to the previously commanded state.

Is this the case, or do I have some cached variable somewhere else? Thank you for your help, kind regards

[mhubii]

in the SystemInterface, one may set the command interfaces to the state interfaces after re-loading the controllers to mitigate this behaviour. But not sure if this is the SystemInterface's task

[destogl]

in the SystemInterface, one may set the command interfaces to the state interfaces after re-loading the controllers to mitigate this behaviour. But not sure if this is the SystemInterface's task

~~IMO, this is the correct solution. Your hardware interface has the storage of values for interface, and only hardware interfaces know exact moment when interfaces (commands) should be reseted. Everything else could cause race conditions. When hardware is re-activated, I would at least invalidate command interfaces, e.g., set them to NaN (std::limits::quiet_nan()).~~

Ok, thinking more about this. which controller are you using and in which configuration? Most of the controllers are resetting command interfaces to states when activated. Maybe we have some bug.

[mhubii]

might definitely be some bug on my side. I am using the JointTrajectoryController, but through the MoveItSimpleControllerManager. So chances are Moveit2 causes this behavior. I'll strip away the Moveit2 stuff and check if the issue persists. Thanks for thinking it through

[destogl]

might definitely be some bug on my side. I am using the JointTrajectoryController, but through the MoveItSimpleControllerManager. So chances are Moveit2 causes this behavior. I'll strip away the Moveit2 stuff and check if the issue persists. Thanks for thinking it through

This should not actually cause this behavior. Let us know if you are still struggling.

[Tuebel]

I have struggled with a similar Problem, specifically with a KUKA iiwa, too. However I have only used ros_control in ROS 1 yet. In my case the error was, that I reset the controller but forgot to reset the safety (saturation & soft) limits. These would override the controller commands and sent old commands. This caused very unsafe and jerky motions which triggered the limits on the KUKA controller and caused it to stop with an error.