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 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.
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!
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?
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.
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.
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
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.