I don’t think it fits Ignition Gazebo, as the interface I am developing can be inherited by solvers for real robots, too.
Indeed, I am developing two concrete implementations for two different real robots.
Do you have an idea of which moveit repository this feature might apply to?
I may suggest considering an alternative to the ros2_controlkinematics_interface (GitHub - ros-controls/kinematics_interface) … but one that offers the dynamics portion as you’ve described?
The idea being that you can create plugins that can be used in real-time controllers that use a robot’s dynamics in their control laws.
I may suggest considering an alternative to the ros2_controlkinematics_interface (GitHub - ros-controls/kinematics_interface) … but one that offers the dynamics portion as you’ve described?
Yes, that was the idea! But in that case, I’d have to create a new repository. I am new in officially contributing to ROS… do you know how can I propose my own repository to the ros-control organization?
@v8p1197 In my opinion, this inverse dynamics library should be an independent library (even ROS-independent), similar to other rigid body dynamics libraries such as RBDL and Pinocchio. This separation would help distinguish the core logic from what is integrated into a controller, avoiding the need to maintain an entirely new dynamics library.
In the future, if we add a dynamics-based controller to ros2_controllers, it would be worth considering a plugin-based system. This would allow users to switch between different inverse dynamics solvers simply by changing the plugin. For instance, how kinematics_interface_kdl has been implemented and integrated with the admittance_controller.
@saikishor Thank you for your suggestion. If my understanding is correct, I have to create my own repository, follow these guidelines, and open a PR to ros/rosdistro to make my library available as a ROS package. Can you confirm this is the correct way to proceed?
In the future, if we add a dynamics-based controller to ros2_controllers, it would be worth considering a plugin-based system. This would allow users to switch between different inverse dynamics solvers simply by changing the plugin.
Yes, that was exactly our idea. Our library is plugin-based, and users can choose the solver to use in controllers or planning algorithms by changing the plugin.
@v8p1197 I was just checking the code in more detail. To gain serious traction in ROS 2 you will have to reconsider the used license. Usual license also allows professional use of such libraries. For example, with this license, I could not support having a controller or an example for ros2_control.