[Question] Controller stacking mechanics

[adolfo-rt]

I've been looking into the architecture of the robot_controllers project, and have had some trouble figuring out how controlling stacking works. I see that:

1. robot_controllers::Controller allows controllers to have access to other controllers by querying the robot_controllers::ControllerManager for a handle that can be dynamic_cast'ed to a controller.
2. robot_controllers::ControllerManager is responsible for updating all controllers.

but I'm not sure I understand the usage pattern, and have failed to find examples.

I can see that a controller can use another controller's interface, but there seems to be no mechanism to control the order in which controllers get updated, other than the order in which they are loaded. My understanding is that all controllers live in a "controller soup", with no explicit topological dependencies between them to enforce that every controller has the most recent input. In the "controller soup" scenario, a controller stack of size n has a worst-case delay of n control cycles until hardware state readings propagate to the last controller in the stack.

Am I interpreting this correctly?.

[mikeferguson]

Hmm. It appears you've actually found a bug -- at some point along the way I refactored the internals (see https://github.com/fetchrobotics/robot_controllers/commit/aa083295cde1f8f961d40b2005bfbbafbf1dce03) and removed the "active" list. In this earlier version, the order of execution was based upon the order in which controllers were started not the order of loading.

As for the desired usage, a simple example I have been using is that of a cartesian twist controller, which outputs a wrench command into a cartesian wrench controller. That said, I haven't actually implemented these and thus far we are primarily stacking just GravityCompensation + FollowJointTrajectory (which have no interaction, and their outputs are simply being summed, so the order of execution does not matter)

[adolfo-rt]

Hmm. It appears you've actually found a bug -- at some point along the way I refactored the internals (see aa08329) and removed the "active" list. In this earlier version, the order of execution was based upon the order in which controllers were started not the order of loading.

OK, that makes sense. It seemed odd that stopped controllers were getting updated.

As for the desired usage, a simple example I have been using is that of a cartesian twist controller, which outputs a wrench command into a cartesian wrench controller.

But there is no way to enforce that the computation graph spanned by controller dependencies is evaluated in the correct order, right?. Even if the above bug is fixed, controllers will be updated in the order in which they are started, as the robot_controllers::ControllerManager does no explicit reasoning on the (implicit) computation graph.

If the above is true, users need to be very careful with the start order of controller stacks with tight feedback loops, as adding unwanted control delays can affect performance negatively.

That said, I haven't actually implemented these and thus far we are primarily stacking just GravityCompensation + FollowJointTrajectory (which have no interaction, and their outputs are simply being summed, so the order of execution does not matter)

Yes, but in this scenario there is no controller stacking. The relevant mechanism that is operating is resource claiming / resource conflict handling. In your particular example, you address it by making the FollowJointTrajectory claim the resources it uses, and by making the GravityCompensation claim none, avoiding possible conflicts, even under an exclusive resource ownership policy.

I've been meaning to ask some questions on the ROS-ng SIG related to ROS 2.0 and writing control code, but before I wanted to look around at how people are addressing typical problems.

Thanks for your answers @mikeferguson. Closing as the main question is addressed. Feel free to add any additional comments.