Documentation for model-based controllers

[v8p1197]

This PR updates ros2_controller's documentation to open the possibility of creating model-based controllers, e.g. gravity compensantion PD controllers or inverse dynamics controllers.

To access the robot dynamics model, the inverse dynamics solver is proposed (here the release repository).
The solver will be soon released via rosdep for humble (here the updated rosdistro index).

[christophfroehlich]

Thank you very much for your proposal. But this is not at all related to ros2_control(lers), right? IMHO this does not fit to control.ros.org.

But it would be great to add such a control low to a generic ros2_controller implementation. Do you want to work in this direction? I'm not sure if your solver is better than pinocchio for example, convince us ;)

[v8p1197]

Hi @christophfroehlich, thank you very much for your feedback.

With this PR, our goal is to invite other members of the ROS2 community to write model-based control laws, for which one should access the specific robot's dynamics model.
To favor robot-agnosticism in such new ROS2 controllers, the solver we mention in this PR exposes a common interface, that can be specialized according to the user's needs, in a pluginlib-based fashion.
This is a fundamental utility for model-based controllers!

You're right in mentioning Pinocchio: it is an example of a dynamics library to compute the dynamic matrices (inertia, coriolis, etc.), similar to KDL.
For the latter, we already proposed an adapter (through a concrete class) here.
In the future, we can work on developing a new adapter based on Pinocchio, to favor computational efficiency, as you suggested :).

However, both KDL and Pinocchio work on URDF descriptions, for which the inertial tags might not match real manipulators' dynamics (e.g., nonlinear friction is disregarded).
So, to provide examples of how our solver can be extended on real robots, we developed concrete solvers for the real UR10 and Franka arms.
These are only some examples, but the interface can be extended as needed.

Since all these classes are exported as plugins, one can choose the specific solver (KDL, Pinocchio, etc.) via configuration, and develop robot-agnostic controllers regardless of the particular implementation.
This is similar to kinematics_interface_kdl and kinematics_interface_pinocchio, but with dynamics terms.
We have already had a preliminary discussion about this on ROS discourse.

I'm not sure if your solver is better than pinocchio for example, convince us ;)

The solver's goal is not competing with Pinocchio: indeed, in the future we might use Pinocchio too, as I said above.
To clarify the advantage of this plugin-based library, one can do, for instance,

// Initialize inverse dynamics solver class loader
inverse_dynamics_solver_loader_ = std::make_unique<InverseDynamicsSolverLoader>("inverse_dynamics_solver", "inverse_dynamics_solver::InverseDynamicsSolver");
// Load inverse dynamics solver plugin
inverse_dynamics_solver_ = inverse_dynamics_solver_loader_->createUniqueInstance("kdl_inverse_dynamics_solver/InverseDynamicsSolverKDL");  // or...
inverse_dynamics_solver_ = inverse_dynamics_solver_loader_->createUniqueInstance("ur10_inverse_dynamics_solver/InverseDynamicsSolverUR10");  // or...
inverse_dynamics_solver_ = inverse_dynamics_solver_loader_->createUniqueInstance("franka_inria_inverse_dynamics_solver/InverseDynamicsSolverFrankaINRIA");  // or...
inverse_dynamics_solver_ = inverse_dynamics_solver_loader_->createUniqueInstance("pinocchio_inverse_dynamics_solver/InverseDynamicsSolverPinocchio");  // ... or other plugins
// Initialize Inverse Dynamics Solver
inverse_dynamics_solver_->initialize(node_->get_node_parameters_interface(), "ns", robot_description_);  // Initialize model with robot description

and write the related control laws as suggested in this PR, i.e.

Eigen::MatrixXd B = inverse_dynamics_solver_->getInertiaMatrix(position);  // and other terms...
// Use B and other terms in the control law

instead of being dependent on a specific (e.g. Pinocchio-based) implementation like

pinocchio::Model model;  // Create model here...
pinocchio::Data data;
pinocchio::crba(model, data, position);
data.M.triangularView<Eigen::StrictlyLower>() = data.M.transpose().triangularView<Eigen::StrictlyLower>();
Eigen::MatrixXd B = data.M;
// Use B and other terms in the control law

In summary, based on your considerations:

this is not at all related to ros2_control(lers), right? [...] But it would be great to add such a control low to a generic ros2_controller implementation

Right, we are not proposing new controllers, but we are providing the right tool to write new model-based controllers in the future.

Do you want to work in this direction?

Yes, we are planning on working on new model-based controllers, using the solver we have developed, but we believe this PR might be an entry point for other users in the same direction ;)

I hope this clarifies our proposal, please let me know what you think :)

[christophfroehlich]

I still don't think this is the right place to put this. I have the feeling that announcing your solver should be posted in a discourse post instead. What do the other @ros-controls/ros2-maintainers think?

It could fit better into a new page similar to the wheeled robot kinematics here. But still, this lacks any connection to ros2_controllers, at least a code snippet how to parse the robot description to parameterize the solver etc would be needed.

[v8p1197]

at least a code snippet how to parse the robot description to parameterize the solver etc would be needed.

@christophfroehlich sounds fair :) I can provide the necessary config parameters (in YAML) and code snippets to instantiate/working with the solver in C++ controllers, to facilitate the implementation of future model-based controllers.

[saikishor]

@v8p1197 I agree with @christophfroehlich I also don't feel this is where this should be reflected. Moreover, looking at the commits from the original repo : https://github.com/unisa-acg/inverse-dynamics-solver/commits/main/, it is not a mature project and it is not even a month old and we don't know who will maintain it and its future plans. I don't think it is the right moment or platform to endorse this approach or propose that the community start using it.