Real-Time Applications with RTLinux
As an example of what can be accomplished with such a system, consider the Henson Company Creature Shop's Performance Control System (see Resources). Originally designed to operate electromechanical creatures used in filmmaking, the ``animatronic'' version of the system is capable of precise control of real-world puppets that are actuated by electromechanical or hydraulic servos. The system runs RTLinux on a laptop PC at the front end for I/O and timing. The PC communicates serially with a back-end embedded PC residing in the puppet, which in turn communicates serially with microcontroller-based motor driver peripherals.
The system incorporates three critical components that run on Linux:
A large suite of high-level graphical tools that allow puppeteers to create complex expressions and performances.
The Henson ``Motion Engine'' that resolves complex character expressions before communicating them digitally to the puppet.
A networked GUI server that gives multiple users local or remote operation of the system.
The artists and engineers at the Creature Shop found that while a soft real-time system was sufficient for computer graphics puppeteering, there was too much frame-rate jitter for use in the animatronic version. In the animatronic implementation, an RTLinux periodic task maintains a 60Hz frame-rate. The periodic task uses RTL interprocess communication to commence ADC driver burst and RT serial communications, then it launches the Linux user-space portion of the motion engine with bounded latency that meets the system frame-rate. The user-space portion of the motion engine is currently being tested using several methods. Ultimately, RTLinux functionality will give it hard real-time invocation from a Linux user-space environment.
The RTLinux approach to system control gives an incredible degree of flexibility when compared to existing DSP systems. As an example, let's consider in some detail a high-speed turbodynamic application in which a one-ton rotor is suspended by a five-degree-of-freedom active magnetic bearing (AMB) and spins at 15,000RPM. This application has the following readily identifiable tasks:
Five-degree-of-freedom suspension controller. The controller runs at a fixed periodic rate (in the 50--100 microsecond range) and both reads and writes the appropriate signals necessary to suspend the rotor. This task is critical in that missing one sample can have catastrophic consequences.
Spin rate measuring task. Triggered once per revolution and used to calculate the spin rate of the rotor. For our rotor, this task will be awakened once every (60/15,000)*1E6 = 4,000 microseconds. The accuracy requirements for the spin rate make this task very intolerant to temporal error.
Anti-imbalance controller. Executed 16 times per revolution and is used to produce a synchronous force used to counteract the effect of rotor imbalance--much the same way that balance weights are added to automobile tires to stop them from wobbling. The intertask scheduling period is dependent on the spin rate of the rotor. So, for our rotor, the task would be scheduled once every (4000/16)*1E6 = 250 microseconds. For this task, very slight temporal incorrectness is allowed.
Data transfer and data plotting tasks. Used to store data to disk, screen or other devices. These tasks allow relatively large temporal error.
Network transfer tasks. Transfer data and commands to and from other computers. For example, the rotor system could be contained in a deep bunker, while the rotordynamics engineers control it from a safe room some distance away. These tasks allow a larger temporal error.
Miscellaneous tasks: such as graphical user interfaces, scripting programs (e.g., Perl and Tcl), and computational engines (Matlab, Scilab, MuPAD, Mathematica, and MathCAD). There is no temporal limitation on these tasks, and they can be performed concurrently with or postmortem to the above tasks.
This entire system can easily be implemented in a single computer using RTLinux, although the standing conventional approach has been to implement each of the above tasks in an independent DSP. In the RTLinux paradigm, the first three tasks would be implemented in the hard real-time environment (RTLinux), while the last three would be comfortably run on the non-RT side (Linux). All can run on the same computer.
Now, let's look at the code. For brevity's sake, we'll focus exclusively on tasks 1 and 2.
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python