Teleoperating an ABB IRB 2400-16 (II)

Delay issues found during the RS422 serial communication and RAPID program execution

Different programming and communication techniques were tested under the development of the optimum teleoperation control. Some of them have already been explained before, and some others related with the loop delay will be commented here.

Pseudo-code of RAPID program running on the SC4+ controller

In a serial communication channel, a common baud rate between sender and receiver has to be established. Different baud rates were tested with the objective of increasing as much as possible the loop frequency of the bilateral control. The measured bilateral loop frequency with each baud rate was the indicated by the table below. It can be seen how the obtained frequency is slow and it is not able to overcome the 13 Hz barrier. In order to study the origins of this unacceptable delay, experiments were performed to measure the execution time of simple instructions written on RAPID code. The methodology used to measure the execution time was the following: certain digital outputs of the SC4+ controller were turn high and low before and after a command execution. They were read with an oscilloscope in order to estimate the elapsed time during the execution of basic instructions.

Table 1. Bilateral loop frequency reached at different baud rates.

The IO unit used for measuring the time lapses was the DSQ328, consisting in 16 digital inputs and 16 digital outputs. The results obtained, which are summarized later, are the following:

A. Changing the state of a digital output.

The time elapsed on changing the state of a digital output was characterized to take into account the minimum amount of time required for measuring the rest of instructions. These set of commands shown in Table 2 (Test 1) turn the first digital output on, then off and finally on again. With this methodology it is possible to characterize the time invested in changing the value of a digital output. This set of instructions produce a voltage profile as shown in the figure. This result means that the first two instructions that turn on and off the digital output 1 have a time lapse of 5 ms, or approximately 2.5 ms in executing each instruction.

B. Write a binary data on the serial channel

The same procedure was applied for the set of commands shown in Table 2, test 2. They took a total time of 6.5 ms. This result helps to infer the time needed to write a binary number, which is around 1.5 ms.

C. String conversion and writing on the serial channel

In Table 2, test 3 it can be seen that the total time expend on this operation is 6.5 ms, which gives a total time for the string conversion and sending of 1.5 ms.

D. Time invested in reading 6 joints’ values

It is important to estimate the required time taken by the robot controller in reading the 6 joint values because these set of instructions are going to be repeated in each cycle and the total time should be minimized. In Table 2 test 4, the total time taken by this set of instructions is 35 ms. Due to the basic set of on and off instructions takes 5 ms, it is possible to infer that the reading of 6 joints values takes 30 ms.

E. Time invested on reading 6 joints values with channel opening and closure.

It is shown in Table 2, and test number 5, than the total time for this set of instruction was 40 ms. This establishes the time required for opening and closing the communication channel in approximately 10 ms.

F. String operations.

Some string manipulations were also quantified to check if the predicted longer operation times were finally measured. The time on reading a string with the values of 6 joints turned out to be 25 ms, and this proved that string operations were not particularly slower.

Oscilloscope waveform recreation of test A

G. Stop the movement and clear the path

Finally the set of instructions for stopping a movement and clearing the buffer of stored movements were analysed and the results clearly indicated the origin of the big delay measured during the teleoperation loop.

The movement stopping command turned out to be just 1 ms operation, while clearing the buffer took up to 300 ms

H. Moving operations

The execution of a moving operations was also analysed. It was found that, as expected, that the time invested for the robot to move was obviously dependent on the target point to be reached. Nevertheless, for a static target position, this is, executing a target position that is the same than the current one, the amount of time required for executing the move operation without the concurrent movement was approximately of 100 ms. The concurrent movement allows the execution of the following operations at the same time than the movement is being accomplished. Unfortunately there is a limitation of 5 instructions in succession, so this strategy could not be employed in an infinite loop.

The methodology employed for measuring the instruction time using an oscilloscope to register the signal coming from the digital outputs of the controller board, proved to be successful. The large amount of time employed by the robot controller (SC4+) in executing simple set of instructions together with the slowness of the communication channel resulted in a very slow loop frequency of around 13 Hz. This low frequency created a very jittery movement and an erroneous reference tracking since the slave was not able to follow the master properly. With the default loop configuration, every time a movement instruction is executed, the controller waits until it is finished before a new movement command is executed. The slow loop frequency and this characteristic provoked a big error when tracking the master. The operator moved the master much faster than the slave was able to update its position. This operating condition was the cause of instabilities and poor performance on the bilateral control. With the objective of increasing the performance, the ability of interrupting the robot movement to update the robot target position on real time was investigated. The only option available without having additional and expensive software extensions was to use the couple of instructions before mentioned of stopping the movement and clearing the buffer. This set of commands allows to stop the current joint target value and prepare the controller for the new one by clearing the planned path. It has been shown the large amount of time required for clearing the buffer which decreased the loop time to around 4.5 Hz. These values are significantly smaller than those ones recommended in the literature [1], [2], [3], where values ranging from 100 Hz to 1000 Hz are recommended for positional bandwidth. Even faster frequencies are recommended in order to obtain a good force response.

Table 2. Timming analysis for SC4+ controller instructions.

The loop frequency obtained during the practical implementation on the ABB IRB 2400-16 with the SC4+ controller, would make a bilateral teleoperation unpractical. Typical values obtained when the slave is in movement are in the order of 4 Hz due to strong hardware limitations. Given the time required by the controller to execute some basic functions, even updating the communication channel and installing Ethernet would not guarantee much better performance. During conversations with ABB representatives from United Kingdom, the best time response they had achieved was a position update frequency range of 100 ms to 200 ms, meaning that the maximum achieved loop frequency was 10 Hz. This is not much faster than the frequency achieved in this experiment. However, it is expected that in newer controller versions, i.e., IRC5 the controller speed would be faster, allowing a better performance of the teleoperation tasks when force feedback is needed. It seems that ABB does not facilitate the rapid interfacing with the low level control system on its robots, giving the research community difficult alternatives. It was possible to find out that the team of Lund University have manage to run the teleoperation loop at 250 Hz using the IRC5 controller after an intense research carried out during years. However, for force-controlled manipulation and teleoperation applications, especially in stiff environments, there is a unanimity of the literature, that control rates of more than 1 KH are essential to avoid damaging the robot and its environment. In this sense it has been an effort of the research community to overcome the limitations of the commercially available control systems for the industrial robots manipulators. Also, although ABB seems reluctant to allow a quick access to its controller, several industrial robots suppliers including Mitsubishi, COMAU Robotics, KUKA Roboter GmbH, and Staubli  have introduced a possibility of interoperability of their robot controllers with control algorithms executing on external computers and developed new control interfaces enabling open communication channels with rates higher than 1 kHz in some cases.