ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

MoveIt Manipulation WG Meeting - September 24th

The next Manipulation WG Meeting / MoveIt Maintainer Meeting will be September 24th at 8am PST

Your time zone: 2020-09-24T15:00:00Z

Agenda:

  • Old business
  • MoveIt Release Schedule (Tyler)
  • Summer student project retrospective / action items (Mark)
  • Cartesian planning (Mark)
  • Adding 4 new MoveIt maintainers?:
    • Andy Zelenak
    • Mike Ferguson
    • Jafar Abdi
    • Felix von Drigalski
  • MoveIt at ROS World 2020, this year’s online version of ROSCON (Dave)
  • Porting MoveIt 1 tutorials to MoveIt 2
  • Pilz PR still blocked?
  • Anything else…

Please request here any agenda topics you would like included.

Meeting ID
meet.google.com/fpo-srqg-feg

Phone Numbers
(‪US‬) ‪+1 347-486-5750‬
PIN: ‪644 991 049#‬

Additional topics for discussion from Robert:

  • There are open release issues: Preparing for Noetic sync 2020-09-18

  • We need to decide whether we want to provide a master docker image for both, Noetic and Melodic (https://github.com/ros-planning/moveit/issues/2299).

    Currently, several downstream packages (e.g. moveit_visual_tools, moveit_tutorials, MTC) rely on a Melodic-based master-source image, because they didn’t yet migrated to Noetic, but rely on master features.

    To mitigate this problem, I disabled auto-building of the master-source image on dockerhub. Currently master-* are Melodic-based and noetic-* are Noetic-based.

Meetings notes

Noetic release

Master branch is officially on noetic, but some downstream packages depend on it being built against melodic. Therefore, auto-building of the master image is disabled and a fixed image is used that works for the downstream packages.

Currently, we decided to keep this temporary hack and wait for the downstream package to migrate.

An alternative is to provide two docker images, one for melodic and one for noetic, but this is not possible with the current docker setup.

For more info, see this issue.

Andy remarks that melodic needs to be supported for another 2.5 years.

There is also an issue with lib-octomap (I can’t find a link for this…).

Changing the release schedule:

Release documentation is changed (by Tyler). We will move to more regular release (every 6 weeks) so there are fewer changes between releases. Mark agrees that it makes releasing easier. It is less dangerous. If a bug slips through in a release, it can be quickly fixed.

Intern and GSoC projects

  • Grasping with deep learning by Boston Cleek blog post
  • Porting moveit_servo to ROS2 and improving it by Adam Pettinger: blog post
  • OMPL Constrained planning by Jeroen De Maeyer: blog post

Andy: how flaky is Cartesian planning with the new OMPL constrained planner? Semi-answer: It can timeout for difficult problems. But it will not return infeasible paths. But still a lot of room for improvement. See blog post mentioned above.

Mark: we should keep doing GSoC in the future!

Cartesian planning

Cartesian planning is an important capability of MoveIt, but there are problems. Where should we focus our efforts? Maybe on these 3 options:

New MoveIt maintainers

We will add 4 new MoveIt maintainers:

  • Andy Zelenak
  • Mike Ferguson
  • Jafar Abdi
  • Felix von Drigalski

There were no objections.

ROS World

Online event. MoveIt organizes a session with talks on:

  • Henning update on MoveIt 2
  • NASA speaker
  • MoveIt Calibration
  • OMPL Cartesian planning

But don’t forget the lightning talk possibility, deadline 30 September. Join the talks and the discussion if you can!

MoveIt 2

Tutorials

Is feature complete, but the tutorials still need to be converted! This is a big task. How do we handle this?

Henning: Find a good launch template that we can use for all the tutorials. Encourages everyone to try out the existing examples and give feedback, especially on the launch files. Then updating the tutorials is not a lot of work, because the API stayed the same. But, no Python interface yet.

Then there was some discussion on moveit_cpp, move_group, and Python bindings.
Andy: try to encourage users to use moveit_cpp
Henning: current Python users would probably prefer move_group?
Tyler: the benefit of using moveit_cpp is smaller in ros2 if we use component nodes for move_group. Component nodes avoid message serialization overhead.
Henning: and can we access this from Python somehow?
Ian: the component nodes cannot be mixed between languages right now.

Felix suggested season-of-docs. Is this a good fit?

Hardware support

Are there more many examples of ros control drivers for robots?
Karsten Knese: The first example could be a demo joint trajectory action server and gazebo.
Writing a driver for a new robot should not be too much work if the ros control framework is finished.
Henning: you can also use moveit_servo and send joint position commands.

Pilz

Christian: We started working on it again this week. We need to add the Pilz robot the moveit_resources and fix support for panda robot. Please review the pull request against moveit_resources that will be coming soon.

Other stuff

moveit_calibration
John: some maintainers should subscribe to moveit_calibration. There is a pr for Python3 support that has been sitting there for some time, but it should be easy to review :slight_smile:

multiple planners, multiple robots?
Felix: can we use different planners at the same time in moveit_cpp? How difficult is it to make it happen.
Henning: is working on it and it is almost finished. After this, it should be possible to also use multiple planners through move_group.
Robert: you can also use different planning pipelines with MoveIt Task Constructor.

Felix: what about multiple robots?
There is currently a single robot description. This can make sense if the robots need to be aware of each other to avoid a collision. Alternatively, you can plan for them completely independently. Can you launch multiple move groups controlling multiple robots at the same time? You can publish the joint trajectory to ros_control directly, instead of moving the robot through move_group.