A Mobile Robots Experimental Environment with Event-Based Wireless Communication

An experimental platform to communicate between a set of mobile robots through a wireless network has been developed. The mobile robots get their position through a camera which performs as sensor. The video images are processed in a PC and a Waspmote card sends the corresponding position to each robot using the ZigBee standard. A distributed control algorithm based on event-triggered communications has been designed and implemented to bring the robots into the desired formation. Each robot communicates to its neighbors only at event times. Furthermore, a simulation tool has been developed to design and perform experiments with the system. An example of usage is presented.

algorithms in a real mobile robots platform since, to the best knowledge of the authors, all the results in this field are mainly theoretical and only present simulation results. The experimental results show the goodness of the event-trigger approach compared to time-driven control, reducing the communication between agents. Furthermore, in contrast to other works, as for example [12,15], in which a costly platform for indoor or outdoor experimentation is used, we give a detailed description of our low-cost hardware platform, and how it was implemented in LEGO robots, in order to help readers who are considering building a similar system for research, educational purposes [17], or to mimic real world exploratory applications [18].
An interactive simulation, which is available at http://lab.dia.uned.es/mass, is also presented as a complement to the experimental setup. This simulation helped in the design and trial of different experiments with variable system and network conditions. The paper is organized as follows. Section 2 describes in detail the experimental environment and its components. Section 3 gives a background on event-based control and multi-agent systems, and the extension of these to the formation control of a multi-robot system. Section 4 describes the simulation tool and an example of usage. Section 5 discusses experimental results and compares them to simulation results and experiences based on time-driven control. Finally, Section 6 ends the paper with conclusions and suggestions of future works.

Test Platform Description
We next describe the experimental environment designed with low-cost components. This may help readers to build similar systems. It can also be scaled up or down to equip bigger or smaller robots, respectively [19,20].

Platform Architecture and Components
The developed tool is a test platform for multi-mobile robot systems. It consists of two main components: the vision and the communication systems. Different software tools exchange information to transform the images captured by the camera into positioning data, which are sent to the robots via wireless communications. Figure 1 shows the block diagram of the architecture and the components of the platform, which are the following: 1. A personal computer (PC) to calculate and send the position and orientation to the robots. 2. A CCD camera (charge-coupled device) connected to the PC and equipped with wide angle optics. The camera is placed in the ceiling of the room, as described in [21] 8. An application (running on the PC), developed in LabVIEW, for the interaction with the camera [21]. 9. A Java application, built with Easy Java Simulations (EJS) [26], for communication between the robots and the PC. 10. A Java XBee API to send and receive data through the Waspmote Gateway card [27]. 11. The JIL server [28] to link LabVIEW with EJS.

Vision System
Though LEGO platforms provide an interesting group of sensors such as ultrasonic, touch, or light sensors, there is no device for measuring absolute positions. This makes experimentation in robot formation control difficult. One option to solve the previous drawback is the use of a GPS as the main localization sensor as in [29]. However, when the experiments are performed indoors, GPS is impractical.
Another alternative is to incorporate a vision system to get the robots poses. The recent appearance of RGB-D cameras has made possible 3D mapping from a single image and state estimation. However, running the robot real-time state estimation algorithms on board would require a powerful computer, which would increase the cost of the platform considerably. Thus, a single camera on the ceiling observes the arena from an overhead position. Each robot can be distinguished thanks to three high brightness LEDs. These light spots form an isosceles triangle with different aspect ratio for each robot as shown in Figure 2a. In Figure 2b, the points Pa, Pb, and Pc represent the LEDs. The orientation is denoted by θ. The position of each robot is calculated using their center of mass (Xcm; Ycm). The Basler A631fc CCD camera (block 2 of Figure 1) is configured in monochrome mode for image acquisition in order to maximize the resolution and shutter speed. Under these conditions, we obtain images with a resolution of 1,388 × 1,038 pixels at 18.7 fps.
The images captured by the camera are processed by the LabVIEW Camera App (block 8 of Figure 1), which computes the robots poses. The execution of the application implies the following steps: • Barrel distortion correction: The image magnification decreases with distance from the optical axis. The apparent effect means that an image has been mapped around a sphere (or barrel). • Perspective transformation: Transforms the coordinates of the object to the camera coordinates, making rotation and translation transformations. • Calculation of positions and orientations: From the reference points on the ground, we calculate the position and orientation taking into account the morphology of the obtained points. • Transformation of coordinates: From pixels to meters. • Calibration: Gets the perspective calibration parameters.
The front panel of the LabVIEW Camera App is shown in Figure 3. The values of the configuration of the camera (gain, shutter, and frame rate) and the period (T) are required to compute the bearings, and shown on the front panel. The application sends the absolute position and orientation to the robots every 200 milliseconds. Further details about this application can be found in [21].

Communication System
After the processing of the robots poses, they are sent to the robots. Each one receives its position and orientation, and decides when to broadcast this information to its neighbors based on the local data, updating the control law afterwards. Thus, the control is distributed in the sense that each robot takes by itself the decision of when to transmit its state and the control law is computed locally, in contrast to [16], where the control law is computed on the central computer and sent to the robots.
Waspmote boards (block 5 of Figure 1) are used for the wireless communications. This card has a modular architecture and is based on the Atmel ATMEGA 1281 microcontroller. The Waspmote also integrates the Digi XBee RF (ZigBee standard) module for communication in the ISMB bands (Industrial Scientific Medical Band, RF-868 MHz) [30]. This module communicates with the microcontroller via interruptions using the UART at the speed of 38,400 bps. It allows the definition of different network configurations (e.g. p2p, tree, or mesh) and uses the protocol 802.15.4 with a frequency of 2.4 GHz [22]. For wireless network settings, each card uses the MAC address of its corresponding XBee. Each robot "talks" to its neighbors given by the communication graph (see Sections 3 and 4.2 for further details).
The power supply for the Waspmote is a lithium battery. The energy system has four operational modes (on, sleep, deep sleep, and hibernate). In normal operating mode (on), the consumption is 9 mA. Every 125 ns the microcontroller runs a routine of low level (machine language) instructions [31,32], which is fast enough to the time requirements of our system.
The I 2 C bus interfaces the NXT LEGO with the Waspmote. The NXT LEGO runs as master and the Waspmote as slave. The Waspmote card runs an application (block 7 Figure 1) that allows the LEGO NXT to communicate with other robots and the PC. Every 100 ms the following tasks are executed: 1. It checks if a packet has been received by the XBee radio. Packets can be sent from the PC or from another robot. If the answer is positive, the received data is stored in a buffer until the NXT LEGO requires it. 2. It checks if a flag is true. If the answer is positive, it indicates that the NXT LEGO requires the sending of a packet to other robots (its neighbors) by Xbee radio. Once the packet is sent the flag is set to false. The NXT LEGO triggers an interruption routine (which sets the flag to true) when a packet must be sent. In event-based control, the flag is set to true at the event occurrence time.
Each NXT LEGO runs a LabVIEW App (block 6 of Figure 1) to interface with the Waspmote card by I 2 C (see Section 2.4 for further details). This application requests data to the Waspmote every 200 ms. If the received packets are from the camera application (own position and orientation), the position is compared to the last broadcasted position, i.e., to the state which generated the last event. If the difference is greater than a threshold, then the current position is sent to its neighbors by using the I 2 C interface with the Waspmote. By contrast, if the source is any robot in the neighborhood, the received data is then used to update the control law as explained later in Section 3.
The communication between the PC and the Waspmote is carried out by the Waspmote's Gateway (block 3 of Figure 1) connected to the PC through the USB port. The Waspmote's Gateway has drivers for Java but not for LabVIEW. For this reason, it is necessary to use an application developed in Java to send the data to each corresponding robot using the gateway. In this case, the JIL Server application [28] (block 11 of Figure 1) is used as interface between the camera application and the EJS Robots App (block 9 of Figure 1). This latter application sends the position and orientation to the robots by using XBee-Java-API (block 10 of Figure 1).
The data packet sent from the PC and between the robots has a size of 16 bytes. This is the maximum size allowed by NXT LEGO Mindstorms for the communications by I 2 C port [33]. Figure 4 shows the packet structure, which is as follows:  Byte 0 (S): The source where the packet comes from. The value is 0 for the robot 0, 1 for robot 1, and so on.  Bytes 1…4 (X 1 …X 4 ): 4 bytes corresponding to the X coordinate of the robot position.

Using I 2 C in NXT LEGO
The LabVIEW toolkit for LEGO has buffers to write and read in each port, and three system call methods to access to these buffers. The write operation begins with the corresponding system call method, which constitutes the start of an asynchronous transaction between the NXT brick and the Waspmote. If the return value is zero, the method starts a communication transaction. After a write transaction is started it is necessary to use a system call function to check the status of the port. To ensure the success of the transmission, there is a system call function to check the status port.
The read operation of a device through I 2 C port is carried out in two stages. First, a write operation must be executed with the number of bytes that the slave has to send. If the count of bytes available in the read buffer is not zero, the read operation is executed and the data is obtained in the external buffer.

Multi-Agent Systems and the Consensus Problem
The simplest model to represent the communication topology of a multi-agent system is a graph G = {V,E}, where the nodes V correspond to agents and the edges E represent communication links between nodes.
According to [3], a simple consensus algorithm to reach an agreement regarding the state of N single integrators of the form can be expressed as an nth order linear system on a graph: The dynamics of the group of agents can be written as: where L is the laplacian of the graph, and N i the set of neighbors of the node i [34]. Based on analytical tools from algebraic graph theory, it can be shown that if the graph is connected, then there is an unique equilibrium state for Equation (2)  Consensus algorithms can be extended to formation control if the formation is represented by vectors of relative positions of neighboring agents. In particular, let us denote by r ij the desired inter-vehicle relative position vector. The following control law: yields the group to achieve the objective of the formation. The consensus problem has been extending regarding the agents dynamics to higher order integrators [35,36], or linear systems [37].

Model of Non-Holonomic Mobile Robots
Single or double integrators do not describe properly the dynamics of most of commercial mobile robots, since these cannot move in any direction instantaneously. In robotics, holonomicity refers to the relationship between the controllable and total degrees of freedom of a given robot. If the controllable degrees of freedom are less than the total degrees of freedom the vehicle is non-holonomic. To avoid the non-holonomic constraint, Reference [38] defines the dynamics in terms of the front wheels coordinates   i i y x , as: . The triple (x i , y i , θ i ) denotes the position and the orientation of the vehicle (see Figure 2b, x i = Xcm, y i = Ycm for each vehicle), and v i and ω i are the longitudinal and angular velocities, respectively. Let us consider as control inputs for each robot u i = (v i , ω i ).

Time Schedule Control
In a distributed control approach, each agent collects information from its neighboring nodes and updates the control law according to some rules. In a networked system, collecting information means to transmit it through the communication channel. The information can be transmitted through the network in a periodic or an event-based fashion. The first case involves the traditional approach of sampling at pre-specified time instances, usually separated by a specific sampling period. However, the selected period must assure adequate system performance over a wide range of operating conditions. This can yield to a conservative choice and result in significant over-provisioning of the communication-network. Event-triggering represents one way of generating sporadic transmissions across network channels [39]. The communication is invoked only when something significant has occurred in the system.
The problem of multi-agent systems with event-based communications has been recently addressed [40,41]. Whereas the controller design of [41] is centralized, [40] presents a distributed approach, in which the agents are modeled by single and double integrators. The control law is based on the states that the agents broadcast to their neighbors through the network at event times. The average consensus is reached preserving convergence properties and the experimental results show a significant reduction in the number of transmissions respect to a periodic approach. Distributed event-based control has been also addressed in [42], where physical coupling may exist between the subsystems.
The control signals in each robot are computed based on the broadcasted information, which means that are not updated continuously, not even at each measurement of its own state received by the camera (see Section 2.2). The rule to determine when to broadcast is given by the trigger function. A trigger function determines the instants of time } { i k t at which each agent broadcasts the state to its neighbors. In general, these broadcasting times are not equidistant as in periodic communications. Moreover, the proposed trigger functions depend on local information only.
If we denote the state of an agent i as x i (t) and ) ( t x i as the broadcasted state of agent i to its neighbors, which is a piecewise constant function, an event is triggered for an agent i when: is fulfilled, where N i is the neighborhood of agent i. The trigger functions are said to depend on local information because the decision of when to re-compute the control law depends on the last update values and the neighbors' states, and each agent does not have to monitor the states of its neighbors continuously in order to evaluate the triggering condition, in contrast to the trigger rules proposed in [10]. , where c 0 is a constant value. The control law u i = (v i , ω i ) to reach the desired formation is computed as: Combining Equations (4) and (6) it yields that:

Stability Anaalysis
Note that defining the control law given in Equation (6), two decoupled equations are obtained and they correspond to the equation of the event-triggered consensus problem of single integrators studied in [40], but extended to reach a formation. There it was proved that the consensus was reached, so in this case the agents achieve the desired formation translated into the XY plane by a vector which is the average of the initial positions (average consensus).
Hence, the stability results sum up in the following corollary to the Theorem 4 in [40], in which time-dependent trigger functions of the form: are considered. Remark 1. In trigger functions given in Equation (8) it is assumed that the initial conditions are t 0 = 0. Otherwise, Equation (8) can be rewritten as: where t 0 refers to the initial time of the experiment. Thus, the threshold decreases exponentially and takes the value c 0 in the limit when time goes to infinity.
the disagreement vectors in the x-and y-coordinates, respectively, where 1 = (1 … 1) T is an eigenvector of the laplacian L [3]. Thus, it holds that y x y , and it yields: where e x = (e x,1 …e x,N ) T and e y = (e y,1 …e y,N ) T . Hence, applying the results of Theorem 4 in [40], it yields the disagreement vectors y x   , converge to the following regions, respectively: is the algebraic connectivity of the graph G (second smallest eigenvalue of L). with an error given by Equation (14). Despite the fact that the existing theory that proves the robustness of the proposed control strategy and the simulation results that show a significant improvement as far as the number of transmissions between agents is concerned, there are neither experimental results on a real platform nor a simulation tool to perform a wide set of experiments of formation control of mobile robots. The following section describes the developed software and all its capabilities.

Simulation Tool
The many control and system configuration options needed to simulate a multi-agent system demand a graphical user interface (GUI) with a high degree of flexibility. The GUI is intended to make rapid prototyping and simulation of wireless autonomous agents which execute distributed control algorithms and perform event-based communications. Nevertheless, the GUI has been made keeping the interaction with the user relatively simple and intuitive in order to be used as a pedagogical tool for advanced engineering control courses. The simulation tool is available on line at http://lab.dia.uned.es/mass. See [43] for further details.

Description of the Simulator
The interface of the application, shown in Figure 5, has five main panels, a menu bar, and a small task bar. The two upper panels of the interface provide a quick view of the multi-agent system and a time plot of the outputs and control signals. The top left panel shows an animation of the complete multi-agent system. Each agent is numbered and shows a trace of its former positions. The lower left panel, named Agent Parameters, allows users to set the number of agents in the system, as well as to add and remove a particular agent. The time plots on the top right panel, which are grouped in the System Signals tab, display the relative distance to the desired formation as well as the control actions of each agent. There are also plots grouped in the Network Signals tab, which provide information about the measured delay of the sent packets.
The lower panel, named Network Parameters, is devoted to setting up the network delay and also the network packet loss. Users can choose this panel to set fixed or random delay and loss probability functions. The lower right panel Control Parameters is used to specify the communication strategy which triggers the sending of packets from the agents in order to update the control actions. The interface is completed with a top task bar that provides buttons to start, pause, and reset the simulation.
The components of the interface described earlier provide the basic functionality required to operate the application. A menu bar provides some additional features such as the possibility to specify the dynamic model of the agents and to select a predefined multi-agent system configuration and the experiment to be performed. The user can also save a configuration, mark it as default or load a previous configuration.

A Practical Example
This section presents a usage example of the simulator described above. Different experiments are prefixed. We select one of them in the top menu, for example, Experiment 2, in which the communication topology for four vehicles is given by the graph in Figure 6, and the desired formation respect to the center of the group is: Figure 6. Communication graph describing one-dimensional network topology.
The user can find in the help menu all the information about these experiments. Random initial conditions are generated, but we may be interested in comparing the performance of different control strategies (periodic and event-based, for example) for a prefixed initial coordinates. We can do that by right-clicking in the drawing panel and selecting the option "Setting current state as default". Figure 5 shows the simulation output when the trigger function is of the form . The user can change the parameters of i f while the simulation is running or switch to a periodic communication and check online the effect of these changes in the system.  We observe that the major discrepancies are at the beginning of the experiment. Note that the control signals are constant piecewise functions and change their value only at event times, while Equation (6) reads that they change continuously with the orientation θ i even though r x x  and r y y  remain constant in the inter-event times. The reason for this is the constraint imposed by the hardware in the real system. Because one agent cannot monitor its state continuously (the camera sends measurements every 200 ms, which is the minimum period allowed by the Waspmote cards), and the slow variation of the angle, the computation required to implement the continuous control law given in Equation (6) is not worthy. Thus, the angle is considered to remain constant between events.

Comparison of Simulation and Experimental Results
Moreover, the selected trigger functions decrease with time. This means that the threshold to detect an event is greater for small values of time, and fewer events are generated consequently. When the system approaches to the desired formation, the threshold decreases and makes the error arbitrary small. Note that i d takes the same value for all i = 1,…,4 and the final state only depends on the initial conditions, as predicted by the consensus problem theory (see Section 3). However, the final state for the real experiment differs slightly from the result given by the model. The reason for that might be sensing errors, dead-zone in the actuator and/or transmission delays. Finally, Figure 8 shows the view of the experiment at t = 0, 6, 12, and 24 s.  Figure 9 compares the results obtained from event-trigger and time-trigger experiments. In the last case, each agent receives data from the camera every 200 ms, it processes the information, broadcasts its state to its neighbors, and computes the control law every two samples (400 ms). In the lower graph of Figure 9 the broadcasts in both cases are depicted for each agent (labeled from 1 to 4). For the periodic case, the number of packets sent through the network during the experiment should be 500 4 . 0 / 4 50   agents s . However, for the event-based control this number is by far lower: 83 events in total. In the upper graph of Figure 9 the distance to the formation is shown. Note that even though the desired formation and the initial conditions are the same, the final state (which depends on the average of the initial positions) is different. As remarked before, these differences come out because it is difficult in experimentation to exactly reproduce the same conditions.

Event-Trigger Versus Time-Trigger
For instance, network delays cannot be controlled, or sensing errors may occur more frequently in one case than in the other. However, observe that the time at which the formation is achieved (the stationary) is very similar for both time-trigger and event-trigger.

Conclusions
We have described an experimental environment for mobile robots. The hardware platform was developed using different components and software to overcome the limitations of the LEGO Mindstorms NXT robots. A distributed control approach has been used in formation control. Each robot communicates to its neighborhood in an event-triggering fashion for network saving purposes. A simulation tool with high degree of flexibility has been presented. An example has demonstrated its usability, and simulated and experimental results have been presented showing how the multi-agent system reaches the desired formation with few communications meanwhile the system performance is preserved. Future works will include the implementation of collision and obstacle avoidance control and formation control with specified paths. Exploring self-triggering techniques [44] to predict the next event occurrence in order to optimize the communication between the camera and the robots is also a future line of research.