Kinematics

Forward kinematics

Forward kinematics (FK) is the pose of the end-effector given the joint coordinates. It can be computed for robots of the DHRobot or ERobot class

T = robot.fkine(q)

where T is an SE3 instance.

T = robot.fkine_all(q)

where T is an SE3 instance with multiple values, the pose of each link frame, from the base T[0] to the end-effector T[-1].

Inverse kinematics

Inverse kinematics (IK) is the joint coordinates required to achieve a given end-effector pose. The function is not unique, and there may be no solution.

RTB's numerical IK solvers are implemented as classes in roboticstoolbox/robot/IK.py (IK_NR, IK_LM, IK_GN, IK_QP), each with a .solve(ets, Tep) method. Robot and ERobot also expose a convenience method per solver, so you don't need to import and instantiate the class yourself for the common case:

Method	Solver class	Type	Joint limits	Description
ikine_a	—	analytic	no	For specific DHRobots only, see below
ikine_NR	IK_NR	numeric	yes	Newton-Raphson
ikine_LM	IK_LM	numeric	yes	Levenberg-Marquadt, with a choice of damping-matrix method (chan/wampler/sugihara)
ikine_GN	IK_GN	numeric	yes	Gauss-Newton
ikine_QP	IK_QP	numeric	yes	Quadratic-programming based (requires the qp optional dependency, qpsolvers/quadprog)

Equivalently, construct the solver class directly and reuse it across multiple calls:

solver = rtb.IK_LM()
sol = solver.solve(robot.ets(), Tep)

All methods return an IKSolution dataclass (roboticstoolbox/robot/IK.py):

Attribute	Type	Description
q	ndarray(n)	Joint coordinates for the solution — not valid unless success is True
success	bool	True if a solution was found
iterations	int	Number of iterations performed
searches	int	Number of searches performed (a search restarts from a fresh initial guess after ilimit iterations without convergence)
residual	float	Final value of the cost function
reason	str	Reason for failure, if applicable

IKSolution also supports tuple-unpacking (q, success, iterations, searches, residual, reason = sol) for backward compatibility with the older named-tuple return.

Numerical solutions

These IK solvers minimise a scalar measure of error between the current and the desired end-effector pose. The measure is the squared-norm of a 6-vector comprising:

• translational error (a 3-vector)
• the orientation error as an Euler vector (angle/axis form encoded as a 3-vector)

Each solver supports joint-limit avoidance and a secondary manipulability-maximisation objective via the kq/km gain parameters — see the solver classes' docstrings (IK_NR, IK_LM, IK_GN, IK_QP in roboticstoolbox/robot/IK.py) for the full parameter list and the underlying maths.

There's no current relative-performance comparison across solvers/methods/joint-limit settings on this page — the one that used to be here measured the now-removed SciPy-minimize-based ikine_min solver (and hasn't been replaced with numbers for the current IK_NR/IK_LM/IK_GN/IK_QP classes). If you need real numbers, benchmark against your own robot/use case — the relative cost differences (e.g. ikine_a being much faster than any numerical solver when it's available) are still qualitatively true.

Analytical solutions

Only the DH/Puma560 robot model has an analytic solution method ikine_a(T, config).

Such a method could be added to any other robot class, including any custom class that you might write.

For the class of robots that have 6 joints and a spherical wrist, the Toolbox provides additional support. First define a method in your class

def ikine_a(self, T, config):
    return self.ikine_6s(T, config, func)

where:

• ikine_6s is a method of the DHRobot class
• func is a local function func(robot, T, config) that solves for the first three joints, given T which is the pose of the wrist centre with respect to the base.
• config is a pose configuration string. For example, the Puma robot defines this as

Letter	Meaning
l	Choose the left-handed configuration
r	Choose the right-handed configuration
u	Choose the elbow up configuration
d	Choose the elbow down configuration
n	Choose the wrist not-flipped configuration
f	Choose the wrist flipped configuration

but you can choose whatever is appropriate for your robot.

Base and tool transforms

All robot classes support a base transform. This defines the pose of the robot's base with respect to the world frame and is by default null transform (identity matrix).

DHRobot objects support a tool transform. This defines the tip of the robot's end-effector with respect to the final link frame, which is typically inside the spherical wrist. By default this is a null transform (identity matrix). Note that some robot models describe the tool transform using DH parameters, see Section 5 of this tutorial.

Joint offsets

DHRobot support a joint offset which is important since often the required zero-angle configuration is not what the user or robot controller considers the zero-angle configuration, due to the constraints imposed by DH notation.

For forward kinematics the joint offsets are added to yield the "kinematic" joint angles, and then the forward kinematics are computed. This occurs within the A method of the DHLink class. This means that the offsets are the kinematic joints angles corresponding to the user's zero-angle configuration.

Jacobian calculation use the A method so joint offsets are taken into consideration.

Numerical inverse kinematics use the fkine method so joint offsets are taken into consideration. Analytical inverse kinematics explicitly subtract the offset in the ikine_6s method.

Robots with multiple end effectors

This is just speculation so far...

T = robot.fkine(q, link)

where link is either a reference to a Link subclass object, or the name of the link.

q = robot.ikine_XX(T, link)

where link is either a reference to a Link subclass object, or the name of the link.

Ideally we would be able to express other constraints by passing in a callable

q = robot.ikine_XX(T, lambda q: 0.1 * q[2]**2)

which adds a cost for elbow bend, for example.