Inverse Kinematics
Inverse kinematics (IK) finds the joint coordinates \(\vec{q}\) that put the end-effector at a desired pose \(\mat{T}\). It is the reverse of forward kinematics, and is harder: there may be no solution, one, several or infinitely many, and which one you get can matter.
Every IK method in the Toolbox takes the same input and returns the same result.
The desired pose, Tep
Tep is the desired end-effector pose in the robot’s base frame, an SE3 or a 4x4 NumPy array (a homogeneous transformation). The name follows the Toolbox convention: T is an SE(3) pose, e is the end-effector, p is “prime”, the desired value, and with no frame to the left of the T the world or base frame is implied. Most methods also accept a trajectory of poses, an SE3 object containing N poses or an array with shape (N, 4, 4), that is one pose for each index of the first axis, not (4, 4, N) as in MATLAB.
The result, IKSolution
The result is an IKSolution.
Member |
Meaning |
|---|---|
|
the joint coordinates, shape (n,) for a pose or (N, n) for a trajectory; not valid if there was no solution |
|
true if a valid solution was found |
|
how many iterations were performed, zero for an analytic solution |
|
how many searches were performed, zero for an analytic solution |
|
the final error of the solution |
|
why it failed, if it did |
An IKSolution is a sequence of the rows of q, so len(sol) is the number of poses and for q in sol visits them, and bool(sol) is success.
Changed in version 1.5.0: Iterating over the six members was removed, use the attributes or sol.astuple().
The Toolbox has three ways to find a solution, shown in the figure. Numerical solvers start from a guess for \(\vec{q}\) and iterate until the pose is reached. They work for any robot, and are written in Python, or in C++ for speed. Analytic solvers (see Analytic inverse kinematics) derive the equations of the inverse kinematics once, symbolically, and then solve them directly for any pose, with no guess and no iteration, giving all the solutions. They work for six-axis arms, and can write the solution out as source code with no dependency on the Toolbox.
The three mechanisms (click to enlarge). The numerical methods ikine_XX and ik_XX are methods of the ETS class, and a robot has methods of the same names that call its ETS. The analytic methods belong only to DHRobot.
The numerical algorithms have names that are shown ending in _XX, where XX identifies a particular numerical algorithm:
|
Algorithm |
|---|---|
|
Levenberg-Marquardt |
|
Gauss-Newton |
|
Newton-Raphson |
|
quadratic programming (not for C++ solvers) |
For a tutorial on numerical IK, see here.
Numerical, Python |
Numerical, C++ |
||
|---|---|---|---|
Robots |
six-joint arms with standard DH parameters |
any, from an |
any, from an |
Solutions |
all of them, or the one nearest |
one, which depends on |
one, which depends on |
Initial guess |
not needed |
needed |
needed |
Trajectory |
yes |
yes |
no, one pose only |
Time for one pose |
about 0.2 ms, or microseconds as generated C |
about 1 ms |
about 10 µs |
Methods |
|
|
|
Extra to install |
|
none |
none |
In the browser (JupyterLite) |
yes |
yes |
no, it needs the compiled extension |
SymPy parameters, joint offsets |
not applicable |
yes, if every parameter has a numeric value |
no, see C++ Solvers |
The times are indicative, for a six-axis arm on a recent laptop (an Apple M4). The script examples/benchmark_ik.py in the repository measures the numerical solvers on your own machine. Where an analytic solution exists it is the right choice: it is exact, finds every configuration, and can be generated as code for a controller. Otherwise use a numerical solver, and the C++ one if you only need a single pose quickly and its limits do not matter to you.
Analytic
The analytic solvers are methods of a DHRobot. analytic_ik() makes a solver for the robot, which gives every solution for a pose and can write the solution out as source code, and ikine_analytic() is the one-step counterpart of the ikine_XX methods. They need the ik extra, which installs SymPy. See Analytic inverse kinematics for how to use them, and the notebook ik-symbolic.ipynb for worked examples with a Puma 560, the Stanford arm and a Kinova Jaco, including trajectories and code generation.
Numerical
The numerical solvers start from a guess and iterate. They work for any robot and are written in C++ and in Python, but the C++ ones need the compiled extension and have limits. See Numerical inverse kinematics for the arguments that they share, and for the C++ and Python solvers, the classes that implement them and examples.