A library for inverse dynamics computation - where to contribute?

I have developed an interface exposing methods to compute the dynamic components of robots (inertia, coriolis, gravity, friction).

I am also willing to specialize this interface with a KDL-based solver for simulated robots, and with a concrete solver for real manipulators.

I am wondering where I should commit the code I have produced:

  • should it be a new repository? If so, how can I create a new repo under existing organizations?
  • should it be a PR in a specific repository? If so, which repository should it be?

For your convenience, the library has been released on CodeOcean: Code Ocean

1 Like

Have you considered integrating it with moveit2 or gazebo ignition?

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_control kinematics_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.

However, I will always promote Pinocchio over KDL :slight_smile:

3 Likes

I may suggest considering an alternative to the ros2_control kinematics_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?

However, I will always promote Pinocchio over KDL :slight_smile:

Thanks, I’ll check this out!

@destogl @bmagyar @saikishor – what do you guys think?

1 Like

@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.

3 Likes

@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 Yes, doing a bloom-release from your repository should do :slight_smile:

1 Like

@scastro @saikishor thank you! If you have any suggestion/resource I should follow to correctly set up my repo, I’d be glad to check them out.

Thank you again for your valuable advice! :slight_smile:

2 Likes

@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.

Did I miss something? I thought it was BSD-3-Clause?