Thoughts about path-planning within roboticslab-uc3m

[jgvictores]

Thoughts about path-planning within roboticslab-uc3m, and considerations on creating a path-planning repository within the organization.

Considerations to be taken into account before blindly doing this:

1. Path-planning is not required for much of our research. 2D/3D path-planning is mostly required in the presence of obstacles, which is not our current general use case within our current research (this can change with time). Cases where we are doing some path-planning:
   1. [2D navigation] TIAGo navigation, via ROS navigation stack.
   2. [2D navigation] There should be some remanent code in asibot-main ravebot or tasks, where OpenRAVE was used. Should be migrated to openrave-yarp-plugins if it hasn't been done yet.
   3. [3D grasping] There has been some progress with TEO in OpenRAVE in https://github.com/roboticslab-uc3m/teo-grasp for grasping a bottle. This may remain independent or some day be merged into openrave-yarp-plugins.
2. We already have some trajectory generation in kinematics-dynamics, which is a good place for it (not exactly path-planning, does not take obstacles into account).

As seen, the above candidates already have their place. Therefore, my recommendations are the following:

1. Not creating a new path-planning repository within this organization, at least for now.
2. Use this issue to track path-planning developments within this organization.
3. If results are in Cartesian space, keep close integration with kinematics-dynamics, which treats Cartesian to joint space conversions. Therefore, new issues will potentially arise at kinematics-dynamics too.

[jgvictores]

cc: @PeterBowman @rsantos88

[jgvictores]

If results are in Cartesian space, keep close integration with kinematics-dynamics, which treats Cartesian to joint space conversions. Therefore, new issues will potentially arise at kinematics-dynamics too.

Regarding trajectories in Cartesian space, new related issues for keeping close integration: roboticslab-uc3m/kinematics-dynamics#134 and roboticslab-uc3m/kinematics-dynamics#135

[jgvictores]

Regarding trajectories in joint space, just a reminder that we have some tools in the, well, tools repository. Namely, as commented here:

Specifically, you'll want the PlaybackThread. You can find an example of use at examplePlaybackThread and its corresponding test.

[jgvictores]

Related: https://github.com/ros-industrial-consortium/tesseract (refs: https://rosindustrial.org/news/2018/7/5/optimization-motion-planning-with-tesseract-and-trajopt-for-industrial-applications and roboticslab-uc3m/kinematics-dynamics#155 (comment))

[PeterBowman]

See also: https://github.com/personalrobotics/aikido.

AIKIDO is a C++ library, complete with Python bindings, for solving robotic motion planning and decision making problems. This library is tightly integrated with DART for kinematic/dynamics calculations and OMPL for motion planning. AIKIDO optionally integrates with ROS, through the suite of aikido_ros packages, for execution on real robots.

[PeterBowman]

Not exactly path-planning, but kinda related: https://github.com/robotology/navigation.

[jgvictores]

See also: https://github.com/strands-project/strands_navigation

[jgvictores]

TODO: See https://github.com/roboticslab-uc3m/kinematics-dynamics#similar-and-related-projects, specifically https://github.com/roboticslab-uc3m/kinematics-dynamics/blob/3859656e713d3bda9a10b13157a19b3a8f9a190e/README.md#path-planning-trajectory-generation-and-optimization

[PeterBowman]

I think the demo developed by @elisabeth-ms has some bits of path planning. It's an DL-based object detection app for grabbing stuff with one of TEO's arms.

[jgvictores]

I think the demo developed by @elisabeth-ms has some bits of path planning. It's an DL-based object detection app for grabbing stuff with one of TEO's arms.

Cool, nice catch! I'm totally seeing some OMPL at https://github.com/elisabeth-ms/teo-sharon/blob/cfc3a62270e130d0f3a8a8418c18b1a901508bea/programs/TrajectoryGeneration/TrajectoryGeneration.hpp#L17-L24 in addition to the KDL and FCL code. Thanks!

[PeterBowman]

See also this grasping demo featuring the iCub: robotology/community#573.

[PeterBowman]

Moar grasping straight from the ongoing Nvidia GTC AI conference (thanks @imontesino):

• https://graspnet.net/anygrasp.html
• https://www.youtube.com/watch?v=vH1enCXeBnU