Real-time mobile robot navigation with LINUX / RTAI
Audrey Marchand*, Christophe Plot* and Maryline Silly**
*CRTTI (Centre de Ressources Technologiques et de Transferts Industriels)
**IRIN (Institut de Recherche en Informatique de Nantes)
Rue Christian Pauc
44306 Nantes cedex 03 France
E-mail :
Abstract
This paper describes the implementation of a real-time computing system on a mobile robotic platform (an Automated Guided Vehicule) and its integration in a FMS (Flexible Manufacturing System). This application, developped under the Linux variant, RTAI (Real-Time Application Interface) controls all the navigation of the robot. First, mechanical aspects are presented. Then, we are interested in the open-source operating system Linux RTAI and more precisely in its specifications, scheduling policies and performances in a real-time context. In addition, we tackle the problem of the control of all the components involved in navigation. An explicit description of the real-time tasks and mechanisms involved in the follow-up of track, the obstacle detection and the treatment of missions orders is given. Finally, the discussion is opened in terms of real-time scheduling and fault-tolerance so as to put forward and manage system overloads. From an innovative point of view, this project1 aims at proving the gain obtained from an open free real-time operating system such as Linux, both during the development phase and the operation phase.
1 Flexible Manufacturing Systems
Success of modern Flexible Manufacturing Systems (F.M.S.) comes from many factors including appropriate selection of parts or jobs to be processed, development in machine tools and material handling, high computer and information technology, efficient planning and scheduling algorithms and complete specification of the control software. The rapid development of FMS has been possible thanks to the advent of Automated Guided Vehicle Systems (AGVS). AGVS electronically feature controlled vehicles which travel on a network of guide-wires or painted lines. Vehicles are programmable and may be directed to any station without any human intervention. They provide automatic loading and unloading of parts and automatic destination seeking. AGVs are used as transporters and mobile workstations when the distances between machines are large, making impossible to use conveyor systems.
In any manufacturing system, once the production plan has been established for a pre-defined time horizon, the problem of scheduling operations has to be considered. Generally, scheduling will consist in the allocation of available resources (machines and vehicles) to operations or parts over time with respect to specified constraints including timing constraints. Real time constraints imposed on these systems are specified by deadlines by which jobs need to be fulfilled. So, the major goal in designing a real time manufacturing system is to ensure adherence to all the timing constraint s during the whole lifetime of the application in order to avoid a system failure. To meet these timing requirements, coordination, scheduling, resource management and control are functions that must be adequately implemented.
2 Real-time Linux / RTAI
There are three major components that characterize real-time systems: time, reliability and environment. Tasks must be scheduled to be completed before their deadlines and messages are required to be sent and received in a timely manner. Two constraints must be checked in order to consider a real-time system as a functional one : logical correctness and timeliness. Reliability is crucial because failure of a real-time system can cause an economical disaster. And the environment under which the computer operates is an active component (here, the robot).
RTAI presents the specifications of an industrial real-time operating system, over and above of the own features of the standard Linux kernel. It basically consists in an interrupt dispatcher : RTAI captures the interrupts from devices and if necessary, redirects them to Linux. In other words, RTAI uses the RTHAL (Real-Time Hardware Abstraction Layer) concept. RTAI is a patch for the Linux kernel which provides the ability to make it fully pre-emptable (tasks may be suspended and later resumed). RTAI considers Linux as a background task being carried out when no real-time activity is present. In this way, developers can precisely build their applications by choosing which parts of the design need to be performed in real-time. In others words, we can talk about flexibility with such a model. As a free open-source operating system, RTAI is also interesting by its status of “bazaar”-like project, in the sense that it easily accepts and integrates contributions from anybody. As a consequence, RTAI fulfills a little bit more users’ needs, to the detriment of a little bit more chaos.
RTAI consists in different modules. The main module which has to be load for any application, comprises basic functions. For more complex developments, RTAI offers scheduling, FIFOs and shared memory facilities. RTAI includes three different priority based, pre-emptive real-time schedulers : the Uni-Processor (UP), the Multi Uni-Processor (MUP) and the Symmetric Multi-Processor (SMP) scheduler.
In addition, another project, LTT (Linux Trace Toolkit), developed by Opersys, supplements RTAI. Indeed, first built in order to analyze Linux kernel events, this tool has been extended to manage the events relative to RTAI, thus allowing time performance measurements (percentage of CPU time, execution time, ...). For instance, the events captured by LTT are context switches, hardware and software interrupts or disks accesses.
In terms of performance, RTAI is very competitive, offering typical context switch times of 4 µs, 20 µs interrupt response, 100KHz periodic tasks, and 30KHz one-shot task rates.
In the design of the present real-time application, RTAI appears to fit our specific needs even if a scheduler based on dynamic priority (e.g. Earliest Deadline First) would guarantee more determinism and provide more flexibility because of possible treatments of sporadic tasks (investigating field of CLEOPATRE project [Silly 2001]). Nevertheless, in the concerned application, the system load is quite predictable and then, the scheduler based on fixed priority that is currently offered by RTAI is initially sufficient.
3 The mobile robotic platform
The bi-directional mobile robotic platform is designed to be used in an industrial context. That’s why, it is fitted out with conveyor belts in order to carry standard vats. The robot appears as follows :
Fig 3.a Mobile robotic platform photograph
The mechanical support includes the following components : frame, batteries, motor reducers, wheels, the system of vats’ loading and the embedded PC. Moreover, the follow-up of track, the pace monitoring and, the obstacle and collision detection rests on various embedded sensors. The scheme below, presents the frame of the robot with its pairs of driving wheels and insane wheels. It shows the site of all the sensors specifying the role of each one :
1, 2, 3, 4 : obstacles infra-red detectors
5, 6 : differential sensors (follow-up of track)
7, 8 : announce point sensor
9 : operation point sensor
10, 11 : speed sensor
Fig 3.b Frame and sensors
An opto-guidance system allows the robot to follow a white self-adhesive band put on the ground. A fluorescent tube lights the track, the luminous energy reflected by the ground is measured by two photo-resistive cells located on both sides of the track. A comparator carries out the difference between the signals resulting from these two sensors and works out a signal of error which is used to control the direction engines so as to maintain this signal close to zero. Reflectors placed in the medium of the track indicate the points of the circuit where the robot has to operate.
The possible operations on the robot are the following:
- MA : indicator of direction go ahead (Marche Avant)
- MR : indicator of direction reverse gear (Marche aRrière)
- IS : inversion of direction (Inversion de Sens)
These indicators allow to fix the direction of the navigation of the robot. The direction of navigation can only be modified when the robot has stopped. The IS order inverse the direction of navigation, without any need of knowledge of the actual direction.
- DE : start (DEmarrer)
- AR : stop (ARrêter)
These two orders allow to start or stop the mobile robotic platform.
- SP : follow-up of track (Suivi de Piste)
This order indicates to the robot it has to follow the track, reaching a shunting.
- AI : shunting (Aiguillage)
At the arrival of the robot on a shunting, this one indicates if or not this shunting should be taken.
- TD : turn on the right (Tourner à Droite)
- TG : turn on the left (Tourner à Gauche)
With order SP, these orders allow the robot to manage intersections. If one gives an order TD or TG to the robot, it stops in the center of the intersection thanks to the indicator of center then swivels on itself towards the right or the left-hand side according to the direction of the order.
The right and the left-hand side of the robot in this case are referred compared to the direction of walk, and not compared to the real front.
- CD : load on the right-side (Chargement Droite)
- CG : load on the left-side (Chargement Gauche)
- DD : unload on the right-side (Déchargement Droite)
- DG : unload on the left-side (Déchargement Gauche)
These four orders allow to manage the load and unload of vats. As well as for the operations of intersections’ crossing, the right and the left-hand side are referred compared to the direction of walk, and not compared to the real front of the robot.
- RS : ReStart
This order reinitializes the platform. At the reception of this order, it stops and waits to be reprogrammed.
- SS : status (Statut)
This instruction requires of the robot to communicate its state, the level of the batteries and the state of alarms to the distant station.
An example of standard test circuit is as follows :
Fig 3.c Standard test circuit
All of the missions orders worked out from a distant station are received by radio contact. The illustrated mission above makes the robot acts as follows : the industrial platform loads vats on the right-side at workstation A, starts, then turns on the left at the arrival of the first intersection, and goes straight away at the following one before turning on the right to reach the workstation C where the robot proceeds to an unloading on the left-side.
4 Navigation under real-time control
One of the key aspects in a real-time system which has to interact with a dynamic environment, is the delay between the occurrence of a particular event and its perception by the system involved in the monitoring of such events. In our embedded application, the navigation of the mobile robot is controlled in real-time in the sense that, for each event from sensors, a response is provided in specified delays. In this way, the orders for engines, ensuring a differential navigation, control with a relative precision the follow-up of track of the platform. If a variation is detected, then the system corrects the trajectory, decreasing the speed of one engine while increasing that of the other. Actually, engines’ control is strictly symmetrical.
Another point must be considered to provide quite an autonomy to the robot. Indeed, the embedded real-time application performs a monitoring of the status of the robot. As instance, the system should appropriately react to an insufficient battery level so as to keep it safety. The mobile robotic platform is fitted out with conveyor belts, carries out orders of mission received by radio contact, and reports both its status and the mission progress. In this way, the user can decide to operate on the behavior of the mobile robot according to all the reported changes (emergency stop because of a near obstacle, a shock or an internal non-operation...).
The robot supports two modes of guidance:
- the guided mode where the robot is required to follow the track rectifying its trajectory according to the variation measured. This value from sensors is provided in real time to the system,
- the blind mode where an external instruction of position comes to control the trajectory of the robot. This mode can be used in cases where the robot is brought to deviate from the track. For example, the robot can carry out an obstacle going beyond in this manner.
First, depending on the direction of walk, one of the two embedded track sensors is used to provide the error corresponding to the variation detected.
These two sensors provide an analogical signal ranging between -10V and +10V, corresponding to the variation measured compared to the track, in terms of distance. An illustration is given below :
Fig 4.a Follow-up of track error obtaining
Then the error is brought back in a definite interval, adjusted by a regulator K and added or withdrawn from the instruction speed so as to worked out the orders of respectively the right and left amplifiers. Thus, the engines’ control is carried out in a completely symmetrical way. The functional scheme appears as follows :
Fig 4.b Regulation and engine control
In this paper, we shall consider the follow-up of track control problem for the system. More precisely, we shall deal with the control system such that the resulting closed-loop system is stable.
Initially, we implement a simple proportional regulator :
(4.1)
where E(z) and U(z) are respectively the control input and the controlled output.
The results are not optimal ones. Indeed, oscillations testify a certain instability of the system :
Fig 4.c System behavior with a P regulator
In order to obtain the best performance from the system, the use of a more elaborate device, namely a Proportional Integral regulator (PI) is preferable.
While the proportional term is used to adjust the speed of the system, the integral control is used to provide the required accuracy for the control system.
For the taking into account of the integral term, it is necessary to perform and add a digital Integral controller in the preceding form (4.1) for the system :
(4.2)
(4.3)
Then, the resulting equation for the digital PI controller is :
(4.4)
Our approach was to use a technique which was developed in the 1950's but which has stood the test of time and is still used today. This is known as the Ziegler Nichols tuning method. The calculated values were not optimal values and additional fine tuning was required to obtain the best performances from the system. Are presented below the associated results for a PI controller at constant speed :
Fig 4.d System behavior with a PI regulator
Then, always by preoccupations with an improvement of performances, we perform an adjustment of the Ki parameter, sensitive at the speed of the robotic platform, thus allowing to have a behavior quite similar for any given speed :