Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port "Move Group Python Interface" tutorial #3

Open
Tracked by #760
bostoncleek opened this issue Feb 4, 2021 · 23 comments
Open
Tracked by #760

Port "Move Group Python Interface" tutorial #3

bostoncleek opened this issue Feb 4, 2021 · 23 comments

Comments

@bostoncleek
Copy link
Contributor

Port tutorial to ROS2.

@DLu
Copy link
Contributor

DLu commented Mar 10, 2021

Blocked by #59

@JonatasVT
Copy link

Hello, I'd like to port this Tutorial.

@nikorose87
Copy link

nikorose87 commented Jul 22, 2021

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
Copy link

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
Copy link

Thank you for the info!

@nikorose87
Copy link

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

@JonatasVT
Copy link

JonatasVT commented Jul 29, 2021

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

@vatanaksoytezer
Copy link
Contributor

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
Copy link
Contributor

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

@vatanaksoytezer
Copy link
Contributor

moveit/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.

@tlpss
Copy link
Contributor

tlpss commented Sep 24, 2021

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
Copy link
Contributor

@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
Copy link
Contributor

tlpss commented Sep 24, 2021

@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
Copy link
Contributor

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.

MikeWrock added a commit that referenced this issue Jul 15, 2022
* Test docker (#3)

* renamed cartesian limits file (#472)

* Tutorial dockerfiles (#463)

Build and push docker images for tutorials

* fixed clang complaints

* removed dockerhub pushes

* successfully ran htmlproofer

* removed chomp tutorial commits

* removed accidental commits

* Update CMakeLists.txt

* renamed mtc tutorial cpp file

* updated cmakelists

* updated cmakelists

* removed vscode

* refactored docker

* skipping base image

* added conditions on building base image

* added conditions on building base image

* added conditions on building base image

* ran pre commit

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* resolved comments

* updated location to check for changes

* test change to dockerfile

* test change to dockerfile

* test change to dockerfile

* updated scripts to run only when dockerfile changes

* fixed syntax

* chaged to ros base image

* chaged to ros base image

* update

* removed ccache and change repo names

* removed ccache and change repo names

Co-authored-by: Henry Moore <44307180+henrygerardmoore@users.noreply.github.com>
Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Docker debug (#2)

* Tutorial dockerfiles (#463)

Build and push docker images for tutorials

* fixed clang complaints

* removed dockerhub pushes

* successfully ran htmlproofer

* removed chomp tutorial commits

* removed accidental commits

* Update CMakeLists.txt

* renamed mtc tutorial cpp file

* updated cmakelists

* updated cmakelists

* removed vscode

* refactored docker

* skipping base image

* added conditions on building base image

* added conditions on building base image

* added conditions on building base image

* ran pre commit

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* resolved comments

* updated location to check for changes

* test change to dockerfile

* test change to dockerfile

* test change to dockerfile

* updated scripts to run only when dockerfile changes

* fixed syntax

* got it building

* building dockerfiles of tutorials

* added pick container

* pushing to new pc

* changed to multi-stage

* updated dockerfile

* rebased

* continued rebasing

* continued rebasing

* continued rebasing

* continued rebasing

* continued rebasing

* merged online edit

* continued rebasing

* pre commit

* modified dockerfile

* added ccache to path

* merging

* merging

* successfully ran htmlproofer

* removed chomp tutorial commits

* removed accidental commits

* Update CMakeLists.txt

* renamed mtc tutorial cpp file

* updated cmakelists

* updated cmakelists

* removed vscode

* merging

* merging

* ran pre commit

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* resolved comments

* test change to dockerfile

* test change to dockerfile

* test change to dockerfile

* merging

* changed dockerfile

* changed dockerfile

* changed dockerfile

* changed dockerfile

* changed dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* changed naming for ros-planning

* fixed conflict resolution artifsct

Co-authored-by: Henry Moore <44307180+henrygerardmoore@users.noreply.github.com>
Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>
MikeWrock added a commit that referenced this issue Jul 15, 2022
* renamed cartesian limits file (#472)

* Tutorial dockerfiles (#463)

Build and push docker images for tutorials

* fixed clang complaints

* removed dockerhub pushes

* successfully ran htmlproofer

* removed chomp tutorial commits

* removed accidental commits

* Update CMakeLists.txt

* renamed mtc tutorial cpp file

* updated cmakelists

* updated cmakelists

* removed vscode

* refactored docker

* skipping base image

* added conditions on building base image

* added conditions on building base image

* added conditions on building base image

* ran pre commit

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* resolved comments

* updated location to check for changes

* test change to dockerfile

* test change to dockerfile

* test change to dockerfile

* updated scripts to run only when dockerfile changes

* fixed syntax

* chaged to ros base image

* chaged to ros base image

* update

* removed ccache and change repo names

* removed ccache and change repo names

Co-authored-by: Henry Moore <44307180+henrygerardmoore@users.noreply.github.com>
Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>
MikeWrock added a commit that referenced this issue Jul 26, 2022
* renamed cartesian limits file (#472)

* Tutorial dockerfiles (#463)

Build and push docker images for tutorials

* fixed clang complaints

* removed dockerhub pushes

* successfully ran htmlproofer

* removed chomp tutorial commits

* removed accidental commits

* Update CMakeLists.txt

* renamed mtc tutorial cpp file

* updated cmakelists

* updated cmakelists

* removed vscode

* refactored docker

* skipping base image

* added conditions on building base image

* added conditions on building base image

* added conditions on building base image

* ran pre commit

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* Update .docker/Dockerfile

Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>

* resolved comments

* updated location to check for changes

* test change to dockerfile

* test change to dockerfile

* test change to dockerfile

* updated scripts to run only when dockerfile changes

* fixed syntax

* chaged to ros base image

* chaged to ros base image

* update

* removed ccache and change repo names

* removed ccache and change repo names

Co-authored-by: Henry Moore <44307180+henrygerardmoore@users.noreply.github.com>
Co-authored-by: Robert Haschke <rhaschke@users.noreply.github.com>
@sea-bass
Copy link
Contributor

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

@peterdavidfagan
Copy link
Member

peterdavidfagan commented Apr 18, 2023

@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
Copy link

m-elwin commented Oct 22, 2023

@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
Copy link
Member

peterdavidfagan commented Oct 23, 2023

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
Copy link

m-elwin commented Oct 23, 2023

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
Copy link
Member

peterdavidfagan commented Oct 24, 2023

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
Copy link

m-elwin commented Oct 26, 2023

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
Copy link
Member

peterdavidfagan commented Oct 26, 2023

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
Copy link
Member

tylerjw commented Dec 1, 2023

Fixed by #810

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests