matrix-based discrete event control for surveillance...

J Intell Robot Syst (2009) 56:513–541DOI 10.1007/s10846-009-9326-x

Matrix-Based Discrete Event Controlfor Surveillance Mobile Robotics

Donato Di Paola · David Naso · Biagio Turchiano ·Grazia Cicirelli · Arcangelo Distante

Received: 1 August 2008 / Accepted: 30 March 2009 / Published online: 30 April 2009© Springer Science + Business Media B.V. 2009

Abstract This paper focuses on the control system for an autonomous robot forthe surveillance of indoor environments. Our approach proposes a matrix-basedformalism which allows us to merge in a single framework discrete-event supervisorycontrol, conflict resolution and reactive control. As a consequence, the robot isable to autonomously handle high level tasks as well as low-level behaviors, solvingcontrol and decision-making issues simultaneously. Moreover, the matrix-basedcontroller is modular and can be easily reconfigured if mission characteristics or robothardware configuration change. An illustrative example and a report on experi-mental investigations are provided to illustrate the main features of the proposedapproach.

Keywords Discrete event systems · Mobile robots · Planning ·Supervisory control · Surveillance

1 Introduction

The increasing need for automated surveillance systems in indoor environments suchas airports, warehouses, production plants, etc. has stimulated the development ofintelligent systems based on mobile sensors. Differently from the mature and wide-spread surveillance systems based on non-mobile sensors (e.g. [1, 2]), surveillance

D. Di Paola (B) · G. Cicirelli · A. DistanteInstitute of Intelligent Systems for Automation (ISSIA),National Research Council (CNR), Bari, Italye-mail: [email protected]

D. Naso · B. TurchianoDepartment of Electrical and Electronic Engineering (DEE),Polytechnic of Bari, Bari, Italy

D. Nasoe-mail: [email protected]

514 J Intell Robot Syst (2009) 56:513–541

systems based on mobile robots are still in their initial stage of development, andmany issues are currently open for investigation [3, 4]. Mobility and multifunctional-ity are generally adopted as a means to reduce the number of sensors needed to covera given area. Besides, it is also important to note that the use of robots significantlyexpands the potential of surveillance systems, which can evolve from the traditionalpassive role in which the system can only detect events and trigger alarms, to activesurveillance systems in which a robot can be used to interact with the environment(e.g. manipulating objects, removing obstacles, finding exit pathways), with humans(e.g. indicating emergency exits, prohibiting access to forbidden areas), or with otherrobots for more complex cooperative actions [5–9].

However, developing a fully autonomous, integrated and effective surveillancesystem based on mobile robots is also challenging from the control engineeringviewpoint because the control system must simultaneously address task planning,dynamic task sequencing, resolution of conflicts for shared resources, and event-based feedback control. On the one hand, it is well-known that all these sub-problemshave been extensively investigated in related areas such as operations research andmanufacturing system control [10, 11]. On the other hand, it can still be observed thatthe preponderance of the related literature focuses on one aspect only, disregarding(or strongly simplifying) the interactions with the others. This gap is particularly no-table in the considered application domain, in which neither commercially-available(typically passive) platforms (IOImage—http://www.ioimage.com; Alma Vision—http://www.almavision.it) nor architectures developed for other problems (rovermissions, automated guided vehicles for manufacturing systems, etc.) seem to fullymatch with the mentioned specifications [12, 13].

Therefore, in order to achieve an effective exploitation of the capabilities of multi-functional robotics in surveillance systems, as well as in many other areas in whichmobile robotics is becoming increasingly widespread, it is important to develop inte-grated approaches capable of properly describing and addressing all the problemswithin a unified modeling and decision-making approach.

Recently a new approach which is very efficient in both modeling and controllingdiscrete event systems has been proposed [14]. It is based on a novel matrix formu-lation that allows fast and intuitive design, mission planning, computer simulation,and actual implementation. The Matrix-based Discrete Event Control (M-DEC)is an integrated modeling and control framework based on Boolean matrices andvectors, which is intuitive (it can be interpreted using simple if-then rules), inherentlymodular (models of large systems can be obtained by assembling submodels ofsmaller size) and versatile.

In this paper we present the control system, based on the M-DEC, which has beendeveloped for an experimental surveillance platform. This work aims to adapt theM-DEC concept to a fully autonomous platform based on a single robot in the areaof surveillance, which is a novel attempt with respect to existing literature. To datethis new modeling and control tool has been applied to a variety of different complex,large-scale distributed systems including manufacturing flow lines [15], materialhandling systems [11] and warehouses [16]. In this work we prove the efficiencyof M-DEC in controlling a surveillance robot which has to manage a variety ofcomplex tasks.

The matrix-based framework allows a simultaneous characterization of the issuesof both supervisory and operational levels in the same mathematical formulation.

http://www.ioimage.com

http://www.almavision.it

J Intell Robot Syst (2009) 56:513–541 515

In this work, in order to enhance the reactivity and the autonomy of the robot inaccomplishing its surveillance task, we furthermore extend the M-DEC with a newlevel, implementing a reactive actuator control. In this new control system, each taskis viewed and executed as a sequence of closed-loop continuous plant behaviors.That is, a discrete-event controller selects a continuous state controller, a referencetrajectory, and an output function from a library of plant control algorithms, inputfunctions, and output functions, respectively. The selected plant behavior is keptactive for a certain time until an event from the environment or from the controlleroccurs. Thus, in this paper, the M-DEC is not only in charge of implementing pre-conditions, post-conditions, and interdependencies of the tasks, but it also implicitlycontrols the sequence of low-level behaviors, viewed as shared resources, neededto execute each task. This strategy leads to an integrated, hybrid deliberative-reactive platform combining the full predictability and mathematical rigorousnessof supervisory discrete-event control with the prompt, inherently sensor-drivendynamics of reactive control [17, 18]. To show the effectiveness of the approach thispaper presents details on the implementation of M-DEC on an experimental roboticplatform developed for indoor active surveillance.

The remainder of this paper is structured as follows. Section 2 surveys the relatedworks. Sections 3 and 4 overview the main assumptions and the overall architectureof the control system, respectively. Section 5 describes the discrete event model andthe supervisory control, Section 6 proposes a case study and Section 7 summarizesexperimental results. Finally Section 8 draws some conclusions.

2 Related Work

Modeling and control of discrete event systems (DES) have been studied for someyears in a variety of applications: manufacturing, process control, data acquisitionsystems, fault diagnosis, software engineering, transportation, and so on. Recentlythe extension of DES theory to mobile robotics is receiving increasing attention.Recent related works have proposed discrete event supervisory control to addressspecific issues such as behavior modulation [19] and fault accommodation [20]. In[21] event-based control of an industrial robotic workcell is also presented. Variousmodeling and control approaches have been proposed such as finite state machines[22], Petri Nets [23–25], vector DES [26, 27] and so on. Also the potential of theM-DEC in the area of robotic and sensor networks has been investigated. In [28], theM-DEC is used to control a mobile sensor network for which it is assumed that taskallocation is predetermined off-line by human planners using a priori information,while in [29] the framework is extended with an efficient task allocation algorithmcapable of dynamically determining task-to-resource assignment in real time.

In our work the M-DEC framework is used to control a surveillance mobile robot(SMR). Traditional approaches to mobile robot control derive a single control lawby constructing a complex behavior as a combination of concurrently executingelementary behaviors, avoiding the complexity of a monolithic control law andallowing the robot to perform tasks in the presence of uncertainties. In most casessuch systems use DES supervisory control at a low level, where simple reactivebehaviors are employed. The application of DES supervisory control to complex


problems is unusual, since behaviors don’t have an abstract representation thatwould allow them to be employed at a high level. In [30] the authors introduce theconcept of abstract behaviors which are used to specify one or more complex tasksin the form of a behavior network which can be automatically generated. Our workconceptually follows the same direction. The key difference is that in our approachthe M-DEC supervisory controller is in charge of monitoring only the complex tasksat the higher level. As a consequence it does not suffer of the problem of stateexplosion typical of finite state machines. Moreover the M-DEC is a versatile andintuitive tool.

3 Problem Statement

A Surveillance Mobile Robot (SMR) can be seen as a versatile unit equippedwith heterogeneous sensory and actuating devices. This mobile platform is ableto perform a variety of tasks, including measuring, observing, tracking and findingor manipulating objects. The objective of this paper is to design and implementactive environment surveillance operation (Fig. 1) using a single SMR equipped withdifferent physical sensors (laser range finder, sonar, RFID reader and antenna orvideo cameras).

The SMR must execute a set of missions. Each mission consists of a predeterminedset of atomic tasks, which may be subject to precedence constraints (the end of onetask may be a necessary prerequisite for the start of some other ones). Some missionsmay have a repetitive nature (e.g. nocturnal patrolling of an unattended indoorenvironment), other may be triggered by sensed events (fire, intrusion detectionor other emergency situations). Reactions to these events should be prompt andeffective, in the sense that the robot should have the ability to reorganize thesequence of missions when new events occur and/or when priorities change.

To execute each task, the SMR must perform a predetermined sequence ofactions. These primitive actions are the basic behaviors of the robot. Each behavior

Fig. 1 Decomposition ofthe active environmentsurveillance operationinto missions, tasks,and behaviors


runs until an event (either triggered by sensor data or by the supervisory controller)occurs. Two or more behaviors can be active simultaneously. In such a case, apredefined coordination algorithm is used to compute the appropriate command torobot actuators. Missions may be triggered at unknown times, while the number andtype of tasks composing a mission is known a priori. Further, we make the followingassumptions:

No preemption: Once started, a task interrupted by unexpected circumstancescannot be resumed and must be restarted from the beginning.

Mutual exclusion: The same behavior cannot be simultaneously associated to twoor more tasks.

Hold while waiting: To start a task, all the necessary behaviors must be available(i.e. not currently executed by other tasks).

Immediate release: Behaviors are released immediately after the task ends.

Following these assumptions, we propose the use of the M-DEC as a centralsupervisor to control the execution of surveillance missions as described above.

In the next section we provide a brief overview of the architecture which imple-ments the control of SMR, using a discrete event model of surveillance missions,controlled by the M-DEC.

4 Control Architecture Overview

A fully autonomous SMR needs a reactive control scheme capable of handlingcomplex situations in unstructured environments to efficiently perform assignedmissions. Due to the complexity of the surveillance domain and the large numberof tasks, the design of a robust control architecture is a challenging issue.

The surveillance scenario needs a very large number of cooperating behaviors(and additional sensor processing components) to perform complex tasks. By usinga DES supervisor to control all the involved behaviors, a large number of eventsand states have to be handled (see Fig. 2a). The reduction of the state space size,for example, could simplify the modeling and analysis problem, but the synthesis ofthe supervisory controller still remains a highly complex problem. In general such asimplification reduces the complexity of the off-line design phase, but the obtainedsystem is incomplete and as a consequence its computation burden increases duringthe on-line phase. This clearly accentuates the necessity of an abstraction from therobot state variables and pure sensor data processing. This abstraction requiresthe use of underlying continuous control and sensing modules which act as eventgenerators for DES. In this way the system is an hybrid system which containsboth continuous state dynamics and logical clauses. Such a technique utilizes thesupervisory control capabilities of DES framework, while reducing the complexity ofthe model by adding a reactive component to handle uncertainties and unpredictedeffects.

In contrast to the classical supervision of DES, our hybrid control framework con-sists of three main components: a continuous-state plant, the DES supervisory con-troller, and an interface (see Fig. 2b). Through the interface, the continuous controlelements act as generators of symbolic events for the DES controller, thereforeremoving the necessity of a continuous monitoring at the supervisory level. By


(b)(a)

Fig. 2 A comparison of robot control schemes. Traditional robot control approach using a low-level control performed by a DES (a). Hybrid DES control scheme for complex behaviors/tasksmanagement (b)

using these abstract events, the supervisor handles an abstract state space, withoutconsidering those parts of the system which are automatically handled within thecontinuous control elements. The described control policy can be easily integratedinto a three layer deliberative/reactive structure well known as robotic controlparadigm, in which the low level control is independent from the high level planningand reasoning processes [31–33].

Our SMR control scheme is based on a framework belonging to the hybridthree-layer system just described. In our approach a DES supervisory controllerautomatically coordinates the activation of a set of general reactive modules, thusreducing the amount of off-line specifications required to the system designer. Morespecifically, the control system can be decomposed into the continuous part andthe DES supervisory controller (DEC). The first handles a set of reactive behaviorswhich can be activated individually or in parallel and are used by a library of complextasks to reach a specific objective. More specifically, behaviors are simple primitiveactivities, such as goTo, avoidObstacle, goFoward, wallFollow, wander. The DECallows the system to move through a task-dependent sequence of behaviors that arekept active for a given amount of time until a prescribed plant event or controllerevent occurs.

As shown in Fig. 3, the SMR control architecture is composed of three mainmodules, nevertheless two modules can be viewed as containers of objects belongingto the lower control layer and the other one contains the supervisory controller andthe interface. All the modules are executed on a discrete-time basis: matrix and stateupdates, event detection and commands are all processed at the beginning of eachsample time. Each module is connected with the sensory input. This information is


Fig. 3 Overall architectureof the SMR control system

used in different ways: at the higher level, sensory data are converted into eventswhich are used by the supervisor to start or inhibit task executions; at the middlelevel, sensory data are used to monitor and control the execution of the task inprogress; finally, at the lower level, sensory inputs are used by the active behaviorsto perform the associated actions.

The controller module performs the control at the behavior level. This modulecontains all the behaviors needed to accomplish all possible SMR tasks. Multi-ple behaviors can be executed at the same time, if different tasks are activated.Each behavior computes an output for each actuator on the robot, and when multiplebehaviors are active at the same time, a predefined command fusion/cooperationalgorithm (e.g. subsumption [34], cooperative methods [35], fuzzy logic [36]) is usedto obtain the final control signal. This module interacts with the upper module in twoways: it receives the information about the activation and configuration of behaviorsto be performed (in the form of a list b a shown in Fig. 3) and it sends the informationabout the currently active behaviors by means of list b exe.

The executor module handles the execution of the tasks as commanded by theupper level; similarly to the controller, this module is considered as a continuous-statecontroller container. Each task can be viewed as a procedure to achieve a result. Atthe end of the task the completion flag and the result is sent to the upper level. Twodifferent classes of tasks are considered: Passive Tasks (PT) which mainly involve theanalysis of sensory inputs to generate information needed by other tasks (e.g. storedata, build a model of the environment, detect a face), and Active Tasks (AT), whichinvolve the execution of actions (e.g. move to a goal, find a tag, follow a people). For


the AT, the executor sends the corresponding commands to the controller by meansof b a. Finally, the executor sends, at every time sample, information about completedtasks using the list tc.

The supervisor module implements the high-level functions, monitoring themission execution and generating events through the evaluation of sensory data.More specifically this module controls the execution of missions in progress (e.g.guaranteeing the satisfaction of precedence constraints), sends the configurationinformation about the tasks that must be started (list ta) to the executor module andreceives the information about the completed tasks (tc). The supervisor performs itsfunction using a discrete-event model of the SMR and a conflict resolution strategy,which will be described in the following section.

5 M-DEC Supervisory Control

The matrix-based framework, provides a rigorous, yet intuitive mathematical frame-work to represent the dynamic evolution of system according to linguistic if–thenrules such as

Rule k: IF 〈 task( j)-missioni completed 〉 AND 〈 behaviorh available 〉THEN 〈 task(l)-missioni start 〉

Rules are converted in Boolean matrices, vectors and equations, which areupdated and processed at each controller time sample. The following subsectionspresent the system model formalism and the control scheme with the conflictresolution strategy.

5.1 Matrix-Based Discrete Event Model

The discrete event model is obtained using the M-DEC formalism in the same waydescribed in [28]. For brevity, here we provide a short introduction to the maincomponents of the model and the fundamental matrices and equations.

Let us consider n missions composed of an overall number of m tasks, and tbehaviors. The value of the logical conditions for the activations of q rules of a certainmission i composed of p tasks is summarized by the rule logical vector

xi = [xi(1) xi(2) . . . xi(q)

]T. (1)

An entry of “1” in the k-th position of vector xi denotes that rule k is currently fired(all the preconditions are true). The conditions of the tasks of each active missionare described by two vectors, the mission task-in-progress vector vi

IP, and the missiontask-completed vector vi:

viIP = [

viIP(1) vi

IP(2) . . . viIP(p)

]T, (2)

vi = [vi(1) vi(2) . . . vi(p)

]T. (3)

Each component of viIP (vi) is set to “1” when the corresponding task is in-progress

(completed), and “0” otherwise. In particular, vector vi represents a fundamental


precondition of many logical rules of the matrix-based model, while vector viIP is

mainly necessary to complete the characterization of each mission. Hereinafter, forbrevity, we will focus on vi only, and omit the further details about vi

IP and itsdynamical update rules.

Finally, let us indicate with ui and yi, the Boolean input and output vectors ofmission i, respectively. The generic element of vector ui is set to “1” when thetriggering event (timer alarm, movement detection, intrusion, etc.) of mission ihas occurred, and the generic element of vector yi is set to “1” when mission i iscompleted.

In order to model n simultaneously missions we define the global rule logicalvector

x = [(x1)T (x2)T . . . (xn)T ]T

, (4)

obtained by stacking the n column rule logical vectors. Similarly, we can define:the global task vector

v = [(v1)T (v2)T . . . (vn)T ]T

, (5)

the global input vector

u = [(u1)T (u2)T . . . (un)T ]T

, (6)

and the global output vector

y = [(y1)T (y2)T . . . (yn)T ]T

. (7)

Moreover, let us define the Boolean global behavior vector b having t elements,where an entry of “1” represents the behavior currently available:

b = [ b 1 b 2 . . . b t ]T , (8)

Vectors v, u, y, and x have a dynamic size depending on the number of missionsthat the robot has to accomplish at a given time. In particular, if a new mission isassigned to the robot, the vectors are resized accordingly, introducing new elementswith appropriate values (e.g., the vector u is updated adding a new element setto “1”).

All of these vectors provide a static description of the conditions of the SMR ata given time. In the following, we illustrate the update laws defining the evolutionof the system variables over time. As mentioned, the model is run in discrete-time,i.e. the effects of events are computed at the first sample time after their occurrence.When no event occurs between two sample times, all the system variables remainunchanged. Hereafter, except where noted differently, all matrix operations aredefined in the or/and algebra, where ∨ denotes logical OR, ∧ denotes logical AND,⊕ denotes logical XOR, and overbar indicates negation (see [14] for further details).

Before the description of the update rules, it is convenient to introduce somefundamental matrices. Let Fi

v (q × p) be the task sequencing matrix for an individualmission i. This matrix has element (k, j) set to “1” if the completion of j-th task ofvector vi is a necessary prerequisite for k-th rule in the rule logical vector xi. Similarly,let Fi

b (q × t) be the behavior requirements matrix having element (k, h) set to “1” if


the condition of h-th behavior is an immediate prerequisite for k-th rule in the rulelogical vector xi. Moreover, let Fi

u (q × z), where z is the size of vector ui, be the inputmatrix, having element (k, l) set to “1” if the occurrence of input l-th is an immediateprerequisite for k-th rule in the rule logical vector xi.

As for the vectors of variables, the matrices related to the list of n missionscan be easily obtained by either stacking or concatenating together the matrixblocks corresponding to each individual mission. As an example, we report the tasksequencing matrix Fv for n missions

Fv =

⎡

⎢⎢⎢⎢⎣

F1v

. . .

Fiv

. . .

Fnv

⎤

⎥⎥⎥⎥⎦

(9)

The updates of vectors are computed according to the equations that will follow inthe sequel.

After a task starts the corresponding behaviors becomes busy and the correspond-ing element of vector b is set to “0”:

b = b ⊕ (Fb )T ∧ x (10)

At the end of a task, the controller will command the release of the correspondingbehaviors and the SMR will feed the “behavior release” input, which is directly usedin the model to reset the value of b to the idle (“1”) condition.

The update of vector v occurs in two different cases. The first one is when theM-DEC model receives the “ j-th task of i-th completed mission” message fromthe executor module. In such a case, the corresponding element of v is set to one(vi( j) = 1). The second case occurs when the vector element, corresponding topreviously completed tasks, is set to “0”, using the following equation:

v = v ⊕ (Fv)T ∧ x (11)

Finally, mission inputs and outputs vectors are updated with the followingequations:

u = Su ∧ x (12)

y = Sy ∧ x (13)

where Su (w × q), where w is the size of vector u, is the input events matrix, havingelement (i, k) set to “1” if the activation of the k-th rule in the vector x determinesthe activation of mission i, and Sy (o × q), where o is the size of vector y, is the outputmatrix, having element (i, k) set to “1” if the activation of k-th rule determines thecompletion of mission i.

5.2 Matrix-Based Discrete Event Control

The main function of the M-DEC is to determine which rules must be fired, whichtasks must be started, and which behaviors are in charge of performing the tasks.


These functions are processed by means of two different sets of logical equations, onefor checking the conditions for the activation of a generic rule of a generic mission,and one for defining the consequent supervisor outputs. The updated value of therule logical vector is computed with the following controller state equation:

x = (Fv ∧ v) ∨ (Fb ∧ b) ∨ (Fu ∧ u) ∨ (Fud ∧ ud) (14)

Matrix Fud in Eq. 14 is called the SMR conflict resolution matrix and is used tomodel the influence of control input vector ud on the rule vector x. In particular, anentry of “1” (“0”) in ud disinhibits (inhibits) the activation of the corresponding task.The vector ud can be seen as one controllable input of the SMR. Depending on theway one selects the strategy to assign the control vector ud, task sequencing decisionscan be implemented.

On the ground of the current value of the rule logical vector x, the controllerdetermines which tasks to start and which behaviors to release by means of the matrixcontroller output equations. In particular, the command of a task start is performedby means of the task start vector vs (having the same structure of vectors v and vIP)using the following Boolean matrix equation:

vs = Sv ∧ x (15)

where Sv (m × q) is the task start matrix and has element ( j, k) set to “1” if the k-thrule in vector x triggers the start command for the j-th task in vector vs. Similarly, thebehavior release command is performed by means of the Boolean behavior releasevector br using the following matrix equation:

br = Sb ∧ x (16)

in which Sb (t × q) is the behavior release matrix, having element (h, k) set to “1”if the k-th rule in vector x triggers the release command for the h-th behavior ofthe SMR. Therefore, vector br has t elements, each set to “1” when the controllercommands the release of the corresponding behavior.

Fig. 4 Supervisor block diagram


As illustrated in Fig. 4, at each sample time, the supervisor activity can bedescribed as follows: new input events, completed tasks and released behaviors arereceived by the M-DEC Discrete Event Model block, then vectors v, b, u, and x aresent to the M-DEC Supervisory Controller block which determines the rules thatmust be fired, the tasks that must be started, and the behaviors for which a releasecommand must be sent to the lower level of the SMR.

6 A Case Study: Environment Monitoring for Object and People Detection

In order to illustrate the intuitive, modular structure of the M-DEC supervisorycontrol of the SMR, this section discusses a simple example.

Let us consider a SMR equipped with three sensors (a laser rangefinder, a RFIDsystem and a monocular camera), which has to perform the surveillance of an indoorenvironment (the map of the considered environment is assumed to be known inadvance). Assume that the SMR has to periodically visit a set of predefined goalpoints. The navigation between the goal points is performed using the known map,laser rangefinder and odometry. Periodically or when a large positioning error isdetected, the SMR must execute a self-localization procedure based on RFID tagsand visual landmarks spread in the environment. Once a goal point is reached, theSMR has to examine the scene looking for removed or abandoned objects. If thisevent is detected, the SMR has to issue an alert and continue to the next goal point.Moreover, the SMR has to detect the intrusion of humans in the environment, and ifthis event occurs, it has to follow the human until he leaves the area.

6.1 Mission Programming

According to the M-DEC notation introduced above, the SMR has three missions:RFID Global Localization (self-locating using the RFID and visual landmarks),Patrolling (the SMR visits the sequence of goal-points looking for scene changes),and People Following (the SMR follows intruders). Implementing the M-DEC con-sists of three different steps. First, the fundamental sets of inputs, outputs, tasks andbehaviors have to be defined. In this example, we consider three main events, ninetasks, and four behaviors, all listed and described in Tables 1, 2, and 3, respectively.The association between tasks and behaviors is listed in Table 4. The behavior andtask vectors are the following:

b = [ b1, b2, b3, b4 ] (17)

v = [ t1, t2, t3, t4, t5, t6, t7, t8, t9 ] (18)

The second step is defining the if-then rules describing the system constraints andsupervisory control strategy (reported in Tables 5, 6, and 7). In the construction of

Table 1 Events Event Description

u1 Global position erroru2 Start patrollingu3 Person detection


Table 2 Missions and tasks

Name Notation Description

RFID global localization m1

FindRFIDTag t1 The robot wanders until a specific RFID tag is detectedLocalizeRFIDTag t2 The robot scans the environment to estimate the RFID

tag positionMoveToGoal t3 The robot moves to a goal point on the mapLocalizeRobotVision t4 The robot localize itself using a visual landmark

Patrolling m2

PathPlan t5 The robot computes the path to a goal in the environmentMoveToGoal t6 The robot moves to a goal point on the mapDetectObjectsLaser t7 The robot detects objects using the laser range finderDetectObjectsVision t8 The robot detects objects using the monocular camera

People following m3

PeopleFollowing t9 The robot follows the nearest person

the rule bases particular attention has to be devoted to the definition of consecutivetasks that use the same behavior. If the tasks are not interdependent, before startingthe new consecutive task, the DEC releases the corresponding behavior and makessure that no other missions are waiting for it. If after a predetermined period of timeno other missions request that behavior, the previous mission can continue.

Then, the rules are translated into Boolean matrix notation, which is better suitedfor mathematical analysis and computer implementation. For example, consideringthe rule-base of mission 1 (Table 5), the first blocks of Fv and Fb can be easily writtenas illustrated in Fig. 5 (which also includes the block of the other missions obtainedwith an identical procedure). In particular, Fv(k, j) is “1” if the completion of thetask j is a precondition for the rule k and Fb (k, j) is “1” if behavior j is required toexecute the task associated to rule k.

The Sv matrix (Fig. 6a) is built considering which tasks should be executed aftera rule is fired. For example, for mission 2 (see Table 6), when rule x8 is fired,the DetectObjectsVision (task t7) and the DetectObjectsLaser (task t8) are started.Accordingly, the elements in position (7, 8) and (8, 8) of Sv are equal to “1”.

The Sb matrix (Fig. 6b) is built considering that Sb (h, k) is “1” if behavior h has tobe released after rule k has been fired. For example, since AvoidObstacle (behaviorb1) has to be released when rules 2, 4, 8, and 11 are fired, we have entries of “1” inpositions (1, 2), (1, 4), (1, 8), and (1, 11).

Thus, the matrix formulation of the overall monitoring operation is easily obtainedby stacking together the matrices of mission 1, mission 2 and mission 3 as blocks ofthe global matrices (as can be seen in Figs. 5 and 6).

Table 3 Available behaviors Name Notation Description

AvoidObstacle b1 The robot avoids obstacles usingthe Laser sensor

GoTo b2 The robot goes to a position inthe environment

Wander b3 The robot wanders randomly inthe environment

LocalizeRFID b4 The robot wanders until a RFIDtag is detected


Table 4 Task/behaviorsassociation

Task name Used behavior

DetectObjectLaser −DetectObjectVision −FindRFIDTag b1, b3

LocalizeRFIDTag b4

LocalizeRobotVision −MoveToGoal b1, b2

PathPlan −PeopleFollowing b1, b2

Table 5 Mission 1—rule base Notation Rule description

x1 IF 〈 u1 occurs AND b1, b3 available 〉THEN 〈 start t1 〉

x2 IF 〈 t1 completed AND b4 available 〉THEN 〈 start t2 AND release b1, b3 〉

x3 IF 〈 t2 completed AND b1, b2 available 〉THEN 〈 start t3 AND release b4 〉

x4 IF 〈 t3 completed 〉 THEN 〈 start t4AND release b1, b2 〉

x5 IF 〈 t4 completed 〉 THEN 〈m1 accomplished〉


x6 IF 〈 u2 occurs 〉 THEN 〈 start t5 〉x7 IF 〈 t5 completed AND b1, b2 available 〉

THEN 〈 start t6 〉x8 IF 〈 t6 completed 〉 THEN 〈 start t7, t8

AND release b1, b2 〉x9 IF 〈 t7, t8 completed 〉 THEN 〈m2 accomplished〉


x10 IF 〈 u3 occurs AND b1, b2 available 〉THEN 〈 start t9 〉

x11 IF 〈 t9 completed 〉 THEN 〈m3 accomplishedAND release b1, b2〉


Fig. 5 Implementation ofmissions. (a) Task sequencingblock-matrix Fv, (b) behaviorrequirements block-matrix Fb

(a)

(b)

6.2 Implementation of Conflict Resolution Strategy

The conflict resolution matrix Fud (Fig. 6c) has as many columns as the number oftasks sharing one or more behaviors. Since these tasks may generate conflicts (e.g.two tasks may need the same GoTo behavior but heading to two different goal-points) the element (k, j) of Fud is set to “1” if completion of shared task j is animmediate prerequisite for the activation of the k-th rule in vector x. Then, an entryof “1” in position j in the conflict-resolution vector ud, determines the inhibitionof the k-th rule in vector x. It results that, depending on the way one selects theconflict-resolution strategy to generate vector ud, different sequencing strategies canbe implemented.


Fig. 6 Implementation ofmissions. (a) Task startblock-matrix Sv, (b) behaviorrelease block-matrix Sb ,(c) conflict resolutionblock-matrix Fud

(a)

(b)

(c)

In order to take into account the dynamical priorities among multiple missions, wederive the global conflict-resolution matrix Fud with the following procedure, derivedfrom [28]. After assigning a priority order to each mission, we calculate, for everyshared behavior h and every mission i, a matrix Fi

ud(bh). This matrix is composed


by a number of columns equal to the number of occurrences of “1” appearing inthe h-th column of Fb for the mission i. The number of rows is the number of rulesassociated to the mission i, as in matrix Fb . For each column there must be just a “1”for the rule as in the matrix Fb , all other elements must be “0”. Then, we constructthe global conflict-resolution matrix of behavior bh, [Fud(bh)], inserting each Fi

ud(bh)

matrix in position (i, f ), where f is the priority index of the mission i. The result isthe overall matrix

Fud = [Fud(b1) Fud(b2) . . . Fud(bh) . . . Fud(bt)

](19)

that contains the conflict-resolution information needed for dispatching sharedbehaviors in multiple missions for the SMR.

An analysis of the matrix Fb (see Fig. 5c), for the mission 1, reveals that b1 andb2 are shared behaviors (due to multiple “1” in the corresponding column of the firstblock, on top, of Fb ), therefore we need to specify just F1

ud(b1) and F1

ud(b2), the first

and the second block on top, respectively, in the global Fud matrix (Fig. 6c). In thesame way, the set of matrices for the shared behaviors b1 and b2, relative to mission2 and mission 3, can be built as follow:

Fud =

⎡

⎢⎢⎢⎢⎣

F1ud

(b1) F1ud

(b2)

F2ud

(b1) F2ud

(b2)

F3ud

(b1) F3ud

(b2)

⎤

⎥⎥⎥⎥⎦

(20)

6.3 Execution of the Missions

A dynamic simulation of the example described above can be easily obtained byimplementing the hybrid control scheme and the above vectors, matrices, andequations within any general-purpose programming environment (e.g. Matlab [14]).In this subsection we present the results of a simulation campaign of the threemissions described above, to prove the reactivity of event-driven control and theefficiency of conflict resolution strategy. First, we show a single simulation withrandomly generated events. Figure 7 reports the evolution of missions, the utilizationtime trace of the behaviors, and the execution time trace of the tasks. In these timetraces, active behaviors and tasks in progress are denoted by high level, whereas idlebehavior and tasks not in progress are denoted by a low level.

At time instant 2, the event u2 (start patrolling) occurs, and mission 2 (Patrolling)is triggered. Then task t5, the first task of mission 2 (see Table 6), can start. At timeinstant 10, the event u1 (global position error) occurs, and mission 1 (RFID GlobalLocalization) is triggered, but the first task of this mission, t1 cannot start becausethe behavior b1 (AvoidObstacle), is already assigned to mission 2 for the executionof task t6. When the behavior b1 is idle, at the instant 12, t6 is completed, then itreleases the behavior that can be assigned to task t1. Mission 1 can start (actuallyat the instant 15), while mission 2 can be successfully terminated since there are noother conflicts between missions.

Since mission 3 (People Following) has a lower priority, the event u3 (persondetected) occurs at instant 28, the mission is temporarily kept waiting becausebehaviors b1 (AvoidObstacle) and b2 (GoTo) are assigned to mission 1 for theexecution of task t3 (MoveToGoal). At time instant 37, b1 and b2 are assigned to


Fig. 7 Execution of missions: utilization time trace of tasks and behaviors. The circles indicatethe instant time when missions and tasks start. Notice that missions are not really active until thetriggering of relative tasks because of conflicts

mission 3, which can actually start and then mission 1 ends with the execution of lasttask t4 (LocalizeRobotVision). Finally, mission 3 can be successfully terminated.

To prove the efficiency of the SMR we show a second simulation case with adifferent event sequence (see Fig. 8). The mission priority order is changed withrespect to that of the previous simulation. In this second case we simulate a nocturnalpatrolling of the environment, when the SMR has to monitor an area where peopleis not allowed. By this assumption mission 3 (People Following) has the highestpriority, mission 1 (RFID Global Localization) the lower, mission 2 (Patrolling) isin the middle.

Fig. 8 Execution of missions: utilization time trace of tasks and behaviors. The circles indicatethe instant time when missions and tasks start. Notice that missions are not really active until thetriggering of relative tasks because of conflicts. The square indicates the end of task t5. Task t6 cannotstart until task t9 ends


The first mission that starts is mission 2 (Patrolling), the robot starts to monitorthe environment. At time instant 4 event u3 (person detected) occurs. Since mission3 has the highest priority, its first task is triggered and mission 2 is kept waiting.Also in this case, the M-DEC solves the conflict: task t6 and task t9 require both b1

(AvoidObstacle) and b2 (GoTo) behaviors, then task t6, associated with the missionwith the lower priority is postponed. Task t9, associated with the mission with thehigher priority, starts first (as shown in Fig. 8). Thus, task t6 can start only when taskt9 ends.

During the execution of mission 2, at time instant 22, the event u1 (global positionerror) occurs and mission 1 (RFID Global Localization) is triggered. Behaviors b1

(AvoidObstacle) and b3 (Wander), required by the first task t1 of mission 1, cannotstart, according to the priority, since the behavior b1 is already assigned to mission 2.When behavior b1 is idle, t6 is completed (at instant 28), then it releases the behaviorthat can be assigned to task t1 and mission 1 can start (actually at the instant 29).

From the time traces in Figs. 7 and 8, it is interesting to note that wheneverpossible, the missions are executed simultaneously, and the shared behaviors arealternatively assigned to the three missions.

To test the performance of the proposed M-DEC task allocation in case of conflictresolution, we performed 30 different simulations with the same setup of the lastsimulation described above. Also in these cases the events are generated randomly.As an evaluation parameter we consider the makespan (the overall number of timesamples needed to accomplish all missions). To compare the results we consider, asa ground truth, a preliminary simulation in which all missions are triggered manuallyby an operator to avoid conflicts between tasks and to obtain the best execution ofthe three mission. The resulting makespan of this simulation is 54 time samples. Afterthat, 30 simulations are performed. The resulting makespan of these simulations isdepicted in Fig. 9. The results show that the M-DEC handles the conflict in a efficientway, in fact the mean makespan of these simulation is 55 time samples, comparablewith the result obtained by the human operator. Moreover the makespan in theworst case (60 time samples), and in the best case (53 time samples), demonstratethe efficiency of the M-DEC in both conflict resolution and task allocation problem.

Fig. 9 Makespan of 30 simulations used for performance analysis


The matrix-based control system described above can be also used in a straight-forward way to implement the actual control system for the hardware SMR platform,as illustrated in the next section, where real experiments will be shown.

7 Experimental Results

7.1 Hardware and Software Platform

The hardware platform developed at the Institute of Intelligent Systems for Au-tomation of the National Research Council in Bari, Italy, consists of a PeopleBotmobile robot by MobileRobots Inc (Fig. 10). The robot is equipped with sonarand infrared sensors, a SICK LMS-200 laser range finder, an AVT Marlin IEEE1394 FireWire monocular camera, and an RFID device. The latter consists of twocircularly polarized antennas and a reader. The software system is distributed onthree processing units, the robot embedded PC and two additional laptops: an IntelPentium M @ 1.6 GHz used for the vision and RFID signal processing on boardthe robot and an Intel Pentium M @ 1.5 GHz used for application control and userinterface.

The developed software system, running on both laptops and the PC, is devel-oped under GNU/Linux OS, using an open source robotic development frame-work, named MARIE [37]. The software control architecture is implemented asdescribed in Section 3. Missions and tasks dependencies are defined, using XMLsyntax (World Wide Web Consortium—Extensible Markup Language (XML)—http://www.w3.org/XML/), in a configuration file. Using this file the mission-parsertransforms if-then rules into the matrices of the discrete event model (Figs. 5 and 6).Tasks and behaviors are implemented using state-of-art signal processing and controlalgorithms. More specifically, the navigation package is based on CARMEN Navi-gation Toolkit [38], the detection of abandoned or removed objects is based on an

Fig. 10 The robotic platform

http://www.w3.org/XML/


image-processing algorithm [39] and a laser based algorithm [40], the localizationof the robot is performed using a method based on RFID sensor [41], and peoplefollowing is implemented using the laser range finder [42].

7.2 Real World Experiments

Differently from the simple experimental setup of simulations shown in the pre-vious section, in the real world experiments the SMR surveillance capabilities are

Table 8 Missions and tasks

Name Notation Description

RFID global localization m1

FindRFIDTag t1 The robot wanders until a specific RFID tag is detectedLocalizeRFIDTag t2 The robot orients itself toward the RFID tagLocalizeRobotVision t3 The robot localizes itself using a visual landmark

Environment learning m2

MoveToGoal t4 The robot moves to a goal point on the mapStoreData (Laser) t5 The robot stores laser data in a databaseStoreData (Vision) t6 The robot stores image data in a databaseMoveToGoal t7 The robot moves to a goal point on the mapStoreData (Vision) t8 The robot stores image data in a databaseMoveToGoal t9 The robot moves to a goal point on the mapStoreData (Laser) t10 The robot stores laser data in a databaseStoreData (Vision) t11 The robot stores image data in a databaseMoveToGoal t12 The robot moves to a goal point on the mapStoreData (Laser) t13 The robot stores laser data in a databaseStoreData (Vision) t14 The robot stores image data in a databaseMoveToGoal t15 The robot moves to a goal point on the mapStoreData (Vision) t16 The robot stores image data in a database

Patrolling m3

MoveToGoal t17 The robot moves to a goal point on the mapDetectObjectsLaser t18 The robot detects abandoned objects using laser dataDetectObjectsVision t19 The robot detects abandoned objects using imagesMoveToGoal t20 The robot moves to a goal point on the mapLocalizeRFIDTag t21 The robot orients itself toward the RFID tagDetectObjectsVision t22 The robot detects removed objects using imagesMoveToGoal t23 The robot moves to a goal point on the mapDetectObjectsLaser t24 The robot detects abandoned objects using laser dataDetectObjectsVision t25 The robot detects abandoned objects using imagesMoveToGoal t26 The robot moves to a goal point on the mapDetectObjectsLaser t27 The robot detects abandoned objects using laser dataDetectObjectsVision t28 The robot detects abandoned objects using imagesMoveToGoal t29 The robot moves to a goal point on the mapLocalizeRFIDTag t30 The robot orients itself toward the RFID tagDetectObjectsVision t31 The robot detects removed objects using images

People recognition m4

PeopleFollowing t32 The robot follows the nearest personTalk t33 The robot speaks a sentenceDetectFaceVision t34 The robot detects a face and compares it whit a database

Map update m5

MapUpdate t35 The robot updates the map using laser data


extended. The available events, tasks, and behaviors are implemented consideringthe real-world situations. In particular each mission is defined as a sequence of taskswhich depend by the real environment and by the surveillance requirements. Theseconcepts will be better clarified in the following.

Five events are available: global position error (u1), start environment learning(u2), start patrolling (u3), person detection (u4) and start update map (u5). The de-veloped missions are: RFID Global Localization, Environment Learning, Patrolling,People Recognition and Map Update. The name of each mission explains by itselfwhich is the role of the mission. Notice that some new missions have been consideredwith respect to the simulation case (see Section 6), due to the requirements of realworld experimentation. Some others, instead, are similar to those of the simulatedexperiment.

Table 8 lists the described missions, giving for each one the sequence of tasks thathave to be run to complete the mission. Notice that the sequence of tasks of eachmission depends on the real environment in which the SMR operates. For example,in mission Patrolling the SMR has to visit five goal positions in the environmentin order to check if there are abandoned or removed objects. Therefore tasksMoveToGoal, DetectObjectsLaser and DetectObjectsVision are triggered five timesin the sequence. Notice that each task has a new identification label, even if it isthe same. This is due to the abstraction ability of the M-DEC, in fact the M-DECsupervisory controller abstracts from the meaning of each single task. Actually ittriggers each task in the sequence depending on the happening events, the rules andeventual conflicts among tasks and behaviors.

In the real experiment behaviors are the same of Table 3, with the differenceof the AvoidObstacle that can be performed either by using the laser range finder(AvoidObstacleLaser) or the sonar sensors (AvoidObstacleSonar). The complete listof behaviors and their description are shown in Table 9. As described in Section 4behaviors can be coordinated by using a variety of reactive approaches, in our workbehaviors are coordinated using the subsumption approach [34] in the controllermodule.

As described in Section 6 all information is codified as Boolean vectors andmatrices. In the real case of experimentation, the size of vectors and matricesincrease: e.g. matrix Fv has 35 columns (tasks) and 40 rows (rules), Fb has fivecolumns (behaviors) and 40 rows. This is typical of a real world implementation, how-ever the M-DEC formalism allows the handling of huge quantities of events, rules,

Table 9 Available behaviors Name Notation Description

AvoidObstacleLaser b1 The robot avoids obstaclesusing the laser sensor

AvoidObstacleSonar b2 The robot avoids obstaclesusing the sonar sensor

GoTo b3 The robot goes to a positionin the environment

Wander b4 The robot wanders randomlyin the environment

LocalizeRFID b5 The robot wanders until aRFID tag is detected


Table 10 Task/behaviorsassociation

Task name Used behavior

DetectFaceVision −DetectObjectLaser −DetectObjectVision −FindRFIDTag b1, b2, b4

LocalizeRFIDTag b5

LocalizeRobotVision −MapUpdate b1, b2, b4

MoveToGoal b1, b2, b3

PeopleFollowing b1, b3

StoreData −Talk −

tasks and behaviors in an efficient way. For brevity the rules are not presented here,but they can be easily deducted from Tables 8, 9, 10 and from the following description.

For the sake of clarity, in Fig. 11, the configuration of the operating environmentis depicted. This figure shows the map of the area under surveillance, the position ofthe goal-points for scene analysis and object detection, and the position of the RFIDtags and visual landmarks for global localization.

Fig. 11 Configuration of themonitored environment: goalpoints (G1, G2, G3, G4, G5),RFID tagged objects (O1, O2)and RFID-VISUALlandmarks (L1, L2, L3, L4)


During the experimental phase, mission m2 (Environment Learning) and missionm5 (Map Update) are preliminarily activated. In this phase the robot explores theenvironment to store all data useful for the surveillance activity. In Fig. 12a, therobot is performing the Map Update mission. As shown in Table 8, this missionconsists of only one task. This case emphasises the potential of the hybrid controlarchitecture because the M-DEC supervisor starts task t35 (MapUpdate) delegatingthe control of task execution to the lower modules. The control of behaviors b1,b2, b4, activated by this task, is entrusted to the controller module which performsa low level control coordinating the behaviors. When the task is completed or anevent occurs the M-DEC will take the control of the overall system. An exampleof this situation is illustrated in Fig. 12b. During the MapUpdate task, event u2

(start environment learning) occurs, and the M-DEC starts mission m2 and suspendsmission m5, according to the priority levels, and triggers task t4 first. During theexecution of this mission the robot traces the goal sequence storing laser and imagedata for each those goals (G1, G3, G4) where abandoned objects must be searchedand storing only image data for those goals (G2, G5) where an RFID tagged objectmust be checked.

Once the environment has been explored, the robot can perform the surveillanceof the assigned area. The first mission that starts is mission m3 (Patrolling). Figure 13ashows the SMR while reaches the first goal (G1). After reaching the goal, tasks t18

and t19 are performed searching for abandoned objects. As shown in Fig. 14a, theSMR detects a new object in the environment (an abandoned bag). In this case an

(a) (b)

Fig. 12 Real-world experiments execution: The robot performs the MapUpdate mission, wanderingin the environment (a). During this mission the Environment Learning mission starts, then the robotstarts to trace the goal sequence (b)


(a) (b)

(c) (d)

Fig. 13 Real-world experiments execution: The robot reaches the first goal and founds a new objectin the environment (a). The robot reaches the goal G2 searching for a tagged object (b). The robotreaches the third goal (c). During the path following toward the goal G4 a global position error eventoccurs, then the robot starts the localization procedure using RFID and visual landmark (d)


(a) (b)

Fig. 14 Real-world experiments execution: The robot founds a new object in the environment (a).During the Patrolling mission a global position error event occurs, then the robot starts thelocalization procedure (b)

alarm message is generated. In Fig. 13b the SMR has reached goal G2 to check if theRFID tag is in the correct position. After that, task t22 starts to check if the monitoredobject is the correct object associated to the tag ID, then the robot goes toward goalG3. After the monitoring of the area close to this goal, where no abandoned objectshave been detected, the robot starts task t26 (Fig. 13c). During the path toward goalG4 a global position error event occurs (u1). Thus M-DEC stops the current task,suspending the current mission (m3), in order to start the first task t1 of mission m1

to find an RFID tag in the environment. In Fig. 13d, the robot performs a shortwandering, avoiding obstacles, to find the tag and to start the localization procedureusing RFID and camera sensors (Fig. 14b). When the RFID Global Localization

(a) (b) (c)

Fig. 15 Real-world experiments execution: The robot reaches the goal G4 (a). During the pathfollowing toward the goal G5 a person is detected and mission m4 starts (b). When mission PeopleRecognition is completed, the robot terminate successfully the pending mission Patrolling, goingtowards goal G5 (c)


mission (m1) is completed, the suspended mission (m3) starts again activating taskt26 (MoveToGoal) to go to G4 (Fig. 15a). Notice that, as described in Section 3 thistask cannot be resumed and must be restarted from the beginning (no preemptionassumption). While the SMR goes toward goal G5, it detects the presence of a person(event u4), then People Recognition mission (m3) must be activated. Since the priorityof this mission is higher than the Patrolling (m3) one the SMR approaches the person,suspending mission m3. Once the person has been reached the SMR checks if he isan authorized person or not (task t34) (Fig. 15b). Finally, suspended mission (m3)starts again until the final goal (G5) is reached and the detection objects tasks arecompleted (Fig. 15c).

Some final considerations must be done observing the performance of the M-DECduring the real world experiment. First of all each mission is activated or stoppedcorrectly depending on the occurring events. Suspended missions and in particularsuspended tasks are resumed at the suitable instant permitting the correct ending ofeach mission. Moreover due to the preemption assumption the surveillance activity isexhaustively carried out. In fact since each suspended task starts from the beginningand not from where it was stopped or as it was completed, the overall executionof missions is guaranteed without gaps. This is furthermore advantageous if somechange in the environment occurs. Moreover the SMR does not get stuck due to theconflict resolution strategy during the surveillance activity. Finally, task sequencingallows the SMR to carry out its missions safely and efficiently due to the low levelreactivity of behaviors in the controller module.

8 Conclusions

This paper presented a control system for an autonomous robot for the surveillanceof indoor environments. The proposed control architecture integrates, in the samematrix-based formalism, a discrete event model, a supervisory controller and abehavior-based controller. This control system makes the robot able to executeautonomously multiple heterogeneous missions in dynamic environments. In particu-lar, the M-DEC is able to model the sequential constraints of the tasks, to define thepriority among missions and to dynamically select the most appropriate behaviorsin any given circumstance. This paper shows that the M-DEC allows one to easilyperform a “simulate and experiment” approach, with noticeable benefits in terms ofcost, time and performance.

The M-DEC proposed in this paper is fully centralized since it uses a singlerobot only. Following current trends in multi-robot systems, the research activitiesin progress are focused on the distribution of the M-DEC controller across a set ofindependent robots to obtain a multi-agent surveillance system.

Acknowledgements The authors wish to thank the associate editor and the anonymous review-ers for their valuable suggestions, which contributed to significantly improve the quality of thismanuscript.

References

1. Hu, W., Tan, T., Wang, L., Maybank, S.: A survey on visual surveillance of object motion andbehaviors. IEEE Trans. Syst. Man Cybern. Part C Appl. Rev. 34(3), 334–352 (2004)


2. Valera, M., Velastin, S.A.: Intelligent distributed surveillance systems: a review. IEE Proc. Vis.Image Signal Process. 152(2), 192–204 (2005)

3. Everett, H.R.: Robotic security systems. IEEE Instrum. Meas. Mag. 6(4), 30–34 (2003)4. DehuaI, Z., Gang, X., Jinming, Z., Li, L.: Development of a mobile platform for secu-

rity robot. In: Proceedings of IEEE International Conference on Automation and Logistics,pp. 1262–1267 (2007)

5. Burgard, W., Moors, M., Fox, D., Reid, S., Thrun, S.: Collaborative multi-robot exploration.In: Proceedings of IEEE International Conference on Artificial Intelligence, pp. 852–858 (2000)

6. Kwok, K.S., Driessen, B.J., Phillips, C.A., Tovey, C.A.: Analyzing the multiple-target-multiple-agent scenario using optimal assignment algorithms. J. Intell. Robot. Syst. 35(1), 111–122 (2002)

7. Grace, J., Baillieul, J.: Stochastic strategies for autonomous robotic surveillance. In: Proceedingsof IEEE Conference on Decision and Control, pp. 2200–2205 (2005)

8. Roman-Ballesteros, I., Pfeiffer, C.F.A.: Framework for cooperative multi-robot surveillancetasks. In: Proceedings of Electronics, Robotics and Automotive Mechanics Conference, vol. 2,pp. 163–170 (2006)

9. Vig, L., Adams, J.A.: Coalition formation: from software agents to robots. J. Intell. Robot. Syst.50(1), 85–118 (2007)

10. Mireles, J., Lewis, F.: Deadlock analysis and routing on free-choice multipart reentrant flowlines using a matrix-based discrete event controller. In: Proceedings of the IEEE InternationalConference on Decision and Control, vol. 1, pp. 793–798 (2002)

11. Mireles, J., Lewis, F.: Intelligent material handling: development and implementation of a matrix-based discrete event controller. IEEE Trans. Ind. Electron. 48(6), 1087–1097 (2001)

12. Volpe, R., Nesnas, I., Estlin, T., Mutz, D., Petras, R., Das, H.: The CLARAty architecturefor robotic autonomy. In: Proceedings of the IEEE Aerospace Conference, Big Sky, Montana(2001)

13. Mes, M., van der Heijden, M., van Hillegersberg, J.: Design choices for agent-based control ofAGVs in the dough making process. Decis. Support Syst. 44(4), 983–999 (2008)

14. Tacconi, D., Lewis, F.: A new matrix model for discrete event systems: application to simulation.IEEE Control Syst. Mag. 17(5), 62–71 (1997)

15. Bogdan, S., Lewis, F.L., Kovacic, Z., Mireles, J.J.: Manufacturing Systems Control Design:A Matrix based Approach. Springer (2006)

16. Giordano, V., Zhang, J.B., Naso, D., Lewis, F.: Integrated supervisory and operational con-trol of a warehouse with a matrix-based approach. IEEE Trans. Autom. Sci. Eng. 5(1), 53–70(2008)

17. Koutsoukos, X.D., Antsaklis, P.J., Stiver, J.A., Lemmon, M.D.: Supervisory control of hybridsystems. Proc. IEEE 88(7), 1026–1049 (2000)

18. Fierro, R., Lewis, F.L.: A framework for hybrid control design. IEEE Trans. Syst. Man Cybern.Part A 27(6), 765–773 (1997)

19. Huq, R., Mann, G.K.I., Gosine, R.G. : Behavior-modulation technique in mobile robotics usingfuzzy discrete event system. IEEE Trans. Robot. 22(5), 903–916 (2006)

20. Ji, M., Sarkar, N.: Supervisory fault adaptive control of a mobile robot and its application insensor-fault accommodation. IEEE Trans. Robot. 23(1), 174–178 (2007)

21. Brink, K., Olsson, M., Bolmsj, G.: Increased autonomy in industrial robotic systems: a frame-work. J. Intell. Robot. Syst. 19(4), 357–373 (1997)

22. Chen, Y.L., Ling F.: Modeling of discrete event systems using finite state machines with para-meters. In: Proceedings of IEEE International Conference on Control Applications, Anchorage,Alaska (2000)

23. Ma, L., Hasegawa, K., Sugisawa, M., Takahashi, K., Miyagi, P.E., Santos Filho, D.J.: On resourcearc for petri net modelling of complex resource sharing system. J. Intell. Robot. Syst. 26(3),423–437 (1999)

24. Holloway, L.E., Krogh, B.H., Giua, A.: A survey of petri net methods for controlled discreteevent systems. Discret. Event Dyn. Syst. Theory Appl. 7(2), 151–190 (1997)

25. Georgilakis, P.S., Katsigiannis, J.A., Valavanis, K.P., Souflaris, A.T.: A systematic stochastic petrinet based methodology for transformer fault diagnosis and repair actions. J. Intell. Robot. Syst.45(2), 181–201 (2006)

26. Li, Y., Wonham, W.M.: Control of vector discrete-event systems I - the base model. IEEE Trans.Automat. Contr. 38(8), 1214–1227 (1993)

27. Li, Y., Wonham, W.M.: Control of vector discrete-event systems II - controller synthesis. IEEETrans. Automat. Contr. 39(3), 512–513 (1994)


28. Giordano, V., Ballal, P., Lewis, F., Turchiano, B., Zhang, J.B.: Supervisory control of mobilesensor networks: math formulation, simulation, and implementation. IEEE Trans. Syst. ManCybern. Part B Cybern. 36(4), 806–819 (2006)

29. Schiraldi, V., Giordano, V., Naso, D., Turchiano, B., Lewis, F.: Matrix-based scheduling andcontrol of a mobile sensor network. In: 17th IFAC World Congress, pp. 10415–10420 (2008)

30. Nicolescu, M.N., Mataric, M.J.: A hierarchical architecture for behavior-based robots. In: Pro-ceedings of First International Joint Conference on Autonomous Agents and Multi-Agent Sys-tems, Italy (2002)

31. Gat, E.: Three-layer architectures. In: Kortenkamp, D., Bonasso, R.P., Murphy, R. (eds.) Artifi-cial Intelligence and Mobile Robots, pp. 195–210. AAAI, Menlo Park (1998)

32. Connell, J.: SSS: a hybrid architecture applied to robot navigation. In: Proceedings of IEEEInternational Conference on Robotics and Automation (1992)

33. Arkin, R.C., Balch, T.R.: Aura: principles and practice in review. J. Exp. Theor. Artif. Intell. 9,175–189 (1997)

34. Brooks, R.A.: Intelligence without representation. Artif. Intell. 47, 139–159 (1991)35. Payton, D.W., Keirsey, D., Kimble, D.M., Krozel, J., Rosenblatt, J.K.: Do whatever works: a

robust approach to fault-tolerant autonomous control. Appl. Intell. 2(3), 225–250 (1992)36. Cupertino, F., Giordano, V., Naso, D., Delfine, L.: Fuzzy control of a mobile robot using a

matlab-based rapid prototyping system. IEEE Robot. Autom. Mag. 13(4), 74–81 (2006)37. Côté, C., Brosseau, Y., Létourneau, D., Raïevsky C., Michaud, F.: Robotic software integration

using MARIE. Int. J. Adv. Robot. Syst. 3(1), 55–60 (2006)38. Montemerlo, M., Roy, N., Thrun, S.: Perspectives on standardization in mobile robot program-

ming: the carnegie mellon navigation (CARMEN) toolkit. In: Proceedings of the IEEE/RSJInternational Conference on Intelligent Robots and Systems (IROS), vol. 3, pp.2436–2441 (2003)

39. Di Paola, D., Milella, A., Cicirelli, G., Distante, A.: Robust vision-based monitoring of indoor en-vironments by an autonomous mobile robot. In: Proceedings of ASME International MechanicalEngineering Congress & Exposition (2007)

40. Marotta, C., Milella, A., Cicirelli, G., Distante, A.: Using a 2D laser rangefinder for environmentmonitoring by an autonomous mobile robot. In: Proceedings of ASME International MechanicalEngineering Congress & Exposition (2007)

41. Milella, A., Vanadia, P., Cicirelli, G., Distante, A.: RFID-based environment mapping forautonomous mobile robot applications. In: Proceedings of the IEEE/ASME InternationalConference on Advanced Intelligent Mechatronics (2007)

42. Milella, A., Dimiccoli, C., Cicirelli, G., Distante, A.: Laser-based people-following for human-augmented mapping of indoor environments. In: Proceedings of the 25th IASTED InternationalMulti-Conference, pp. 151–155. (2007)

matrix-based discrete event control for surveillance...

Documents