by Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic <rzotovic(at)aii.upv.es> 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> Content: Introduction Description of the Vehicle Software Architecture Conclusions References

An Autoguided Vehicle Based on Linux Abstract: 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. _________________ _________________ _________________

Introduction

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

Description of the Vehicle

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

Hardware Architecture

Software Architecture

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:

• The operating system uses hardware resources efficiently and is very robust.
• The source code is public and therefore is easy to modify and expand.
• The development cost is very small and even null.
• It has a powerful and free real-time extension, with utilities and services at the same level of its analogous commercial counterparts.
• The technical support, consisting of a multitude of enthusiasts, is excellent.
• There is a large volume of documentation on the internet.

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.

Software Architecture

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

Conclusions

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.

References

Other articles about RT-Linux in LinuxFocus:
Real-Time Linux
Real-Time Linux II

2002-11-03, generated by lfparser version 2.34

mirror server hosted at Truenetwork, Russian Federation.