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

MoveIt Manipulation WG Meeting - December 17th

The next Manipulation WG Meeting / MoveIt Maintainer Meeting will be December 17th at 8am PST. While normally this meeting is held on the fourth Thursday of the month, this month we moved it a week earlier to avoid conflicting with Christmas Eve.

Your time zone: 2020-12-17T16:00:00Z

Agenda:

  • Old business
  • ROS 2 control and UR driver update (Andy)
  • Discussion of breaking changes in future MoveIt versions (Mark)
    • If MoveIt were written from scratch today, what would be done differently?
    • What features seem ready for deprecation?
    • What major changes are you holding off on, because it would mean breaking too many things?
  • Cartesian planning PR (GSoC 2020 project by Jeroen De Maeyer) ready to be merged? If yes, then the Cartesian interpolator and PoseModelStateSpace can potentially be deprecated. (Mark)
  • 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#

2 Likes

I would love to get some opinions on https://github.com/ros-planning/moveit/pull/2456

basically the function RobotState::setJointGroupPositions() expects the values for all joints (including mimic joints) but people normally tend to pass it a vector with the position of only active joints (excluding mimic joints). There is even a check in MoveIt Visual Tools that checks that you misuse the API. :wink: (https://github.com/ros-planning/moveit_visual_tools/pull/83)

What I need input on is if it would be preferable (but backwards incompatible) to “fix” RobotState::setJointGroupPositions() or to add a new variant setJointGroupActivePositions() as done in the (WIP) PR above.

My pre-meeting notes on the Cartesian planning PR:

  • The PR should be ready (apart from some unidentified CI failures I have to look into…)
  • I will be the first to point out that this PR is more a starting point than a finished product. The next step is to work on support for orientation constraints with #2401. Although this new parameterization might be not necessary anymore since important issues were discovered and resolved in the Euler angles calculations with #2434. Thank you @JafarAbdi! I did not test this new fix for projection-based planning yet.
  • I think the PoseModelStateSpace, while clearly imperfect, still is a useful alternative to the new Cartesian planner. (And I do believe it can be fixed, but this is a controversial point as nobody knows how yet :slight_smile: )

Meeting notes 17 / 12 / 2020

(Around 30 participants at the start, I’m sorry I forgot to write down an attendance list…)

ROS2 control

Andy:

  • API is a table, you can use it in MoveIt2
  • 2 related PRs #272 and #271

Abishalini works on the UR driver for ROS2 (PickNik received a UR5 from Universal Robots to test it!)

Cartesian planning PR

(For the status see my other comment above.)

De planner directly interfaces with the constrained planning functions in OMPL

Mark: acknowledges his bias as he is the lead developer of OMPL. Please speak up if you think this ties us in too much with OMPL. See pull request for details.

Several people mentioned that partial solutions and de solved fraction from the Cartesian interpolation are really useful. We can also return approximate solutions from OMPL when planning fails (for certain planners). But this would be a new feature of OMPL interface independent of this new Cartesian planner.

Breaking changes in future MoveIt versions

Planning Scene Complexity

Andy: collision checking at a high frequency does not work.
Tyler: collision checking is the bottleneck for complex planning scenes. PlanningScene is a bit complex or messy in general.
Maybe we need to formalize what the different interfaces are? PlanningScene tries to be multiple things at once.

The planning scene is not able to present many relationships between objects more symbolically.
Henning: scene graph representation could be really useful, but does it belong inside the planning scene, or in a separate node? Not a lot of support for dynamic states also. Other nodes could maintain extra info on objects and subscribe to the collision word to keep up to date.
Dave fan of moveit_cpp because of this issue, Henning remarks this is only useful if you want to use only MoveIt components. Otherwise, composability with components outside MoveIt is important. In that case, it is much easier to use the ROS nodes / services / … system. In ROS1 this was slow, in ROS2 this can be fast.

In conclusion, the two options discussed are:

  1. Make the planning scene more complex by adding new features.
  2. Open up the interface more so other nodes can use it and implement the new features.

I think most people agreed that the second option would be better.

Python bindings

Python bindings are a lot of work to maintain, but they are very useful for beginners, machine learning interfaces (often Python-based), …
Example use case: Peter Mitrano uses them to integrate an external calculation of forward dynamics using neural networks into MoveIt planning.

Tyler: The people who can maintain them are not the people who use them and visa versa.
-> Felix is the welcome exception to this rule. (He is a maintainer, uses the python interface all the time, and is a strong advocate of it.)

ROS2 could allow us to not write python bindings. By going for a data-centric design instead of an API-centric design. Is there a performance problem with a pure ROS message-based interface?

The current python interface often uses ROS messages under the hood. This is problematic if you need the guarantee that somethings must happen. (Peter’s solution now is to wrap everything into a service to have this guarantee.)

pybind conversion between python messages and C++ bindings. https://github.com/UM-ARM-Lab/pyrosmsg.

Conclusion: we need people that care about the python bindings to help maintain it. We need more input from people that use them in the maintainer group. PickNik almost never uses the Python interface.

How to avoid misuse of setJointGroupPosition ?

Simon explained the issue and the options to resolve it in a comment above and in this PR.

I think Felix preferred to add the new function setJointGroupActivePositions and not change the behaviour of the existing function.

CI problems

MoveIt (and other open-source projects) don’t get Travis runners anymore. Now PickNik pays for two runners, compared to the 5 free ones we had in the past. Some alternatives are discussed:

  • Circle CI
  • Github actions + industrial_ci
  • Does AWS offer something in the context of RoboMaker?

Upside industrial ci: native Github action experience, easy to use for small projects, …

Downside industrial ci:

  • Maintainers are very busy and merging PR’s is slow, and MoveIt also does not want to give them to much work, or building large projects is not their intended use case? Solution: ask them :slight_smile:
  • One big running job compared to circle ci where things can be tested more incrementally which would make running CI a lot faster.

Nathan brooks: what is easier to set up for other users that want to self-host a project? -> for small ROS projections industrial_ci is plug and play.

The ROS navigation team has really could performance and willing to help with Circle CI, but the setup script is complex.

First-time contributors

Are the issues to trivial? Do we need extra guidelines for how to progress to more complex issues? How can we improve this experience?

Some ideas:

  • Listen to there use case.

  • Curate a document on next steps after a first-time issue.

  • Make it easier to build and develop with the source code, this can be a large hurdle. Maybe a really could docker tutorial, or docker alternatives? (LXD?)

  • For the docker complexity, look into how Autoware does it, they seem to have a good process.

  • https://ade-cli.readthedocs.io/en/latest/