Article: Fourth Real-Time Linux Workshop — invitation and abstracts
Nov 5, 2002 — by LinuxDevices Staff — from the LinuxDevices Archive — 3 viewsAn invitation to attend . . .
December 6-7 2002
Computer Science Department, Boston University
111 Cummington Street Boston, MA-02215, USA
Conference overview
The GNU/Linux operating system, originally designed as a general purpose operating system, is nevertheless employed in many embedded and real-time applications where some form of real-time performance is required. To meet these timing requirements, several approaches can and have been undertaken, either in the kernel, by add-ons, or by other means in order to guarantee real-time performance of the application running on top. These real-time Linux versions have been gaining more and more importance in industry. However, there are many questions unanswered for newcomers, users, and developers concerning topics such as: development tools, debugging applications, licensing models, stability of kernels, reliability of applications, and persistency and consistency of variants and their APIs. For these reasons this workshop offers . . .
- Kick start sessions for free to make you familiar with this rising technology
- Paper presentations on new developments and technologies, contributions, and on applications in industry
- Linux in control “Birds of a Feather” (BOF) session
- Bring together developers and users, as well as developers of variants themselves
- Discuss user demands with users, and implementation issues with co-developers, in hands-on sessions
- Show me your code!
- Encourage the spirit of a community
For more details and for registration please visit the conference's website.
The conference's organization committee consists of: Pablo Alvarez, Nicholas McGuire, Richard West, and Peter Wurmsdobler.
Technical presentation abstracts
So far, the following abstracts for technical presentations at the conference have been submitted. The complete set of papers is expected to be made available at LinuxDevices.com for viewing/download following the conference.
Here are the abstracts . . .
Real Time Linux for Flight Testing Uninhabited Aerial Vehicles and GA Aircraft, by Charles E. Hall, Jr.
Flight testing of small UAV's requires a small, lightweight computer system on board the aircraft. To obtain quality data and correctly implement control systems the system must have a hard real time operating system.Real Time Linux has been installed on a PC104 system and interfaced to the UAV's transducers, actuators and radio control system. The system has been used to implement a full set of attitude controllers and a navigator for autonomous flight tests of a UAV. The system has also been used to collect data during flight tests of a general aviation aircraft. The paper will discuss the use of Real Time Linux in the flight critical system.
Realtime issues in telecommunications, by David Sugar
In this paper I will talk about the needs and requirements to successfully implement telecommunication services under GNU/Linux, particularly in terms of media processing, both for traditional telephone networks and IP based ones, as well as discussing the GNU projects recent efforts in these areas, particularly in the development of stable high performance and scalable RTP transport (GNU ccRTP) and in the development of GNU Bayonne (the telephony server of the GNU project), and how realtime kernel services impact this area of development.
Development of a general-purpose, open-source real-time experiment interface system, by Calin Culianu, David J Christini
The need for real-time interface systems is ubiquitous in scientific research (e.g., cardiac arrhythmia control, torque measurement, fluid dynamics analysis). However, current options have significant drawbacks: common multi-tasking operating systems are inherently non-real-time and therefore require special hardware for real-time functionality, DOS functionality is outdated, and proprietary real-time operating systems are expensive. Furthermore, each of these options is vulnerable to the ever-looming possibility of obsolescence in the event that the proprietary, closed-source operating system were to be discontinued. To overcome these limitations, we are developing a general-purpose, open-source, real-time experiment interface system based on Real-Time Linux, Comedi, and Qt. This system is being developed with flexibility and adaptability in mind, so that experimentalists with limited programming experience can modify it to meet the specific demands of their application. With this freely available system, we hope to ease the burden of experiment interfacing for a wide range of scientists and engineers.
Space robotics: an Experimental Setup Based on RTAI-Linux, by A. Macchelli, C. Melchiorri, R. Carloni, M. Guidetti
Thanks to a constant research and development activity in the field of robotics and, more in general, of automation, reliable and relatively low-cost machines that can substitute or assist human operators in repetitive or dangerous tasks are now available. In robotics, this is particularly true for applications in structured environment, i.e. when the workspace in which the robot operates is known with great accuracy and precisions. On the other hand, it is obviously of interest the development of applications in unstructured or unknown environments. In this case, control algorithms that can give a sort of human behavior to the machines are needed: in other words, the machines should be characterized by a functional autonomy, i.e. they should be able to modify their behavior on the basis of information acquired in real-time from the environment. In space application, it is of great interest the development of autonomous or semi-autonomous robotic devices that can substitute the astronauts in routine operations in order to free them from repetitive tasks and reduce mission costs. In this work, an experimental setup based on a 6 degrees of freedom (dof) manipulator with a 3 dof gripper designed for a possible application within PaT, the Payload Tutor proposed by ASI (Italian Space Agency), is presented. This system consists of a robotic arm, a vision system, and a gripper. Since the gripper has to interact with free-floating and irregular objects, the vision subsystem provides all the information needed for grasping unknown objects in an optimal way. The robotic arm is a Comau SMART 3-S robot, a standard industrial 6 dof anthropomorphic manipulator with a non-spherical wrist, equipped with the standard controller C3G-9000. Each joint is actuated by a DC-brushless motor, and its angular position is measured by a resolver. In our setup, the controller is only used as an interface between the resolvers and drives on t he robot and a PC running RTAI-Linux. In each sampling period generated by the controller, the real-time control system running on the PC must acquire the data from the encoders, compute the new control input for the actuators and send their values to the C3G-9000. On the robot wrist, both the video-camera and the gripper are installed. The vision system is used to provide visual information about the environment and, in particular, about objects within the workspace of the robot. These information are needed to track a moving object in the workspace with the robot, to move the robot in a desired position in order to grasp an object with the gripper and to automatically calculate the optimal grasping configuration. At the moment, the vision system consists of a monocular camera, connected to a frame-grabber board installed on the same PC that implements the robot control algorithms. By properly moving the robot arm and, at the same time, acquiring images of the object from different points of view, the vision algorithms can give a good estimate of the distance of the object from the robot wrist. This information is essential to correctly move the robot in order to grasp the object with the gripper. Moreover, by means of the vision system, the shape of the object is recognized in order to calculate the better grasping points (target points). The object is caught on these points and the contact forces are properly controlled. Generally, the target points are selected on the basis of a kinematic analysis of a first order model: the resulting points do not depend on the shape of the object and on the geometric characteristics of the gripper. In our case, the target points are calculated by means of a kinematic analysis of a second order model that takes into account also the shape of the object and of the gripper's finger: in this manner, the resulting grasping configuration is more stable. The third component of our setup is the A.S.I. Gripper. It has three degrees of freedom, and is particularly suited for no-gravity manipulation tasks (i.e. in space applications), since it can interact with free-floating and irregularly shaped objects. Its control algorithms are executed on a custom DSP board (based on the TMS320C32 chip). For this board, a loader and a DSP-monitor have been developed under Linux, together with some drivers for the DSP board. Once the object distance and the target points are calculated, the gripper is correctly positioned in the workspace with respect to the object. Then, the fingers are closed and the object is grasped on the target points. At this point, the DSP board executes the control algorithm in order to assure proper contact forces. In the final version of the paper, a detailed description of all the subsystems will be presented, together with some experimental results.
Real-time Linux in Chemical Process Control: application results, by Andrey Romanenko, Lino O. Santos, Paulo A.F.N.A. Afonso
Many chemical processes require real-time control and supervision in order to operate them safely and profitably, while satisfying quality and environmental standards. As a means to comply with these requirements, it is common practice to use control software based on a proprietary operating system such as QNX, VxWorks, or MS Windows with real-time extensions. To our knowledge, the idea of using Real-Time Linux has not been embraced widely by research and industrial institutions in the area of Chemical Engineering. Nevertheless, recent application reports from other industrial fields indicate that several variants of the Linux operating system, that enable it to be real-time, are an attractive and inexpensive alternative to the commercial software. In fact, several implementations of open source data acquisition and control software, and real-time simulation environment have been developed recently. Moreover, the apparent trend for the number of such applications is to increase. We describe our experience at the Department of Chemical Engineering of the University of Coimbra, with two pilot plants that are under control of a system based on real-time Linux. One of them is a completed project and the other is under development. The experimental set-ups closely resemble industrial equipment and function in similar operating conditions. We hope that this successful application will encourage further deployment of real-time Linux in the Chemical Engineering research and industry.
A Simulation Framework for Device Driver Development, by Yan ShouMeng Zhou XingShe
Proprietary I/O devices are often involved in many computer application systems,especially in embedded systems. In such scenarios, Developers have to develop drivers for these devices to utilize them under some embedded operating system. Traditionally, development of device driver can undertake only after hardware design finishes, for the writing and debugging process involve many interactions with real hardware. However, with the increasing competition among corporations, shorter time to market is important for a successful production. To shorten the development cycle of device driver, this paper propose that using a simulation device as the target of driver's operation. Previous works on device simulation focus on how to support development of application level software. VxSim[1], a component in Vxworks Tornado environment for platform simulation, only support application software which requiring very simple interactions with hardware, but is not suitable for software with extensive device accesses, especially device drivers. A simulation development method for device drive is proposed in paper[2], which simulate all system routines in a application and compile and link the driver source code with the application together. This method can only make some testing work on device driver, but cannot support the simulation of the running of the entire application system that based on the device driver. This paper presents a device simulation mechanism based on an abstraction model of I/O devices. Then a simulation framework for device driver development is discussed. This framework can effectively support writing and debugging of device driver without the need of hardware existence. For the running of application software is relying on the underlying device driver, it is natural that this framework also supports the development of the entire system without requiring hardware involvement.
POSIX application defined scheduling on RTLinux, by J. Vidal, F. Gonzálvez, I. Ripoll
Although in the last years many scheduling algorithms has been proposed, just few of them has been truly implemented in real RTOS. In most cases, the availability of RTOS source code or the complexity and risks involved in introducing new politics in kernel, causes that major part of nowadays RTOS only implements fixed priorities politics. To solve this, M. González (Universidad de Cantabria) is proposing a new POSIX standard called application-defined scheduling, that allows to introduce new scheduling politics without having to modify O.S. kernel's. This paper describes our experiences in the implementation of application-defined scheduling in RTLinux. With this feature, several application-defined schedulers, implemented as special threads, can coexist in the system in a predictable way.
A Remote Surveillance and Control System Prototype with RTLinux and RTNET, by Yan Shoumeng Zhou Xingshe
An embedded real-time system prototype for remote surveillance and control is presented. The system consists of an embedded single-board and a few simulators for devices of which status is monitored and behavior is controlled. These components are connected through a fast switch via which the status information of devices is sent to the single-board computer periodically. And then the single-board computer will publish the status information to Internet or Intranet through an embedded web server called GoAhead. The operators can browse the status of devices and issue device control command via any standard browser (e.g. IE or Netscape) without additional client side software installation bother. To guarantee the timely data collection of the single-board computer, RTLinux was employed. But considering RTLinux cannot access network on the RT side, we employed the RTNET, which implemented a IP stack on RT side. The data is collected by a real-time task and then fed to a user space process via FIFO and share memory. The application code for client side was a JAVA applet and would be downloaded upon the operator¡¯s browse request. The applet runs on the client side and provides the graphical presentation of data and the operating interface for operator. This prototype system will have broad application scenarios, such as Device Remote Surveillance system especially the remote monitoring of device that located in the distant mountain and hazardous scenario.
Shielded Processors: Guaranteeing Sub-millisecond Response in Standard Linux, by Steve Brosky
There has been much good work in making standard Linux into a more responsive system for real-time applications. The low latency patches and the preemption patches have allowed guarantees on worst case interrupt response time at slightly above a millisecond. These guarantees today are only met when there is no networking or graphics activity in the system. The shielded processor concept dedicates selected processors in a symmetric multiprocessing system for the real-time components of an application. This paper will describe the implementation of shielded processors in RedHawk Linux and the benefits of shielded processors. It will also present the results of benchmarks for both interrupt response and program execution determinism. Interrupt response time guarantees are significantly below one millisecond and can be guaranteed even in the presence of networking and graphics activity.
Graphical Programming of Realtime Applications with LabVIEW for Linux RTAI, Thomas Leibner, Gerd Schmitz
The programming of real-time applications nowadays involves multitasking using timing demands with microsecond resolution, inter task messaging including semaphores for synchronization of multiple running tasks. For solving this task efficiently a programmer likes to use graphical visualization methods for program flow, messaging and priority dependencies. Instead of using graphical methods only for debugging and schematic overviews of analysis problems typical for real-time and multitasking, the graphical programming environment LabVIEW(tm) by National Instruments provides state-of-the-art tools for solving programming tasks by just doing graphical formulation of algorithms and data flow. One major disadvantage of LabVIEW, not being able to be used as programming environment for hard real-time in kernel space, could be eliminated using the user space API 'LXRT' of the RTAI 'Real Time Application Interface' for Linux. It is shown, that by implementing a generalized call interface to the 'LXRT' , the user space API of RTAI could be integrated into LabVIEW for Linux. By this extension it is now possible to perform with hard real-time using graphical user space programming. The visual data flow programming of LabVIEW easily visualizes timing and synchronization dependencies. Although the full LXRT API hasn't been implemented yet, a basic set of timing and data acquisition functions for hard real-time are shown to be working. A jitter as low as five microseconds on a Pentium III/500MHz makes it possible to have 20 kHz loops with sophisticated computing, e.g. PID closed loop control and audio filtering, by just doing graphical programming. This is another example of the power of the LXRT user space API of the Real Time Application Interface for Linux, giving us the possibility to do hard real-time from user space.
Optimal Pulse Patterns Modulator Using Real Time Linux, by David Antonio Ulloa Guzman
Since that microcontrollers and DSP's stated to be used in power electronics many ideas could be realized and the Optimal Pulse Pattern Modulator was developed together with the Trajectory Controller in order to correct its problem. Working in this kind of research one need a stable and comfortable system which must be flexible to make almost any change. According to that a combination between a Hitachi SH2 core and a personal computer under Real Time Linux was implemented. This paper describes some aspects about the theory of this modulator, how that was implemented and shows results obtained with this system.
Predictability in Embedded Linux and Commercial Requirements, by Masatoshi Iwasaki, Tatsuo Nakajima
In Japan, many campanies who are building complex embedded systems such as cellular phones and degital televisions are considering to adopt embedded Linux for their products. Most of these companies have been adopted the ITRON real-time operating system as their operating systems, but the functionalities are not enough to build complex embedded systems because ITRON does not provide memory protection, and file systems and network systems are provides as additional middleware components. Many future embedded systems need to access various services on the Internet, and Linux already provide a lot of middleware to reduce the development cost dramatically. Japan Embedded Linux Consortium consists of over 100 companies in Japan is now discussing on how to migrate from ITRON-based embedded systems to Linux-based embedded systems. Especially, many campanies are interested in whether embedded Linux can satisfy timing constraints for their products or not. Our paper describes requirements on timing constraints that should be satisfied in their products. We have been discussing the requirements in Real-Time Working Group of Japan Embedded Linux Consortium, and we like to show whether current Linux can satisfy the requirements.
A Quality-of-Service Enhanced Socket API in GNU/Linux, by H. Abbasi, C. Poellabauer, G. Losik, K. Schwan, R. West
With the increase in available network bandwidth and reduction in network latency, more emphasis has been placed on End-Host QoS to provide quality of service guarantees for distributed real-time applications, such as video streaming servers, video conferencing applications, and VoIP applications. End-host QoS requires support from the underlying operating system (OS) in the form of network schedulers and traffic controllers. GNU/Linux supports a variety of network schedulers for the provision of end-host QoS, but no easy-to-use API is provided between applications and system-level traffic controllers. Moreover, existing APIs lack the ability to link QoS attributes with stream or datagram sockets and to associate QoS information with individual packets allowing sophisticated network schedulers to make scheduling decisions based on such information or to link different streams such that their QoS management is coordinated. We propose an extension to the standard Berkeley socket interface that enables applications to easily create and manage connections with QoS requirements. This new API — called Q-Sockets — includes per-socket traffic classification that allows the application developer to link a socket connection with a scheduler so that all data going out on this socket is scheduled accordingly. We further allow an application to pass packet-specific parameters to the scheduler for fine-grained scheduler control. Finally, we provide functionality to allow developers to link multiple sockets for the coordinated scheduling of packets on these sockets. We evaluate our approach with a multimedia application using Q-Sockets and a real-time packet scheduler.
Loosely Coupled Tool Integration Architecture for Embedded Linux, by Seung Woo Son; Hyung-Taek Lim; Chaedeok Lim; Heung-Nam Kim
When developing applications under embedded Linux, there is a range of software tools to assist the development process. However, they are so tightly integrated that it is not only difficult to integrate into IDE but hard to add an additional tool. They are communicating with each other through their own protocols so that there is much communication overhead between host and target machine. In this paper, we propose loosely coupled tool integration architecture based on lightweight RPC mechanism. The proposed architecture is mainly composed of two agents running on host and target side respectively. To integrate various tools in a seamless way, we suggest well-defined host-to-target protocol and inter-tool protocol. Host agent mediates request from several host tools and interacts with the target agent. The host agent set out a set of common APIs needed for host-resident tool integration. The target agent, the counterpart of the host agent, is a kind of debug demon which serves request from the host agent. As designed for embedded software development, the size of target side agent is about 100KB and consumes less than 5% of CPU time. With the proposed architecture, we easily integrate various host tools using open APIs with low overhead target agent.
Pretty Pictures in Hard Real-Time, by P. N. Daly (et al)
The WIYN Tip-Tilt Module (WTTM) was developed as an adaptive optics solution to image degradation due to atmospheric instability and dynamics. The WTTM was successfully commissioned onto the WIYN 3.5m telescope in February 2002 and it currently undergoing shared risks commissioning. In this paper we review the hardware and software design of the WTTM and present some spectacular results from the commissioning data.
A Digital PID Controller Using RTAI, by Rodrigo da Silva Guerra, Hermes Jose Goncalves Jr., Walter Fetter Lages
This work presents an implementation of a digital PID (Proportional+ Integral+Differential) controller in a PC machine running RTAI. PID controllers are well known and have a wide range of applications in the control of analog systems such as servomotors. In order to achieve the desired performance the system output (axis position) is feed-back to the PID controller which generates the system input (motor voltage), in a closed loop. The controller computes the error between the desired system output (reference) and the actual system output. Then, the system input, which is the PID controller output, is generated as weighted sum of the error, its integral and its differential. The weighting coefficients are known as controller gains and referred as Kp, Ki, and Kd. The values of the controller gains determines the performance of the closed loop system and even its stability. The design of PID controllers is outside the scope of this paper, however it should be said that its values are very dependent on the sampling rate at which system output is read and the new value for system input generated. Therefore it is highly desirable to have an accurate sampling rate. For typical mechanical systems, the adequate sampling rate is in the range of milliseconds. Thus, well implemented PID controllers are usually hard real time systems. The PID controller described in this work uses the PC parallel port as an analog I/O interface. Just two bits are used. One to read the system output and the other to generate the system input. As the system input and output are analog variables, a technique called Pulse Width Modulation (PWM) is used to generate (and read) analog values using digital signals. This technique is based on varying the duty cycle of a rectangular wave accordingly to the analog value to be represented. By using PWM, an analog interface can be built without the use of conventional A/D and D/A converters. However, the switching rate of the PWM signal should be fast enough to be filtered by the system under control. For typical mechanical systems that means a few hundreds of microseconds. The implemented system can be characterized by four main tasks: Two PWM tasks which generate the input and output signals, a PID task responsible for the controller in a proper sense and a user interface task. Except for the user interface task, each one of the main tasks has its own time requirements which must be accurately met. The user interface was implemented as a plain Linux process using the NCurses library. Real time tasks were provided by threads under LXRT hard real time mode. The implementation of PWM under RTAI using the timing functions provided by RTAI are presented and the convenience of using these functions for actual real time control is discussed. In Particular, the semantics of rt_sleep() is analyzed in details and it is shown that the current semantics can lead to an confusing interpretation of what a periodic task is and what a task period is. Furthermore the current semantics of rt_sleep() is incompatible with the the semantics of rt_busy_sleep(), which can lead to even more confusion. A new semantics for rt_sleep() is suggested and the corresponding implementation presented.
Simulating a Vehicle with RTLinux for the Testing of Transmission Control Units, by Karl Rentsch
As part of the software development cycle engineers regularly need a systematic method of testing a product prior to release. In the automotive industry this testing is critical to the safety of the users. Complex embedded control units must be tested under precise conditions representative of an automobile. This paper looks at the signals and system requirements necessary to simulate a vehicle environment in hard real-time, the development of an automated test facility for an embedded transmission control unit and the RTL tricks and techniques used along the way. Many of the complexities in developing a vehicle simulation lie in the diverse range of signals required. In the past vehicle manufacturers have relied on wiring looms to share signals between sensors and electronic modules. Today, in-vehicle networks are replacing the need for looms and simplifying the sharing of information between electronic modules. Any vehicle simulation must be able to synchronize packet data with digital and analogue signals and be highly configurable. Extended simulations require an efficient method of describing a sequence of time critical events. These sequences must combine all data types, be repeatable with sub-millisecond precision and provide a true representative of in-vehicle signals. This paper describes the use of language tools, operating from user-space, cleverly controlling real-time signal sequences One of the best methods to verify the simulation is by recording I/O signals in-vehicle for direct comparison. By developing a miniRTL based “black box” we created an in-vehicle data recorder backward compatible with the test facility. This not only allows vehicle signals to be logged but also replayed as a real-time simulation at will. This paper describes methods of data synchronization, the development of language tools for writing real-time signal sequences, the incorporation of a miniRTL based system in the recording and playback of vehicle signals and automated processes for benchmarking the controllers behavior.
Flash Storage in a Linux-Based Residential Gateway, by Zachi Friedman
The availability of new in-home interconnection technologies, combined with the explosion of non PC-based devices, is driving the demand for a single device to connect in-home appliances to the public Internet. The residential gateway, as its name implies, is a central entry and control point at the home for all voice, video and data services, as well as the cornerstone for future services. It is the true enabler of the Age of Information. Embedded Linux distributions play a leading role in this brave new gateway world, surpassing veteran operating systems. What are the do's and don'ts of working with Linux on an embedded gateway design where storage is concerned? How do you address the concern of some 38% of the respondents to a poll that said: “My main concern about using Linux in embedded applications is insufficient driver support from chip vendors” What are the pros and cons of NOR versus NAND-based flash storage devices, and how do you choose the right technology for your system? What are the special considerations when choosing a flash file system for a Linux gateway design? How can you avoid data and code corruption and premature flash block expiration? This presentation will discuss the above items, and also focus on the crucial tools needed for a successful, long-lasting Linux-based gateway design as perceived by M-Systems, based on the company's experience with leading OEMs. Proposed Speaker: Zachi Friedman, Technical Marketing Engineer In May 2001, Zachi Friedman joined M-Systems, where he now serves as a Technical Marketing Engineer in charge of 3rd party relations, integration projects and Linux partnerships. Friedman was previously employed as a Sr. Software Engineer by NICE Systems California and was responsible for 3rd party software integration projects. In 1994, Friedman graduated with a B.Sc. in Computer Sciences from the renowned Technion Institute. He then went on to serve 6 years in the Israeli Air Force Software Division as a team leader. In 2000, Friedman graduated with an MBA from the University of Tel Aviv. Friedman was born in Haifa, Israel. He was first introduced to the PC at the age of 12, at which time he became hooked and remains so until today.
Driver Architecture In A Linux World, by John Linville
Vendors of modern networking hardware realize that the devices they provide require a great deal of software in order to function effectively. As a result, many hardware vendors provide large amounts of software for use with their devices. However, the prevalent use of the VxWorks operating system has allowed hardware vendors to become careless with the architecture of the driver software they provide. Often the driver software provided by hardware vendors is difficult to use in a protected environment like Linux. This paper begins by discussing strategies for making use of such drivers in a Linux environment, and continues by discussing how hardware vendors might architect Linux-friendly driver software. Finally, the paper discusses how vendors can provide first-class Linux support for their hardware and why it is in their best interest to do so. This paper is a must read both for system integrators new to Linux and for driver software architects unfamiliar with the Linux environment.
Calling Plain Linux Device Drivers Functions from Hard Real Time Tasks, by Walter Fetter Lages
Processes running under plain Linux usually access I/O devices through device drivers implemented monolithically in the kernel or as loadable kernel modules. This has the advantage of exposing standard interfaces for all I/O devices and enables processes running without root privileges to access I/O. Unfortunately, hard real time tasks can not use the standard kernel interfaces to I/O devices, since that would force an execution of kernel code, which does not comply with the hard real time requirements. This problem has been dealt with by implementing special device drivers to be used by real time tasks. Nonetheless, those special device drivers adhere more to the concept of a library than to the concept of a device driver. Each special device driver exposes his own set of functions that can be called by real time tasks, but there is not a common set of functions among all special device drivers. In other words, the concept of uniformity is not implemented. Obviously, it is highly desirable to use the same device driver for programs running under plain Linux or under real time. If soft real time is enough for the application, LXRT can be used. LXRT tasks runs in user space but under control of the real time linux scheduler. By running under user space, LXRT tasks can use standard C library calls to access I/O through standard device drivers. However, to access the device driver a portion of the plain Linux kernel code is executed on behalf of the LXRT task. Since the temporal behavior of the kernel code is not deterministic, the real time scheduler is force to switch the LXRT task to soft real time mode while it is executing kernel code. This paper addresses that problem and shows that under some assumptions it is possible to avoid the switch to soft real time mode while accessing device drivers and therefore the hard real time properties of the task are retained. By using the method proposed in this paper, the very same device driver can be used by plain Linux processes, by hard real time tasks running in kernel space, by LXRT tasks running in soft real time mode and by LXRT tasks running in hard real time mode. The effectiveness of the method is demonstrated by the implementation of a device driver for a robot controller. Test programs written in C++ as plain Linux programs, as real time kernel modules, as LXRT soft real time tasks and as LXRT hard real time task, all accessing the controller through the device driver have their temporal behavior discussed.
Yet Another RTAI Interface, by Francesco Mandracci
The described library is a software level that enables modules to run either in user-space (POSIX threads) or real-time (RTAI tasks), without filling up the code of ifdef and forcing a well-defined code structure. It is different from LXRT: here we twice compile the same source code in order to obtain a user space executable and a kernel module. The library provides a software abstraction for: threads, semaphores, memory allocation, timing, fifo-byte-queues (memory ring buffers, named pipes, rtai fifos and tcp/ip sockets). Moreover threads/tasks needs to be structured in a strict way: each thread/task must provide five callbacks, init(), start(), step(), stop() and destroy(). Each callback must return, no infinite loops allowed. The timing source in user space is the operating system clock. In real time you can choose among the RTAI timing, one interrupt (say IRQ 7), one PCI timing source. 1) What you loose You won't be able to use the full POSIX and RTAI interfaces. And in user space you won't be able to write your main() function. 2) What you gain You gain a known-to-work structure to start from. You gain the ability to run the same source code in user space and in real time. You can less painfully debug an algorithm in user space and then try it in real time. 3) Past to present The library was developed for a numerical control for a laser cutting machine, with timings of 30 ms in user space and 0.1 ms in real time. The timing source is the same PCI servo board used to control the motors. 4) Future The process of releasing it with GNU General Public License is in progress.
Generic real-time infrastructure for signal acquisition, generation and processing, by Herman Bruyninckx, Peter Soetens
This paper presents the design for the real-time core of a generic real-time signal acquisition, processing and generation system. The design is generic in the sense that it can be used in a wide variation of application domains, from the PLC logic of MatPLC, over medical signal processing in the RT-Lab project, to the robot motion control of the Orocos project. It's exactly the functional overlap between these projects that has stimulated the presented design, in the hope of gaining more critical mass for the real-time signal processing core of these, and other, projects. The paper only presents the design of an application-independent real-time signal processing infrastructure, and its implementation on a Linux RTOS, but not the protocols and plug-ins to be provided by the applications, on top of this infrastructure.
An Assessment of Real Time Robot Control over IP, by Gustavo Hommerding Alt and Walter Fetter Lages
This paper presents an assessment of the performance of a real time controller using an IP network to link the controller, the sensor and the actuator. This control system is part of a anthropomorphic robot manipulator with two arms and a pan-and-tilt stereo vision head, totalizing 19 joints. Each joint has an actuator, an incremental encoder, an electromagnetic break and an inductive contact sensor. There are also two six-axis force sensors. In order to cope with all devices an distributed control system was implemented. The devices are all connected to an IP network and the real time control loops are configured by software and run over the IP network. The real time requirements of the control loops, which must run at 100Hz rate, are enforced by using RTAI in LXRT hard real time mode. RTAI is also used for monitoring the time behavior of the network packets, in order to deal with the best-effort of assumption of the IP network. Indeed, an IP network assures that it will do its best effort to deliver each data packet, but there is no guarantee that the packet will be delivered. However, a real time control loop must run at an accurate rate or the system performance or stability will be impacted. Therefore, sensor data must be feed to the controller at the same rate, or it will not be able to compute the control action. Hence, the ability of the IP network to deliver the packets with reliability and rate accuracy is very important. Of course, IP networks were not designed with such applications in mind, but it is very difficult to neglect the low-costs due to mass-production. The time behavior and the performance of a controller implemented over an IP network is characterized and compared with those obtained with a local controller. A method to deal with lost packages is also proposed. The key to this method is to note that a control network does not carry digital data in the same sense a generic computer network. A control network carries control signals in a digital format, hence the corruption of the digital data can be tolerated as long as the control signal can be recovered. This paper proposes a method to recover the control signal even in the presence of lost or late packets.
Graphic Supervisor of Lung Ventilator, by River Quispe Tacas, Alejandro Palomino Amaro, Adolfo Ascanio Rafael, Carlos Albino Rivera
The Units Intensive Cares (UIC) of the Hospitals in Peru, they need of a centralized system that it integrates in a net, the different marks of Lung Ventilator to supervise from oneself place the process of ventilation mechanics, to be a process of high risk; they also need of a graphic monitor of local supervision for the Lung Ventilator that lack this system. The denominated developed system Graphic Supervisor of Lung Ventilator it consists of a sensor of developed gassy flow, a module of acquisition of data to acquire the signs of the process of the ventilation mechanics, software for the graphic user interface monitoreo developed in Linux and Real Time Linux with a net of local area to integrate the Lungs Ventilator. The signs that they supervises are: pressure proximal, breathing flow, relative humidity and temperature of breathing flow. The Graphic Supervisor of Lung Ventilator, allows the professionals of the health to observe the breathing signs of all the patients in a centralized way, this way it can improve the quality of attention to the patients in UIC and to reduce the operative costs for the attention of the patients in the hospitals
Improving the responsiveness of Linux Applications in RTAI, by Luca Marzario, Luca Abeni, Giuseppe Lipari
RTAI is a real-time kernel that permits to execute, on the same physical machine, both hard real-time applications and the Linux Operating System. RTAI is particularly useful when dealing with real-time processes that needs a guaranteed low response-time to interrupts. By using a fixed priority scheduler provided with RTAI, it is also possible to schedule periodic hard real-time, and to guarantee the schedulability of the system. In this framework, Linux is assigned the lowest possible priority, and it is scheduled in background, i.e. when no other real-time task requires execution. This is the simplest way to guarantee that the behavior of the real-time tasks is not compromised by the behavior of Linux applications. However, in certain cases, under high real-time load, this method can be too restrictive for Linux applications. In certain cases, it is useful to mix hard real-time and soft real tasks activities in the same system. Hard real-time tasks represent critical activities that must finish before their assigned deadline, otherwise the system correctness is compromised. Soft real-time system represent non critical real-time activities: they are required to finish before their deadline, but occasional deadline misses do not compromise the correctness of the system. The most popular example of soft real-time application is a multi-media player: if some video frame is not displayed on time, or if it is skipped, nothing catastrophic happens. The ratio of deadline misses over a given interval of time can be taken as a measure of the Quality of Service (QoS) experienced by the final user: the lower the deadline miss ratio, the better the QoS. Soft real-time multimedia applications are usually executed on Linux mainly because many drivers, libraries and tools for video and sound systems are already available on Linux. When soft and hard real-time applications share the same physical machine, one possibility is to schedule hard real-time tasks as RTAI tasks, so guaranteeing a bounded response time; and soft real-time tasks as Linux processes. However, since Linux is assigned the background priority, the amount of execution time assigned to Linux processes over a given time interval depends on the requirements of the RTAI tasks and can vary a lot from interval to interval. Therefore, the amount of execution time that multimedia streams will receive is quite irregular, and it is difficult to guarantee a-priori a certain level of QoS. In this paper, we propose to apply a well-established technique in the real-time system literature, called Resource Reservation, to RTAI. In particular, we changed the RTAI scheduler to implement the Earliest Deadline First (EDF) scheduling policy and the Constant Bandwidth Server (CBS). With CBS, every task is assigned a capacity Q and a Period P, with the meaning that a task is allowed to execute at least Q unites of time every P units of time. A hard real-time task is assigned a capacity Q greater or equal to its worst case computation time and a period P equal to the task's period. Linux is assigned a capacity and a period as well, that depend on the QoS requirement of the soft real-time applications that execute on Linux. The system is schedulable if $sum_i{frac{Q_i}{P_i}}$. At run-time, every task has a remaining capacity q and an absolute deadline d. According to EDF, the task with the earliest deadline is scheduled to execute. At run-time, Linux is treated exactly as any other hard real-time task: initially, it is assigned an absolute deadline $d = P$ and a remaining capacity $q = Q$. When the capacity of Linux is finished, its priority is decreased by postponing its absolute deadline to $d = d + P$, and its capacity is recharged to $q = Q$. In this way, Linux cannot jeopardize the behavior of the hard real-time tasks, but it is guaranteed a minimum execution time of Q every period P. This mechanism has very little overhead at run-time. Moreover, it has another advantage in the debug phase. During the development of a hard real-time task, it can happen that the task goes into an infinite cycle. For example the task might actively wait for a condition that does never happen. With a pure fixed priority scheduler, it is quite difficult to see what happens, because Linux is scheduled in background and will never execute again. Instead, with our scheduler, Linux is guaranteed a minimum execution time every period: therefore, the programmer can still record the trace and see the logs indicating the situation. In this paper, we implemented the proposed scheduler under RTAI. It is worth to point out that the proposed mechanism is very general, and it can be implemented with little effort in RT-Linux as well. Then, we run a series of experiments that show the advantages of using our mechanism over a pure fixed priority scheduler with Linux in background. We run some simple hard real-time application consisting of 5-10 tasks with different loads, and a mpeg-player under Linux that receives the multimedia stream from a remote host through ethernet. We measured the jitter experienced by the mpeg player: by using methodology, the “regularity'' of the player is much higher than using the plain fixed priority scheduler. The paper is organized as follows: after a brief description of the Constant bandwidth Server (CBS), we describe our implementation in RTAI and discuss the overhead. Then, we describe the experimental setup and we report the results. Finally, we draw the conclusion and discuss future improvements.
Implementing CPU Reservations in Linux, by Luca Abeni and Giuseppe Lipari
With the recent development of kernel patches for implementing kernel preemptibility and high-resolution timers (and the acceptance of the first patch in the 2.5 development kernels), supporting real-time applications in Linux user-space is no more a dream. However, real-time applications must be run using the POSIX fixed priority scheduler, and we believe that this solution presents a number of problems: for example, either a non-root user is not enabled to run real-time applications (hence, real-time support is useless for most users), or it has the power to starve all the other users' processes (even the daemons, and the root's processes). It is our opinion that to safely support real-time applications a multi-user OS such as Linux should provide Resource Reservations to enable users to access the real-time facilities without being able to starve the system. Resource Reservations are not a new concept, and they have been implemented in some Linux variants (the most notable is Linux/RK). In this work, we propose a new implementation, that fundamentally differs from the previous ones in some important points: 1) Our implementation is non-intrusive, i.e, the whole reservation scheduler is a kernel module that can be loaded at run time, and requires only few changes to the kernel; 2) Since the modifications to the Linux kernel are very limited, we can easily upgrade to new kernel versions, or take advantage of new features implemented in Linux, such as kernel preemptibility and high-resolution timers; 3) The scheduling infrastructure that we use is very general, and can be used to implement other loadable schedulers; 4) Compatibility with standard Linux is maintained; 5) Thanks to the algorithm that we implemented (the Constant Bandwidth Server – CBS) and to the careful design of the scheduler infrastructure, our scheduler can cope with aperiodic task arrivals (and with tasks that block and unblock), that cause problems in other reservation-based systems. In this paper, we present the design of our scheduler (showing also how to implement different schedulers based on the scheduling infrastructure that we propose), we compare it with some previous works, and we present a preliminary performance and overhead evaluation. Finally, we describe how a user-level or kernel-level QoS manager can be implemented based on our scheduler, and can be used to enforce a CPU allocation policy, to avoid that a single user can reserve too much CPU to its real-time applications.
Realtime dynamic systems implementation with DSLib, by Ivan Martinez, Jim Luther, Elbert Hendricks
The Dynamic Systems Library (DSLib) is a newly developed interface tool for use between block-diagram modeling and realtime programming. DSLib is a set of C++ classes representing components of block-diagram modeling: blocks (functions, integrators, summing points…), inputs, outputs, schedulers, etc. Such classes can be used in standard C++ code to define simply a dynamic system from a block-diagram approach. Once the system is properly defined, DSlib classes generate the implementation of the dynamic system for a specific realtime operating system (RTLinux and RTAI, at the moment). DSLib has the following advantages with respect to ease of implementation: – It is an easy tool for users familiar with dynamic systems modeling. There is a direct equivalence between a block diagram and its DSLib definition. – It encapsulates the target operating system, so standard C and C++ is the only required programming knowledge. DSLib will generate the specific functions for realtime threads definition and interaction, memory managing, etc. For interaction of the dynamic system with the external world, DSLib also provides classes to easily define realtime fifos, shared memory, and even hardware inputs and outputs by using the Comedi library. From the point of view of the software developer, DSLib can be the kernel of any dynamic system modeling application. For example, a Matlab-like application can be obtained by just adding a user interface. For more info, please visit http://dslib.sourceforge.net/
New RTLinux API for synchronous and asynchronous IO on Realtime FIFOs, drivers, and other files, by Cort Dougan
The primary means of communication between RTLinux tasks and Linux tasks are realtime FIFOs. They were limited by the fact that there was a static number of them and their names were limited to /dev/rtf0 through /dev/rtfXX. Starting with RTLinux/Pro 1.2, we have added a means for creating real-time FIFOs with arbitrary names and locations that can be created and operated on just as with ordinary UNIX FIFOs.
realBOX, by Nurpinar Akdeniz, Tekin Aydin
RealBOX is a PC104 form factor computer based on a 486DX2 processor with 8MB RAM and 8MB Disk-On-Chip Millenium. MiniRTL operating system boots from Disk-On-Chip and expands itself to RAM when the power is applied to the box. Our initial aim and the motivation behind our work was to have an embedded system with the following critical requirements which were fulfilled ; -real-time scheduler -operation without HardDisk. -small foot-print (so a solid state memory preferably the Disk-on-Chip) -no file system checks when power goes off and come again We are using the realBOX in our data acquisition and control applications and planning to utilize it for airborne control projects. We are late a little bit to submit this abstract but we strongly hopeful that you will pay attention to our work.
Using Linux kernel facilities from rt-threads, by Nicholas McGuire
RTLinux has been focused on developing a POSIX compliant RTOS layer that operates below Linux – within this development communication between RT-threads and kernel as well as user-space have been quite limited, in part due to the inherent restrictions of a RTOS and in part due to the restrictions imposed by POSIX, or rather the combination of these two sets of restrictions. As RT-threads are operating in the same address-space as the Linux kernel itself it seems natural to investigate what capabilities within the Linux kernel could be made available to RT-threads as to enhance communication paths too and from user-space and non-rt kernel-space. In this paper a few of these, very non-portable, absolutely non-POSIX, paths are described. The main resources of interest to RT-threads being: Tasklets, Kernel Threads, Software interrupts, Global Variables and Shared Memory. Accessing Non-RT facilities in kernel space Presenting a few simple examples the mechanisms and problems with utilizing these capabilities of the Linux kernel from within RT-context are discussed.
Teaching Real-Time Control Using Free Systems Software, by Kenneth H. Jacker
The paper begins with a short description of the Department's real-time course and its required group projects. This is followed by an overview of the hardware and systems software used in a specific real-time control laboratory assignment. After a discussion of the analysis, design, and implementation of the project, the paper concludes with a brief look at future work.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.