# MoveIt Manipulation WG Meeting - September 24th

**URL:** <https://discourse.openrobotics.org/t/moveit-manipulation-wg-meeting-september-24th/16379>\
**Category:** Manipulation\
**Created:** [September 13, 2020, 11:03pm UTC](https://discourse.openrobotics.org/t/moveit-manipulation-wg-meeting-september-24th/16379 "2020-09-13T23:03:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mmoll](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/mmoll/32/5717_2.png) [@mmoll](https://discourse.openrobotics.org/u/mmoll)\
**Post date:** [September 13, 2020, 11:03pm UTC](https://discourse.openrobotics.org/t/moveit-manipulation-wg-meeting-september-24th/16379/1 "2020-09-13T23:03:21Z")

</div>

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](https://meet.google.com/fpo-srqg-feg)

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

---

<div class="post-metadata">

**Author:** ![mmoll](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/mmoll/32/5717_2.png) [@mmoll](https://discourse.openrobotics.org/u/mmoll)\
**Post date:** [September 24, 2020, 2:59pm UTC](https://discourse.openrobotics.org/t/moveit-manipulation-wg-meeting-september-24th/16379/2 "2020-09-24T14:59:26Z")

</div>

Additional topics for discussion from Robert:

- There are open release issues: [Preparing for Noetic sync 2020-09-18 - #3 by rhaschke - Noetic - Open Robotics Discourse](http://discourse.ros.org/t/preparing-for-noetic-sync-2020-09-18/16429/3)

- We need to decide whether we want to provide a master docker image for both, Noetic and Melodic ([master vs. noetic-devel branches · Issue #2299 · moveit/moveit · GitHub](https://github.com/ros-planning/moveit/issues/2299)).

---

<div class="post-metadata">

**Author:** ![JeroenDM](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/jeroendm/32/1105_2.png) [@JeroenDM](https://discourse.openrobotics.org/u/JeroenDM)\
**Post date:** [September 24, 2020, 4:30pm UTC](https://discourse.openrobotics.org/t/moveit-manipulation-wg-meeting-september-24th/16379/3 "2020-09-24T16:30:20Z")

</div>

# 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](https://github.com/ros-planning/moveit/issues/2299).

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](https://moveit.ros.org/documentation/contributing/releases/) 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](https://picknik.ai/3-d%20perception/moveit/grasping/deep%20learning/2020/09/17/new-moveit-grasping-capabilities-using-deep-learning.html)
- Porting moveit\_servo to ROS2 and improving it by Adam Pettinger: [blog post](https://moveit.ros.org/moveit/ros2/servo/jog/2020/09/09/moveit2-servo.html)
- OMPL Constrained planning by Jeroen De Maeyer: [blog post](https://moveit.ros.org/moveit/2020/09/10/ompl-constrained-planning-gsoc.html)

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:

- Cartesian planning with OMPL
- moveit\_servo
- [Pilz planner](https://github.com/ros-planning/moveit/pull/1893)

## 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](https://github.com/ros-planning/moveit2/tree/f5d429e479883717223860cd30e9cb45126b2768/moveit_demo_nodes) 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](https://developers.google.com/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](https://github.com/ros-planning/moveit_calibration)**. There is a pr for Python3 support that has been sitting there for some time, but it should be easy to review 🙂

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