Added example_17: chained controllers for diff drive using effort interface and Gazebo.

[peci1]

General

This combination is actually a part of the system described in https://control.ros.org/rolling/doc/ros2_control/controller_manager/doc/controller_chaining.html#motivation-purpose-and-use .

I think people quite often try to create a diff drive robot in Gazebo + ROS 2 control and all tutorials they find are actually scr***ng up physics by using the velocity interface. This is an example on how to properly do a diff drive robot in Gazebo.

New Examples

If you propose adding a new example, make sure that your new example has:

• The correct folder structure (described in the main README.md)
• Example has doc/README.rst with description
• Detailed commands how to run an example
• Output examples of CLI commands
• Screenshots with expected visualizations (if applicable)

[Juliaj]

This is a fascinating topic! Gazebo is new to me, and I’m eager to learn more. Could you include specific scenarios or examples to highlight the differences between control over effort versus velocity? With these, we could potentially streamline the tutorial steps by reducing overlap with example_16 and provide developers with more insights for simulation.

[christophfroehlich]

Thanks for your initiative! I know exactly what you want to showcase w.r.t. the physics engine. But I'm a bit reluctant in making your proposal a best practice.

• ros2_control setup ideally should be the same for real hardware and simulation, and just be exchangeable by swapping the hardware_component plugin. And torque-controlled diff-drives are rare, I would say.
• This means that the simulation plugin should deal with this by implementing "something" in between velocity input and physics engine.
• This comes to Port PID controller to contro joint using effort gz_ros2_control#306
• In a more advanced simulation setup, one would include identified actuator dynamics in the simulation plugin, which can be done by inheriting from gz_ros2_control, see the (vague, unfortunately) instruction in the docs.

Summarized, I propose adding such a custom plugin as an extension variant to the existing example_16, because this is IMHO the way to do it and perfectly enhances the existing example with a more sophisticated simulation.

[peci1]

Thanks all for the comments. I'm on vacation this week, so I'll have a look at them next week.

[peci1]

I know about ros-controls/gz_ros2_control#306 and I guess that would really be the best way. However, I don't have the resources to finish ros-controls/gz_ros2_control#306 .

At the same time, I'm not happy with the state when the ROS2 control tutorials only provide a broken approach (wrong physics) and it may even seem it is the preferred one.

What about this course of actions:

1. Add a warning to the tutorial in this PR that the presented approach is not ideal and after Port PID controller to contro joint using effort gz_ros2_control#306 is merged, it will be suboptimal.
   1. Possibly also expand this tutorial with a section describing the difference between velocity and torque control in simulation.
2. Add a warning to example 16 that the presented approach breaks physics interactions and link to tutorial 17.
3. Create an issue here to merge 16 and 17 together once Port PID controller to contro joint using effort gz_ros2_control#306 is merged.

[saikishor]

@peci1 The PR itself looks fine itself and should be functional.

However, the motivation behind the example is something I don't encourage. If it is done somehow to show the functional integration with an effort based actuator, then it should be good. IMHO Just because the Gazebo physics are bad for the velocity interface, shouldn't drive this example. I agree with @christophfroehlich that the ecosystem developed should be agnostic, as that's the general idea of ros2_control.

[peci1]

That depends on the interface the robot provides. We, for example, have a robot that directly provides cmd_vel control via a micro-ROS MCU because it has a non-standard locomotion system and individual joints should not be controlled by the user. So the ROS interface on the main PC doesn't run ros_control at all. And ros_control is used only to fill this gap between what the simulator provides (velocity/effort control of individual joints) and what the real robot provides (diff-drive-like control).