Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic
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-Electronics.
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.
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
|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
by Miguel Ángel Sepúlveda
© Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic