An Autoguided Vehicle Based on Linux

ArticleCategory: [Choose a category for your article]

Hardware

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author and translation history]

original in es Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic

AboutTheAuthor:[A small biography about the author]

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.

Abstract:[Here you write a little summary]

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.

ArticleIllustration:[This is the title picture for your article]

ArticleBody:[The article body]

Introduction

Commercial autoguided vehicles available right now have a number of short comings that limit their use to R & D. Among others is the high costs, closed and proprietary architectures, lack of documentation, difficulty of scalability, all these at the hardware and software levels.

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

Our system is a holonomic vehicle with two powered traction wheels and two support wheels. Its kinematics is similar to that of a wheel chair or a tank. To control the speed of its center, we have to control de speed of each wheel along the time.

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 hardware architecture is based on a control card that controls the motors through one of the power cards. The control of the axis can be done by the control card or directly by the PC. For this project we custom designed both the cards and the software of the system.

Hardware Architecture

The commands to control the vehicle are sent from an external computer (host). The on-board PC takes care of sending the appropriate movement commands and references to the control cards. The latter generates a voltage request that becomes amplified in the power stage that feed the motors. The motion of each axis is detected by a position sensor (encoder), and gets handled by the control cards.

Software Architecture

The implementation of an autoguided vehicle requires first a closed loop control system that warranties control adjustments at a constant period of time. Secondly it also requires a periodic update of certain state variables, for example to determine the position of the center of the vehicle at every instant.

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.

The real-time operating system RT-Linux was developed at the Computer Science Department in the Mining and Technology Institute of New Mexico by Victor Yodaiken and Michael Barabanov. The following diagram shows a sketch of its architecture. The real-time kernel runs at the level closest to the hardware. A scheduler with static priorities manages a series of tasks in real time with total access to the hardware. Linux itself is seen by the scheduler as another real time task, with the lowest priority, that gets executed whenever there is time available.

Real-time system RT-Linux

The software architecture for the PCBot is based on the known client-server model. The server runs on the robot, handling the requests from the clients running on the remote machines. Communication between server and clients is carried out via TCP/IP.

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

Two separate parts divide the software architecture. One is executed over the Linux operating system and another that must be executed in real time (RT-Linux) due to its temporal requirements. The server is on the Linux side and it is resides on the PC installed with the vehicle. The client, which is a second application without strict time requirements, need not reside on the onboard PC.

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

A system architecture based on the PC has advantages like the low cost, easy upgradability of both hardware and software, flexibility due to the large amount of software available and power in terms of the capacity to perform operations. Moreover the hardware never becomes obsolete because its replacement by a similar one of the next generation is immediate and preserves compatibility with the existing software.

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

http://www.rtlinux.org

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