Linux as a Software Platform for Mobile Robots - CiteSeerX

Linux as a Software Platform for Mobile Robots Walter Fetter Lages1 & Elder M. Hemerly2 Abstract: The requirements for a mobile robot operating system are analyzed and the suitability of Linux and similar operating systems is discussed. The use of Linux in two mobile robots built in our labs is described. The real time system is based on custom drivers for the real time clock and a POSIX threads library. A complex real time task is analyzed and experimental data is presented to validate the proposed approach. The architecture of the robots and the usefulness of services provide by Linux are also discussed. Keywords: Linux, operating systems, mobile robots, real time control can require busy-wait procedures to be sampled, Introduction preventing the sampling of the remaining sensors. In mobile robots, the fusion of data from A basic requirement for mobile robots is the sensors operating under diverse physical principles autonomous locomotion capability. The robot is a standard procedure to improve the position and should be able to perform autonomous motions due orientation estimates. The Kalman filter usually to either the need to interact with an unstructured employed for data fusion should also be environment or to the need to operate without synchronized with the sensors and control sampling supervision. [10][11][12]. In order to achieve the desired autonomy, The above mentioned problems can be mobile robots are typically equipped with several solved with the help of a real time multitasking sensors. By using its sensors, the robot can react system. appropriately to environment changes. This work proposes the use of the Linux Usually, the procedure for data acquisition operating system as an embedded real time from a sensor is simple. However, in a mobile robot multitasking system for mobile robots. The use of the problem is not acquire the sensor data and save Linux as the operating system for two mobile robots it for later analysis. The data just sampled from the developed in our labs is described. Both robots are sensor is used to generate control actions for the equipped with many sensors. In particular, the robot in an interactive fashion. Also, due to control implementation of methods for position and stability related reasons, this interaction should be orientation estimation, control of the robot and user done at a constant rate, called the sampling rate of interface are discussed. the system. Robot control and position and orientation If there is just one sensor, the sample of the estimation is done in real time, based on the fusion sensor is synchronized with the control in a of data from incremental encoders and a digital straightforward way: the sensor is sampled, the compass. control is generated, then sensor is sampled again, As Linux was not conceived as a real time the control is generated again and so forth. The system, some adaptations are need to assure that the sampling rate of the system is chosen such that the timing requirements of the system are going to be sensor can be sampled and control action computed meet. Also, as the mobile robots are activated by with a single period. Note that the maximum rate at custom build interface cards, the corresponding which a sensor can be sampled, depends not only on device drivers need to be developed and integrated the time needed to sample the sensor, but also on into the Linux kernel. the recovery time of the sensor. The recovery time The user interface is based on the Linux is the time it takes for the sensor to be ready for communication facilities and radio frequency another sample [13]. modems activated by a device driver developed to In a robot with many sensors, operating on be integrated with Linux networking sub-system. diverse physical principles, it is not possible to find Major Internet services are available to the user, a single sample rate that can be used for all sensors including Telnet, FTP and WWW. A web site based and for the control loop. Worst yet, some sensors on a server running on the robot enables any user 1

Fundação Universidade do Rio Grande, Departamento de Física, Av. Itália km 8, Rio Grande, RS 96201900, Brazil 2 Instituto Tecnológico de Aeronáutica, Departamento de Controle e Conversão de Energia, CTA - ITA IEEE, São José dos Campos, SP 12228-900, Brazil

interact with the robot in real time using a conventional browser.

Embedded Real Time Systems for Mobile Robots Program developing for embedded real time systems is a challenging proposition. In some sense it is like developing an interrupt handling routine. There is no easy way to debug the program because often the system does not have display and keyboard and the debugging code would disrupt the program timing, possibly causing the system to behave in a different way. Furthermore, the system timing is strict and the extra time needed to execute the debugging code may not exist. In the absence of display and/or keyboard, the program could be transferred to the system using a socketed EPROM, loaded with the system software. Of course, this is time-consumpting and not practical for developing purposes. In a developing environment, the EPROM is usually burned with a bootstrap code. The program under development is then uploaded to the embedded system using a serial connection. There are even debuggers that can operate over this serial line, which is very useful for embedded systems that are not under real time constraints. This monolic program approach is common on small robots based on microcontrollers. Due to memory size limitations and to the simplicity of its hardware, an operating system is not used. Medium to Large sized robots are generally built around a more powerful general purpose microprocessor. The production scale of industry standard computer parts offers a very good price/performance ratio. Given the number of choices for readily available parts, the effort needed to develop a similar custom system from scratch is difficult to justify. Also, the use of standard hardware ensures the promptly availability of replacement parts. Even using industry standard hardware, the same monolic program approach would be possible, by replacing the original motherboard EPROM. Nonetheless, the hardware complexity is considerably increased with respect to a microcontroller based system. This complexity is not only due to the standard hardware only, but also due to the more sophisticated sensors used on larger robots. Hence, as memory size is not a concern anymore, an operating system becomes desirable. For reasons explained above, the mobile robots built in our labs were based on PC hardware.

The first robot, called IEEE-rover3, is based on a AMD 5x86 running at 160 MHz. Its successor, called Twil, is based on an Intel Pentium MMX running at 233MHz. Obviously, the analysis of candidate operating systems is biased towards operating systems running on Intel compatible machines, but other architectures, such as Motorola/68K and DEC/Alpha, should have similar options. Back to 1994, when IEEE-rover (Fig. 1) was built, the natural operating system choice for PC compatible machines was MS-DOS/Windows 3.x. The alternative systems were Windows NT and OS/2, but their use was not widespread. OS/2 was around for some time, and had not established itself as a major operating system. Documentation and tools for native development under OS/2 were not easy to find. Also OS/2, with its Warp version, essayed an approximation with Windows 3.x, so that many tools available under OS/2 were actually native Windows tools. It was natural to suppose that the OS/2 approximation with Windows would bring together the limitations of Windows.

Fig. 1 - IEEE-rover. One of the main drawbacks of all versions of Windows for mobile robot applications is its strong dependency on a graphics display. These systems were not conceived to run on machines that can only be accessed remotely. Also, the development of device drivers for custom built adapters is not straightforward, requiring a driver development kit (DDK), which is not readily available. Furthermore, the system must be reboot for loading and 3

The acronym IEEE here is not related to The Institute of Electrical and Electronics Engineers. IEEE is also the acronym for the Control and Energy Convertion Department at ITA, where the robot was built.

unloading of device drivers, slowing down the process of device driver development. Although considered an outdated system, MS-DOS alone, i.e., without Windows, fulfills much better the requirements of a mobile robot. It can easily be accessed through a serial line, runs smoothly without display, keyboard and mouse. Also, there are a solid base of development tools and documentation on how to write device drivers and interact with the system at a low level is abundant. Device drivers can be written using the same tools used for applications development and when properly written can be loaded and unloaded on-the-fly. Furthermore, since MS-DOS does not run in protected mode, any program has direct access to the hardware, simplifying the real-time implementation. A program can easily take-over interrupts and reprogram the hardware to generate clock interrupts at the desired rate. The main limitation of MS-DOS seemed to be the amount of memory it manages (1MB), but for many mobile robot applications that is enough. Typically, only the computer vision subsystem needed more memory. An extended memory manager enables the use of the memory above 1MB under MS-DOS. Coupled with an appropriate C++ library, the extended memory use is almost invisible to the user. All subsystems of IEEE-rover were developed and tested under MS-DOS and for two years all real-time robot control programs executed under this system. Then, the implementation of a robot position and orientation estimation method based on the fusion of data from sensors with distinct sampling rates exposed the main limitation of MS-DOS: the lack of multitasking. There are multitasking libraries which run on top of MS-DOS. But a multitasking system based on the protected mode of 80x86 processors is more appealing, since it unleashes the 32 bit processing capabilities of the processor and solves the memory limitation problem in a much more natural way. Since Windows NT and OS/2 are already ruled out, Unix-like systems are the closer option. Commercial real time systems such as QNX and VxWorks are expensive and perhaps not open enough to accommodate the need for custom built hardware. Many commercial real time systems are appropriate for real time data acquisition, but almost useless for real time control. Linux is an inexpensive system and because the source code is freely available, it is open to be changed as needed. Also, it is a full 32 bits operating system with performance comparable to commercial ones. Almost all usual Unix applications have been ported to Linux. And

recently Linux ports of some typical Windows applications have appeared. Many of the Linux characteristics are desirable in a mobile robot setup. Linux can run comfortably in a machine without keyboard and display. Device drivers have a standard interface (contrary to Windows) and can be written using just a C compiler. Also, device drivers can be loaded and unloaded without machine reboot. Actually, there are tools to load and unload device drivers on demand, optimizing machine resources and enabling the use of multiple device drivers for a single physical device. This is useful, for example, for the parallel port. It can be used as a standard printer port, as a communications (laplink) port, as a general purpose I/O port, as a Zip drive port and so on. Linux is able to load the appropriate driver when needed and then unload it. Most system reconfiguration tasks can be done without system reinitialization. System reconfiguration can be easily done by remote access, since it does not need a graphical interface. But that is not a very important issue, since graphical applications written to the X Window System can also be run remotely. That is, the application can be run on a system without display, possibly the mobile robot, with the output shown on another system responsible for the user interface. Since Linux runs in protected mode, it uses the full addressing capabilities of 80x86 processors, overcoming the main limitation of MS-DOS. In some sense, for mobile robot applications, Linux gathers the best of MS-DOS (simple interfaces and development) and Windows (full memory access, 32 bit code, multitasking), with the advantage that its multitasking is much better than Windows multitasking. Linux was not designed to be a real time system, but there is a real time extension called Real Time Linux [7]. The idea behind this extension is to implement a real time preemptive scheduler that shares the processor among the actual Linux kernel and the real time processes. To honor the real time constraints, the Linux kernel has the lowest priority. Although for real time systems in general, Real Time Linux might be adequate, for advanced real time control such as needed for mobile robots it proves to be of limited usage. A strong emphasis was put on minimizing the interrupt latencies (the time needed for the system to respond to and interrupt), which is really very important for real time systems. But for control systems, the execution time of the real time task is also very important. In robotics the calculations needed to compute the control signals can be very involved and hardly can

be computed within the sampling period without the help of a floating-point processor. Real Time Linux does not adequately support floating-point. There is a fixed-point library for Real Time Linux, but the range of the variables typically used on robotics spawns into a set hardly covered using fixed-point numbers. Furthermore, Real Time Linux programs are executed as kernel modules and hence, as the Linux kernel is not reentrant, can not use kernel and standard C library services based on kernel services. In particular, the inability to use memory allocation and device drivers related services is a major drawback. However, Real Time Linux is a promising direction and hopefully in the near future it will be integrated with the standard kernel. That day it would be nice if it were possible to run standard programs with real time scheduling, instead of the current procedure requiring the use of kernel modules. In order to make possible the use standard C and C++ libraries and standard device drivers, the real time system implemented on IEEE-rover and Twil is based on the standard Linux kernel. The timing of real time tasks are controlled by specially created virtual devices, called real time timers. Also, as the real time tasks are typically tightly coupled, the traditional Unix processes model is not appropriated due to the overhead for data exchange. Therefore, the real time tasks were implemented using the threads model. More specifically, a POSIX threads library is used.

Linux On-board Linux has been used as on-board operating system even for commercial robots. Here, the Linux usage on two generations of mobile robots built in our labs is described. The Block diagram of the second generation Twil mobile robot is shown in Fig. 2.

Fig. 2 - Twil mobile robot block diagram. The block diagrams of both robots are very similar, since they have many blocks in common.

The differences are that IEEE-rover does not have sonar sensors and joystick. Both robots are differential drive robots, since they are steered by the difference of the velocities of the traction wheels. The angular displacement of each traction wheel is measured by an incremental encoder. Two video cameras are mounted in front of the robot and can be rotated to focus on interesting environment points. The same tower supports the ultrasound sonars. The robot sensor system includes also a digital compass. The communication system comprises a wireless modem using the AX.25 protocol and a parallel cable interface using the PLIP protocol. Although the block diagrams of both robots are the same, the implementation of some blocks differs. Twil is controlled by a computer based on a Pentium MMX-233 while IEEE-rover is controlled by a 5x86-150. The frame grabber used on IEEErover has a greater resolution, but on Twil the grabbed image can be accessed more efficiently because the image is directly stored on the host memory and not on the frame grabber card. Twil encoders resolution is 8192 pulses/revolution, resulting in a better positioning. IEEE-rover encoders resolution is 4000 pulses/revolution. The joystick had to be added to Twil due to its weight (45Kg), that makes movimentation by hand impossible. Because it is much more lighter (5.6Kg), IEEE-rover does not need a joystick. The RS232 interface that was used by the joystick on Twil, can then be used to create a serial connection using SLIP or PPP protocol. However, transfer rate is much slower than the obtained with PLIP. Anyway, SLIP and PPP are standard protocols, while PLIP compatibility is more implementation dependent. Many blocks shown in Fig. 2 are implemented by custom hardware. Therefore, the corresponding device drivers were also developed in our labs. Due to simple structure of the Linux drivers, almost each of them could be developed in a single day. Although the frame grabber and the wireless modem are commercial products, device drivers for Linux were not available and were also developed in our labs. Consonant with Linux spirit, the wireless modem driver [4] was released under GNU General Public License [1] and the frame grabber driver [3] was released under the GNU Library General Public License.

Communications System Since there is not display nor keyboard on the computer mounted on the robot, the system is

operated from a remote computer. Four communication methods can be used. Three of them are based on standard Linux capabilities. a) serial line terminal: the robot is connected using a null-modem cable to an RS232 terminal (or a computer emulating a terminal). The main advantage of this method is the simplicity, but the services offered using this method are not good. Therefore, it is basically used to configure the networking software. b) TCP/IP connection via SLIP or PPP: the same null-modem cable is used to create a SLIP or PPP connection between the robot and another computer. TCP/IP protocols can then be used to offer a number of services. In particular, Telnet and ftp services are very useful. c) TCP/IP connection via PLIP: The null-modem cable is replaced by a null-printer cable connected to the parallel port. The transfer rate of a PLIP connection is well above limit of the serial ports. d) TCP/IP connection via AX.25: Wireless modems are used to create an AX.25 connection. This way, the robot can communicate with the operator computer without cable connection, but the transfer rate is limited to 38400 bps. While the AX.25 level 2 protocol is implemented in the standard Linux kernel, level 1 protocol is implemented on the device driver written for the wireless modems [4]. The methods a and b above require a serial port. While on IEEE-rover such a port is available, on Twil all serial ports are used. Hence, the joystick or the wireless modem would need to be removed. Nonetheless, there are few reasons to use such connection methods, since the data transfer rate using PLIP is much greater. Therefore, the following methods are the preferred ones. If the robot is on its docking station, a cable connection (PLIP) is used else a wireless modem (AX.25) is used. By using Linux autorouter daemon gated and writing a small utility to detect the presence of a connected parallel cable, it was possible to implement an automatic switching between methods c and d, in such a way that the faster available link is always used. When the robot is connected to the parallel cable, TCP/IP messages goes through the PLIP link. If the parallel cable is unplugged, the messages are automatically redirected to the AX.25 link. The level 1 AX.25 implementation [4] enables the communication among many identical wireless modems using a single radio frequency channel. The wireless modem employed are halfduplex. As all modems operate on the same frequency, a medium access policy is needed to

avoid simultaneous transmissions that would cause the loss of the message. Medium access control is done using CSMA (Carrier Sense Medium Access) p-persistent [6]. In general lines, the CSMA p-persistent method implements the following protocol: whenever a station wants transmit, it listens to the medium and verify if it is free, i.e. if there is not carrier present. If the medium is free, the station transmits with probability p. With probability (p - 1) or if the medium is not free, the transmission is delayed until the next time slot. This protocol is repeated until the transmission is completed. On IEEE-rover and Twil the defaults are p=0.25 and a slot time of 10 ms, but there are tools to change these values if necessary. The use of Linux simplified a lot the implementation of communications with the robot. First of all, Linux was conceived to be used with a terminal, thus the serial connection with another computer was straightforward. Second, the networking system is powerful and very flexible, operating with a number of lower level protocols. It is important to note that it can perform complex routing procedures, which enables the implementation of automatic route changes depending on the availability of interfaces. Also remarkable is its support of AX.25 protocol that enabled the development of a wireless network with little more than the implementation of the modem drivers. Driver implementation is eased due to the availability of source code for similar drivers and for the operating system itself.

Back to the Real Time Problem As already commented, the timing of real time loops is implemented using virtual devices called real time timers. These timers were implemented as standard Linux character device drivers. Real time timers define four operations: open, close, write and read. The Semantics of open and close operations are obvious. They are used to allocate and deallocate a real time timer. As many real time timers as needed can be allocated. The write operation initializes a down-counter with the desired sampling period. This counter is decremented by a hardware interrupt, thus the timing is software independent. A read operation blocks until the associated timer expires, enforcing the timing. Also, it returns the number of real time clock ticks that occurred while it was blocked. This way, the loop idle time can be assessed. If the read operation is executed after the timer expiration, it returns a negative tick number. This number reveals

how long after the deadline it takes to the loop to blocking system call would block only the calling complete. Of course, this is an exeption condition thread. Because the real time timers mechanism is since the real time assumptions were violated. For based on blocking functions, this type of threads safety reasons, the system must be shutdown. Also, library is more convenient. A library called it indicates that the sampling period should be LinuxThreads [5] is used in conjunction with real enlarged or a powerful processor must be used. time timers to implement the real time multitasking Due to the tight coupling among real time system of the robots. tasks, the threads [8] multitasking model is used. The operation of this real time system is There are many threads libraries for Linux. They more easily understood through a real example. can be divided in two categories: In the first Consider the problem of real time category, threads are implemented by the library implementation of a data fusion method using the itself, in user space [14]. All threads are mapped Kalman filter. The data to be fused are obtained in into a single kernel process. Since no kernel call is real time from the robot sensors, such as encoders needed to switch among threads, switching and compass [9]. overhead is minimized. But as all threads are seen The timing diagram of compass read is by the kernel as a single process, a blocking kernel shown in Fig. 3. The symbol å denotes processing call would block all threads. by the microcomputer. This processing is just the This limitation is overcome by kernel space read or write of some bits on I/O ports, therefore it threads [5]. Kernel support is used to implement is executed within some µs. The numbers denote the threads. In general the clone system call is used and necessary delays in ms and the symbol ã denotes each thread is mapped into a kernel process. As the the remaining free time within the compass thread switching is done inside the kernel, there is a sampling period of 200ms. substantial increase in overhead when compared to user space threads. However, a more consistent behavior of threads is obtained. In particular, a å 10 å 80 - 100 10 å 5 å 1 å 1 … 1 å 5 å ã trig wait enable data (16 bits) read - 16ms total disable free Fig. 3 - Compass read timing diagram. Note that although the compass read takes about 135ms, processing is done only in small chunks of a few µs. Almost all the time needed to read the compass is formed by delays of several ms. This timing diagram can be easily implemented in software. But in a real time implementation of the proposed system, the encoders need to be read concurrently with the compass. The timing diagram of encoder read is seen if Fig. 4. The sampling time is 50ms.

å

ã

data read

free

Fig. 4 - Encoder read timing diagram. Therefore, it can be noted that compass reading can not be done by busy-wait methods, since due to its processing time of 135ms, it would not be possible to process the encoders each 50ms. The solution is to use a multitasking system and do

not use busy-wait, but suspend the task during delays. The program which implements the data fusion has four threads: 1) compass read, with sampling period of 200ms; 2) encoder read, with sampling period of 50ms; 3) data fusion, without fixed sampling period, but synchronized with the compass and encoder threads and 4) user interface, with a sampling period of 1s. This thread has the lower priority, thus it is executed only if the remaining threads are suspended. The synchronization among threads is done using semaphores. They are used to enforce a) that the real time operation starts only after all threads have completed their initialization and b) that the data fusion occurs only after compass and encoder data be available, thus synchronizing the operation among the sensor read threads and the data fusion thread. In general lines, the sensor read threads execute the following algorithm

void compass(struct cps_param *data) { // inicialization sem_post(&data->ready);

// initialized

sem_wait(&data->start); write(&data->rtc_timer, &data->samp_time, sizeof(data->samp_time)); for(;;) { // sensor read

// other threads need initialize // start real time timer

sem_post(&data->avail);

// signalize data available

read(&data->rtc_timer, &data->block_time, sizeof(data->block_time));

// suspend until the next sampling period

sem_wait(&data->ack);

// get data available acknowledge

} }

The data fusion thread executes the following algorithm. Note that for each compass sample, there are four encoder samples. Also, the

timing of this thread is implicitely controlled by the timing of the compass and encoder threads.

void fusion(struct fus_param *data) { // initialization int c=3; sem_post(&data- >ready); sem_wait(&data->start); for(;;) { sem_wait(&(data->enc_data->avail));

// c = synchronism counter // initialization performed // wait for all threads ready // wait for encoder data

// encoder data processing sem_post(&(data->enc_data->ack));

// encoder data processed

if(c==0) { c=4 sem_wait(&(data->cps_data->avail));

// wait for compass data

// compass data processing sem_post(&(data->cps_data->ack));

// compass data processed

// compute Kalman filter } c--; // compute motor contro l } }

Real Time Results In Fig. 5 is shown the sampling period of compass and encoders. The signal logic level is inverted on each sampling. As seen, compass sampling is not synchronized whith encoder sampling, but for each compass sampling, four encoder sampling is performed.

Fig. 5 - Sampling period of compass and encoder. Synchronization is done on the data fusion thread, as verified in Fig. 6, where the signals generated by the compass thread and by the data

fusion thread are shown. Again, there is a logic level inversion per loop execution. The execution period of the data fusion thread is not exactly at 50 ms, but varies slightly to force the synchronization between the sensors.

device drivers and requires just the same tools used for applications development and readily available. Networking is one of the strengths of Linux. Its networking subsystem is very flexible and complete. It can perform complex routing tasks, including automatic routing reconfiguration. While Linux standard kernel does not support real time applications, there are some patches to turn Linux in a real time operating system. It would be nice if one of these patches makes its way through the standard kernel. This would enable the development of a real time system based on standard programs scheduled by a fully preemptive real time scheduler on the kernel. If this becomes reality it would be possible to develop real time programs using the full functionality of the standard libraries.

Fig. 6 - Timing of compass and data fusion threads.

References

On the non real time side, Linux was used to provide networking connections. Due to the use of the TCP/IP protocol, the robots can be accessed from the Internet. Anyone on the Net can access the Twil robot while it is idle. With a conventional browser, a real time sample of its sensors can be obtained and limited motions performed. Fig. 7 shows a web page with sensor data obtained in real time. Telnet and FTP services are also available and are used mostly for development.

[1] Free Software Foundation - GNU General Public License - version 2, June 1991. [2] Free Software Foundation - GNU Library General Public License - version 2, June 1991. [3] Lages, W. F. - DT2851 Frame Grabber Driver, available on-line at ftp://sunsite.unc.edu/ pub/Linux/apps/video/ dt2851-2.01.tar.gz. [4] Lages, W. F. - BIM-XXX-RS232 Radio Transceiver Driver, available on-line at ftp://sunsite.unc.edu/pub/Linux/apps/ham/drivers/ bim-1.0.tar.gz. [5] Leroy, X. - Linuxthreads - POSIX 1003.1c kernel threads for Linux, 1997 - available on-line at http://pauillac.inria.fr/~xleroy/linuxthreads. [6] Tanembaum, A. - Computer Networks, Prentice-Hall, Englewoods Cliffs, 1988. [7] Yodaiken, V. - Cheap Operating Systems Research and Teaching with Linux, available online at http://luz.cs.nmt.edu/~rtlinux. [8] Tanenbaum, A. - Modern Operating Systems, Prentice-Hall: Englewood Cliffs, 1992. [9] Vector 2X Compass Module - Application Notes, Precision Navigation, Inc., Version 1.03, january, 1996. [10] Hollestein, A. A. - Aufdatierung der Position und der Orientierung eines mobilen Roboters, ETH Doktor Abhandlung, Zürich, 1992 (in german). [11] Murata, S. & Hirose, T. - On Board Locating System Using Real-Time Image Processing for a Self-Navigating Vehicle, IEEE Trans. on Industrial Electronics, Vol. 40, No. 1, February 1993.

Fig. 7 - Real time sample of the sensor of the Twil robot, obtained through the Internet using a conventional browser.

Conclusions Due to its openness, Linux is an ideal platform for embedded development, specially for mobile robots. Since the source code is available, the system can be easily modified to fit special hardware requirements. Also, the development of

[12] Knoll, A. Sensordatenfusion für Anwendungen in der Robotik, Technische Bericht KIFS 94 Universität Bielefeld, 1994 (in german). [13] Sandi Lora, F. A., Hemerly, E. M. & Lages, W. F. - Estimação em Tempo Real de Posição e Orientação de Robôs Móveis Utilizando Sensores com Diferentes Taxas de Amostragem, Anais do 3o Simpósio Brasileiro de Automação Inteligente, Vitória - ES, 2-5 september 1997 (in portuguese). [14] Mueller, F. - FSU Pthreads (POSIX Threads), 1993, available on-line at http://www.informatik.hu-berlin.de/~mueller/ pthreads.html

Walter Fetter Lages received the B.S. in Electrical Engineering from Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS), Porto Alegre, Brazil in 1989 and the M.Sc. and D.Sc. degrees in

Electronic Engineering and Computer Science from Instituto Tecnológico de Aeronáutica (ITA), São José dos Campos, Brazil in 1993 and 1998. Dr. Lages main areas of interest are robotics, digital control systems and real time systems. Elder M. Hemerly is an Adjoint Professor in the Electronics Division, Instituto Tecnológico de Aeronáutica (ITA), São José dos Campos, Brazil. He received the B.S.E.E. from Universidade Federal do Espírito Santo, Vitória, Brazil, the M.Sc. in Electronic Engineering from Instituto Tecnológico de Aeronáutica (ITA), São José dos Campos, Brazil, and the Ph.D. degree from Imperial College of Science, Technology and Medicine, London, in 1989. Dr. Hemerly is the author of the book Controle por Computador de Sistemas Dinâmicos, published by Edgard-Blücher (in Portuguese). His main areas of interest are adaptive control, system identification and digital control systems.