I’m afraid I miss a lot of these meetings this year…
Here are some thoughts from my side.
Support for HPP-FCL as collision checker (Vatan)
Great to see my suggestion being picked up!
How is current benchmarked performance actually compairing to tesseract
As Levi pointed out multiple times MoveIt’s use of FCL is rather convoluted, partially for historical reasons, partially by (current) design. The caches can help a lot in some cases, but not in general.
I believe a big point of the “by design” part is the representation of the robot as a separate structure which needs to be recreated for each check.
What are the current shortcomings? Bullet incomplete, CCD,…
From my perspective by far the biggest shortcoming in URDF/MoveIt though is the inability to mark meshes as convex.
With convex mesh support many realistic collision checks could speed up tremendously (though models would actually need to be changed to ensure convex meshes and mark them as such).
[Henning] It is easy to observe that collision checking is the bottleneck by changes in your environment affects planning time
[Vatan] I agree, but do we have data
[Simon] You can also just do less collision checks if you can reason at a higher level to find solutions you don’t have to collision check. We should find ways to not use RRTConnect and find better solutions.
[Henning] Maybe the most performance improvement could be in higher level reasoning. Rejection sampling is really expensive because you do all the work only to discard the result.
[Tyler] I’ve had good results with Intel® VTune™ Profiler when benchmarking small bits of code
[Henning] What is the future of moveit benchmark
[Simon] CaptianYoshi are doing to work on a paper using moveit1
