Markus Klotzbuecher, Katholieke Universiteit Leuven, Belgium
Herman Bruyninckx, Katholieke Universiteit Leuven, Belgium

Control and Coordination in industrial robot applications operating under hard real-time constraints is traditionally implemented in languages such as C/C++ or Ada. In the context of component based engineering, Coordination refers to the process of managing and monitoring functional computations such that the system behaves as intended. We present an approach to use Lua, a lightweight and single threaded extension language which is integrated in the Orocos RTT framework.

Using an interpreted language for Control and Coordination has several advantages. Firstly, the robustness and hence safety, of the system is increased. This is because scripts, in contrast to C/C++, can not easily crash a process and thereby bring down unrelated computations that are executed in sibling threads. This robustness is essential for the aspect of Coordination, which, as a system level concern, has much higher requirements of robustness than regular functional computations.

Secondly, the use of a scripting language facilitates less experienced programmers not familiar with C/C++ to construct components. This is important for the robotics domain, where users are often not computer scientists. Moreover, rapid prototyping is encouraged while leaving the option open to convert parts of the code to compiled languages after identification of bottlenecks.

At last, the use of an interpreted language permits dynamic changes to running systems such as hot code updates. This is essential for building complex and long running systems that can not afford downtime.

The major challenge of using Lua in a hard real-time context is dealing with allocation and recuperation of memory. Previously we sketched two strategies to address this: either running in a zero-allocation mode and with the garbage collector deactivated or in a mode permitting allocations from a preallocated memory pool using a O(1) allocator and with active but controlled garbage collection. We confirm these hypotheses in two steps. Firstly, several experiments are conducted to assess worst-case latencies and overhead compared to using C/C++. This includes a Lua implementation of the well known cyclictest and a benchmark of the worst case latency of reacting to event messages within in the Orocos RTT framework.

Secondly, we show two concrete examples that illustrate both strategies of memory management. The first is a comparison of a Cartesian position controller implemented in both Lua and C++. Neither implementations allocate memory after initialization, thus the problem of real-time allocation and collection can be avoided. (Note that the Lua version still makes use of the C++ Kinematic and Dynamic Library (KDL) for kinematic calculations.)

The second example is a Coordination Statechart implemented in the Lua based rFSM domain specific language. Here allocations can not be avoided at run time, hence the following must be taken care of: preallocation of an appropriately sized memory pool for the O(1) real-time allocator, management of low-memory conditions and scheduling and monitoring of garbage collection. In particular the point in time when garbage collection is performed directly influences worst case latencies. Hence, it can become necessary to manually optimize it by defining safe points for incremental collection to take place. For instance, an appropriate time could be at the end of a control cycle when the control thread is going to sleep anyway.

All experiments are carried out on a previously validated and loaded Xenomai system using the Orocos RTT framework to communicate messages in a lock free manner. All code will be made available to enable reproducibility of the results.

Quantitatively, the results of the cyclictest comparison indicate an increase of approximately a factor 1.5 of both average and worst-case latency when using Lua compared to the C implementation. For the Orocos RTT event message benchmark the worst-case latencies increased roughly by a factor four compared to a C   version. This increase can be mostly attributed to the (currently still unoptimized) interaction between the Lua and the foreign Orocos RTT type-systems. The comparison between both Cartesian controller implementations reveal an overhead of approximately a factor 7 for the Lua version.

As usual, benchmark results should be judged with caution and mainly serve to remind that appropriate validation should be repeated for each critical use. In particular when real-time allocation and collection is involved, run time validation of real-time constraints must be considered as an integral part the application.

More important than the quantitative results, the worst-case latencies determined for all tests could be upheld after running several hours of stress testing on a loaded machine.

The major shortcoming of the current approach is that worst-case memory use can be difficult to predict. To deal with this we currently allocate additional safety margins. As the overall memory usage of the Lua language is comparably small, such a measure will be acceptable for many systems, save the very resource constrained.

To conclude, we believe the results demonstrate the feasibility of our approach to use a scripting language for hard real-time control and Coordination that permits to significantly improve robustness and safety of a system. The price of these improvements are (i) increased yet bounded worst-case latencies, (ii) computational overhead, as well as (iii) requiring additional precautions such as manual scheduling of garbage collection. In summary, we believe this constitutes a modern and practical approach to building hard real-time systems that shifts the focus from lowest possible latency to sufficient latency while maximizing reliability.