# A Novel Approach for a Inverse Kinematics Solution of a Redundant Manipulator
## 3 Inverse Kinematic Model and Computing Algorithm
### Final Inverse Kinematic Model
Our approach is based on changing the priority of a particular task of the inverse kinematic model during the simulation, according to simulation behavior. During the performance of the \"WHILE 2\" cycle, the variable _counter_ increases in each cycle while the actual position of the end-effector x does not equal the required position \(\mathrm{x_{d}}\). If the value of the variable _counter_ is greater than _max. admissible value_, which means that the calculation time is too long, the priority of the chosen task decreases in order to accelerate the computation. When the solution for the required position \(\mathrm{x_{d}}\) has been found and at the same time if the value of the variable _counter_ is lower than _min. admissible value_, the priority of the chosen task increases. Increasing, as well as decreasing, the priority of the chosen task is in certain boundaries defined function (linear, quadratic, etc.). Our new approach, namely flexible priority solution (FPS), significantly accelerates the computation of the inverse kinematic model with secondary tasks that will be shown in the simulation results. ## Low Level Control

For experimental purposes, we used a five-link manipulator with five Dynamixel AX-12 servomechanisms (ROBOTIS, Seoul, Korea) with a torque of 1.49 Nm and a speed of 0.169/60\({}^{\circ}\). The servomechanisms were connected in series, as shown in Figure 6.

The servomechanisms communicate together through UART (Universal asynchronous receiver-transmitter) communication protocol using circuit SN74 LS241N. Every transmitted and received packet has the following form:

\[0x\text{FF--0 xFF--Id--Length--Instruction--Parameter 1-- \ldots --Parameter N--Check sum}\]

The first two bytes indicate the start of the received or transmitted packet. By other bytes we set the required operation from all available functions of Dynamixel AX12. The servomechanisms of the experimental manipulator were controlled by an ATmega162 microcontroller running at 16 MHz. The ATmega162 microcontroller has RISC (Reduced instruction set computer) architecture allowing up to 16 MIPS (Million Instruction Per Second) throughput at 16 MHz. The simplified model of algorithm running on ATmega162 describes Algorithm 4 (Low level control):
```
1:CYCLE WHILE 1
2:Find out positions of servomechanisms (UART 1)
3:Send positions to PC (UART 2)
4:CYCLE WHILE 2
5:wait for all required positions from PC
6:END CYCLE WHILE 2
7:Move servomechanisms to required positions
8:END CYCLE WHILE 1
```
**Algorithm 4** Low level control

The \"WHILE 1\" cycle is an infinite cycle running on microcontroller ATmega162. The microcontroller uses two independent UART communications, the first one for communication with the servomechanism inner controller and the second one for communication with a PC. Both of these communications run at a speed of 200 kB/s. The scheme of information flow is shown in Figure 7.

The user determines the input parameters, such as the priority of primary and secondary tasks. The control systems are run using MATLAB (MathWorks, Natick, MA, USA) software, which transmits the requirements of servomechanisms positions to the microcontroller and microcontroller to the inner control system of the servomechanisms. The actual positions of the servomechanisms are transmitted to the microcontroller by the inner control system of servomechanisms. The microcontroller processes these data and transmits them to MATLAB. Algorithm 5 (Modified algorithm for inverse kinematic model) is run in MATLAB, while Algorithm 4 (Low level control) runs in the ATmega162 microcontroller. ```
1:CYCLE WHILE 1
2:Determination of new required vector \(\mathrm{x_{d}}\in\mathrm{R^{m}}\) from the matrix of planned path \(\mathrm{P}\in\mathrm{R^{r}}\times 2\)
3:CYCLE WHILE 2
4:increase counter
5:IF counter > max.