Kinematics solver: implementations via MoveIt / OpenRave / V-REP / IK-Fast / Trac-IK / KDL / etc

[gonzalocasas]

Specific implementations for different solvers. To be split into multiple issues.

[yijiangh]

FYI, for IKFast code generation, I have a detailed tutorial with concrete examples (ABB robot on a linear track) here. I spent a lot of time mining tutorials on this (especially for 7-dof system, which has 1 redundant joint) online. Hopefully this tutorial can be helpful.

Another WIP analytic kinematic solver is OPW_kinematics which is compatible with 6-dof systems only, but we can discretize redundant joint on our side.

[jf---]

I'd be happy to contribute a KDL solver. I'm assuming first an abstract base class is implemented, specifying the API?

[gonzalocasas]

@jf--- that would be awesome! 💯 I'll make a couple of changes and send you/post here the specific API to implement this! thx!

[yijiangh]

In regard to IKFast, I just made this package ikfast_pybind and an in-progress tutorial to streamline the process of building IKfast modules and build python bindings. With these python modules built and installed, we can have access to IKFast through compas_fab's API.

[gonzalocasas]

@jf--- the abstract base classes that define the API are finally ready! There's docs about the general architecture of these interfaces here and specific about the IK solver interface is here.

You'll see that these interfaces ('backend features') are client-based, ie they assume there's a service they connect to and they come accompanied by a client interface that handles the connection. The info flow over the different classes involved is: Robot -> Client -> Planner -> Backend feature (in short, their responsibilities are: scale & convert data -> handle client connection -> group planning features -> actual implementation).

If the solver is client-less, the implementation can easily be attached to any other client to replace the default implementation. For example, here's tiny custom IK solver using deriving PyBullet client to leverage its collision checking:

from compas.geometry import Frame
from compas_fab.backends.interfaces import InverseKinematics
from compas_fab.backends.pybullet import PyBulletClient

# New IK solver needs to inherit from the InverseKinematics interface
class KdlInverseKinematics(InverseKinematics):
    def __init__(self, client):
        self.client = client

    def inverse_kinematics(self, robot, frame_WCF, start_configuration=None, group=None, options=None):
        # here goes the magic 🌟
        config = calculate_ik_magically()
        self.client.check_collisions(robot, config)
        return config.values, config.joint_names

# Here we hook it up
class AectualClient(PyBulletClient):
    def inverse_kinematics(self, *args, **kwargs):
        return KdlInverseKinematics(self)(*args, **kwargs)

# So that usage would be:
with AectualClient() as client:
   robot = client.load_robot(path_to_urdf_file)
   some_frame = Frame([0.3, 0.1, 0.5], [1, 0, 0], [0, 1, 0])

   print(robot.inverse_kinematics(some_frame))

[jf---]

@gonzalocasas thanks for the elegant example. I'm messing about with a tesseract, of ROS-Industrial fame

tesseract includes a KDL IK solver & FCL collision detection ( which was what build upon in the good ol' Odico days ), but most of all, implements the trajopt algorithm, and also the descartes ROS-I planner

I'll hit you with a draft PR when there's something worth sharing. The fact that compas_fab supports a generic PlannerInterface is highly encouraging 💎

[gonzalocasas]

yay!! looking forward! 👍