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:
- Make the planning scene more complex by adding new features.
- 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
- 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/
(