Thanks for contributing all your work. It's really interesting and it will take some time to digest all of it... :cat:
I would like to ask you to clarify the comparison to BiRRT you show in your readme and documentation.
The right trajectory clearly includes separate approach/put-down/retract motions without phase blending which are often preferred in physical robot experiments for predictability during execution, for clearance between motion phases, and to account for minor errors in perception. These phases were not computed through BiRRT so the label seems wrong. I don't think the left trajectory includes comparable constraints (or at least the required distances are tiny), so the comparison seems flawed. If you wanted to compare the pure transit motion + optimizing grasp pose IK(?) could you indicate that somewhere for fairness? I believe your solutions are still faster there.
Where both trajectories computed with the same (sphere) collision geometry and how long did it take to compute both? The typical advantage of BiRRT is that it's fast to generate feasible but jerky paths and running BiRRT* with a very short time epsilon after finding the first solution will generate much shorter Cartesian paths. Obviously time to solution is a problematic comparison between GPU and CPU anyway, but I believe you want to give a good first impression here so it should be fine.
Thanks for contributing all your work. It's really interesting and it will take some time to digest all of it... :cat:
I would like to ask you to clarify the comparison to BiRRT you show in your readme and documentation.