BRNO UNIVERSITY OFTECHNOLOGYVYSOKE UCENI TECHNICKE V BRNE

FACULTY OF ELECTRICAL ENGINEERING ANDCOMMUNICATIONCYBERNETICS, CONTROL AND MEASUREMENTSFAKULTA ELEKTROTECHNIKY A KOMUNIKACNICH TECHNOLOGIIKYBERNETIKA, AUTOMATIZACE A MERENI

CONTROL OF 6 JOINT ROBOT IN REAL-TIME LINUX

SEMESTRAL PROJECTSEMESTRALNI PROJEKT

AUTHOR LUKAS DOKTORAUTOR PRACE

BRNO 2009

BRNO UNIVERSITY OF TECHNOLOGYVYSOKE UCENI TECHNICKE V BRNE

FACULTY OF ELECTRICAL ENGINEERING ANDCOMMUNICATIONCYBERNETICS, CONTROL AND MEASUREMENTS

FAKULTA ELEKTROTECHNIKY A KOMUNIKACNICHTECHNOLOGIIKYBERNETIKA, AUTOMATIZACE A MERENI

CONTROL OF 6 JOINT ROBOT IN REAL-TIME LINUXRIZENI 6-TI OSEHO ROBOTA V REAL-TIME LINUX

SEMESTRAL PROJECTSEMESTRALNI PROJEKT

AUTHOR LUKAS DOKTORAUTOR PRACE

SUPERVISOR ING. PAVEL KUCERA, PH.D.VEDOUCI PRACE

BRNO 2009

ZDE VLOZIT LIST ZADANI

Z dubodu spravneho cıslovanı stranek

ZDE VLOZIT PRVNI LIST LICENCNISMLOUVY

Z duvodu spravneho cıslovanı stranek

ZDE VLOZIT DRUHY LIST LICENCNISMLOUVY

Z duvodu spravneho cıslovanı stranek

ABSTRACTThe author describes a control of 6 joint robotic arm using the real-time operationsystem GNU/Linux. The robotic arm is built using electric servo motors, which arecontrolled directly from a parallel port of the computer. Control program itself isdivided into 2 parts, client and server. Communication between them is handledby standard POSIX sockets which brings a possibility of control over the network.The project’s main focus is on new design using small modules, which handlesparticular function. Than it’s easier to verifie the right functionality. It also exploreother opportunity which real-time GNU/Linux provides to increase developmenteffectivity and safety of the design.

KEYWORDSGNU, Linux, MRG, RHEL, Real-time, robotic arm, joint, servo motor, parallel port,LPT

ABSTRAKTAutor resı moznosti ovladanı 6-ti ose roboticke ruky v operacnım systemu real-time GNU/Linux. Servopohony roboticke ruky jsou prımo ovladany rıdıcımisignaly z paralelnıho portu pocıtace. Samotne ovladanı je rozdeleno do 2 castı,klient a server. Komunikace mezi nimi je za pomocı standardnıch POSIX socketucımz umoznuje ovladanı pres sıt.Prace se zameruje na vytvorenı jednoduchych modulu, ktere se zamerujı nakonkretnı cinnost a lze jednoduse overit jejich spravnou funkcnost. Dale sezabyva moznostmi ktere operacnı system real-time GNU/Linux vyvojari posky-tuje k urychlenı a zabezpecenı vyvoje.

KLICOVA SLOVAGNU, Linux, MRG, RHEL, Real-time, roboticka ruka, joint, servomotor, paralelnıport, LPT

DOKTOR, L. Control of 6 joint robot in Real-time Linux. Brno: Brno University ofTechnology, Faculty of Electrical Engineering and Communication, 2009. 28 s.Supervisor Ing. Pavel Kucera, Ph.D.

DOKTOR, L. Rızenı 6-ti oseho robota v Real-Time Linux. Brno: Vysoke ucenıtechnicke v Brne, Fakulta elektrotechniky a komunikacnıch technologiı, 2009. 28s. Vedoucı semestralnı prace Ing. Pavel Kucera, Ph.D.

CONTENTS

1 Introduction 10

2 Analyse 112.1 Robotic arm platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Operation system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Real-time GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Enterprise solution . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Parallel port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Hardware connection 163.1 Computer to robot board . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Software implementation 174.1 User GUI application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Robot control application . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Current solution . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 GUI and control application connection . . . . . . . . . . . . . . . . . . 25

5 Results and conclusions 27

References 28

LIST OF FIGURES

2.1 Robotic arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Robotic arm workspace - xyz . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Robotic arm workspace - x . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Robotic arm workspace - xy-z . . . . . . . . . . . . . . . . . . . . . . . 132.5 Robotic arm workspace - y . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Robotic arm workspace - z . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Robotic arm workspace - motor 1 angle 〈−1; 0〉 rad - xyz . . . . . . . . . 132.8 Robotic arm workspace - motor 1 angle 〈−1; 4〉 rad - x . . . . . . . . . . 142.9 Robotic arm workspace - motor 1 angle 〈−1; 4〉 rad - y . . . . . . . . . . 142.10 Robotic arm workspace - motor 1 angle 〈−1; 4〉 rad - z . . . . . . . . . . 143.1 Computer to robot board connection . . . . . . . . . . . . . . . . . . . . 164.1 Client initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Client main loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Client joint update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5 Robot module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.6 Robot module main loop . . . . . . . . . . . . . . . . . . . . . . . . . . 224.7 Log module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8 Comm module structure . . . . . . . . . . . . . . . . . . . . . . . . . . 244.9 Message decripting [Doktor:2009:C6JRRL] . . . . . . . . . . . . . . . . 26

LIST OF TABLES

2.1 List of joints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

INTRODUCTION

This work relates previous [Doktor:2009:C6JRRL]. That book described the new real-time GNU/Linux capabilities and the possible solutions of handling concurrent acces to -not only - LPT1. A part of this book was also analyse of the target robotic arm platformand the first simply prototype of program, which handled that particular robot.

This document extends previous work with the actual design of possible solution formultiple robots of different types. The main accent is on easy modificability without re-compiling and even online changes into the whole array of robotic arm platforms. To metreal-time specifications it introduces new system of logging. Other necessary part whichneeded to be completely rebased is getting the values from client application (actualyfrom communication thread) to robot’s controling thread. Those and other modificationsare described in following chapters.

1LPT - Line Print Terminal is the original, yet still common, name of the parallel port interface on IBMPC-compatible computers [Wikipedia]

10

ANALYSE

2.1 Robotic arm platform

This section is a copy from [Doktor:2009:C6JRRL]A robotic arm was provided by Brno University of Technology. It’s a basic stationary

platform with six joints. They are displayed on figure (2.1) “Robotic arm”.

Figure 2.1: Robotic arm

As the source of the force are used servo motors. 4x Hitech HS-311, 2x HitechHS-81 and 1x unknown. The power source of the servo motors is 5V DC. The signalsource is directly from the parallel port. This should be changed in the future version.

Acording to the [HiTech:2002:sm1] Hitech manual pulse data should be 3-5V peakto peak square wave pulse. The pulse duration from 0.9ms to 2.1mswith 1.5ms as center.The pulse refreshes at 50Hz. Real-time linux should be capable to work in µs resolutionwhich makes the direct control of servo motors possible.

11

Robot’s joints parameters - established by reverse engineering method - are in followingtable 2.1:

Joint Label Type Motion range Pulse range [µs]

Motor1 Waist Rotation Left-Right 〈−4; 4〉 [rad] 450 - 2580Motor2 Waist Up/Down Up-Down 〈π〉 [rad] 700 - 2550Motor3 Elbow Up-Down 〈−1; 4〉 [rad] 490 - 2480Motor4 Wrist Up/Down Up-Down 〈−2.1; 1.6〉 [rad] 520 - 2480Motor5 Wrist Rotation Left-Right

⟨−π

2; π

2

⟩[rad] 640 - 2380

Motor6 Finger Close-Open 〈0; 3〉 [cm] 860 - 1880

Table 2.1: List of joints

For easy imagination there are 3d picture of the robot’s workspace. Pictures are madeusing custom program and rendered by POV-ray. Whole process is described in appendix(??) “Robot workspace generator”. The green cone shows the beginning of axial coordi-nates 〈0, 0, 0〉.

12

Figure 2.2: Robotic arm workspace - xyz Figure 2.3: Robotic arm workspace - x

Figure 2.4: Robotic arm workspace - xy-z Figure 2.5: Robotic arm workspace - y

Figure 2.6: Robotic arm workspace - zFigure 2.7: Robotic arm workspace - motor

1 angle 〈−1; 0〉 rad - xyz

13

Figure 2.8: Robotic armworkspace -motor 1 angle〈−1; 4〉 rad - x

Figure 2.9: Robotic armworkspace -motor 1 angle〈−1; 4〉 rad - y

Figure 2.10: Robotic armworkspace -motor 1 angle〈−1; 4〉 rad - z

2.2 Operation system

This project uses GNU/Linux with real-time preemption patch which is high level real-time operation system (similar to RTAI, RTLinux, RTX and other).

Low level operation systems

Low level operation systems (or even embeded systems without an operation system) re-quires from the developer to create everything himself and as much as possible optimizedfor speed and simplicity of the code. This is great for the speed of the program. On theother hand it needs skillful developer with experiences with the particular HW and par-ticular operation system. Also the development time is increased as it needs to create allmodules from scratch.

High level operation systems

Situation in these systems are a bit different. They are targeted for bigger and faster hard-ware platforms with plenty of memory. They are oftenly based on an existing operationsystem with some modifications or additions which brings real-time capabilities. The de-veloper could use existing libraries or even previous version of non-real-time programsand use them with some minor modifications. This significantly accelerates the develop-ment.

Also the developer have fast and standart hardware platform. The computation powerenables developer to creat more complex program, which is possible to configure withoutrecompiling or even online.

14

2.2.1 Real-time GNU/Linux

History and principe was described in previous book [Doktor:2009:C6JRRL].In short real-time GNU/Linux is not whole new operating system, it’s based on GNU/Linux

with patched kernel. It adds new scheduler and fix the problem with big locks inside ofkernel. All these patches are continously applied into mainstreem kernel and becomingnew standard GNU/Linux operation system.

These modifications doesn’t need any changes into already existing user-space pro-grams as the POSIX1 already specifies real-time operations which could be implementedeather as soft2 or hard3 real-time. The only difference is in guarantee of deathlines. TheGNU/Linux is now guarantee as hard real-time operation system.

2.2.2 Enterprise solution

This section is partily a copy from [Doktor:2009:C6JRRL]Red Hat Inc. provide real-time version of their Red Hat Enterprise Linux based on the

Real-time preemption patch in additional package called MRG - Message, Real-time andGrid. They also certify hardware suitable for this patch. Main focuse of this solution ison bank industry.

Red Hat also provides the real-time installation guide [Bridley:2008:RIG], the real-timereference guide [Bridley:2009:RTG] and the real-time tuning guide [Bridley:2008:RTG]which are very useful during the development and deployment of the real-time project.

2.3 Parallel port

This section is a copy from [Doktor:2009:C6JRRL][Olmr:2005:LPT] Parallel port is bidirectional interface present in almost every com-

puter. It have 17 digital lines - 8 output, 4 input/output and 5 input. Newest implementa-tions are reaching top speed of 8MB/s. It uses standard TTL logic. Parallel port is proneto overload so it’s better to use a driver.

1POSIX or “Portable Operating System Interface [for Unix]” is the name of a family of related standardsspecified by the IEEE to define the application programming interface (API), along with shell andutilities interfaces for software compatible with variants of the Unix operating system, although thestandard can apply to any operating system.[Wikipedia]

2Soft real-time system on the other hand will tolerate such lateness, and may respond with decreasedservice quality.[Wikipedia]

3Hard real-time or immediate real-time system, the completion of an operation after its deadline is con-sidered useless - ultimately, this may cause a critical failure of the complete system.[Wikipedia]

15

HARDWARE CONNECTION

3.1 Computer to robot board

Provided robot have three pins per motor. Two are power cables and they are supplieddirectly by the converter. The last one is signal cable and in previous version was con-nected directly into paralel port. This had to change as paralel port wasn’t able to provideenough power.

Current version uses optocoupler (KP3040) for separating primar (LPT) from secundar(ROBOTIC BRD). Whole scheme is displayed in figure (3.1).

Figure 3.1: Computer to robot board connection

16

SOFTWARE IMPLEMENTATION

The control software was developt - according to analyse - with the focus on modularity,fast development and reliability. Same as before there are two parts.

• User GUI Application - which is used by users to control the robot.

• Robot Control Application - It generates signals according to desired position.

There is a space between the first and the second part for AI1 or speed shaper plugins.

4.1 User GUI application

As it perserves the same this is only a copy from [Doktor:2009:C6JRRL] The GUI2

is based on Python3 and built on top of the Pygame4 framework. With main focus onuser controllability it uses mouse and joint specification to move the robotic arm.

User select the joint using keyboard and then by moving the mouse directly control theangle of selected joints. There are two axes in mouse (x and y) which correspond withthe two setting of joint movement sources. That way you can specify two groups of jointswhich could move with different speed at one time.

Joints are specified in Joint class, which contains all necesarilly information about bothstatic and dynamic informations:

• angle - actual angle of this joint

• active - activity of this joint (set by selecting this joint)

• joint - joint number used later for identification of this joint (since there are multiplejoints on one robotic arm)

• source - source of a movement (0 or 1 relative mouse x or y movement)

• inverse - invert input

• range - minimum and maximum angle range

1AI - Artificial intelligence is the intelligence of machines and the branch of computer science that aimsto create it. [Wikipedia]

2GUI - A graphical user interface is a type of user interface item that allows people to interact withprograms in more ways than typing with images rather than text commands.

3Python - a general-purpose high-level programming language. Its design philosophy emphasizes codereadability. [Wikipedia]

4Pygame - a cross-platform set of Python modules designed for writing

video games. [Wikipedia]

17

To date all joints are defined in main initialisation. This is usable with one robot, butlater there should be created “Robotic arm” class, which will take care of all it’s stuff.

Whole process is demonstrated in following diagrams (4.1, 4.2 and 4.3).

Begin

Connect to socket

Create a screen

Define joints

Start main loop

Figure 4.1: Client initialisation

Main loop

Wait until

defined clk

Process events

Update joints

Form

message

Send

message

Redraw the screen

Figure 4.2: Client main loop

4.2 Robot control application

Introduction is a copy from [Doktor:2009:C6JRRL]The control application of the robotic arm is written in ANSI C5. ANSI C altogether

with POSIX6 defines real-time environment independently of whether it’s hard or soft.Hard or soft real-timenes is guarantired by a kernel7

5ANSI C - American National Standards Institute C is the standard for the C programming language[Wikipedia]

6POSIX - Portable Operating System Interface for uniX is a name for standards defining the applicationprogramming interface. It’s for the most part implemented in linux distributions. [Wikipedia]

7Kernel - central component of operating systems. It manages system resources. [Wikipedia]

18

Update joint

is active?inverted

input?

angle +=

move

angle -=

move

angle ≥max

angle ≤min

angle = max angle = min

End

no

yes

no

yes

yes

no

yes

no

Figure 4.3: Client joint update

There is truly no difference between hard and soft real-time linux application, but thereare some recomendations. This article is not about these differences, you can find themin [RedHat:2006:rhd256] and [RTWiki].

4.2.1 Current solution

The control application was completely rebuilt from scratch. This was necesarilly as theprevious version was just a preview.

Current application is highly modular which helps with code readability, maintainabil-ity and also witch furthure development. Modular design is also better for code review

19

and error correction. Every module is developed to do one thing and do it right. Modulesare described furthure in detail.

Main program

The main loop of control program - “control app.h” was written staticaly as an easiestworkflow for the robot. It allows user to define robots staticaly using configuration file.For an actual use it’s recomend, but not necessarily, to create dynamic main programwhich will use all the capabilities which the modules provides.

In this example it’s shown how to periodicaly check the status of robots and keeps spacefor the fault-tolerant logic.

Module structure

Each module have predefined structure (shown on figure (4.4)), which helps with devel-opment and also with easier communication and handling in the main program loop. Asthe code is written in pure C the modules are only structures with defined functions. Thisshould probably change in the future using C++.

From the function names is pretty clear the module workflow.

1. init - Initialize the module and creates thread with handler handler and storeinformation about it into variable self->thread.

2. state - Check for the module status. Actually only reads variable self->die.Possible values are defined in config.h.

3. exit - Sets self->die to DIE EXIT and waits for self->thread thread tofinish and than sets self->die with DIE SUCCESS or DIE ERR*.

MODULEpthread t threadunsigned char die...

state

handlerinit exit

Figure 4.4: Module structure

20

Module robot

This module generates the signals on defined port. The module structure is shown onpicture (4.5).

robot tint sig timerunsigned int countunsigned int periodstruct joint t * jointstruct log t * log[LOG LEVELS]struct comm t * commtimer t timerunsigned short portunsigned char flags

pthread t threadunsigned char die

robot loadrobot validate robot sort

robot state

robot handlerrobot init robot exit

Figure 4.5: Robot module structure

Life cycle of robot entity comes from default workflow with some additionalities:

1. robot load - Reads the configuration file, load robots and returns number of loadedrobots. Configuration file syntax is described in later in the text.

2. robot validate - Validates and correct the robot configuration. If pass it sets theself->die valriable to DIE VERIFIED.

3. robot init - Opens the desired port and creates the robot handler thread.

- robot handler - Creates the periodic timer and implements Timer Based solu-tion described in [Doktor:2009:C6JRRL]. There is already implemented swithingmethod between this and Time Slices solution also described in [Doktor:2009:C6JRRL]but wasn’t yet fully implemented. The robot handler function is described in detaillater in this chapter.

4. robot exit - ends safely the robot handler thread and closes the port.

21

robot handler uses the timer generated signal sends directly to this (self->thread)thread instead of the timer thread self->timer as is usual. To do that it was neces-sarily to use a bit nonstandart way and change the tid using syscall. After the timer andsignal initialization the main loop is initiated. The function is described on the diagram4.6.

Begin

Initialize

self->die

FLAG SLICES defined joints UP

sorted joints

sleep

sorted->durat

sorted->joint

DOWN

(++sorted)->

duration==0

sorted->joint

DOWN

Renew dataSort dataFree

Exit

DIE ALIVE

FALSE

sorted

TRUE

!=DIE ALIVE

Figure 4.6: Robot module main loop

Timer Based sollution uses sorting of the joints and calculating differences in timing.Actually the first duration stays the same and the next is always difference between cur-

22

rent and previous. This way we can wake up the thread and then continue in sleep withprecalculated value. For faster continuances there is a limit TIMER RESERVE (definedin config.h under which the time difference is set to zero. Whole sorting mechanismwas based on insert sort [Honzik:2007:OIAL] and hardly optimized. It checks all alreadyfilled values and find the first lower item than current inserted value. Inserts it after thisitem and move the other ones to next position. See the code for actual implementationwhich contains a bit of optimisation.

Robot configuration file always starts with NO ROBOTS: string followed with newline and number of robots we want to load from current configuration file. Than eachrobot starts with ROBOT: string. First line after this defines information about robot(number of joints period port). After robot definition there have to be num-ber of joints lines with the joint definition (min angle start angle max angle

port offset).

Module log

Logging module is solving one of the biggest problem in real-time, creating visible outputwith minimal overhead. To met this requirements it was created special module. Thismodule supports different logging priorities and also detects possible overflows. Modulestructure is shown in (4.7).

log tunsigned int overflowstruct stack t stack readystruct stack t stack busychar [MAX PENDING MSGS][MSG LENGTH] logunsigned char levelconst char * level nameFILE * fd

pthread t threadunsigned char die

log newlog send log send text

log statelog init file

log handlerlog init log exit

Figure 4.7: Log module structure

During the logger development it was tested many platforms and an array of buffers

23

with own logging thread led to the best result (lowest overhead on booth - client andserver - sides). This concept uses two stacks. One is used by clients to lock free bufferfor themselfs and second when the message is complete and ready to write. Always whenthe client tries to open more than available buffers (locked + not yet written) the overflowvalue is increased. Logging thread then log this occurence and clear the overflow flag.Priorities are set by self->level.

Module comm

Communication module uses the same protocol implemented in [Doktor:2009:C6JRRL].The structure is displayed on 4.8.

comm tint fd sockpthread mutex t data mtxunsigned int data countunsigned int * data

pthread t threadunsigned char die

comm statecomm init tcp comm client handler

comm handlercomm init comm exit

Figure 4.8: Comm module structure

To ensure that this module won’t break the critical real-time robot part it was usedFIFO8 characteristic of mutex. The maximum robot reload value then are:

tRModif = n · tCModif + tRRead (4.1)

Where:n is number of communication modules,tRModif is robot thread’s values modification time,tCModif is communication’s thread values modifiaction time,tRRead is robot thread’s reading joint values time

This time have to be lower than MODIF RESERVE defined in config.h.comm init tcp works as usual init function but allows to set the communication port.

8FIFO - an acronym for First In, First Out, an abstraction in ways of organizing and manipulation of datarelative to time and prioritization. [Wikipedia]

24

comm handler listens on defined interface and accept connections. It’s prepared tohandle multiple clients but current protocol doesn’t support them yet. Clients are handledby comm client handler.

comm client handler reads data from client until one of the sides close the communi-cation. Message decripting stayed almost identical as before and is shown in 4.9.

4.3 GUI and control application connection

Communication protocol stayed the same as described in [Doktor:2009:C6JRRL]. It usesPOSIX sockets which keeps space for additional tools which may be added between GUIand signal generator as it was suggest in the introduction.

25

Begin

Recive a

buffer?

while data

Send data

back?

for recived

data

Number?

Save this

byte to

value buffer

Check for

more data

End?

Already

exist src?

Assign data

to the source

Log this

change

Get new

src from

current data

src valid?

End 0

End 1

OK

data

OK

datanumber

data

end

src prev src

first src

OK

err

data

continue

err

err

err

Figure 4.9: Message decripting [Doktor:2009:C6JRRL]

26

RESULTS AND CONCLUSIONS

This document introduced software framework for generating of periodic signals primar-ily designed for controling robotic arms. It presents the way of process signals only ondesired signals (4.2.1), special sorting mechanisms, new logging mechanism (4.2.1) andmuch more.

Since previous version the whole design was recreate from scratch (4.2.1). The frame-work itself is modular which enables this project to be used by other systems and makeseasier the future development.

The C++ or different object oriented language could even more enhance this project.Also the control application is prepared to be dynamic. The module is prepared to dy-namicaly switch between different signal generating modes it just need to add anothersolutions described in [Doktor:2009:C6JRRL] or the other solutions.

Another place for future development is in between GUI and the control application.There could be easily added utilities for AI1 and dynamic shapers. GUI itself is also onlyfor testing purposes.

1AI - artifical intelligence is the intelligence of machines and the branch of computer science that aims tocreate it.

27

REFERENCES

[HiTech:2002:sm1] HiTech documentation team, General Servo Information, Korea,2002-03-07.

[Olmr:2005:LPT] Olmr V., Paralelnı port - LPT (IEEE 1284),<http://lpt.hw.cz/>.

[RedHat:2006:rhd256] Red Hat documentation team, Red Hat Linux Application Devel-opment And Porting, electronic course material, 2006-06-24.

[Honzik:2007:OIAL] Honzık J., Studijnı opora IAL 2007, Scriptum FIT VUT Brno.

[Bridley:2008:RIG] Brindley L., Realtime Installation Guide online documentation page,<https://www.redhat.com/docs/en-US/Red Hat Enterprise MRG/1.1/html/Realtime Installation Guide/index.html>.

[Bridley:2008:RTG] Brindley L., Realtime Tuning Guide, online documentation page,<https://www.redhat.com/docs/en-US/Red Hat Enterprise MRG/1.1/html/Realtime Tuning Guide/index.html>.

[Bridley:2009:RTG] Brindley L., Realtime Reference Guide, online documentation page,<http://www.redhat.com/docs/en-US/Red Hat Enterprise MRG/1.2/html/Realtime Reference Guide/index.html>.

[Doktor:2009:C6JRRL] Doktor L., Control of 6 joint robot in Real-time Linux Semes-tral project, Brno University of Technology, Faculty of Electrical Engineering andCommunication 2009-04-30 Supervisor Ing. Pavel Kucera, Ph.D.

[RTWiki] Public domain, Real-Time Linux Wiki, Wiki page around real-time linux kernelpreemption patch,<http://rt.wiki.kernel.org/>.

[Wikipedia] Public domain, Wikipedia, online encyclopedia,<http://en.wikipedia.org/>.

28