Hi @fjp,

If you observe the picture provided here, You can use Ros Control in both, the real platform and the Gazebo model. The only difference is the type of harware_interface you want to use: RobotHWSim or RobotHW.

In the URDF model you need to use always the trasnmissions since they are compulsory to load the proper controllers in the controller_manager. If you look at how you load ros_control in Gazebo you can see that a plugin is used, libgazebo_ros_control, in which it is stated the type of interface to be used with <robotSimType>gazebo_ros_control/DefaultRobotHWSim</robotSimType> which is connected with the transmissions with the transmission tag.

Furthermore, as described here in order to implement this in a real platform you may need to write you own hw_interface as explained here.

Hi @Weasfas thanks for your help. As far as I know the controller_manager loads the controllers specified in the launch file using the spawner node and doesn't use the transmissions inside the urdf. Do you know where the transmission tag from the urdf is used (in the controller_manager or the controller itself)?

And I still don't know exactly what to do with the transmission in the hardware_interface::RobotHW. Do I need to use something from the transmission_interface documentation? From the examples in the docs, it seems to be required inside the read() and write() methods. But I would like to know if it is mandatory?

To simplify things I would say: transmission are always needed because they are the elements used to map between joints and actuators, if you not provide a transmission you will not load a controller associated with the joint thus you will not have a control over the joint. This mapping process is done in the config file in which you map between joints and actuators and that is used by the launcher file you mentioned to load each controller name in the ros control namespace.

Furthermore, when using ros control in a real platform the transmission are also compulsory, since you need to launch the model description and ros controll need to load all those elements in its controller interface.

This tutorial may be useful.

Thank you for the valuable comments and tutorial @Weasfas. You mentioned that the mapping process between actuators and joints is done in the controller yaml config file. Isn't the mapping done in the urdf file in the transmission tag? I think the controller yaml config file maps the controllers to the joints they control and the mapping between actuators and joints is done in the urdf. Please correct me if I am wrong or missing something. I agree that the spawner node from the controller_manager in the launch file makes use of the controllers configured in the yaml config file.

To me the difference between between joint-specific information, actuator-specific information, and transmission-specific information and also joint-space and actuator-space is not clear. I tried to follow this issue regarding these topics. From the image you provided it seems obvious though to use the transmission tag for both (sim and hw) but I'd still like to find out where this information is required and used in the code implementation. Do you have any resources regarding joint|actuator|transmission-space?

You are correct in saying that the mapping is done by the transmission element in the URDF, Perhaps I have expressed myself badly.

The important thing here is how you connect you robot with the ros control framework. In the simulation scene it not a big problem since you will not have any I/O hardware problem (Hence you do not have a hardware_interface element loaded) because Gazebo plugins and URDF are able (and programmed) to process and give the information needed by ros controll automatically.

When it comes to the real robot, you need to have a component that is able to read from the sensors and write on the real actuators. Since this is highly dependent on the platform this should be provided unless there is already a controller interface implemented in a similar robot. This is one of the multiple reasons why most people decide to implement its own harware_interface like here.

For instance here you can find and example of a custom harware interface.