An auto-guided vehicle controlled by PC

Authors:
Ranko Zotovic, Polytechnic University of Valencia, Camino de Vera s/n, 46011 Valencia, Spain, rzotovic@isa.upv.es
Roberto Guzmán, Robotnik Autimation S.L.L, C/Cooperativa de San Fernando, 20-9. CP:46007 Valencia, Spain
rguzman@robotnik.es

Abstract  After two years using different commercial autoguided vehicles, we met several problems due to limited
performances, high prices, closed architectures and lack of scalability of these mobile robots. Starting from this experience
we decided to build our own AGV. We used cheap components. We made the power stages. As on- board computer, we chose
a PC, since it is the most scalable, versatile and has the best performance/price relation of all the architectures available on
the market. The operating system we selected was RT-Linux because it is free of cost, powerful, and open to modification.
The software architecture used the client- server model, with the TCP/ IP protocol what makes the communication
independent of the operating system of the host. Several motion and control modes were implemented.

Index Terms  AGV, open architecture, PC, RT-Linux .

INTRODUCTION
The popularity of mobile robotics is having an enormous increase in the last years. Several Robotics, Artificial Intelligence
and Mechatronics Departments have focused their interest to autoguided vehicles. For the moment, the high investigation and
development costs have limited its use for aerospatial, military, nuclear energy applications, etc., but the actual high level of
technology is allowing its firsts implementations in commercial applications like agriculture, industry, mining, industry, etc.
It could become soon a strategic sector with a very important increase.
Most of the commercial available AGVs have common lacks that seriously limit their use for investigation purposes. The
most important are the high price, closed architecture, incomplete documentation, difficult scalability, in hardware and in
software.
In order to deal with this situation a group of the Department of Systems Engineering and Automation of the Polytechnic
University of Valencia took the decision to build a laboratory autoguided vehicle without the disadvantages of the
commercial platforms. We decided to use a PC based architecture because of its enormous advantages: price, power,
scalability, software and hardware availability.
As operating system we choose RT-Linux, because it is completely open to modifications and enhancements, very
powerful, robust and free of cost.
DESCRIPTION OF THE VEHICLE
The vehicle has two independent motor wheels and two castor wheels, which means it has two degrees of mobility and zero
degrees of dirigibility. Its kinematics is equivalent to a wheelchair. The position and velocity control of the vehicle centre is
realised by the coordinated control of the velocities of the wheels.
The physical design is made in two separated compartments: the low level, containing all mechanical elements and
power electronics, and the high level compartment containing the control hardware. The low level compartment includes the
motors, gear boxes, encoders, servo amplifiers, power sources and batteries. The high level area is mounted on the
motherboard frame of a personal computer, containing also the video cards, I/O cards, control card, LAN card, hard and
floppy disk, etc.
The hardware architecture is based on a control card that steers the motors through the amplifiers. The control of the axes
may be realised through the control card as well as directly from the PC.
From an external host computer, commands are sent to the PC on-board. In case of motion commands, the PC is in
charge of sending references or other commands to the control cards. These generate a voltage reference that is amplified by
the servo amplifiers. The motion of each axe is measured by a position sensor (encoder) and stored in the control card.

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

1
SOFTWARE ARCHITECTURE
The motors of the AGV are controlled in closed loop. For good performance, the control actions must be applied in constant
time increments. Also, the periodic updating of some state variables (e.g. the position and orientation of the robot) implies
that some tasks need to be executed in exact moments of time. The two above-mentioned restrictions can only be solved by
the use of a real- time operating system. A real time system is the one in which the correctness of the system depends not
only on the accuracy of the computations, but also on the moment they are produced.
We made the decision to use the Linux O.S. (kernel 2.0.33) using the real time extensions RT- Linux (ver 0.6). The
reasons for the election of this O.S are the same that motivate an increasing number of automation companies to develop
their software under this platform:
- The O.S. is very robust, and takes the maximal advantage of the hardware.
- The source files are public domain, and therefore easy to modify and enhance.
- The cost is low and none in the development phase.
- The real time extension is very powerful, with performances comparable with the equivalent commercial
systems.
- A great number of enthusiasts from all over the world make an excellent technical service.
- There is a great quantity of documentation in several publications and web pages.
The real time system RT-Linux has been developed in the Department of Informatics of the Mining and Technology
Institute of New Mexico by Victor Yodaiken and Michael Barabanov. A real time kernel is executed in the hardware nearest
level. An expulsive scheduler with static priorities handles a set of real time tasks with total access to the hardware. Linux
itself is seen by the scheduler as a real time task with the lowest priority, that is executed when there is time left.
The software architecture of the PCBot is based on the well known client- server model. A server application is executed
on the robot, handling requests of client applications running on remote computers. The communication is made by means of
the TCP/IP standard protocol.
The use of TCP/IP makes the robot independent of the operating system of the host. The client application allows the
user to introduce the commands that control the robot. There are three types of commands: motion, state definition or state
request. The client application verifies the syntax of the commands, builds the appropriate message for the server, and sends
it to the server by means of sockets.
The server application, is permanently waiting for client connections. Once the connection has been established, the
server interchanges messages between the client and the real time module.
The real time module is in charge of the execution of the robot commands. It also supervises the system integrity by
means of a periodic task equivalent to a Watchdog.
The architecture is divided in two parts. The first one is executed as normal Linux process and the second one is
executed on the real time module because of its timing requirements. The first part consists of the server is implemented on
the on board PC and the client, which may also be implemented on the host. The real time module consists of some periodic
real time tasks (motion commands, and supervision task) and some sporadic (handler and stop).
The access of the real time tasks to the control hardware is protected by means of a binary semaphore. There are two
reasons for its use. First, the communication protocol with the controllers is based on a shift register. Data transmission can
not be interrupted before the shifting finishes. The other reason is that the sending of the references to both axes should be
done as simultaneously as possible.
Communication between real time module and server is implemented by means of three real time first in first out (rt-
fifo) queues. The server writes in the first rt-fifo motion commands received from the client. The real time module uses the
other two queues to acknowledge sent commands and to inform the server about unexpected critical situations.
An operation sequence could be the following: the user launches a client process that works as interface with the
operator, who introduces the commands on line. The client processes them, and sends them to the server, who reprocess them
and sends them to the rt-module through the associated rt-fifo.
A handler process associated to the rt-fifo is in charge of receiving the command, launching the corresponding rt-task,
and sending an acknowledgement message to the server. This rt-task realises the necessary actions for controlling the motors
or reading/writing the state variables. Global variables are placed in a memory location shared by the real time tasks and the
handler. They are used for information interchange between tasks. The watchdog communicates to the server any relevant
change in the state of the vehicle, and possible malfunctions.

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

2
REAL TIME CONTROL
The control card contains a motion control specific integrated circuit (HCTL-1100) for each motor. The control of the motors
can be made by the integrated circuits or directly from the PC, in which case, the HCTL acts as encoder counter and PWM
generator. It has been demonstrated in practice that the control of the HCTL’s is not suitable for sophisticated trajectories
and/or control algorithms.
The real time control consists of the trajectory generator and the control algorithm. The implemented trajectories are
trapezoid (joint, Cartesian and velocity space) and spline (Cartesian space). The last one is very useful, since it allows the
users to simply introduce points of the path, and the robot interpolates the smooth trajectory between them. Nevertheless, the
spline trajectory may have inconveniences depending on the points introduced. In some situations, the angular velocity may
have high peaks, and the linear velocity is always continuous, but not constant.
An algorithm for postprocessing the spline trajectory has also been developed. This algorithm has the purpose to
maintain constant linear velocity while the angular velocity is under a given limit. If the angular velocity exceeds the
maximum, the continuity of the linear velocity is lost, and the robot decreases its speed in order to protect it of too fast
rotations. An example of this trajectory is showed in the figure 5. Three basic control algorithms have been implemented:
PID for each axe, state feedback in Cartesian space, and state feedback in velocity space.
It has been demonstrated experimentally that using state space Cartesian control in a spline trajectory, the system is
controllable along the whole path, excluding the final references.
The block diagram of the velocity space control is represented below. This kind of control is better suited for control by
joystick or teleoperation.
The actual version of the robot contains about twenty different motion commands, which can be easily enhanced.

CONCLUSIONS
The PC based architecture gives many advantages as low cost, easy scalability in hardware and software, versatility due to
the high quantity of available software, and great computational power. Also, the hardware never gets obsolete, because its
substitution by one of the next generation is immediate conserving the compatibility with the previous software.
The election of the Linux with its real time extension RT-Linux gave very good results. Very powerful development
tools have been used, like the environment gnu wpe (Windows Programming Environment), or the gnu C compiler, and all of
it free of cost. Another important feature is the availability of the source code, which allows absolute flexibility to the
programmer.
The Linux operating system has demonstrated its robustness in practice and additionally it takes maximal advantage of
the processor. As on-board computer an i486 has been used, without consequences on neither execution nor development
time. The analysis has demonstrated the availability of the processor time of 70% in the worst case.
The control algorithms implemented have demonstrated better accuracy in positioning and path following than our
commercial robots in the same conditions. Also, the spline trajectory generator and its postprocessor resulted as adequate,
because of its adaptability to the path, its velocity control in the curves, and the user friendly way to introduce a path.
Finally we have developed a robot, with completely open architecture, easily scalable, low cost, and better performances
than most of the commercial ones.

REFERENCES
[1] Carlos Canudas de Wit et. All. “Theory of Robot Control”. Springer Verlag, 1997
[2] P.H McKerrow. “Introduction to Robotics”,Adisson – Wesley Publishing Company, 1995
[3] K.S Fu, R.C. González, C.S.G Lee, “Robótica. Control, detección, visión e inteligencia”, McGraw-Hill 1988
[4] Patrick F. Muir, Charles P. Neuman. Kinematic modelling of wheeled mobile robots. Department of electrical computer engineering. Carnegie-
Melon University. 1996.

[5] J. Tackett Jr. and David Gunter. Using Linux. Prentice Hall, 1996.

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

3
FIGURES AND TABLES
FIGURE. 1
PROTOTYPE OF THE AUTO GUIDED VEHICLE PCBOT

FIGURE. 2
HARDWARE ARCHITECTURE OF THE PCBOT

Remote Host

NETWORK Power Supply

HD PC
Parallel Port
Emergency Stop
Control Card

Servo Servo
Bat. Bat.
Amplifier Amplifier
12V 12V

Encoder Encoder
Motors

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

4
FIGURE. 3
THE CLIENT- SERVER MODEL

Socket

TCP/IP

Socket

Server
Client

FIGURE. 4
SOFTWARE ARCHITECTURE

Remote host
Client
TCP/IP

Linux
RT-FIFO1 Server
RT-FIFO2 RT-FIFO3
Handler Watchdog

Global RT-Linux
variables
Motion comands.

Semaphore

Control Hardware

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

5
FIGURE. 5
EXAMPLE OF A POSTPROCESSED SPLINE TRAJECTORY

500 500

400 400

300 300

200 200

100 100
Y 0 0

-100 -100

-200 -200

-300 -300

-400 -400

-500 -500
-500 0 500
-500 -400 -300 -200 -100 0 100 200 300 400 500
X

0.6

1
0.4

0.2
0.5
0
0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500
Lineal Velocity Left wheel velocity
-3
x 10 Lineal
0 0.6

0.4
-1
0.2
-2
0

-3 -0.2
0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500
Angular Velocity Right wheel velocity

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

6
 FIGURE. 6
CONTROL IN THE CARTESIAN SPACE

 x(k )  ∆x(k )
   
 y (k )  ∆y (k )
θ (k )  ∆θ (k )
 d    ∆q 
 izq  T=0.005
rajectory  ∆qder  λ q
enerator
ZOH PROCESS
K Inverse PID
+ +
Kinematics

 ∆qizq 
 x(k )  
   ∆qder  r
 y (k )
θ (k )
 r Forward z −1 ZOH
Kinematics
z
T

FIGURE. 6
CONTROL IN THE VELOCITY SPACE

Inv. Transform
 ωl 
 
1 D  ω r  ∆q T q
v R 2R 
  1
ZOH PROCESS
ω d
+ K − D 2πr
 
R 2R 

R − R
2 2  1 z −1 ZOH
R − R
  2πr z
T
D D 

Dir. Transform

International Conference on Engineering Education July 21–25, 2003, Valencia, Spain.

7