Simulation biased random walk associated with Escherichia Coli

Escuela T´ecnica Superior de Ingenier´ıa Inform´atica Universitat Polit`ecnica de Val`encia Simulation Biased Random Walk associated with Escherichia Coli Final Degree Project Computer Science Author: Jose Miguel Lloret P´erez Supervisors: Dr. ´ Angel Valera Fernandez Dr. John McCall August 2, 2012 In collaboration with: Abstract The aim of the project is to simulate cellular intelligence in e-puck robots through a novel method named Artificial Reaction Network (ARN). Biased Random Walk (BRW) is implemented in three robots simultaneously and these are controlled by a computer which runs a program in Java platform. The characteristics and limitations that e-puck has and protocol for communicating Java platform with e-puck is discussed. Also approaches like: Odometry, Kalman Filter (KF), Particle Filter (PF), proximal and distal are presented as well as its advantages and disadvantages. Thus, the implementation of each approach selected is explained and future improvements are discussed. Acknowledgements The author wishes to express his gratitude to his supervisor, John McCall who has offered invaluable assistance, support and guidance. Also, the author would like to thank Claire Gerrard since without her knowledge, this study would not have been successful. Not forgetting David Davidson for giving him the opportunity of be an exchange student in this University as well as the students met at Ideas Research Group. The author whishes to express his love to Cinta Gomez for her understandability in every situation elapsed during the project since without her would not have been possible to get the strenght enough for achieving the purposes. Finally, the author is grateful for his family who has been giving him help and backing in his experience far away from home. Contents Introduction 6 Requirements analysis 7 Detailed specification 8 Basicactions ........................................ 8 Protocolavoidance ..................................... 8 Concurrence......................................... 8 Environmenttosimulate.................................. 9 E-puck robot, selected to simulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Overview........................................ 9 Hardware ....................................... 9 Software........................................ 11 Interfacewiththerobot ............................... 12 Mechanisms and useful theories . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Design discussion 15 Basicactionsapproaches.................................. 15 Basic actions using Odometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Basic actions using Kalman Filter . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Basic actions using Particle Filter . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Protocol avoidance approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Protocol avoidance using Proximal (reactive) . . . . . . . . . . . . . . . . . . . . 17 Protocol avoidance using Distal (rule-based) . . . . . . . . . . . . . . . . . . . . 18 Concurrenceapproaches .................................. 19 ConcurrenceusingThread.............................. 19 ConcurrenceusingRunnable............................. 19 Implementation issues (excluding programs listings) 20 Structure of the system (Java side) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Structure of the system (C side) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Odometryasapproachused ................................ 24 Distal (rule-based) as approach used . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Threadaswayused..................................... 26 Communication Java and E-puck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Improvements for resource limitations of e-puck . . . . . . . . . . . . . . . . . . . . . 29 Analysis of system performance 30 Firstexperiment ...................................... 30 Firstexperiment-Scenario.............................. 30 Firstexperiment-Results .............................. 30 1 First experiment - Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Secondexperiment ..................................... 32 Second experiment - Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Secondexperiment-Results............................. 33 Second experiment - Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Conclusions 35 Reflections 37 Program listings 40 2 List of Figures 1 E-puckrobot ..................................... 10 2 Electronice-puck ................................... 10 3 Webotsstepstodevelop ............................... 12 4 Differential drive kinematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5 Classdiagram(Javaside) .............................. 20 6 Comparison BRW, between Computer and Robot . . . . . . . . . . . . . . . . . 31 3 List of Tables 1 Variablesfore-puck.................................. 14 2 Java messages for sending to each e-puck . . . . . . . . . . . . . . . . . . . . . . 27 3 Example encoding message from Java . . . . . . . . . . . . . . . . . . . . . . . . 28 4 Comparison coordinates BRW, between Computer and Robot . . . . . . . . . . 32 5 Secondexperiment .................................. 33 4 Listings 1 Java. Class extends Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 Java. Class implements Runnable . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3 C. Atan function customized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4 C.Distalapproach .................................. 40 5 C.Odometryforward................................. 40 6 C. Odometry counterclockwise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7 C.Odometryclockwise................................ 41 8 Java.Methodsclass.................................. 41 9 Java. Connect with E-puck by Bluetooth . . . . . . . . . . . . . . . . . . . . . . 42 10 Java. Disconnect with E-puck by Bluetooth . . . . . . . . . . . . . . . . . . . . 42 11 Java. Send message to E-puck by Bluetooth . . . . . . . . . . . . . . . . . . . . 42 12 Java. Receive message from E-puck by Bluetooth . . . . . . . . . . . . . . . . . 43 13 C. Send message to Java by Bluetooth . . . . . . . . . . . . . . . . . . . . . . . 43 14 C. Receive message from Java by Bluetooth . . . . . . . . . . . . . . . . . . . . 43 15 C. Regular expression for two doubles received . . . . . . . . . . . . . . . . . . . 44 16 C. Regular expression for one double received . . . . . . . . . . . . . . . . . . . 44 17 C. Regular expression for one integer received . . . . . . . . . . . . . . . . . . . 44 18 C.Ordersinterpreter................................. 45 19 C.Releasememory.................................. 47 20 C. Management agenda e-puck . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 21 Java. Output first experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 22 Java. Output second experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5 Introduction Artificial Intelligence (AI) is the study of intelligence machines and is one of the branches of computing which was invented by John McCarthy and defined as he said “the science and engineering of making intelligent machines, especially intelligent computer programs. It is related to the similar task of using computers to understand human intelligence, but AI does not have to confine itself to methods that are biologically observable” [7]. Since then, many approaches to simulate intelligence have emerged, such as bio-inspired approaches which have achieved that AI has enormous progress. Bio-inspired AI approaches have proven valuable, for example: Genetic Algorithms (GA), Particle Swarm Optimization (PSO) and Ant Colony Optomization (ACO). This project intends to explore the potential of Artificial Reaction Network (ARN) as a source to simulate cellular intelligence in a particular robot. The Ideas Research Institute is part of Robert Gordon University and could consider this type of project like the first project using e-puck robot, an educational robot with an emerging use in Engineering. The first aim of this project has been to establish a contact with every term involved with the robot, studying its characteristics, as well as its limitations. The secondary aim has been to research how to communicate the robot with programs in java, so this may be very useful for a future research projects related to simulated cellular intelligence using Java as a principal programming language, due to the extensibility and power that resides in this language. The third aim has been to apply ARN to simulate the Biased Random Walk (BRW) associated with Escherichia Coli, combining the first aim as well as the secondary aim, to simulate artificial intelligence in e-puck robots. 6 increments known as steps in response to the application of digital pulses to an electric drive circuit from a digital controller. The number and rate of the pulses control the position and speed of the motor shaft. E-puck motors have 20 steps per revolution. The wheels diameter is about 41 mm and they are separated by distance of 53 mm. The maximum speed of the wheels is 1000 steps per second, which corresponds to one wheel revolution per second [21]. By varying the speed of the two wheels, the trajectories that the robot takes can be varied. There are three interesting cases: 1. If, V r =V l robot moves in a straight line. 2. If, V l =−V r robot turns clockwise. Whether V r =−V l, robot turns counter clockwise. 3. If, V l = 0 there is a rotation about the left wheel. Whether V r = 0, there is a rotation about the right wheel. As robot has a differential drive configuration, imposes non-holonomic constrains on establishing its position. It means that robot cannot move laterally along its shaft. So, cannot simply specify an arbitrary robot position and find the speed needed to reach that position. To control the robot and reach a given configuration x y θTthere is need to know the inverse kinematic: x(t) = t Z 0 υ(t)cos[θ(t)] dt(1) y(t) = t Z 0 υ(t)sin[θ(t)] dt(2) θ(t) = t Z 0 ω(t) dt(3) where υrefers to linear speed and ωis the angular speed. To apply this principle for a motion in a straight line, the (Equation 4) shows how to reach the position:   x0 y0 θ0  =  x+υcos(θ) dt y+υsin(θ) dt θ  (4) If the robot rotates over itself (Equation 5) is used which allows the position to be got:   x0 y0 θ0  =  x y0 2υdt l  (5) The variable lrefers to diameter of the robot axis, as can be seen in (Figure 4). Below, the (Table 1) represents a summary of useful data for solving any problem related with the project. 13 Table 1: Variables for e-puck Variable Value Meaning l53 Distance in mm between the wheels. d41 Diameter in mm per each wheel. s1000 Speed in steps per second. w2πAngular speed in radians per second, per each wheel Θdπ Maximum speed in mm per second. V l ι sΘ Speed for left wheel giving ιsteps, where ιis an integer value [-1000,1000]. V r ι sΘ Speed for right wheel giving ιsteps, where ιis an integer value [-1000,1000]. 14 Design discussion In this chapter has been explained the different alternatives studied to reach each requirement. Each alternative as well as its advantages and disadvantages are explained. Regarding the environment to simulate and the robot selected (e-puck) are not discussed nothing since these requirements are closed without possible changes. Basic actions approaches ”Basic Actions” explained in the previous chapter, involve know where is located the robot every-time. Localisation involves determine the Cartesian coordinates (x, y) and the orientation θknown as the state x y θT. Three alternatives are studied in this project: Basic actions using Odometry Odometry, also known as Dead Reckoning, is the measurement of wheel rotation as a function of time[2]. If the two wheels are joined to a common axle, to estimate position in time t the previous position as well as the linear speed vand angular speed ware used, the (Equation 1,2,3) show how get the position. Thus, the change of position during time, is known through encoders of the wheels. It is considered as the first approach to know an estimation about robot position x y θT. The advantages of this approach are: •It requires only the use of encoders of the motors to get the position and there not need to use other sensors for estimating of position. •If length paths are short, it provides good accuracy of position estimation. •It is compatible with other positioning approaches. Hence, this approach combined with other allows get better results. The disadvantages of this are: •Encoders return discretized values, losing precision due to the motors are represented as continuous function really. •The estimation of position can be better or worse depending on floor type where robots are located. •The wheels diameter inequalities influence in the estimation of position. •If the wheels produce slippage, a loss of position is got. 15 Basic actions using Kalman Filter The Kalman Filter (KF) provides an efficient computational tool to estimate the state of a process, minimizing the mean squared error [19]. KF has two steps: •The update uses the dynamical model of the system (forward kinematics in e-puck), requiring an initial position to start. •The predictor uses a sensor model, such as the error distribution calibrated from its sensors, for getting an improved estimation. Hence, KF updates the state of the system, that are the position for the robot as well as its variance. xk=Axk−1 + Buk−1 + wk−1 zk=Hxk+vk (6) where x∈ <nis the state vector, u∈ <uis the input vector and z∈ <mis the measurement vector. wk,vkrepresent process and measurement noises at time k. They are considered to have an independent, white, normal probability distribution with zero mean. The exact values of wkand vkat time kare normally unknown but it is assumed the knowledge of the covariance matrices, Qkand Rkrespectively(assumed to be constant). The KF aim is to estimate the state xkof (Equation 6) based on the knowledge of the system dynamics (linear model), the covariance matrices (disturbance characteristics) and the availability of the noisy measurements zk. More details about how works this approach can be found in [19]. The advantages of this approach are: •It is obtained better accuracy than using odometry since with this approach are fused various sensors for getting better estimation of position. •It is possible to apply this filter for different purposes like speed of the wheels or speed of the robot. •There are more extensions for this filter that provide better estimation for robot position, for instance extended KF. The disadvantages of this approach are: •If the platform where the filter is implemented has limited resources, as e-puck robot, it is difficult develop the approach due to resources limitations. •Calibration of the wheels is need to get good estimation of position, that are, measure the diameter for each wheel and remove slight differences in wheels speed. Basic actions using Particle Filter Particle Filter (PF) is an approach that can be used to estimate position of the robot. The main objective of PF is to ”track” a variable of interest as it evolves over time [10]. The variable of interest has multiples copies (particles) and each copy has a weight which corresponds with quality of that specific particle. Hence, the value of interest variable is got by the weighted sum of all particles. The PF algorithm has three phases: 1. Prediction: It uses a model in order to simulate the effect an action has on the set of particles with appropriate noise added. For instance, to estimate robot position, odometry can be used, adding after a noise model for motions performed. According authors [10] if an arbitrary motion is performed as a rotation followed by a translation, is needed to apply a noise model separately, because these motions are independent. 16 2. Update: It uses information obtained from sensors like (proximity sensors, laser, camera) to update the particle weights in order to accurately describe the moving probability density function (pdf) of the robot. 3. Re-sampling: This phase removes particles with small weights since these particles become to small to contribute to the (pdf) of the moving robot. There are three methods of evaluation to obtain an estimate of the position, according authors [10]: •Weighted mean: x y θT=PM j=1 wjxj, where Mis the number of particles sampled, wjis the weight associated with the particle and xjrefers to particle j. •Best particle: It selects the particle with maximum weight associated. x y θT= max(wj) : j= 1...M. •Robust mean: A weighted mean in a small windows around the best particle. It is the method most computationally expensive. The advantages of this approach are: •If sensors like camera o laser are used, allows get a global estimation of the position, being more reliable than others approaches which obtain only a local approximation of the position. •If the number of samples are increased, allows get better estimation of position. •There is not restrictions in model, so can be applied to non-Gaussian models, hierarchical models or even others. and the disadvantages are: •If the number of samples are increased, it can be inefficient computationally or even inaccessible for e-puck. •It can be hard find programming errors due to different phases and their associated calculations. Protocol avoidance approaches Protocol avoidance, explained in the previous chapter, involves avoid crashing with the walls and the other robots located in the environment. There are two alternatives for explaining these requirements: Protocol avoidance using Proximal (reactive) In this approach the robot sensors control the speed of the motors and these are changed according the value got by sensors. To implement this approach a matrix is used normally where rows represent each sensor and columns are associated to each motor. Thus, the speed is the sum of rows associated with the column that represents the motor. For instance, e-puck robot has eight proximity sensors, each one would be associated in a row and it has two motors where would be represented in two columns [9]. 17 The weights of the matrix are determined empirically and they depend on the problem to solve. The (Equation 7) estimates the speed of the motors: speedmotors =X 0<i<m 0<j<n matrix(i, j)·(1.0–(sensorV alue(i)/v)); (7) where iis weight associated for each sensor, jis each motor, sensorV alue(i) represents the value got from the sensor and vis a value estimated empirically to normalize the sensor value, for instance could be 512. The advantages of this approach are: •There is not need to establish actions to do when an obstacle is detected since it tries to avoid obstacles, varying motors speed. •The motions for avoiding obstacles are less abrupt since the speed is controlled by proximity sensors. The disadvantages of this approach are: •It is needed a very good calibration of the sensors for avoiding behaviours in motors speed unexpected . •It is needed find out weights of the matrix, changing depending on problem. •Whether the robot is crossing over a narrow passage, it will remain in this situation probably. •If the robot has objects in front of it, as well as in its left and right, it will remain in this situation probably. This type of scenario is known as ”U-shaped”. Protocol avoidance using Distal (rule-based) In this approach is established a threshold for each sensor and when this value is overcome, it is decided the actions to do [9]. For instance, the next code provides an example combining the sum of two sensors: sensorV alue(i) + sensorV alue(j)> k{action or actions to do}(8) where kis a value (threshold) established empirically, although exist other examples for determining the actions to do. The advantages of this approach are: •There is flexibility to establish the behaviour which performs the robot, allowing to choose action or actions to do depending on the criteria satisfied. •It is easy to detect possible mistakes in code since the actions can be separated depending on the sensor. The disadvantages of this approach are: •Whether the robot is crossing over a narrow passage, it will remain in this situation probably. •If the robot has objects in front of it, as well as in its left and right, it will remain in this situation probably. This type of scenario is known as ”U-shaped”. 18 Concurrence approaches Concurrence, explained in the previous chapter, involves run a program which controls robots in one computer simultaneously. Moreover, there is another restriction to satisfy, the program must run in Java. So, in Java exists thread approach which allows an application to have multiple threads of execution running concurrently [13]. A Thread has a priority and depending on its priority will be executed before or after another. There are two ways to create a new thread of execution: Concurrence using Thread It must be declared a subclass which extends from Thread and it should modify the run method. The principal disadvantage using this way is that Java language does not allow more than one class to extend, providing less flexibility. (Listing 1) provides an example which uses this approach. Firstly, there is need to create an object myThread, and after, call start method for starting to run the Thread. Listing 1: Java. Class extends Thread 1 c l a s s myThread extends Thread{ 2 int value ; 3 myThread( int value ){ 4 t h i s . value = value ; 5} 6 public void run (){ 7 // Override t h i s method 8} 9} Concurrence using Runnable It must be declared a class that implements the Runnable interface. This type of approach provides more flexibility than previous approach, above mentioned, because in Java language it is possible implements various classes. (Listing 2) provides an example which uses this approach. Firstly, there is need to create an object myRunnable, and after, call start method for starting to run the Thread. Listing 2: Java. Class implements Runnable 1 c l a s s myRunnable implements Runnable{ 2 int value ; 3 myRunnable( i nt value ){ 4 t h i s . value = value ; 5} 6 public void run (){ 7 // Override t h i s method 8} 9} 19 Implementation issues (excluding programs listings) In this chapter it is explained the structure of system in two sides, Java and C. Java is the language chosen to achieve requirements like concurrence and C is the language supported by e-puck. Further, the approach chosen for each requirement as well as its code developed are explained. Structure of the system (Java side) Java has been the language chosen since one of the aims, explained in ”Introduction”, requires a communication between this language and e-puck robots. Thus, following the principles of Software Engineering a class diagram has been created to provide a general vision about the code implemented in Java. Bellow, each class in (Figure 5) will be explained: Figure 5: Class diagram (Java side) •DiscoveryBluetoothDevice: This class searches bluetooth devices installed in the machine where it is running. It implements DiscoveryListener which allows to receive device discovery and service discovery events [1]. It has two attributes, Devices (a vector of RemoteDevice) and Lock (an object to lock the process until inquiry is completed). The method getDevicesFound() returns a vector of RemoteDevice found in the computer or null if an error happens. 20 •Controller: This class is the entry point to the system. It has four methods, –main() it is the method executed when program starts. It allows to choose between different actions (looking for e-pucks, proximity sensors calibration...). –lookingForEpucks() it shows in screen, friendly name and bluetooth address for each e-puck installed in the machine. –launchMethod() it launches the method selected in main() method. –epucksInConfiguration() it reads each e-puck and its attributes in a configuration file. •Epuck: This class is a abstraction of an e-puck. It has five attributes, –BluetoothAddress: it is an unique identifier for each e-puck. It is used to connect with the e-puck. For instance, e-puck 2479 has 1000E8AD6AC4 as identifier. –FriendlyName: It is the name for each e-puck and it is different for each one. For instance, e-puck 2479 has e-puck 2479 as friendly name. –Position: It represents the position (x, y) that robot has. –Angle: It represents the angle θthat robot is facing. –Near: It represents the threshold for taking into account that there is an object near. and has ten significant methods, –connect() it tries to connect with the e-puck, through its BluetoothAddress identifier. –disconnect() it tries to disconnect the e-puck. –sendPosition() it sends a position (x, y) where the robot is located. It is useful when robot loses the reference position. –sendAngle() it sends an angle θwhere the robot is facing. It is useful when robot loses the reference angle. –sendStop() it sends a signal to stop the process running in the robot. –sendGoToAvoidingObstacle() it sends a position to reach, taking into account avoid crashing with obstacles. –sendGoTo() it sends a position to reach. –sendNear() it sends a new threshold. It is useful when ambient light is changing. –sendOverallTime() it sends this order, for receiving the overall time elapsed of the orders that (Algorithm 1) executes. –sendObstaclesDetected() it sends this order, for receiving the number of obstacles detected for orders that (Algorithm 1) executes. •Method: it is the class which allows to connect various e-puck simultaneously. It receives an Epuck object as well as an integer mthat determines the method to run. It has various methods but run() is the most important since decides the method to execute concurrently. •BluetoothCommunication: It is the class that implements the communication between Java and e-puck. It has four methods connect(),disconnect(),send() and receive(). They are explained in ”Communication Java and E-puck”. •Camera: This class interacts with an IP Camera through http. It has three attributes, 21 –Address: It is an http address where the camera is installed. –User: I is the user name to connect with the camera. –Password: It is the correct password to connect with the camera. and has one method, takePicture() that takes a picture of the environment where camera is pointing. •Picture: it represents an abstraction of an image. It has one attribute, path that refers to path where the picture is stored. It has two methods, –locateRobotPosition() it finds the coordinates (x, y) where the robot is located in the picture. –locateRobotLookAt() it finds the angle where the robot is facing in the picture. •Configuration: This class implements Singleton pattern to avoid more than one instance can be run simultaneously when the program is executing. It has two attributes INSTANCE that references the class (itself) and pthat represents the different properties, reading them from CONFIGURATION.txt file. These properties allow to update the different attributes of some classes, mentioned previously. Properties is a class which represents a persistent set of properties, more information [12]. •Language: This class has an important attribute pwhich represents the different properties, reading them from english.txt and these properties represent messages that application produces. It can be useful if it is required translate the messages to another language. Structure of the system (C side) E-puck robots can be programmed using C language and through the standard library, the sensors, the actuators as well as the communications are possible to control. It is recommended to read the standard library documentation that can be downloaded in the official site of epuck [22] and it provides good explanations about the different files integrated and the data structures which has. In order to show the structure of the system in e-puck side a list of functionalities, that robot have implemented, has been created. Below, each functionality, the files which contains and the different functions developed will be explained: •runbrw: It is the controller for the system and every action, that robot performs, is managed on this functionality. This contains two files, runbrw.h and runbrw.c. Also it has these functions: –void run brw(): It is the main function for the project. It always is waiting until an order is coming for doing the correct action associated with order. –void protocol(char *data, int length): It is the order interpreter which decides the action to do depending on the order received. •runbrw bluetooth: It allows to send and receive data through bluetooth. This contains two files, runbrw bluetooth.h and runbrw bluetooth.c. Its functions associated are: –char * receive(int *length) –void send(char *output, int length) 22 1. A determinate format for messages. 2. Connection, disconnection, send and receive methods in Java. 3. Send and receive methods in e-puck. 4. Encoding and decoding messages in both sides, due to channel accepts bytes only. 5. Regular expressions to allow e-puck understands what is coming. 6. Order interpreter to decide which action execute in e-puck. Improvements for resource limitations of e-puck E-puck robot has limitations of memory, so the amount of memory which it has is 8KB. Therefore, it is necessary to take into account this amount of memory for every code programmed otherwise it can be locked sometimes. Thus, there are two examples performed in this project trying to avoid full memory of e-puck. These examples are: •Release memory: This action is done in last line at principal loop of the program since a pointer of size TAMBUFFER is created every time in a function that is waiting for everything coming through Bluetooth. Thus, once order interpreter sends the reply to Java, the memory created is released, avoiding getting it filled by useless data. Line 11 of (Listing 19) shows how this action is done. •Management of agenda: This action allows a good management of agenda to be done. This is an approach developed in standard library of e-puck which provides the possibility of executing functions at certain times. For instance, to obtain estimation of position, wheels increments are calculated each millisecond but this function is not always called, only when robot speed is different from 0. Thus, if the agenda for this function is activated and then destroyed when wheels speed are 0, the function for destroying agenda does not release the memory, so in a short time the memory of the e-puck is full. Thus, the behaviour for a good management of agenda is: 1. Create an agenda (once) for each function which needs to update a particular action in a certain time. 2. Pause agenda when the function is not needed for updating the action. 3. Restart agenda when the function is needed for updating the action. (Listing 20) shows the code for the example explained previously. 29 Analysis of system performance In this chapter is presented two experiments for trying to achieve every requirement imposed in the project. The first experiment executes one e-puck and the second executes three epucks concurrently. For each one the scenario chosen is detailed as well as the result obtained. Experiments execute orders coming from the program which executes BRW really. This program has been developed by authors [8] and produces a file which the format is friendy name;x coordinate;y coordinate. An example line would be e-puck 2479;39.0;95.0. For overall time is summing elapsed time for performing turns and motions forward without counting pause and communication times. First experiment The first experiment executes BRW in one robot trying to achieve ”Basic Actions”. First experiment - Scenario The scenario for this experiment has the following characteristics: •The start coordinates are (4.00,3.50). •It receives twenty-five orders. •The speed to move forward the robot is 800 steps. •The speed to turn the robot is 1000 steps. •The environment where the robot is placed is an enclosed surface with green carpet floor. •Each order is received from computer through Bluetooth. First experiment - Results The blue line (Figure 6) corresponds to path which one robot performs in simulation mode and the red line (Figure 6) corresponds to path which does e−puck 2479 robot. (Table 4) shows the values represented in (Figure 6), where ”(x, y) BRW” refers to coordinates executing program simulation in Java, whilst ”(x, y) BRW robot” refers to coordinates reached at e-puck 2479 robot. The average absolute error in x is 2.752 and average absolute error in y is 2.988, the overall time for executing these orders is 54.914154 seconds. It is not produced slippage in wheels during this experiment and the communication for sending works without errors. The output created by Java is shown in (Listing 21), the video executing this experiment can be downloaded from [17]. 30 Figure 6: Comparison BRW, between Computer and Robot First experiment - Conclusion Looking at (Figure 6), the robot (red line) performs the same path that (blue line), despite the path is shifted slightly from original it keeps same shape. The principal problem detected is when robot executes a motion which involves a long path since the error of position is increased, whilst if it is executing short path, the error of position can be considerate acceptable. ”Basic actions”, that are ”Run” and ”Tumble”, explained in ”Detailed specification”, are achieved since each order received in the robot turns the degrees needed to facing objective coordinates and then goes to those coordinates. The error of position is due to deterministic errors in this experiment. Thus, deterministic errors are slight differences in wheels diameter or in motors speed. Moreover, errors coming from encoders are possible since they have to return an integer value and motors are represented as a continue function really, loosing precision in each reading of each encoder. 31 Table 4: Comparison coordinates BRW, between Computer and Robot x BRW y BRW x BRW robot y BRW robot abs error x abs error y 39.00 95.00 43.00 93.00 4 2 26.00 91.00 30.50 89.50 4.5 1.5 33.00 92.00 37.00 90.50 4 1.5 45.00 87.00 48.50 84.50 3.5 2.5 55.00 74.00 58.50 71.50 3.5 2.5 41.00 60.00 44.50 57.50 3.5 2.5 27.00 59.00 30.50 56.00 3.5 3.0 25.00 52.00 28.50 49.50 3.5 2.5 26.00 47.00 29.50 44.20 3.5 2.8 31.00 46.00 34.50 43.10 3.5 2.9 26.00 44.00 29.50 41.00 3.5 3.0 56.00 32.00 59.00 28.60 3.0 3.4 54.00 45.00 56.50 41.50 2.5 3.5 41.00 50.00 43.50 46.20 2.5 3.8 38.00 63.00 40.00 59.20 2.0 3.8 51.00 64.00 53.00 61.00 2.0 3.0 33.00 58.00 35.00 54.50 2.0 3.5 36.00 68.00 38.00 64.70 2.0 3.3 41.00 79.00 43.00 75.70 2.0 3.3 49.00 64.00 51.00 60.50 2.0 3.5 42.00 79.00 43.50 75.40 1.5 3.6 29.00 89.00 30.70 85.50 1.7 3.5 21.00 96.00 22.90 92.20 1.9 3.8 19.00 88.00 20.50 85.00 1.5 3.0 24.00 87.00 25.70 84.00 1.7 3.0 Second experiment For second experiment has been used three e-pucks simultaneously with the aim of achieve every requirement mentioned in ”Detailed specification”. Second experiment - Scenario The scenario for this experiment is: •e-puck 2478,e-puck 2479 and e-puck 2481 simultaneously. •The start coordinates are (90.00,60.00) for e-puck 2478, (90.00,50.00) for e-puck 2479 and (100.00,55.00) for e-puck 2481. •They receive twenty-five orders. •The speed to move forward the robot is 800 steps. •The speed to turn the robot is 1000 steps. •Threshold for proximity are 650, 480, 620 respectively, keeping numeric sort in the epucks. 32 •The environment where the robot is placed is an enclosed surface with green carpet floor. •Each order is received from computer through Bluetooth. Second experiment - Results Results are shown in (Table 5). That summarizes the important things performed for each e-puck. Start time means start sequence, being e-puck 2479 the first. End time refers to Table 5: Second experiment e-puck 2478 e-puck 2479 e-puck 2481 Start time Third First Second End time First N/A Third Overall time 61.532501 seconds N/A 60.659618 seconds Completed orders 25 25 7 25 24 25 Overcomes threshold-proximity 3 N/A 11 Obstacles avoids 1 3N/A 4 11 Ambient light influences 2 3N/A 7 11 sequence for finishing twenty-five orders, concluding that e-puck 2479 is locked at order eight. Overall time means elapsed time for performing twenty-five orders, where is not added pause times neither communication times. Completed orders refers to number of coordinates that has been reached respect to total. Overcomes threshold-proximity means the number of times that sensors detect something. Obstacles avoids refers obstacles avoided during the experiment, where e-puck 2481 detects once a robot e-puck 2478 and three times detects a wall. Ambient light influences means number of times which is detected something, not being this an obstacle. The output created by Java is shown in (Listing 22) and the video executing this experiment can be downloaded from [18]. For this experiment is need to calibrate proximity sensors. There is a video [16] which shows the execution of calibration procedure which allows to get the value for threshold in each e-puck. Second experiment - Conclusion ”Basic actions” has been proved in the first experiment but can be highlighted that is need to use another approach to estimate better the position of the robot since the paths which the robot runs can be shorts or long, having to work well in every situation. ”Protocol avoidance” requirements are achieved since there are three robots located at the environment and they are avoiding to crash each other and walls. Despite sensor proximity has been calibrated before, there is noise due to ambient light, although it does not influence for detecting the obstacles. Regarding ”Concurrence” is satisfied since three robots are running simultaneously in one computer. Although, e-puck 2479 is locked after seven orders it can be due to computer which 33 runs the program has resources limitations or due to data loss through Bluetooth communication. If it is run this experiment in another computer, over seventy orders without losing communication are reached. Hence, ”Concurrence” is achieved also. 34 Conclusions BRW is one of the behaviours which performs Escherichia Coli and it is implemented in ARN. ARN approach is a source of inspiration for creating new AI techniques and can be applied for simulating cellular intelligence in robots. Thus, e-puck robot has been selected as a candidate for executing BRW, being new in the research group that works with ARN where there has been the need to study characteristics which provide the e-puck. After the characteristics has been studied, the need to develop a protocol for communicating the robot with Java platform has been discovered since no API developed in Java exists. Thus, after creating this protocol the understandability between the device and Java platform is possible. The next step has been the programming of the behaviour associated with BRW which are ”Runs” and ”Tumbles”. This behaviour has been implemented using Odometry approach since there is need to know where the robot is located in the environment every-time. Despite this approach does not work with accuracy, for data evaluated in the first experiment, it is however acceptable, taking into account that this data corresponds with real behaviour performed by BRW in ARN. Hence, ”Basic Actions” have been achieved, getting good results when robot runs short paths and increasing the error estimation of position when robot runs long paths. But there are errors that can be solved, those are systemic errors, so a proper calibration can remove them, improving estimation of position. Some of these systemic errors are (misalignment of the wheels, slight differences in wheels diameter or even slight differences in motors speed). However, there are non-systemic errors where removal without use an external source is impossible. Some of these non-systemic errors are (slippage of the wheels, variation in the contact point of the wheel). Regarding obstacles avoiding, this requirement is very important since the scenario of the project involves running three e-puck simultaneously without crashing with the walls. This requirement has been solved using Distal approach, concluding that is working very well if proximity sensors are calibrated correctly. Indeed, to obtain a good calibration is available a method which runs in the environment where the robots must execute BRW, since the value for threshold is changing every-time due to influence of ambient light. However, possibility of differentiate walls or other robots when threshold is overcome does not exist, concluding that the use of the camera which robots have or an external camera, removing uncertainty and improving avoidance protocol is needed. This improvement of avoidance protocol would allow remove try approach used currently and could improve the response time for deciding actions to do when something is near, so using another sensor like the camera, the system would have more information over the environment. Talking about concurrence, this requirement is solved through Java platform, allowing every request coming from e-puck simultaneously and establishing the needed resources for each e-puck, concluding that approach selected works well for project purposes. However, as the communication is done via Bluetooth some data can be lost during execution time and is thought that improving communication using errors control, would remove this loss and would avoid robots becoming locked. It should also be noted that it is impossible to manage robots simultaneously in a computer having resources limitations. 35 Although, e-puck robot has resources limitation it has responded very well for project purposes since BRW behaviour can be executed without any problem, so using this robot for future project related with cellular intelligence could be carried out, but the most important thing now is that it is possible to do complicated calculations in Java side, using a computer with good computational resources and after transferring to e-puck basic actions through Bluetooth, allowing the simulation of other behaviours of cellular intelligence. Hence, it can be affirmed that e-puck robot is available for performing experiments related with ARN and now the first contact with e-puck has been established, allowing other new projects to focus on other behaviours provided by ARN. 36 Reflections In this chapter possible improvement are talked about with the intention of getting better results in the simulation of cellular intelligence. Firstly, to improve motions that robot performs, using odometry is not enough since the removal of systemic errors is first needed and after an estimation of position should be used through external source, that is, the camera available in the lab where robots run experiments. Regarding the use of the camera, work is currently been done to eliminate the distortion that it has and with a software for recognizing the objects located in a picture. This software is imageJ and now is capable of recognize position of robots in the picture, although due to distortion of camera, these positions are wrong. Secondly, to differentiate objects detected by proximity sensors in protocol avoidance, the camera that robot has can be used for sending by Bluetooth the image (when threshold is overcome), so it would allow this uncertainty to be removed doing system more accurate. Thirdly, at the moment Bluetooth communication has been customized for this project, that is, really is like an order interpreter adapted for project requirements. Thus, developing an API in Java which implements a mapping of standard library of the e-puck can be considered useful doing more extendible communication and avoiding programming in two languages simultaneously. 37 Bibliography [1] Bluecove 2.1.0 API. Interface discoverylistener. http://bluecove.org/bluecove/ apidocs/index.html, 2006. [2] Kok Seng CHONG and Lindsay KLEEMAN. Accurate odometry and error modelling for a mobile robot. MECSE, June 1996. [3] Cyberbotics. Webots overview. http://www.cyberbotics.com/overview, 2012. [4] Gregory Dudek and Michael Jenkin. Computational Principles of Mobile Robotics. Cambridge University Press, February 2000. [5] Brian J. Ford. Are cells ingenious? MICROSCOPE, 52:3/4:135–144, September 2004. [6] Claire E. Gerrard, John McCall, George Coghill, and Christopher MacLeod. Artificial reaction networks. 11th UK workshop on Computational Intelligence, University of Manchester, September 2011. [7] John McCarthy. What is artificial intelligence? http://www-formal.stanford.edu/jmc/ whatisai/whatisai.html, November 2007. [8] Francesco Mondada, Michael Bonani, Xavier Raemy, James Pugh, Christopher Cianci, Adam Klaptocz, Stephane Magnenat, Jean-Chistophe Zufferey, Dario Floreano, and Alcherio Martinoli. The e-puck, a robot designed for education in engineering. Technical report, ´ Ecole Polytechnique F´ed´erale de Lausanne, 2009. [9] University of Colorado. Introduction to robotics, obstacle avoidance. http://correll. cs.colorado.edu/?p=974, September 2011. [10] Ioannis M. Rekleitis. A particle filter tutorial for mobile robot localization. February 2004. [11] Roland Siegwart and Illah R. Nourbakhsh. Introduction to autonomous mobile robots. Bradford Books, 2004. [12] API specification for the Java 2 Platform. Class properties. http://docs.oracle.com/ javase/1.4.2/docs/api/java/util/Properties.html, 2010. [13] API specification for the Java 2 Platform. Class thread. http://docs.oracle.com/ javase/1.4.2/docs/api/java/lang/Thread.html, 2010. [14] Robert Gordon University. Code implemented in c side. https://www.dropbox.com/sh/ n4yz3w9o91jss2t/ooeBdCWc4C, Julio 2012. [15] Robert Gordon University. Code implemented in java side. https://www.dropbox.com/ sh/90q1zcgnzhinz1y/Z_KjtUitAA, Julio 2012. 38 10 ∗n = a t oi ( xs ) ; 11 } Listing 18: C. Orders interpreter 1 void protocol ( char ∗data , int length ) { 2 char output [TAMBUFFER] ; 3 double x , y ; 4 int success ; 5 int n ; /∗Variable to set proximity sensor ∗/ 6 switch (∗( data+0)) { 7 case ’A’ : 8 regExp2 ( data , length ,&x) ; 9 s p r i n t f ( output ,”SEND ANGLE(%f ) ” ,x ) ; 10 send ( output , s t r l e n ( output ) ) ; 11 LOOK AT ROBOT = x ; 12 break ; 13 case ’D’ : 14 s p r i n t f ( output ,”X:%f ,Y:%f ,ANGLE:% f ” , CURRENT X,CURRENT Y,LOOK AT ROBOT ) ; 15 send ( output , s t r l e n ( output ) ) ; 16 break ; 17 case ’G’ : 18 regExp ( data , length ,&x,&y) ; 19 go to (x , y) ; 20 s p r i n t f ( output ,”GO TO(%f ,% f ) ” ,x , y) ; 21 send ( output , s t r l e n ( output ) ) ; 22 break ; 23 case ’N’ : 24 regExp3 ( data , length ,&n) ; 25 s p r i n t f ( output ,”SEND NEAR(%d) ” ,n) ; 26 send ( output , s t r l e n ( output ) ) ; 27 NEAR = n ; 28 break ; 29 case ’O’ : 30 regExp ( data , length ,&x,&y) ; 31 s uc ce ss = g o t o a v o i d i n g o b s t a c l e s (x , y) ; 32 i f ( succes s == 1) {s p r i n t f ( output ,” GO TO AVOIDING(%f ,% f ) ” ,CURRENT X, CURRENT Y) ; } 33 e l s e {s p r i n t f ( output ,”STOPS AT(%f ,% f ) ” ,CURRENT X,CURRENT Y) ; } 34 send ( output , s t r l e n ( output ) ) ; 35 break ; 36 case ’P’ : 37 regExp ( data , length ,&x,&y) ; 38 s p r i n t f ( output ,”SEND POSITION(%f ,% f ) ” ,x , y) ; 39 send ( output , s t r l e n ( output ) ) ; 45 40 CURRENT X = x ; 41 CURRENT Y = y ; 42 break ; 43 case ’S ’ : 44 s p r i n t f ( output ,”SEND STOP() ”) ; 45 send ( output , s t r l e n ( output ) ) ; 46 break ; 47 case ’T’ : 48 s p r i n t f ( output ,”OVERALL TIME(%f ) ” , OVERALL TIME) ; 49 send ( output , s t r l e n ( output ) ) ; 50 break ; 51 case ’U’ : 52 s p r i n t f ( output ,”OBSTACLES DETECTED(% d) ” ,OBSTACLES DETECTED) ; 53 send ( output , s t r l e n ( output ) ) ; 54 break ; 55 case ’X’ : 56 s p r i n t f ( output ,”PROX0:%d−PROX1:%d− PROX7:%d−PROX6:%d” , e get prox (0) , e get prox (1) , e get prox (7) , e get prox (6) ) ; 57 send ( output , s t r l e n ( output ) ) ; 58 break ; 59 case ’a ’ : 60 regExp2 ( data , length ,&x) ; 61 go to angl e (x) ; 62 s p r i n t f ( output ,”%d;%d;%d;%d” , e get prox (0) , e get prox (1) , e get prox (7) , e get prox (6) ) ; 63 send ( output , s t r l e n ( output ) ) ; 64 break ; 65 case ’b ’ : 66 regExp2 ( data , length ,&x) ; 67 turn angle (x ) ; 68 s p r i n t f ( output ,”GO TO ANGLE(%f ) ,TIME ELAPSED(%f ) ” ,LOOK AT ROBOT, TIME ELAPSED) ; 69 send ( output , s t r l e n ( output ) ) ; 70 break ; 71 case ’ c ’ : 72 regExp ( data , length ,&x,&y) ; 73 forward (x , y) ; 74 s p r i n t f ( output ,”FORWARD,TIME ELAPSED (%f ) ” ,TIME ELAPSED) ; 75 send ( output , s t r l e n ( output ) ) ; 76 break ; 77 case ’ i ’ : /∗Start connection ∗/ 78 s p r i n t f ( output ,” CONNECTION ESTABLISHED() ”) ; 46 79 send ( output , s t r l e n ( output ) ) ; 80 break ; 81 de fau lt : 82 s p r i n t f ( output ,”UNKNOWN ORDER, length s t r i n g i s : %d” , length ) ; 83 send ( output , s t r l e n ( output ) ) ; 84 break ; 85 } Listing 19: C. Release memory 1 void run brw ( ) { 2 char ∗data ; 3 int length =0; 4 e init motors(); 5 e i n i t a d s c a n (ALL ADC) ; /∗Proximity∗/ 6 e c a l i b r a t e i r () ; /∗Calibrate proximity sen sors ∗/ 7 e start agendas processing(); 8 while (1) { 9 data = r e c e i v e (&length ) ; 10 protocol ( data , length ) ; 11 f r e e ( data ) ; /∗Free memory space used by pointer data ∗/ 12 } 13 } Listing 20: C. Management agenda e-puck 1 i f ( enabled3 == 0) {e activate agenda ( odometry forward ,T ∗10000) ; enabled3 = 1;} 2 e l s e e re st ar t ag en da ( odometry forward ) ; 3 e s e t s p e e d l e f t (MOTOR SPEED) ; 4 e s e t s p e e d r i g h t (MOTOR SPEED) ; 5 6 /∗Actions to perform here ∗/ 7 8 e s e t s p e e d l e f t (0) ; 9 e set speed right(0); 10 e pause agenda ( odometry forward ) ; Listing 21: Java. Output first experiment 0. Looking f o r e−pucks connected in computer 1. Launch proximity sen sor s c a l i b r a t i o n 2. Launch Biased Random Walk 3. Launch Biased Random Walk with ob st acle avoidance 4. Test orders customized 5. Odometry e r r o r s 3 BlueCove v er sion 2 . 1 . 0 on winsock Connection f a i l s with e−puck 2478 Order recei ved from e−puck 2479 i s SEND POSITION(4.000000 ,3.500000) 47 Order recei ved from e−puck 2479 i s SEND ANGLE(0.000000) Order recei ved from e−puck 2479 i s SEND NEAR(6000) Connection f a i l s with e−puck 2481 Order : 0 receiv ed from e−puck 2479 i s GO TO AVOIDING (39.000000,95.000000) Order : 1 receiv ed from e−puck 2479 i s GO TO AVOIDING (26.000000,91.000000) Order : 2 receiv ed from e−puck 2479 i s GO TO AVOIDING (33.000000,92.000000) Order : 3 receiv ed from e−puck 2479 i s GO TO AVOIDING (45.000000,87.000000) Order : 4 receiv ed from e−puck 2479 i s GO TO AVOIDING (55.000000,74.000000) Order : 5 receiv ed from e−puck 2479 i s GO TO AVOIDING (41.000000,60.000000) Order : 6 receiv ed from e−puck 2479 i s GO TO AVOIDING (27.000000,59.000000) Order : 7 receiv ed from e−puck 2479 i s GO TO AVOIDING (25.000000,52.000000) Order : 8 receiv ed from e−puck 2479 i s GO TO AVOIDING (26.000000,47.000000) Order : 9 receiv ed from e−puck 2479 i s GO TO AVOIDING (31.000000,46.000000) Order : 10 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (26.000000,44.000000) Order : 11 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (56.000000,32.000000) Order : 12 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (54.000000,45.000000) Order : 13 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (41.000000,50.000000) Order : 14 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (38.000000,63.000000) Order : 15 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (51.000000,64.000000) Order : 16 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (33.000000,58.000000) Order : 17 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (36.000000,68.000000) Order : 18 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (41.000000,79.000000) Order : 19 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (49.000000,64.000000) Order : 20 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (42.000000,79.000000) Order : 21 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (29.000000,89.000000) Order : 22 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (21.000000,96.000000) 48 Order : 23 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (19.000000,88.000000) Order : 24 re ceiv ed from e−puck 2479 i s GO TO AVOIDING (24.000000,87.000000) e−puck 2479 OVERALL TIME(54.914154) BlueCove stack shutdown completed Listing 22: Java. Output second experiment 0. Looking f o r e−pucks connected in computer 1. Launch proximity sen sor s c a l i b r a t i o n 2. Launch Biased Random Walk 3. Launch Biased Random Walk with ob st acle avoidance 4. Test orders customized 5. Odometry e r r o r s 3 BlueCove v er sion 2 . 1 . 0 on winsock Order recei ved from e−puck 2478 i s SEND POSITION (90.000000,60.000000) Order recei ved from e−puck 2478 i s SEND ANGLE(0.000000) Order recei ved from e−puck 2478 i s SEND NEAR(650) Order recei ved from e−puck 2481 i s SEND POSITION (100.000000,55.000000) Order recei ved from e−puck 2481 i s SEND ANGLE(0.000000) Order recei ved from e−puck 2481 i s SEND NEAR(620) Order recei ved from e−puck 2479 i s SEND POSITION (90.000000,50.000000) Order recei ved from e−puck 2479 i s SEND ANGLE(0.000000) Order recei ved from e−puck 2479 i s SEND NEAR(480) Order : 0 receiv ed from e−puck 2479 i s GO TO AVOIDING (39.000000,95.000000) Order : 1 receiv ed from e−puck 2479 i s GO TO AVOIDING (26.000000,91.000000) Order : 0 receiv ed from e−puck 2481 i s GO TO AVOIDING (38.000000,31.000000) Order : 0 receiv ed from e−puck 2478 i s GO TO AVOIDING (184.000000,27.000000) Order : 2 receiv ed from e−puck 2479 i s GO TO AVOIDING (33.000000,92.000000) Order : 1 receiv ed from e−puck 2481 i s GO TO AVOIDING (38.000000,26.000000) Order : 3 receiv ed from e−puck 2479 i s GO TO AVOIDING (45.000000,87.000000) Order : 4 receiv ed from e−puck 2479 i s GO TO AVOIDING (55.000000,74.000000) Order : 1 receiv ed from e−puck 2478 i s GO TO AVOIDING (134.000000,11.070000) Order : 2 receiv ed from e−puck 2481 i s GO TO AVOIDING (24.000000,19.000000) Order : 2 receiv ed from e−puck 2478 i s GO TO AVOIDING (129.000000,9.011000) 49 Order : 5 receiv ed from e−puck 2479 i s GO TO AVOIDING (41.000000,60.000000) Order : 3 receiv ed from e−puck 2478 i s GO TO AVOIDING (125.000000,12.000000) Order : 3 receiv ed from e−puck 2481 i s GO TO AVOIDING (59.000000,18.000000) Order : 6 receiv ed from e−puck 2479 i s GO TO AVOIDING (27.000000,59.000000) Order : 4 receiv ed from e−puck 2481 i s GO TO AVOIDING (66.000000,21.000000) Order : 7 receiv ed from e−puck 2479 i s GO TO AVOIDING (25.000000,52.000000) Order : 4 receiv ed from e−puck 2478 i s GO TO AVOIDING (127.000000,20.020000) Order : 5 receiv ed from e−puck 2481 i s GO TO AVOIDING (76.000000,22.000000) Order : 5 receiv ed from e−puck 2478 i s GO TO AVOIDING (118.000000,24.000000) Order : 6 receiv ed from e−puck 2481 i s GO TO AVOIDING (84.000000,31.000000) Order : 7 receiv ed from e−puck 2481 i s GO TO AVOIDING (88.000000,15.000000) Order : 6 receiv ed from e−puck 2478 i s GO TO AVOIDING (108.000000,13.039999) Order : 8 receiv ed from e−puck 2481 i s GO TO AVOIDING (97.000000,11.000000) Order : 7 receiv ed from e−puck 2478 i s GO TO AVOIDING (104.000000,22.030001) Order : 8 receiv ed from e−puck 2478 i s GO TO AVOIDING (98.000000,36.020000) Order : 9 receiv ed from e−puck 2481 i s GO TO AVOIDING (88.000000 ,8.010000) Order : 9 receiv ed from e−puck 2478 i s GO TO AVOIDING (93.000000,18.000000) Order : 10 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (87.000000,10.000999) Order : 10 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (101.000000,27.000000) Order : 11 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (87.000000,18.070000) Order : 11 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (80.000000,13.000000) Order : 12 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (93.000000,29.000000) Order : 12 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (75.000000 ,7.030000) Order : 13 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (75.000000,12.003000) Order : 13 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (93.000000,13.000000) 50 Order : 14 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (101.000000,19.000000) Order : 15 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (96.000000,30.090000) Order : 16 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (89.000000,45.000000) Order : 17 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (95.000000,41.000000) Order : 14 re ceiv ed from e−puck 2481 i s STOPS AT(68.255150 ,7.976673) Order : 18 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (94.000000,20.000000) Order : 15 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (59.000000,35.000000) Order : 19 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (105.000000,13.000000) Order : 20 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (95.000000,14.030001) Order : 16 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (57.000000,49.000000) Order : 21 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (101.000000,7.040000) Order : 17 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (73.000000,47.000000) Order : 22 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (106.000000,12.000000) Order : 18 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (83.000000,65.000000) Order : 23 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (100.000000,20.020000) Order : 19 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (83.000000,71.000000) Order : 24 re ceiv ed from e−puck 2478 i s GO TO AVOIDING (91.000000,32.000000) e−puck 2478 OVERALL TIME(61.532501) e−puck 2478 OBSTACLES DETECTED(3) Order : 20 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (83.000000,65.000000) Order : 21 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (80.000000,71.000000) Order : 22 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (78.000000,76.000000) Order : 23 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (72.000000,77.000000) Order : 24 re ceiv ed from e−puck 2481 i s GO TO AVOIDING (68.000000,73.000000) e−puck 2481 OVERALL TIME(60.659618) e−puck 2481 OBSTACLES DETECTED(11) 51