A Lightweight Real-Time Executable Finite State Machine Model forCoordination in Robotic Systems

Markus Klotzbücher, Herman BruyninckxDepartment of Mechanical Engineering, Katholieke Universiteit Leuven

Celestijnenlaan 300B, 3001 Leuven (Heverlee), Belgium

Abstract— We describe our experience in developing a prac-tical, lightweight, real-time executable model as an internaldomain specific language using the Lua scripting language.We show that the problems of memory allocation and garbagecollection can be substantially simplified compared to generalpurpose languages by exploiting knowledge of the modeleddomain. We illustrate this for rFSM, a hierarchical finite statemachine model used for coordination in the robotics domain.

Index Terms— real-time, coordination, garbage collection,domain-specific-language, component-based

I. INTRODUCTION

Building internal domain specific languages (DSL) is anefficient way to implement new programming languages byconstructing these on top of an existing host language [1].One advantage is avoiding to have to develop a new syntaxand an associated parser. But more importantly internal DSLpermit the construction of languages which can be directlyexecuted as interpreted scripts in the host language withoutthe need for additional transformation steps. This is a bigadvantage compared to more static model driven engineeringapproaches like MDA [2] and xUML [3] which typicallyrequire a model transformation and/or compilation beforebeing executable.

rFSM (reduced Finite State Machine) is a minimal variantof UML Statecharts providing hierarchical, parallel andhistory states. States can specify entry and exit programswhich are executed when entering and exiting the state re-spectively. The do program is executed while a state machineresides in a state and no events triggering outgoing transitionsoccur. An important concept of UML Statecharts is the run-to-completion step which implies that transitions betweenstates are executed atomically and can not be interrupted.Transitions can therefore only be triggered after the entryprogram of a state has been executed. This condition is calleda stable configuration.

Traditionally dealing with hard real-time constraints al-ways implied an implementation in lower level languages asC, C++ or Ada. More recently several hard real-time Javaimplementations have emerged [4] providing deterministictemporal behavior. For the rFSM implementation we chose

The research leading to these results has received funding from the Euro-pean Community’s Seventh Framework Programme (FP7/2007-2013) undergrant agreement no. FP7-ICT-231940-BRICS (Best Practice in Robotics).markus.klotzbuecher@mech.kuleuven.be

the Lua extension language [5] which is well suited for thistask due to its single threaded nature, small memory footprintand precisely controllable incremental garbage collector.

rFSM is designed for modeling Coordination in com-ponent based robotic systems [6] [7]. However due to itsportable and lightweight implementation it is not limited torobotics and can be easily applied to other domains too.

A. Coordination with Finite State Machines

It is an increasingly acknowledged best practice for build-ing robust and reusable systems to modularize according tothe aspects of Communication, Computation, Configurationand Coordination [8] [9] [10]. The aspect of Communicationdefines how system parts communicate with each otherand the characteristics of the communication. Computationsare the basic and reusable behaviors and define what iscommunicated. Configuration specifies which Computationsform a system, their properties and interconnections. Atlast Coordination defines when Computations interact whichComputations are part of an interaction and the protocols ofinteraction which are followed.

Finite State Machines (FSM) have been used for modelingcomplex and reactive systems for several decades [11] [12][13] and are well suited for modeling Coordination for sev-eral reasons. Firstly the FSM formalism is well understoodand expressive while still being simple to understand. Thisis an important requirement in robotics where many usersare not software engineers. Secondly FSM are supportedby a wide range of modeling tools and can be formallyverified. At last the hierarchical types of FSM such as HarelStatecharts and the therefrom derived UML Statecharts havegood compositional properties which allow for incrementallydeveloping large Coordination models by composition ofsimpler ones.

Fig. 1. Coordination of Component Assemblies

An example of a simple robotics coordination problem is

illustrated by the component assembly shown in figure 1. Aball swinging on a string is to be followed by a robot arm.The 2D ball positions extracted from two camera imagesby BallExtractor components are passed to the estimationcomponent. The estimated value is then sent to the Robot-Controller which actuates the robot arm. Now the situationis possible that the ball swings out of the observed camerarange. In this case the desired behavior is that the robot armstops at the last estimated ball position. However differentestimation models will show different behaviors; for instancea constant velocity model will predict the ball motion tocontinue with the last estimated velocity while a constantposition model will continue to predict the last observedposition.

A naive solution to this problem would be to add afeature to the estimator to stop the robot controller oncethe ball has left the camera range. This solution howeverwill severely limit the reusability of this component andmake it impossible to replace it with a different estimationcomponent which does not make these application dependentassumptions. A better solution is to introduce a Coordinationcomponent which encapsulates this policy. The state machinefor such a component is shown in figure 2.

Fig. 2. Ball-tracking Coordination state machine

Instead of making assumptions about the component lay-out the estimation component raises an event when the ballis not being tracked anymore. The coordination componentthen reacts to this event and transitions to the pause state inwhich the robot is stopped. When the ball enters the camerarange and the estimator begins tracking the ball again, asecond event is raised to transition back to the followingstate and restarting the robot controller in the exit programof the pause state.

B. Contributions

The contribution of this work is describing an approachfor creating a lightweight, real-time executable FSM modelby showing how domain specific knowledge can be exploitedfor efficiently dealing with memory allocation and collection.

Our approach has several advantages. The use of a garbagecollected language for executing the model eliminates thelarge class of pointer related errors and memory leaks. Thisis especially relevant for Coordination which has higher

requirements of robustness and reliability than regular Com-putations. Secondly our approach unifies simulation and finalsystem, thus avoiding the problem of the two behaving incon-sistently. At last the dynamic nature of scripting languagesreadily supports dynamic changes like hot swapping of codeor even modifications to the structure of the state machine,thereby supporting the principles of evolving systems [9].

C. Outline

The rest of this paper is structured as follows. Section IIdescribes related work. In section III we describe how wedeal with the problem of real-time memory management forthe rFSM DSL. Section IV describes advanced extensionswhich are enabled by our approach and section V gives someexperimental results. We conclude and summarize in chapterVI.

II. RELATED WORK

The UML language has long been used for modeling real-time systems [14] [15], however mostly as a specification andmodeling language without the intent to execute the model.More recently the UML MARTE profile [16] (Modeling andAnalysis of Real-time and Embedded systems) extends theUML modeling language with features specific to real-timeand embedded systems. [17] shows how executable specifi-cations can be generated from these models, yet additionaltransformations are necessary.

With respect to the scheduling of garbage collection thework on time triggered garbage collection [18] is relevant asit describes an alternative approach to the classic allocationdriven collection scheme. In contrast to our work the generalpurpose language of Java is targeted while our state drivenapproach is specific to the target domain of Coordination.

III. MEMORY MANAGEMENT

The main challenge for using scripting languages in a real-time context is dealing with the potentially unbounded timingbehavior of allocation and recuperation of memory. While itis possible to create simple scripting languages which pre-allocate all memory [6] as a result of the static allocationthese languages are restricted in terms of expressivity. Withlanguages providing higher levels of expressivity which arenecessary for building internal DSL one has to face bothreal-time allocation and garbage collection.

In this work we do not propose new techniques foraddressing these issues but rather show how making use ofdomain knowledge combined with existing techniques canallow for substantially reducing the complexity of allocationand garbage collection issues.

A. Real-time memory allocation

Traditional real-time systems preallocate all requiredmemory at initialization time, as allocations and dealloca-tions at run-time may result in unbounded temporal behavior.For allocation in scripting languages this is not practicalas the ability to dynamically create and dispose of objectsmakes the use of a scripting language worthwhile in the

first place. Fortunately results in real-time allocation suchas [19] and more recently [20] allow memory allocationswith guarantees for worst case execution time. For the rFSMimplementation we use the TLSF memory allocator [20] withthe Lua language.

Nevertheless it is important to recognize that using areal-time allocator is still a form of pre-allocation, as theallocations are served from a pre-allocated memory pool.Increasing the pool size might require falling back on a non-real-time safe system memory allocator or under low mem-ory conditions might not be possible at all. Consequently theamount of memory necessary has to be known in advancewhich in practice is often not entirely possible. For the rFSMimplementation the memory consumption depends on:

1) the static size of the state machine graph (states,transitions, user code)

2) the dynamic memory consumption of state machinecore and the user supplied entry, do and exit programs.

The first can be effectively estimated as it increases linearlywith the amount of states and transitions as shown in figure3

Fig. 3. rFSM static memory usage

The graph shows the static memory consumption (in KiB)for rFSM instances of n states and 2*n states and transitions.The second however is less straightforward, as predictingthe memory usage of user supplied programs is not easilypossible. Fortunately for the domain of Coordination we canassume the following: i) the user programs consist mainlyof calls to low-level C/C++ code for Coordinating the actualcomputations and ii) no large amounts of data are transferredbetween the scripting language and low-level C code. Thisway the amount of dynamic memory required is very smallcompared to the overall usage and can be neglected. Insteaddepending on how critical the implemented functionalityis a safety margin of additional memory is allocated. Werealize that such allocations of safety margins might notbe feasible on very small embedded systems. However for

modern robotics systems which are typically well equippedwith memory this is in general not a problem.

B. Allocation Failure Strategies

Besides taking proactive measures against running out ofmemory by predicting memory usage and allocating safetymargins, a robust FSM implementation must nevertheless beable to deal gracefully with low memory conditions. For therFSM implementation this is achieved by pre-allocating asecond block of memory called the “emergency pool”. If thememory of the regular pool is running low, an internal eventis raised by the state machine core which can be used totransition to a safe state. This is illustrated in figure 4.

Fig. 4. Transition to safe state triggered by low memory event

During normal operation the FSM resides in the opera-tional state or one of its substates (omitted for readability).If the FSM core runs short on regular memory, the evente_low_mem is raised. This event then can be used totransition to a state safe_mode in which the system candeal with the situation by making adjustments or performingmanual garbage collection after stopping the robot in asafe manner. Note how the low-memory condition can bedealt with within the state machine model without the needfor external handlers etc. The emergency pool serves toguarantee that enough memory is available for performingthe emergency transition in spite of the regular memory beingexhausted.

C. Real-time garbage collection

Real-time garbage collection has been intensively re-searched over the last decades [21] [22] [23] with a lotof attention directed towards concurrent collection in multi-threaded systems. For the Coordination domain we make thefollowing simplifying assumptions. Firstly Coordination doesnot require true parallel execution. This is because Coordina-tion actions commonly consist of short asynchronous com-mands to lower level Computations as for instance switchingcontrollers, sending a new setpoint to a trajectory generatoror commanding a gripper to close. In fact it is desirable forachieving deterministic behavior to atomically execute theseprograms. Hence even the user programs of parallel states areexecuted in a serialized manner by means of coroutines forcooperative multitasking. This way the complexity and non-determinism of parallel garbage collection can be avoided.

The second assumption can be made about when garbagecollection shall be performed. For an UML like FSM this isnaturally after the run-to-completion step has finished. Moreprecisely this is after a transition has taken place and thestate machine has reached a stable configuration but beforethe in-state do program is executed.

One prerequisite for our implementation is an incrementalgarbage collector which can be disabled and manually in-voked by the host language. Automatic garbage collectionis then disabled and incremental collections are executedby the FSM implementation after each run-to-completionstep. As the overall memory consumption is monitored bythe allocator itself and low memory events are raised fordealing with this condition no extra validation is necessaryto ensure that the incremental collector is keeping up withthe allocations. Due to the deterministic and single threadednature transition coverage testing can reliably reveal suchconditions.

IV. DYNAMIC EXTENSIONS

The use of a scripting language enables the following statemachines extensions.

1) Live code upgrades: For long running, evolving sys-tems it is desirable to be able to make changes to the livesystem at runtime. As rFSM is implemented as a Lua basedDSL it inherits the properties of its host language, in whichloading new modules, replacing existing code and cleaningup of unreferenced functions is supported.

2) Dynamic FSM: It is a common practice today to allowhot-plugging of hardware to running systems by dynamicallycreating the required components. What is less straightfor-ward is including the required coordination for these newcomponents. This is because coordination activities can oftennot be viewed in isolation but rather must be integrated intothe existing coordination, ideally without disrupting ongoingactions. rFSM can accommodate such changes by allowingruntime structural modifications like

• adding a nested state to the existing state machine• replacing a nested state• adding a new transitions between states

Interestingly performing such changes constitutes a Coordi-nation problem itself as for instance it is not permitted toremove a state while its programs are being executed. Cur-rently these extensions have not been sufficiently exploredyet and are subject to further work.

V. EXPERIMENTAL EVALUATION

This section gives some experimental results for evaluationthe temporal behavior of different state machines executed byrFSM. All tests were run using the Xenomai [24] real-timeframework on a Pentium M 1600 MHz.

For evaluating the worst case timing behavior of the FSMimplementation there are two important measures inherent tothe rFSM core and to the specific FSM instance respectively:

1) The worst case time required for transitioning the statemachine from the reception of an event to reaching astable configuration.

2) The worst case duration of an incremental garbage col-lection step which is executed after the entry programof a state.

The first is important for determining the overall worstcase duration of a transition which can be calculated bysumming up this value with the execution time of the exitprograms, transition effect and entry programs.

The second is important as it defines the minimal in-statedelay for exiting a newly entered state again. Together withthe transition time this value can be used for analyzing thetiming behavior of a path of transitions of a FSM.

All tests were performed by executing transitions forminga circular chain of states of different hierarchical depths andusing a different number of states. Figure 5 shows threeexemplary states of a depth of three. The default connector ofeach nested state connects to its substate which causes eachtransition to start from the most nested state and end on themost nested state of the successor. No user programs aresupplied except for calls to Lua POSIX real-time bindingsused to measure the timing behavior. For each benchmark10000 transition steps were executed.

Fig. 5. Detail of a benchmark FSM with depth=3

Figure 6 shows the duration required for the rFSM core totransition between two states. Two things can be observed.Firstly, the worst case transition time for deeper nestedhierarchical states is higher as the rFSM core must exitand enter more states until the next stable configuration isreached. Secondly, the total amount of states in the statemachine does not influence the transition duration. Theglitches seen in the test of a hierarchical depth of 10 arereproducible in subsequent test runs and can most likely beattributed to the exceeding of a CPU cache.

In contrast to transition times the worst case duration ofgarbage collection does depend on the overall size of thestate machine as can be seen in figure 7. This is due to theLua garbage collector which although incremental, performscollections of the Lua table type atomically. As the table sizes

Fig. 6. rFSM worst case transition execution time

increase for hierarchical states containing more substates, sodoes the duration of the garbage collection.

Fig. 7. rFSM worst case garbage collection execution time

VI. CONCLUSIONS

We have presented a executable state machine modelfor the domain of coordination in complex robotic systemsimplemented as a Lua internal domain specific language.Besides freeing the user from the burden of manual memorymanagement our implementation facilitates dynamic FSMextensions such as code hot-swapping or even dynamicstructural modifications to running FSM. We have shownhow the common problem of dealing with real-time memoryallocation and garbage collection can be simplified by mak-ing use of characteristics of the target domain which for theCoordination domain is the feasibility to run single threadedand the tendency to produce little garbage. The evaluationshows, in our opinion, reasonable overhead and latencies

which are quite acceptable for the robustness and flexibilitygained.

Much further optimization is possible. Following the bestpractice of avoiding premature optimization the current im-plementation takes the simplest but not necessary most effi-cient approach. Thus profiling the implementation is likelyto reveal many opportunities for improvement.

The weakest point in our implementation is currently theunpredictable memory consumption of user programs. Inpractice this has been solved by prior profiling the worst casememory usage in a test run covering all transitions. Due tothe single threaded, deterministic implementation the resultcan then be used for pre-allocating the required amount ofmemory.

The current approach of triggering garbage collection aftera run-to-completion step works well and yields deterministicbehavior. However real-world state machines are rarely ashomogeneous as those used in the evaluation. Therefore itmight be beneficial for reducing jitter to dynamically adaptthe collection points in the state machine graph accordingto the duration of the respective garbage collection. Futurework will investigate this.

REFERENCES

[1] M. Fowler, “Language workbenches: The killer-app fordomain specific languages?” Juni 2005. [Online]. Available:http://martinfowler.com/articles/languageWorkbench.html

[2] J. Miller and J. Mukerji, “Mda guide version 1.0.1,” http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf, Object Management Group(OMG), Tech. Rep., 2003.

[3] S. J. Mellor and M. Balcer, Executable UML: A Foundation for Model-Driven Architectures. Boston, MA, USA: Addison-Wesley LongmanPublishing Co., Inc., 2002, foreword By-Jacoboson, Ivar.

[4] “Real-time specification for java (rtsj),” http://www.rtsj.org/specjavadoc/book_index.html, June 2005.

[5] R. Ierusalimschy, L. H. de Figueiredo, and W. C. Filho, “Lua—anextensible extension language,” Softw. Pract. Exper., vol. 26, no. 6,pp. 635–652, 1996.

[6] P. Soetens, “A software framework for real-time and distributed robotand machine control,” Ph.D. dissertation, May 2006, http://www.mech.kuleuven.be/dept/resources/docs/soetens.pdf.

[7] A. Brooks, T. Kaupp, A. Makarenko, S. Williams, and A. Orebäck,“Orca: A component model and repository,” in Software Engineeringfor Experimental Robotics, ser. Springer Tracts in Advanced Robotics,2008, pp. 231–251.

[8] M. Radestock and S. Eisenbach, “Coordination in evolving systems,”in Trends in Distributed Systems. CORBA and Beyond. Springer-Verlag, 1996, pp. 162–176.

[9] ——, “Coordinating components in middleware systems,” Concur-rency and Computation: Practice and Experience, vol. 15, no. 13,pp. 1205–1231, 2003.

[10] L. Andrade, J. L. Fiadeiro, J. Gouveia, and G. Koutsoukos, “Separatingcomputation, coordination and configuration,” Journal of softwaremaintenance adn evolution: research and practice, vol. 14, pp. 353–369, 2002.

[11] D. Harel, “State charts: A visual formalism for complex systems,”Science of Computer Programming, vol. 8, pp. 231–274, 1987.

[12] D. Harel and A. Naamad, “The STATEMATE semantics of state-charts,” ACM Trans. on Software Engineering Methodolody, vol. 5,no. 4, pp. 293–333, 1996.

[13] OMG, “Unified modeling language (uml),” http://www.uml.org/.[14] B. P. Douglass, Real-time UML: developing efficient objects for

embedded systems. Addison-Wesley, 1998.[15] S. Gérard, C. Mraidha, F. Terrier, and B. Baudry, “A UML-based

concept for high concurrency: the real-time object,” in Proceedings ofthe Seventh IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’04), 2004, pp. 64–67.

[16] Object Management Group, “Modeling and Analysis of Real-time andEmbedded systems,” http://www.omgmarte.org.

[17] P. Peñil, J. Medina, H. Posadas, and E. Villar, “Generating heteroge-neous executable specifications in systemc from uml/marte models,”Innovations in Systems and Software Engineering, December 2009.

[18] S. G. Robertz and R. Henriksson, “Time-triggered garbage collection:robust and adaptive real-time gc scheduling for embedded systems,”in LCTES ’03: Proceedings of the 2003 ACM SIGPLAN conferenceon Language, compiler, and tool for embedded systems. New York,NY, USA: ACM, 2003, pp. 93–102.

[19] T. Ogasawara, “An algorithm with constant execution time for dynamicstorage allocation,” in RTCSA ’95: Proceedings of the 2nd Interna-tional Workshop on Real-Time Computing Systems and Applications.Washington, DC, USA: IEEE Computer Society, 1995, p. 21.

[20] M. Masmano, I. Ripoll, P. Balbastre, and A. Crespo, “A constant-time dynamic storage allocator for real-time systems,” Real-Time Syst.,vol. 40, no. 2, pp. 149–179, 2008.

[21] H. G. Baker, Jr., “List processing in real time on a serial computer,”Commun. ACM, vol. 21, no. 4, pp. 280–294, 1978.

[22] A. W. Appel, J. R. Ellis, and K. Li, “Real-time concurrent collectionon stock multiprocessors,” in PLDI ’88: Proceedings of the ACMSIGPLAN 1988 conference on Programming Language design andImplementation. New York, NY, USA: ACM, 1988, pp. 11–20.

[23] H. G. Baker, “The treadmill: real-time garbage collection withoutmotion sickness,” SIGPLAN Not., vol. 27, no. 3, pp. 66–70, 1992.

[24] P. Gerum, “Xenomai - implementing a rtos emulation framework ongnu/linux,” 2004.