1. Introduction
Ordinary control systems for robots are based on having a controller which continuously calculates the inverse kinematics for the robots [
1,
2]. We present a new approach, where the inverse kinematics is solved ahead of time. Similar to offline programming of robots, the inverse kinematics is also solved before the robot performs its task. This approach reduces the complexity of robot control system tenfold, resulting in a system that only needs to read joint values from a file and send the values to the actuators of the robot with a given cycle time.
The current trend in programming for high volume robotic production systems is the use of offline programming. For smaller businesses, the current approach is still manual programming on teach pendant and similar [
3]. There will probably be a shift towards offline programming, even for smaller businesses. This can reduce the time for reprogramming and re-purposing of robots while the robots are still producing. Considering that it takes 400 times as long to program a robot for a complex task as it takes for the robot to actually perform that task [
4], offline programming can be a valuable tool for reducing Life-Cycle Cost (LCC) and increasing Overall Equipment Effectiveness (OEE). For many of the applications of robots where the programming is performed offline, the tasks are performed without external feedback. This opens up the possibility of pre-calculation of the inverse kinematics.
Robots are becoming increasingly more common in industrial fields; however, they are usually limited to simple tasks. The International Federation of Robotics report that 72.7% of all industrial robots are used for pick-and-place, welding and assembly [
5]. For certain tasks, conventional robot design supplied by the major robot companies may just not cut it. This may result in a need for a custom robot manipulator design, where both the joints and the links are designed with the given task in mind. However, robotic system are inherently complex [
6]. Simplification of the robot control system with the help of offline calculation of the inverse kinematics may reduce the complexity of robotic system, and thus the threshold for realizing a custom robot, enabling robotic technology to solve new tasks.
The computation of the inverse kinematics of robots is well studied in the literature [
7,
8,
9,
10,
11,
12,
13], to name a few. There are multiple approaches to calculating the inverse kinematics. One approach for solving the inverse kinematics is by analytically finding a closed form solution, which gives a direct mapping from Cartesian space to the joint space. While the closed-form solution is the most computational effective solution, it may sometimes be difficult, or even impossible, to find. Another approach is by using a numerical technique. Instead of finding a closed-form solution which gives the correct solution after one iteration, a numerical technique converges towards a correct solution after several iteration. One such approach is the Newton-Raphson algorithm [
14,
15], another is the Closed-Loop Inverse Kinematics (CLIK) algorithm, which views the inverse kinematics problem as a feedback control loop [
16,
17]. Very few papers considers directly the gain of the feedback loop of the CLIK. The gain of the CLIK in discrete time was assessed in order the prove proof of convergence in [
18], while [
19] further analyzed the stability of the control loop in discrete time. The importance of the gain in the feedback loop was shown in [
20], however, no approach for choosing the correct gain was presented. In recent years, there has also been an interest in using artificial intelligence for solving the inverse kinematics problem [
7].
Artificial Intelligence is a hot topic of research, with a vast area of applications [
21,
22,
23,
24,
25]. Genetic Algorithms (GA) is a metaheuristic which belongs to the larger class Evolutionary Algorithms (EA). GA and EA can be used to find optimal solution to a problem with more than one variable, and also problems which are both multi-variable and multiobjective. Applications of GA in the field of robotics has received quite a bit of interest over the years. A GA based heuristic was used for flow shop scheduling in [
26]. Two PID controllers for controlling the links of a two-link planar rigid robotic manipulator was optimized using GA in [
27]. GA was used in combination with fuzzy logic controllers for learning behaviour in a robotic football experiment in [
28]. GA has also been applied for learning in fuzzy systems [
29]. Robot selection for paint stripping of steel bridges was carried out by a GA in [
30]. A fractional order fuzzy pre-compensated fractional order PID controller for a 2 degrees of freedom manipulator was developed in [
31]. Artificial bee colony GA was presented and used to optimize the controller’s parameters. Neural networks was used to get an approximate inverse kinematics solution and then the solution to the inverse kinematics problem was optimized by applying GA for error minimization in [
32]. In addition to research related to application of GA and similar algorithms, combinations and improvement of the algorithms themselves also has received a fair share of research [
31,
33,
34,
35]. To the best of the author’s knowledge, no previous work has used a GA to optimize the gain of closed loop inverse kinematics algorithm.
The rest of the paper is organized as follows. First, an example of a typical layout of a robot control system is presented, along with our approach to a robot control system. This is presented in
Section 2. In
Section 3, the kinematics problem is presented, along with the numerical technique used to solve the inverse kinematics problem. A solution for trajectory planning is also presented.
Section 4 shows the Inverse Kinematics Solver implemented on a custom design robotic manipulator, with examples of input and output from the program. Computational times are also presented. Optimizing of the gain of closed loop inverse kinematics algorithm is presented in
Section 5. Finally,
Section 6 concludes and discusses further work.
2. Robot Control Systems
An example of a conventional robot control system can be seen in
Figure 1. This approach gives a highly flexible control system. Some of the capabilities of a conventional robot control system can be: real time correction based on sensors, such as vision, force/torque sensor, temperature sensors, etc., network communication for visualizing the robot in simulation software, programming and monitoring via Teach Pendant. However, building such a control system is time consuming, requires a powerful CPU, and usually has to be implemented in some sort of a low level programming language.
Our new approach simplifies the robot control system, reducing development time significantly. All the parts of the control system can be seen in
Figure 2. As is obvious, developing such a control system is much quicker than developing a more typical control system architecture. However, this is just a bare minimum approach. Expanding the control system to support IO, network, etc., still works using offline kinematics calculation.
Simplifying the control system does come at a cost. The biggest drawback of having a control system which uses offline kinematics calculation is that real-time correction of robot poses is not possible.
3. Kinematics
The position and rotational pose of the end effector of serial link robot can be described as a series of transformations where each transformation is from the previous joint to the current joint. The form of a transformation can be seen in Equation (
1).
where
is the rotation matrix,
is a vector which represents the displacement,
is the zero vector.
A popular approach to setting up transformation between links is the Denavit-Hartenberg (DH) convention. The DH parameters can be extracted from the robot and the corresponding transformation calculated. The transformation using the DH convention can be done as follows:
where
d is the offset between the common normal along the previous
,
is the angle between the old
to the new
, about the previous
,
a is the length of the common normal, and
is the angle from old
axis to new
axis, about the common normal. The
-axis is completed with the right hand rule.
Multiplying all the link transformations then gives the total transformation from the base of the robot to the end effector. This is called the forward kinematics, where the joint values are known, and the end effector pose is calculated. The opposite problem, finding the joint values with a given end effector pose, is called the inverse kinematics.
3.1. Inverse Kinematics
There are multiple approaches to calculating the inverse kinematics. One approach for solving the inverse kinematics is by finding a closed form solution, which gives a direct mapping from Cartesian space to the joint space. While the closed-form solution is the most computational effective solution, it may sometimes be difficult, or even impossible, to find. Another approach is by using a numerical technique. Instead of finding a closed-form solution which gives the correct solution after one iteration, a numerical technique converges towards a correct solution after several iteration. In recent years, there has also been an interest in using artificial intelligence, with a bias towards Artificial Neural Networks, for solving the inverse kinematics problem.
For our approach, we are using the numerical technique CLIK to solve the inverse kinematics problem. This is chosen for simplicity and re-configurability, and since speed and computational efficiency is not of primary concern. An overview of the numerical technique can be seen in
Figure 3.
The inverse kinematics is solved by taking the Jacobian of the current robot pose, taking the inverse of it, and multiplying it with an vector that represents the error in positioning and rotation and a gain (K). The Jacobian is the mapping between the joint velocities and the corresponding end effector linear and angular velocity. A step towards the desired pose is then achieved. This is repeated until the joint angles that give the desired pose is found. If it does not converge after a number of steps, it is likely that the pose is at a singularity, or outside the work envelope of the robot.
The Jacobian for a series of revolute joints can be found as follows:
where
is the axis of rotation for the
nth axis (with a zero-index),
is the position of the
nth joint.
The Jacobian for a series of prismatic joints can be found as follows:
The two equations can be combined to find the Jacobian for a manipulator consisting of both revolute and prismatic joints.
Another benefit of this approach to solving the inverse kinematics is that is it is easy to reconfigure to a new robot, only the transformations between the links needs to be changed. With a closed form solution, all the expressions needs to change when a new manipulator design is to be calculated.
3.2. Trajectory Planning
Another important step for a robotic control system is trajectory planning. Simple point to point motion for the end effector only needs the inverse kinematics solved for the start point and the end point, and the servos can move in whatever order to reach the desired pose. However, when the trajectory of the end effector is of concern, certain steps have to be taken. The most common trajectory between two points is a linear translation accompanied with a simultaneous linear rotation. The Jacobian can be used calculate the joint velocities in order to move the end effector with a constant linear velocity. However, since for a real world application the output to the joint angles has to be discretized, a simpler approach is to calculate the joint angles for a set of points on a line, resulting in approximate linear path.
4. Implementation with a Custom Robot
To test the Inverse Kinematics solver, a robot was set up in the DH table, and the inverse kinematics was calculated. A figure of the custom robot can be seen in
Figure 4. Due to the nature of the DH convention, joint 4 has to be considered as overlapping with joint 3. For simplicity, this is not taken into account in the figure. The DH table can be seen in
Table 1. The graphical user interface (GUI) with the implemented DH table can be seen in
Figure 5.
4.1. Format
The format of the input file is as follows:
Motion Type: Either PTP, for Point to Point motion, or LIN, for a linear trajectory from the previous pose to the new pose.
X: The x coordinate of the end effector, with respect to the base frame.
Y: The y coordinate of the end effector, with respect to the base frame.
Z: The z coordinate of the end effector, with respect to the base frame.
Roll: Roll angle of the end effector. Angle, in radians, around the x-axis of the current frame (which is parallel to the x-axis of the base frame).
Pitch: Pitch angle of the end effector. Angle, in radians, around the current y-axis.
Yaw: Yaw angle of the end effector. Angle, in radians, around the current z-axis.
Configuration bit 1: Configuration bit for deciding “elbow up” or “elbow down” in joint 3.
Configuration bit 2: Configuration bit for deciding “elbow to the right” or “elbow to the left” for joint 6. However, this is just for that specific implementation, in reality it is just a check for the joint value at joint 3 and, and if it opposite of what the configuration bit says it should be, change the sign.
Velocity: Velocity of the end effector. For PTP, this is a relative velocity, where 100 is 100% velocity, dictated by the joint that has the furthest to travel. The other joints will move with reduced velocity in order to reach the desired joint angles simultaneously. For LIN, the value is in m/s. The value will dictate how many interpolated points will be generated.
Acceleration: Acceleration of the end effector.
The fields in the input is delimited by a space. An example of an input file can be seen in
Table 2.
The format of the output file is the 6 joint values, in radians. The resulting output from the input in
Table 2, can be seen in
Table 3.
An example of a LIN motion can be seen in the table. The previous motion is added for reference of the start point. The LIN motion is calculated with a step length of 100 ms, beginning at time 0 ms.
4.2. Computation Time
As discussed previously, the computational speed of the inverse kinematics is not of great concern for offline calculation. However, if the inverse calculator is to be implemented in an online application the computational speed is of great concern. For this reason, the computation time for the input set in
Table 2 and the resulting output,
Table 3, was measured. Since the LIN motion results in several steps with the same step length, and thus the same number of iterations, some of them have been omitted. Bearing in mind that a standard PC has a lot of computational power, it comes as no surprise that even single thread computation of a lot of iterations are completed in a short amount of time. Some computation times can be seen in
Table 4. This is done with a gain of 0.2 for position and 0.1 for rotation, on a Intel Core i7 7700 CPU. The initial guess for the joint values for the first iteration is 0.0 for all joints.
6. Discussion and Conclusions
Separating the inverse kinematics calculations from the robot control system, and keeping the number of tasks for the robot control system to a minimum can reduce the time to develop such a system. Realizing the Inverse Kinematics Solver in Java was a straight forward task, and may enable others to build robot control systems quicker.
At this stage, the Inverse Kinematics Solver is limited to six revolute joints, with the DH table set within the program. A future version should have coverage for a varying number of joints and prismatic joints, with the possibility to set it all up from the GUI. In addition, the rotations are done by Euler angles. This may result in singularity problems, and using quaternions might be a better option. The IKS could also be expanded to include trajectory generation for circular motions.
Optimizing the gain of the IKS with GA gave, as can be seen in the results, a much quicker convergence than randomly selecting some gain. However, the author could not find any other research which focused on optimizing the gain of the CLIK with respect to computational speed, so doing a quantitative comparison to other approaches was not possible. This might be due to the fact that if the desired robot pose is far from singularity, and the initial guess is quite good, the gain for the feedback can be as high as 1, which is the same as not multiplying the feedback by any factor.
In addition, the CLIK in this current implementation does not have any mechanism for handling solutions that are singular or very close to singular. Singularities will result in an inverse Jacobian where one or more of the element will have a high value, increasing the chance for the CLIK to oscillate. Implementing a mechanism for handling this problem, for instance Damped Least Squares, might have a high influence of the optimal gain of the loop, possibly resulting in even quicker convergence. However, with the current lack of singularity handling, the GA finds an optimal solution which does not oscillate, even at singular poses.