|This document is available in: English Castellano Deutsch Francais Nederlands Russian Turkce Korean|
by Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic
About the authors:
Roberto Guzman has a major in Computer Science (Physical Systems), he has been Professor and researcher in the area of robotics at the Department of Systems and Automation Engineering of the Universidad Politecnica de Valencia, also a researcher in the department of Process Control and Regulation at the FernUniversitaet in Hagen Germany. At the present time he works in the Research and Development Department of TMC-Electron ics.
Ranko Zotovic is an Industrial Engineer. He has several years experience implementing and designing industrial machinery like robots, tool machinery for cutting, quality control, etc. At the present time he is professor in Robotics and CAD/CAM in the Department of Systems and Automation Engineering of the Universidad Politecnica of Valencia.
Jorge Garrido Serrano is a major in Computer Science (Physical Systems). His masters project consisted of the design and implementation of the software architecture for the PCBot. He was awarded the Bancaja prize for Partnerships with Industry. At the present time he is part of European Project "MobiNet" (Mobile Robotics Technology for Health Care Research) of the FernUniversitaet - Hagen (Germany).
Vicente Egea Mañas is major in Computer Science (Physical Systems). He was also awarded the Bancaja prize for Partnerships with Industry for his design and implementation of the hardware architecture of PCBot. He works know at TGI.
Translated to English by:
Miguel A Sepulveda <Miguel.Sepulveda(at)disney.com>
An Autoguided Vehicle Based on Linux
The field of mobile robotics has experienced an enormous growth
the past few years. Many Departments of Robotics, Mechatronics,
and Artificial Intelligence have focused part of their research
to the study of autonomous vehicles. Until now, the high costs
in R & D have limited their use in aerospace, military and
nuclear power industries. However the current fast pace of
development in the field is allowing the introduction of this
technology in commercial areas like agriculture, industry,
services, mining, medicine, and others. It is a strategic
sector with a great potential for growth.
At the Department of Systems and Automation we took the
decision of building an autoguided vehicle in the lab without
any of the inconveniences mentioned. We decided to use an
architecture based on the PC because of its enormous
advantages: price, power, compatibility, scalability and
availability of hardware and software. The use of Linux and its
real time extension RT-Linux has made the completion of this
project enormously easier.
|Autoguided Vehicle PCBot 1.0|
The design distinguishes two separate zones: the lower
region, where all the mechanical and electric power elements
are located, and the upper region that is cluttered with all
the elements related to control and communications. The lower
region is mounted over an aluminum sheet. At this level we
placed the wheels, reductions, motors, encoders, and the power
stage, power supply and batteries. On the upper region is
mounted the card of the personal PC with its corresponding
control cards and floppy drive.
|Front and Profile of the autoguided vehicle PCBot|
The two requirements above forces us to use a real-time operating system. Real-time operating systems are those on which the correctness of the system depends not only on the calculations performed but also on the time these results are obtained.
We decided to implement PCBot software architecture on a Linux kernel 2.0.33 using the real-time extensions (version 0.6).
The reasons for using Linux and RT-Linux are the same reasons driving many automation companies to implement their software using this operating system:
|Real-time system RT-Linux|
Using TCP/IP for communications makes the robot independent of the operating system running on the host. The client accepts commands from the user and relays them to the robot. There are three type of commands: motion, state setting and state request. The client checks the syntax of the input command, builds an appropriate message for the server and sends it to the server using Sockets.
The server is permanently waiting for connections from the
client. Once a connection is established, the server becomes an
intermediary between client and the real-time module that runs
the control tasks. The real-time module executes the commands
accepted by the robot and it also supervises the system
integrity through a periodic task of the type Watchdog.
The real time module consists of several periodic real time tasks (movement commands and watch dog tasks) and sporadic tasks (driver and stop).
A binary semaphore protects the access of the hardware by real time tasks. We need this semaphore for several reasons. First, communication with the control cards uses a displacement register. If the task using them is interrupted by another task then invalid data will be written in this register. Second, there are register level protocols that should not be interrupted. And finally, the transfer of control actions to both axis should be carried out as simultaneously as possible.
Three rt-fifo queues implement the communication between the real time module and the server. The server writes movement commands received from the client on a queue. The real time module then uses the remaining two queues to pass a receipt of command arrival to the server and to notify the client through the server of any critical situation.
A typical sequence of events is as follows: the user launches a client process that acts as an interface between the user and the remote PCBot. After each command input the client processes and forwards them to the server. The server receives the processed messages and reprocesses them before sending a message to the real-time module through the associated rt-fifo.
A driver process attached to the rt-fifo handles the command and if it is a movement request it launches the associated real-time task and then sends a confirmation to the server. The task launched manages the actions needed to move the motors.
Besides a movement command, the user may have requested a state request or a state assignment. In this case the same driver responds the request either by reading or writing to the global state variables respectively.
The global variables are allocated in a memory space shared
by all the real-time tasks and the driver. Global variables
allow for a simple and fast communication between tasks. The
watchdog, among other things, takes care of notifying the
server of any relevant change in the vehicle state, as well as
any possible anomalous situations.
|Software Architecture - System Tasks|
Selecting Linux and its real time extension RT-Linux was a very fortunate decision. We used very powerful GNU development tools like the wpe (Windows Programing Environment) or the GNU C compiler without any additional cost.
The Linux system not only demonstrated its robustness during our experiments but it also show a very efficient management of the machine resources, so much that we were able to se a simple 486 PC onboard without any penalties on the performance nor on the development time (several users in parallel over this machine). In fact, our analysis of availability of the system demonstrated that 70% of the CPU time was available even in the worse case scenarios.
The integrity of the software used during this project is in the public domain, so the sources were available to us all the time. This let us have an in-depth understanding of the inner workings of the real time kernel, opening to us the doors to new upgrade possibilities (use of other time managers, development of drivers on the real time side, etc..) that would be out of the question in commercial vehicles.
RT-Linux can be easily debugged in real-time using various techniques ranging from the modification of the kernel to the storage and visualization of variables by invoking the system call printk.
During the development time we always had the unconditional
support of the members of the rt-linux mailing list and with
the extensive amount of documentation available.
Other articles about RT-Linux in LinuxFocus:
Real-Time Linux II
Webpages maintained by the LinuxFocus Editor team
© Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic, FDL
2002-11-03, generated by lfparser version 2.34