Revision history [back]

Your answer is correct and especially for people expecting the traditional use-case it would be a good idea to add a disclaimer to the tutorial page pointing out that difference.

Concerning the ROS one moveit_commander, you described the usual use-case correctly, but keep in mind that especially inverse kinematics is also implemented directly in the wrapped cpp methods:

UserApp (py) -> moveit_commander (binding) -> MoveGroupInterface (cpp) -> MoveitCPP core functions (cpp)

This mix is rather powerful, but also quite hard to maintain.

A python-only interface that focuses only on ROS interfaces is moveit_python, but it is also rather limited and does not support ROS2 yet afaik.

As of today there is no official python-only wrapper that replicates the ROS-interface-based use in ROS2.

We definitely endorse such a wrapping again. It should not replicate the API of moveit_commander though, but be more aligned with the current moveit_py.

Please also note that the decision to keep a single move_group node around with some C++ data structures was taken over a decade ago, also due to more-limited resources, and comes with its pros and cons (mainly, reducing problems with data consistency vs planning limited to sequential requests) and many use-cases these days have different requirements. That does, of course, not mean that the move_group approach is bad, just that it's good to keep an open mind.