Trajectory Planning in `compas_fab`

[Zac_Zhuo_Zhang]

Hi, probably it is not a bug but does happen several times when using compas_fab, and can be a potential update for a better user experience.

When using robot.plan_motion in Python or the ‘Plan Motion’ component in Grasshopper, the output trajectory varies in terms of path rationality. Certainly, multiple trajectory solutions are caused by a lack of constraints and we can find the ideal trajectory solution by clicking ‘compute’ multiple times, but it would be great if this function can auto-rank or auto-provide the best output, i.e. the shortest travelling path.

Thanks.

[Zac_Zhuo_Zhang]

Thanks to @gonzalocasas 's response outside the forum: I was using the ompl planner pipeline, and using other options like pilz_industrial_motion_planner with their advantages and drawbacks might bring a different experience.

[gonzalocasas]

Thanks @Zac_Zhuo_Zhang for reposting my out-of-forum response! To add more details here, there are different planners available inside MoveIt, and they are grouped into pipelines. The OMPL pipeline is the one we use by default, and within OMPL we generally default to RRT* or a similar RRT-like algorithms for planning. There are also alternative pipelines, Pilz is an interesting one for industrial robots, because it’s deterministic, which comes with some caveats though.

The full list of planners on MoveIt is here: Planners | MoveIt (note that not all of them are fully supported in MoveIt itself).

[Zac_Zhuo_Zhang]

Thanks for the answer! maybe a follow-up question:

knowing that part from RRT*, there are bunch of available planners in ompl. What how can we change the default and make use of the rest ?

[gonzalocasas]

The planner is selected using the options parameter of the Robot.plan_motion(), passing the name of the planner algorithm in the planner_id key. options are specific to the backend, but since we’re talking about MoveIt backend, you can check the docs for all available options here: compas_fab - MoveItPlanner.plan_motion

There are examples of selecting the planner with this options in the FS2023 course repository and also the GH component for plan motion exposes this as an input parameter.

[Zac_Zhuo_Zhang]

Hi.

Just to add some findings to share and hope @gonzalocasas could feedback to ensure its accuracy.

Instead of using the term “deterministic path”, I suggest using “efficient path” to better describe the question at hand.

To get an efficient path, here are some related settings:

1. optimization objectives in the moveIt backend is PathLengthOptimizationObjective by default, which is what we need.
2. Certain planners are designed to generate efficient paths, such as: RRTstar, KPIECE, BiTRRT, and the new AnytimePathShortening.

While noticing that the ‘efficient path’ in configuration space and cartesian space can differ: When calculating an efficient path in configuration space, the planners will return a path that requires less joint involvement and dynamic effort, resulting in a curved trajectory in cartesian space. This is why the path is sometimes a conformity curve.

Back to Grasshopper, I am not clear how to specify which space to use, but the trick I found is: using Constraints From Plane as constraints will be more likely to return an efficient path in cartesian space while using Constraints From Target Configuration will be more likely return an efficient path in configuration space. Using Constraints From Target Configuration is easier to succeed than Constraints From Plane.There should be a way to specify the space no matter what the constraints are.

Looking forward to the corrections and updates.

[gonzalocasas]

This is super interesting, thank you so much for putting it the time to explore it in detail!

You are correct in that the resulting paths are efficient in configuration space (but quite funny in cartesian space), and it’s an interesting observation than the different constraint types will skew the solutions towards one or the other side of efficiency.

The constraints don’t really have to be always created from configuration or from plane, if you create these, you will see that they result of each is a list of more primitive types of constraints, so, it’s possible to craft a set of goal constraints combining different primitive types (joint constraints, position constraints, orientation constraints, etc).

Maybe a combination of a set of joint constraints + a bounding volume would be a good thing to try out.

[Zac_Zhuo_Zhang]

Thanks for the comment!

Yes, for now, the constraints are keys for generating the right path we need, but I was also hoping for the possibility of more specification and customization by diving into the moveIt backend a bit. This could be an interesting topic of empowering robots for fabrication, not only for Fixed Base Robots like arms but Floating Base Robots or others. I will keep looking.

Thanks again!