Robotics StackExchange | Archived questions

Battle-proven inverse kinematics and planners for constrained environments

Hi,

We are currently using PyBullet with custom inverse kinematics and planner. We are wondering if ROS has battle-proven tools fitted to our use case that we shall explore.

Our issue is that we have a robotic arm that has to navigate into a very constrained environment. It is a small box that encapsulates the robot, with lots of obstacles. There is always a free path, but it can be a narrow corridor.

The constraints are:

This implementation with PyBullet is working in most cases, but in terms of performance, it can be very slow (a few seconds to something like 30s) and there are some bugs that can prevent convergence. We are currently wondering if we shall continue with DIY on PyBullet or if she shall have a look at some more advanced ROS, MooveIt and Gazebo tools that have been tested to work in such use cases by the community.

If you have some experience with such constrained environments, I would appreciate it if you could point me to some ROS tools that worked for you.

Thanks a lot

Asked by thibd on 2022-06-29 14:24:50 UTC

Comments

Just an observation: many of your bullets (or the behaviour of your current implementation) are not often considered the responsibility of "IK solvers" in something like MoveIt. IK solvers solve IK / FK requests. Motion planners check whether they are "valid", whatever that means to those motion planners (ie: collision free or adhering to some other criteria).

There are possibilities for IK solvers to receive a couple of callbacks which would allow them to check for things like collisions, but I'm not sure those are always used.

Regarding your motion planning requirements: apart from the narrow space aspect, all of your bullets are taken care of by default by the planners something like MoveIt is using (OMPL, CHOMP, STOMP, etc). Depending on the exact planner used, narrow passages can be difficult to plan for, but it's doable.

I'd also recommend taking a look at Tesseract. Similar tool, different focus.

Asked by gvdhoorn on 2022-06-30 03:07:16 UTC

I guess you could summarise my comment as: don't over-constrain your search by just looking for IK solvers.

I'd look at motion planners in general. They'll always come with IK / FK solvers. How they interact with those solvers would come down to how the authors see the division of responsibilities.

Asked by gvdhoorn on 2022-06-30 03:09:13 UTC

Thanks. yes, our implementation is currently part in the IK solver and part in a planner. That's more a convention as there are actually 3 layers: the IK planner by itself, the collision avoidance without moving the tool by iterating in the null space, and the collision avoidance by moving the tool.

Asked by thibd on 2022-07-03 11:29:37 UTC

And yes, we are considering both IK and motion planners.

Asked by thibd on 2022-07-03 11:30:41 UTC

Answers