Thanks for the invitation. I think we will be done with the technical parts of merging our pilz planner into moveit (https://github.com/ros-planning/moveit/pull/1893) and can then discuss further action points.
Execution speed should be low enough to give beginners time to hit the emergency stop if, e.g., IK yielded an inadequate joint solution
The feature will affect all currently running robot demos that do not explicitly set the scaling factors to 1.0 beforehand. This is likely quite a lot.
Are we ok with setting the default to very low values and require people to explicitly specify 1.0 in their joint_limits.yaml if they want acceptable behavior again?
0.1, 0.2, and 0.5 have been proposed in the thread
Here, convenience changes are made to the setup assistant, and no runtime code is affected.
Here, the default scaling factors discussed in the post above are introduced. How do you test for this? Either way, the change does not seem dangerous.
From a developer perspective, it is confusing not to see at first glance if there is a functional issue with the code or if there is a housekeeping issue. It seems clear that the severity is not the same. It would be great if that could be represented somehow, and the code coverage feedback given differently.
Participants: Audrow Nash, Christian Hankel, collaed 11, Dave Coleman, Henning Kayser, Jafar Abdi, Jere Liukkonen, Joachim (Pilz), Mark Moll, Michael Gorner, Mike Lautman, Omid Heidari, Robert Haschke, Tyler Weaver
Becoming official ROS 2 working group (Dave Coleman)
MoveIt and Rviz handles empty collision geometries differently (Michael Gorner, Robert Haschke)
If the user doesn’t add collision geometry MoveIt will set the collision geometry as the visual geometry
Switch to master branch to the default behavior (how Rviz handles it, requiring that collision geometry is filled if not it will issue a warning about not having a collision geometry)