Port "Move Group Python Interface" tutorial

[bostoncleek]

Port tutorial to ROS2.

[DLu]

Blocked by #59

[JonatasVT]

Hello, I'd like to port this Tutorial.

[nikorose87]

Hello.

When trying to launch this tutorial and the roslaunch panda_moveit_config demo.launch I am getting the following error:

Traceback (most recent call last): File "/usr/bin/roslaunch", line 34, in import roslaunch File "/usr/lib/python3/dist-packages/roslaunch/init.py", line 62, in from .scriptapi import ROSLaunch File "/usr/lib/python3/dist-packages/roslaunch/scriptapi.py", line 42, in import roslaunch.parent File "/usr/lib/python3/dist-packages/roslaunch/parent.py", line 54, in import roslaunch.server File "/usr/lib/python3/dist-packages/roslaunch/server.py", line 79, in from rosgraph_msgs.msg import Log ImportError: cannot import name 'Log' from 'rosgraph_msgs.msg' (/opt/ros/foxy/lib/python3.8/site-packages/rosgraph_msgs/msg/init.py)

Is this error because the ROS2 version incompatibility? Is there any way to be able to run with ROS2?

Thanks in advance.

[JonatasVT]

Hey Nikorose, yes it need to be ported from moveit1 to moveit2 which include porting from ROS to ROS2. You'll need to take a look all over the code and see the parts which need to be translated. I was interested in porting this one also but I had no answer from the participants so...

[nikorose87]

Thank you for the info!

[nikorose87]

@JonatasVT Do you have any sample to transform those scripts into the ROS2 environment? Especially from catkin to colcon. Thank you

[JonatasVT]

@nikorose87 I don't but you can take a look on the "Move Group Interface". It was ported to Moveit2 already.

[vatanaksoytezer]

Hello @JonatasVT,

Great to hear that you are interested in porting to tutorial.

Unfortunately the Python Interface that this tutorial uses is not ported to ROS2. See https://github.com/ros-planning/moveit2/tree/main/moveit_commander being COLCON_IGNOREd. This needs to be ported before the tutorial to expose the move_group interface through python. moveit_commander uses bunch of other Python interfaces that hasn't been ported as well under moveit_ros. If you are willing to contribute to port Python interfaces please let me know and at least I (or a maintainer) can help guiding you on what needs to be ported to get this done.

[lorepieri8]

@vatanaksoytezer Is there an ETA or an issue tracking when the python interfaces will be ported?

[vatanaksoytezer]

https://github.com/ros-planning/moveit2/issues/314 is the relevant issue for porting python bindings. As far as I know there is no work in progress right now, so no ETAs.

[tlpss]

Hi @vatanaksoytezer, am I understanding this correct that Moveit2 can - at least for now- not be used with the python movegroup interface? Are there any alternatives for easily setting target poses etc. through python? Thanks in advance for your reply!

[vatanaksoytezer]

@tlpss that is correct. We don't have any official way of interfacing with MoveIt 2 through Python as of now, though the C++ interface should be fairly straightforward and robust to use.

On another note, technically speaking you can always interface with MoveIt 2 through services and topics by using any language or interface you would like (command line, cpp, python). But this might take more effort than just using C++ interfaces.

[tlpss]

@vatanaksoytezer Thanks for your reply! I understand that we could indeed directly connect to the topics/services, but that is slightly less convenient as you already mentioned.

Is there by any chance a roadmap for the python interface?

[vatanaksoytezer]

Is there by any chance a roadmap for the python interface?

So the situation is same as above comment of mine:

ros-planning/moveit2#314 is the relevant issue for porting python bindings. As far as I know there is no work in progress right now, so no ETAs.

[sea-bass]

@peterdavidfagan we can call this done by you, right?

[peterdavidfagan]

@peterdavidfagan we can call this done by you, right?

During my GSoC project we discussed ensuring that the Python bindings I create become mature enough to provide most/all the functionality of MoveIt Commander and hence become the Python interface for MoveIt 2. There are still features that need to be added to the new bindings, in particular from the MoveIt Commander tutorials I need to add Cartesian path planning.

Given the issue is about porting the Move Group Python Interface tutorial, I would say that yes this is supposed to be addressed by the new Python bindings and their corresponding tutorials.

If you want to mark this as done, I'll follow up with a new issue for adding cartesian path planning to the new Python Interface.

[m-elwin]

@peterdavidfagan: would porting this tutorial also require moveit_py to wrap the moveit::planning_interface::MoveGroupInterface?

My current understanding is that if a node wants to use MoveItPy it must have all the moveit-related parameters set on it whereas the MoveGroupInterface uses an already configured and running /move_group node.

[peterdavidfagan]

Hi @m-elwin,

If you have particular functionalities you need that aren't already in moveit_py I'd be happy to potentially add these. Are you having issues setting parameters for moveit_py? I'd be happy to provide guidance on ensuring parameters are set correctly for your robot (there is a pr open to fix the current set of tutorials). As for usability, a goal of moveit_py is to ensure a user friendly API is exposed (similar to the move group interface), there is clearly room for improvement, if there are areas that are lacking feel free to provide feedback on these as we can update the library code accordingly.

Irrespective of the above, it should be possible to launch the move_group node and interact with it via ROS as this is the intended interface for move_group.

[m-elwin]

Hi @peterdavidfagan, thanks for the quick reply and offer to help. I'm also happy to help as well.

The overall missing functionality that I would want (and believe is generally needed) is the ability to use moveit_py without requiring the user to configure any moveit parameters. Instead they would rely on the robot-vendor provided setup. Workflow would be:

1. Run vendor-launchfile that launches and configures move_group node
2. Run your node that uses moveit_py API to move the robot (possible to do with a simple ros2 run command).

The above workflow matches that of the ROS 1 version of the tutorial this issue refers to and the Your First C++ MoveIt Project ROS 2 tutorial but I do not know how to achieve an equivalent workflow with moveit_py right now.

It's not so much a difference of what can be accomplished with MoveIt from python (which I think moveit_py covers pretty well at this point so a big thank you for your work on that!) but more of programmer experience (particularly for beginners). You are right that using the ROS API of /move_group can accomplish these goals, but in my experience that ultimately leads to creating a custom python wrapper around that ROS API, which is essentially something that ROS 1 provided with the python MoveGroup API.

[peterdavidfagan]

Hi @m-elwin,

The overall missing functionality that I would want (and believe is generally needed) is the ability to use moveit_py without requiring the user to configure any moveit parameters. Instead they would rely on the robot-vendor provided setup. Workflow would be:

Managing robot configuration/parameters can be painful, there is now a nice guide explaining some of the parameters used by MoveIt here. In general, somewhere the parameters need to be configured, I think this is somewhat separate to the moveit_py API but it is still a very important discussion. moveit_py nodes accept parameters through launch files in the same manner as moveit_cpp. I'd be happy answer any questions relating to this here.

It's not so much a difference of what can be accomplished with MoveIt from python (which I think moveit_py covers pretty well at this point so a big thank you for your work on that!)

Thanks so much, still looking forward to improving and adding further features to the Python API, your feedback is welcomed.

but in my experience that ultimately leads to creating a custom python wrapper around that ROS API, which is essentially something that ROS 1 provided with the python MoveGroup API.

This is very true, I am considering creating a video tutorial for moveit_py set up. What robot are you trying to work with right now?

[m-elwin]

Thanks @peterdavidfagan,

In general, somewhere the parameters need to be configured, I think this is somewhat separate to the moveit_py API but it is still a very important discussion.

I think that makes sense. I guess what I'm trying to figure out is how the C++ MoveGroupInterface handles moveit configuration parameters and whether the python version of that functionality belongs in moveit_py or somewhere else.

Here's an example of what I mean in more detail: In the Your First C++ MoveIt Tutorial the workflow is:

1. ros2 launch moveit2_tutorials demo.launch.py. This launches a /move_group node with a full moveit configuration. The equivalent of this launchfile is usually provided by robot vendors (at least it is for Franka arms and interbotix arms).
2. ros2 run hello_moveit hello_moveit. The key feature of this command is that we do not specify any parameters. The code that the user writes in the node also does not set moveit options (at least directly). The user just creates a Node object and passes it and the name of a move group to a MoveGroupInterface object.
3. Right now (I think and please correct me if I'm wrong) there is currently no way to use moveit_py to write a direct python equivalent of hello_moveit.cpp because the user would need to explicitly set parameters for that node.

My initial thought was that the best way to achieve this "configurationless" functionality is to wrap MoveGroupInterface (from the moveit-ros-planning-interface package) as part of moveit_py. Do you think wrapping that class that is within scope of moveit_py? If so I'd be happy to work on a pull request.

[peterdavidfagan]

Hi @m-elwin,

Thanks for following up on this.

The parameters are passed to the move_group node here within the launch file.

The same pattern is used to pass parameters to the moveit_py node, here is an example.

Both interfaces use the same method of passing parameters to a node via the launch file, as a result, you could instead launch a moveit_py node and use the Python API to do much of what you are looking for. I am happy to provide some support if you choose this route, also contributions to the library are welcome.

[tylerjw]

Fixed by #810