Framework for Adaptive Swarms Simulation and Optimization using MapReduce. Sergi Canyameres 1, Doina Logofătu 2

Transcription

1 Framework for Adaptive Swarms Simulatio ad Optimizatio usig MapReduce Sergi Cayameres, Doia Logofătu 2 2 Computer Sciece Departmet of Frakfurt am Mai Uiversity of Applied Scieces, Nibelugeplatz 6038, Frakfurt am Mai, Germay logofatu@fb2.fh-frakfurt.de Abstract Natural swarms ca have multiple structures ad follow may differet patters or laws. Most recet studies try to obtai the best solutios i very specific ad sophisticated cotexts. I this research, istead, a applicatio to fid a reasoable approximatio to the behaviour of ay possible icomig eviromet is developed. This paper describes a basic framework, GUI ad algorithms established i a way that ca be easily modified ad adapted to desired paradigms, parameters ad rules. I experimetal research, this will be able to provide help for may applicatios where atural swarm patters are followed but o deep, expert simulator has yet bee developed. To deal with the complexity of the biggest applicatios, the simulatios are to be ru i parallel computig usig the MapReduce framework. Backgroud ad Motivatio We were asked to develop a software which would fit the requiremets for takig part i the IformatiCUP []. I this year's editio the participats were asked to fid the best algorithms some robots should follow uder a specific sceario [2]. These are deployed o the ocea's surface ad ca oly commuicate betwee other earby boids, kowig ot more tha their relative positios. The aim is to move aroud the ocea's surface collectig magaese ad gather together after a certai time or commad. May spreadig or path algorithms could be appropriate, but there was a lack of iformatio about what to optimize (time, fuel, uique track covered...) so the goals were too ambiguous. Noe of the existig swarm algorithms that we foud satisfied our expectatios. As see i previous studies [3][4][5], it's commo to focus research i carefully delimited coditios, but o adaptable platform to use with our costrictios was foud. The goal of our project switched to cover this lack of resources ad try to set the basis for a lot of possible future developmets ad applicatios i experimetal research. Differet states ad phases were itroduced to modify the differet algorithms' weights accordig to the desired behaviour of the robots at every momet. Sectio 2 thoroughly explais the cotext of the project ad the first steps take, describig how startig with differet deploymet patters causes a eed of very differet movemet rules, so regular shapes -square, circlead irregular deploymets -radom, Gaussia, combiedwere created to study all the possibilities. I sectio 3, we show how the applicatio itself works, ad how the iteratio over the desired parameters ca provide some acceptable results ad how should they be uderstood for future applicatios. Sectio 4 itroduces the further eed of usig parallel computig for the executio of the applicatio. I sectio 5 the results are showed ad commeted to extract some coclusios leadig to the future work purposed i sectio 6. Requiremets ad Basis Settled The requiremets for the IformatiCUP were costrictive, especially whe establishig which commuicatios could take place betwee the robots. The ucertaity caused by the icomprehesibly ambiguous formulatio of the task gave us total freedom to focus o the creatio of a ew versatile framework ad leave costrictios behid. The required small viewig rage ad limited kowledge lead to the idea of applyig swarm particle algorithms. Ay other paradigm followed would be by ituitio, ad the time was limited to a few weeks which could ot be spet o tryig ufuded ideas. To keep the differece betwee what the robots could kow ad what ot, a Simulator class was created to keep track ad maage most of the iformatio ad share it properly with the other classes. The robot istaces are stored i a HashMap also cotaiig iformatio about positio (classes Robot ad Coordiates). Simultaeously, a first visualisatio of a "sea" of 500 by 500 positios was ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems

2 implemeted, so it was time to start with the deploymet cofiguratios. Optimisig the gatherig time is differet to optimisig the uique surface travelled or the fuel used after they start. Moreover, if the iitial set of robots is positioed i differet way, it becomes a key fact whe it matters of which algorithm to follow i order to ru over the surface followig some criteria.. Hece, may deploymet methods are available: DeployRadom(). Deploys a amout of robots i radom positios withi the give sea limits. Iitially this algorithm was implemeted to verify ad debug the eed of creatig a ew robot oly withi the viewig rage from at least oe other robot. Later i the project, this distributio stayed i the simulator for further testig of ew features (ew visualisatio, determie movemet behaviours) ad as oe of the startig poit algorithms for the IformatiCUP. As it is a very iefficiet startig set the challege was more ambitious. DeploySquare() ad DeployCircle(). Both deploy a amout of robots followig uiformly filled squared or circle patters. The first robot is oe of the four cetral poits of the figure, which grows i a spiral or surroudig shape from the cetre poit. DeployGauss() ad DeployBadCeters(). Give the iitial radom cetre (mea) ad variace, deploy the robots followig a Gaussia distributio, or i two uequal Gaussia distributios. This offers a iterestig ad challegig begiig, where two uequal groups are deployed close eough to see each other but far eough to, followig the mai algorithms see later, ted to split up ito two groups of boids. This is very useful whe extreme coditios are goig to be tested. Fig.. I order, Radom, Square, Circle, Gauss ad BadCeters deploymets show i the GUI. Previous Work 3. Iteractio Simulator-Robot The Simulator coordiates the evolutio of the steps take by the robots while iteractig with them i order to provide the exclusive data that they are allowed to kow, i the real way robots would perceive their eviromet. For example, the absolute coordiates are traslated to relative coordiates for every robot prior to beig give. Therefore, the boids are just computig machies which traslate the give iputs ito ew positios, give a set of rules or behaviour algorithms which ca be easily exchaged. Iteratio ca be uderstood as a real-time secod, fractio, etc. ad the maximum speed ca be chaged as a cosequece of this. I every step, the movemet for all the robots is calculated, ad oly oce they have foud their ew positio they will actually move, the Simulator beig resposible to iterate o the robots askig for the displacemet vector. With this, both ew positios ad speed ca be stored i order to be used i the followig iteratios as well as displayed through a friedly GUI. This way of iteractig is possibly ot as easy to modify as the algorithms that the robots are goig to use, as it is somethig quite specific for our project. Due to the expected versatility for the future uses, the complete code is carefully documeted with Javadoc i order to make it more uderstadable ad accessible. 3.2 Used Algorithms May differet algorithms for movig objects or swarm behaviour could be implemeted [6][7]. As said before, the mai itetio is ot to simulate some specific sceario, but to create a platform which allows a easy trasformatio of the characteristics to simulate. For this reaso the algorithms to be followed are ot required to be very complex, oly implemeted i a strict modular way. This allows the additio of other algorithms or simply the modificatio of the existig oes. The curret applicatio rus uder a simplificatio of the bird flock movemet described by Craig W. Reyolds [8]. This behaviour paradigm cosists of three criteria every robot follows at each iteratio, which ca be uderstood as three differet algorithms simultaeously workig. Cohesio: Every robot moves toward the cetre of mass of the eighbourig oes (). We assume the eighbourig group as the set of robots give by the simulator. This meas that these eighbours are oly those close eough (view rage limit) to be detected by the robot. Although () is the cocept simplificatio, experiece made us add a ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems

3 regulator which icreases the value of this result if a robot is too far away from the others. alg ( eighbours... ) = ( r r ix, iy) () i= Separatio: Every robot tries to keep a miimum distace with the closest robots (2). I the same way as the first algorithm, the average positio of the robots plays a role i this calculatio, but a little variatio gives a extra value to this result if the robot is too close from aother oe. The mai differece is that oly the really close robots are take ito cosideratio i this calculatio. Otherwise, it would be complemetary, opposite to () ad it would ot make sese to keep two algorithms. alg 2( eighbours... ) = ( r r ix, iy ) (2) i= Aligmet: Every robot chages directio to the average positio where the other robots are tryig to steer to (3). This is similar to a iertial force ifluecig all the set of boids, as it does ot work with the positios, but with the velocities. alg 3( velocities... ) = ( v v ix, iy ) (3) i= Fig. 2. Represetatio of algorithms (), (2) ad (3) [8]. 3.3 Weights ad Gatherig mode The fial decisio of every robot is coditioed by differet weights give to every algorithm implemeted (4). This allows activatio, modificatio ad deactivatio of ay existig algorithms without spedig time programmig or chagig the settigs. I fact, the GUI itself provides glide bars which allow the direct settig of the parameters withi a give rage. The curret versio oly applies the chages prior to the deploymet, but i the future ca easily be chaged. v( algorithms... ) = wi algi ( x, y) (4) i= I case of exceedig the maximum speed allowed by the requiremets, both x ad y compoets ca be ormalized so that the vector speed fits the specificatios: x y v [ x, y] = maxspeed, (5) x + y x + y The origial requiremets asked for a fial behaviour i which all the robots should stop focusig o collectig magaese ad movig towards some commo poit where a mother ship could collect them. Agai, the criteria to look for this poit was ot specified, ad may possibilities could be optimized: time, fuel used... The best poit if the desired parameter to miimize is the total fuel cosumed (or simply the total distace travelled), this should be the average positio of all the robots. Hece, the existet weights used for the algorithms are adequately used for this fial situatio, ad all of them are set to zero except the cohesio () weight, which is set to the maximum value. I the basic performace, a maximum of iteratios ca be set i order to activate Gatherig Mode, simulatig a evetual call from the mother ship or simply a time limit which could be itegrated i the boids. Aother coutdow is carried o by checkig if the robots moved more tha a specified threshold. After a certai umber of iteratios (cosecutive or ot) whe the robots are movig less tha this limit set, the Gatherig Mode ca also be activated. Oce the meetig of all the robots has take place, the simulatio stops after a specified timer ad a reset of all the variables ad parameters is doe, i order to execute a ew simulatio. I case of lookig for the best parameters (see ext paragraph) the iitial deploymet positios are loaded agai. 3.4 Fid Best Parameters The most importat fuctio is resposible for simulatig differet executios by usig as may parameters modificatios as possible i order to fid the best cofiguratio. The results ca be uderstood i may ways, as there are may output values which could be optimised (magaese collected, distace travelled, ratio betwee magaese ad distace, iteratios to joi, etc.). I our case the chose oe is simply the maximum amout of mierals collected. The most logical parameters to iterate o are the weights. However, also the umber of deployed robots, the deploymet method or the iteratios util gatherig plays a importat role o the results. I ay case, the simulatio ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems

4 eds up with a geerated data file cotaiig a header with geeral iformatio about the simulatios; static parameters or simply sequece of parameters used, e.g. simulatio doe with 5, 0, 50 ad 00 robots. All the results follow the header, with particular ifo about the set of variables for each simulatio, ad fially the results for magaese collected ad distace travelled. Iitially oly the best cofiguratio for the same set of parameters was registered. However, i order to uderstad the effects ad the evolutio of the values better, the output file ow icludes the result for all the simulatios. Its maipulatio ad uderstadig would be too tedious to be doe maually, so a script i Matlab is created to read ad plot the results i a 3D graphic, which is very helpful to see the behaviour of the simulatios. As some simulatios may have more dimesios, uable to be show i 3D, some adaptatios may be doe. For example, () ad (2) could be uderstood as complemetary values (the real differece is explaied i sectio 3.2). Istead of usig a axis for each, a ew parameter ca be show as the ratio betwee these two values give a closed rage: w w, w2 [ 0, 4] w2 = (6) w 3.5 Double Deploymet Compariso Whe fidig the best parameters for a give cofiguratio, the actual best weights might ot follow a ituitive patter which allows easy uderstadig. The aalysis of the simulatios so far was mostly a posteriori, by studyig ad searchig a proper iterpretatio of the results give i the output files or the graphics i Matlab. The visualisatio of the simulatio for a specific set of parameters was implemeted sice the very begiig, but the weights were ot modifiable ad the proper aalysis was ot comfortable. Hece, we wated to offer a fuctioality which could allow the user to observe ad compare the behaviour of the flock i a practical, real-time way. For that, a secod deploymet ca take place simultaeously, show i aother colour. The parameters, umber of robots ad the startig distributio ca be differet betwee them, offerig the possibility to see i real time the developmet of both simulatios i parallel. Fig.3 shows the visualisatio offered by the GUI. O the left, a first deploymet i red follows the double-gaussia patter, while the blue oe is purely radom. O the right side, a fulfilled circle is draw by the red robots, whereas a differet amout of robots, i blue, create a square. Both double simulatios perform a similar evolutio, although the uiform deploymets experimet smoother modificatios due to the regular distace betwee the boids. O the other had, the radomly positioed robots eed more iteratios to fid a balace, which still look more irregular tha i the images o the right. It was iterestig to add this little optio i order to explore the 2 capabilities of the platform i the gamig world, if we uderstad the both flocks as a competitio to see who gets a better performace. I the future, other applicatios might be iterested i usig this secod deploymet with ewer fuctioalities, such as direct modificatio of the parameters, commads o splittig or mergig the flocks, ad coutless other possibilities which ca be added. Fig. 3. Visualisatio of two pairs of parallel simulatios ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems

5 Distributed Algorithm Usig MapReduce Nowadays it is quite strage to fid big simulatios beig ru i simple computers, ad this project may ot be a exceptio. Most of the simulatios doe so far by us have used low amout of robots ad iteratios, as well as some simplificatios to just cofirm the operative power of the system. I order to execute these simulatios i a curret geeratio pc, the algorithms ca be sophisticated but the parameters must be simplified whe fidig the best cofiguratios. Otherwise too much memory usage is eeded ad the program's behaviour ca be irregular due to exceed of the memory space. For all this, a implemetatio of algorithm parallelizatio is required to be the ext step i the project. The Hadoop [9] ope-source implemetatio of the MapReduce [0] model is likely to be successfully used, like i other evolutioary applicatios []. This is the OpeSource MapReduce framework implemetatio from Apache, a batch data processig system for ruig applicatios, which process vast amouts of data i parallel, i a reliable ad fault-tolerat maer o large clusters of compute odes, usually ruig o commodity hardware. It comes with status ad moitorig tools ad offers a clea abstractio model for programmig, supportig automatic parallelizatio ad distributio. Hadoop comes with a distributed file system (HDFS) that creates multiple replicas of data blocks ad distributes them o compute odes throughout the cluster to eable reliable, extremely rapid computatios. def MR_REDUCE (List of <Cofiguratios> settigs) = { for( i ; i settigs.size(); step ) for( i ; i settigs[i].iteratios; step ) eighbourslist[i] getneighbours(robots, coordiates); extmove robot.move(eighbourslist[i]); coordiates.update(extmove); ed for ed for } retur bestweights; Fig. 5. Pseudocode for MR_SW_OPT The compute ad storage odes are typically the same. This allows the framework to schedule tasks effectively o the odes where data is already preset, resultig i very high aggregate rate across the cluster. The framework cosists of a sigle master JobTracker ad oe slave TaskTracker per compute ode. The master is resposible for schedulig the tasks for the map- ad reduce-operatios o the slaves, moitorig them ad reru the failed tasks. The slaves execute the tasks, as directed by the master. The applicatios specify the iput/output locatios, supply map ad reduce fuctios ad possibly ivariat (cotextual) data. These comprise the job cofiguratio. The Hadoop job cliet the submits the job (Java byte code packed i a jar-archive) ad cofiguratio to the JobTracker, which the distributes them to the slaves, schedules the map-/reduce- tasks, ad moitors them, providig status ad diagostic iformatio to the job cliet. A MapReduce job splits the iput data ito idepedet chuks (splits), which are the processed by the map tasks i a completely parallel maer. The framework sorts the maps outputs ad forwards them as iput to the reduce tasks. Fig. 4. MapReduce Dataflow Iitialize(Deploymet) def MR_MAP(List of Array possibleparameters) = { for( i ; i combiatios; step ) settigs[i] geeratecofiguratio(); ed for } Experimetal Results Assumig the limitatios of executig the applicatio i a sigle domestic computer, differet simulatios were doe. The iitial goals were just to check the correct behaviour of the applicatio. For this, logical results were pursuit by usig uderstadable ad basic parameters. Some combiatios hold useless values. A perfect circle cosistig o a regular amout of robots may ot eve experiece ay variatio of the positios, as the balace is achieved sice the deploymet itself. Similar behaviours may occur with a perfect squared patter, where the ier robots are balaced ad oly the surroudig oes experiece some little repositioig. I ay case, the evets see were correct. The actual implemetatio of the described project ca be foud at [2]. Oce this was verified more extesive calculatios took place by ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems

6 icreasig the rage of possible values. More real-like weights were itroduced. Also loger simulatios could be held by deployig more robots, as well as tryig all the possible deploymet methods. However, more detailed ad log simulatios should still be doe. The precisio is icreased ad the parameters are tested with smaller steps betwee simulatios, causig a big icrease of the data geerated eeded to be stored. Ufortuately, a stadard 6Gb computer experieces difficulties to keep such volumes of iformatio, leadig ito ustable behaviour of the program as see i figure 6. It is to be uderstood that the output is suddely decreased util 0, which is a seseless value because the robots gather some magaese eve if they are static. I ay case, the performace see so far cofirms the viability of usig the framework to experimet ad research with further cotexts, usig ew algorithms. I coclusio, there are good expectatios for the future. Fig. 6. Magaese depedig o w ad w 2 after Radom (above) ad Square (bottom) deploymets. As the figures show, the evolutio of the Magaese recollectio follows a logical ad acceptable evolutio through the values for the mai weights for algorithms () ad (2) after 25 ad 00 iteratios respectively. These two graphics correspods to two very differet deploymets such as radom ad squared-patter. Despite the iitial variatios both of them look very similar. This ca suggest that the robots act idividually, without oticig a big ifluece from the surroudigs. I the same way, circular ad radom deploymets offer very similar outputs. Refereces [] IformatiCUP. [2] Detailed requiremets for the first prototype. ktio/iformatiktage/studwett/aufgabe_ma gaerte_.pdf [3] Ferades, C.M., Merelo, J.J., Rosa, A.C.: Cotrollig the Parameters of the Particle Swarm Optimizatio with a Self- Orgaized Criticality Model. PPSN XII (II) pp Spriger, Taormia (202) [4] Bim, J., Karafotias, G., Smit, S.K., Eibe, A.E., Haasdijk, E,.: It s Fate: A Self-Orgaisig Evolutioary Algorithm. PPSN XII (II) pp Spriger, Taormia (202) [5] McNabb A., Seppi, K.: The Apiary Topology: Emerget Behavior i Commuities of Particle Swarms. PPSN XII (II) pp Spriger, Taormia (202) [6] Rodriguez, F.J., García-Martíez, C.: A Artificial Bee Coloy Algorithm for the Urelated Parallel Machies Schedulig Problem. PPSN XII (II) pp Spriger, Taormia (202) [7] Motes de Oca, M.A.: Particle Swarm Optimizatio - Itroductio. IL/slides.pdf [8] Reyolds, C.: Boids (simulated flockig). [9] Apache Hadoop ope-source implemetatio. [0] Dea, J., Ghemawat, S: MapReduce: simplified data processig o large clusters, I: Commuicatios of the ACM, Vol. 5, Nr., pp. 07-3, ACM New York, USA (2008) [] Logofătu, D., Dumitrescu, D.: Parallel Evolutioary Approach of Compactio Problem Usig MapReduce, I: Proceedigs of th Iteratioal Coferece o Parallel Problem Solvig from Nature (PPSN(2) 200), LNCS 6239, pp (200) [2] Implemetatio Adaptive Swarm Optimizatio (Robots): /Simulator.jar.htm Fig. 7. Bigger simulatios eed more memory. ALIFE 4: Proceedigs of the Fourteeth Iteratioal Coferece o the Sythesis ad Simulatio of Livig Systems