复制成功
  • 图案背景
  • 纯色背景

笔记

  • 2019-11-16
    为大人带来形象的羊生肖故事来历 为孩子带去快乐的生肖图画故事阅读
    谈谈怎样学好数学_苏步青-中学生文库
bookoneyee..

上传于:2016-03-25

粉丝量:1

该文档贡献者很忙,什么也没留下。



Sustainable multi-robot patrol of an open polyline

下载积分:3000

内容提示: Sustainable Multi-Robot Patrol of an Open PolylineElizabeth Jensen, Michael Franklin, Sara Lahr, and Maria GiniAbstract—We present an algorithm that maintains coverageof an open polyline patrolled by a team of robots. Whileprevious work has focused on the uniformity of patrolling,we focus on ensuring the longevity of the system in theface of robot failures. A central control tower monitors thebattery levels of the robots, and recalls them when they arelow on power replacing them with fully charged robots....

文档格式:PDF| 浏览次数:1| 上传日期:2016-03-25 04:08:04| 文档星级:
Sustainable Multi-Robot Patrol of an Open PolylineElizabeth Jensen, Michael Franklin, Sara Lahr, and Maria GiniAbstract—We present an algorithm that maintains coverageof an open polyline patrolled by a team of robots. Whileprevious work has focused on the uniformity of patrolling,we focus on ensuring the longevity of the system in theface of robot failures. A central control tower monitors thebattery levels of the robots, and recalls them when they arelow on power replacing them with fully charged robots. Wecompare two methods for replacement, both of which aim tokeep coverage interruptions to a minimum. We present resultsobtained through physical experiments and simulations.I. I NTRODUCTIONThe purpose of a patrol is to continuously travel in an areato protect or supervise it. Common goals are uniform fre-quency coverage [1], [2], [3] and detection of adversaries [4],[5]. Frequency-based patrol systems are usually designed forsurveillance, but are also useful in tasks such as cleaning,garbage collection, and monitoring. Multi-robot teams areoften used for such tasks, as they can improve performanceby reducing the area covered by each robot and increasingthe frequency of visits of each point [3].In previous work, algorithms have focused on the differenttypes of routes that need to be covered. With a circular path,any point can be reached from any other point, which makesuniformity of coverage trivial to achieve: simply space therobots evenly and set them to all move along the path in thesame direction and at the same velocity. When the path tobe patrolled is not a closed tour, but rather an open polyline,providing frequency guarantees becomes more difficult [3].A detail that is often overlooked is the fact that robots havelimited power sources and must be recharged. In the caseof a multi-robot patrol system, where we wish to providea frequency of visit guarantee for the entire patrol route, arobot running out of power would violate those guarantees.We present here algorithms that take this limitation intoaccount, with the primary goal being the longevity of thesystem in the face of robot failures. We go beyond thefrequency-based patrol algorithms that have been previouslypresented, and extend them to adapt so that a replacementcan be sent in when a robot runs low on power. This is mademore complex because we focus on open polylines.The main contributions in this paper are (1) algorithms thatsuccessfully maintain a multi-robot polyline patrol systemwith frequency guarantees, and (2) experimental validationE. Jensen, M. Franklin, and M. Gini are with the Departmentof Computer Science and Engineering, University of Minnesota–Twin Cities ejensen@cs.umn.edu, frank511@umn.edu,gini@cs.umn.eduS. Lahr is with the Division of Science and Mathematics, University ofMinnesota–Morris lahrx019@morris.umn.eduof the algorithms, both with physical experiments and sim-ulations. The remainder of this paper is structured as fol-lows: Section II reviews relevant previous work; Section IIIdescribes our long-term multi-robot patrol; we then presentresults of experiments with real robots and in simulation inSections IV and V; and we conclude in Section VI.II. B ACKGROUND AND R ELATED W ORKCoverage by a team of robots is a common task. Chosetprovides a detailed summary of different techniques [6].Coverage generally seeks to visit every point only once(e.g., [7], [8]), while patrol requires that every point bevisited as often as possible [9] or repeated times but withsome randomness [10]. Some algorithms explore the envi-ronment as they cover it, while other create paths basedon the communication capabilities of the robots (e.g., [11]).Our robots know how to reach the line they have to patroland have limited communication channels, so our algorithmassigns each robot a segment to patrol on start-up, but therobots are dynamically reallocated as needed thereafter.Frequency-based patrolling attempts to achieve uniformfrequency of point visits. In [2] this is achieved by generatinga closed path that covers the entire area and distributing therobots uniformly along this path. When cyclical behavioris an option, the cyclical path has been shown to be opti-mal [12]. However, there are tasks for which a cyclical pathcannot be created, as shown in [1].Patrolling a line with uniform frequency requires a morecomplex patrolling algorithm than patrolling a circular pathdue to the end segments that cannot be visited with thesame frequency. The overlapping patrol algorithm presentedin [3] uses an overlap factor, o, which is set to some positiveinteger (see Alg. 1). Each of the robots patrols across itsown segment, and then continues to patrol o−1 segments tothe right, stopping if it reaches the end of the patrol route.The robots pause at the end of each segment to synchronizebefore proceeding to the next segment. The overlappingpatrol improves the average frequency of point visits inthe middle segments, and attenuates the negative impact onuniformity caused by the end segments because there areusually many more middle segments than end segments.Our work extends this algorithm by removing the need tosynchronize the robots at the end of each segment and bymaintaining coverage when robots leave the segment theyare patrolling to be recharged.III. L ONG -T ERM O PEN P OLYLINE P ATROLHigh-frequency coverage is unsustainable if the robotscannot be replaced to allow for recharging/refueling. Our Algorithm 1 Frequency-based Overlapping Patrol Algo-rithm [3]1: repeat2: Patrol o segments, or until edge segment is reached3: Turn and synchronize with other robots4: if located in right-most segment then5: Wait for left neighbor to move over one segment6: end if7: Turn and synchronize with other robots8: until Stop command issuedmain objective in this research is to keep interruptions incoverageto a minimum by taking advantage of the robustnessinherent in multi-robot systems. In this section, we specifythe problem and our approach. We then present the algo-rithms we developed, and discuss performance criteria.We start with a team of r robots and a line split into ssegments of equal length l, where s ≤ r. At the center of theline, there is a control tower where extra robots are queueduntil they are needed (see Fig. 1). We assume that the lengthand number of segments is commensurate with the amountof power needed for the robots to move.Fig. 1. The layout, with s/2 segments on each side of the control tower.We define a lap as the patrol of a segment in bothdirections (forward and back) and 2T is the time it takes theslowest robot to complete a lap (worst-case lap completiontime). Lap times remain consistent until the battery powerdrops below a certain level, at which point the robot isrecalled. That threshold, b, is set to ensure that the robots areable to return to the control tower under their own power.Though all robots start at the same battery level, we havefound that, in practice, it is rare for even two robots to fallbelow this threshold at the same time.A. Algorithms.We have based our algorithms on Alg. 1, using an overlapfactor of o = 1, so each robot patrols only its assignedsegment. We removed the need for robots to synchronizeamongst themselves at the end of each segment, as theoriginal algorithm required. By allowing our robots to pa-trol their own segment independently of other robots, wereduced communication costs, which are often one of thelargest drains on battery power, and the idle time caused byvariability in the robots’ movements. We also include in ouralgorithms the initial deployment of the robots. We presenthere three algorithms: the base algorithm, the proactive recallalgorithm, and the leap-frog algorithm.Algorithm 2 Base Algorithm1: Assign and deploy a robot to each patrol segment2: repeat3: if Battery level is greater than threshold then4: Complete one patrol lap5: else6: Send low battery message7: Leave segment8: Locate and return to tower using camera9: end if10: Check messages from other robots11: if a segment is empty then12: for all active robots r do13: if r is patrolling a segment between empty seg-ment and tower then14: Move r out one segment15: Adjust segment number of r16: end if17: end for18: Deploy reinforcement robot from idle queue atcentral control tower19: end if20: until All robots have failedOn system start-up, all robots are located at the controltower’s queue, and the tower initiates communication witheach robot. Robots also start communication channels witheach other, so that they can reorganize as needed (see Alg. 2).Once communications are initialized, robots are deployed toeach segment in the polyline until all segments are covered.Any remaining robots wait in the queue until needed.In the base algorithm, once deployed each robot au-tonomously patrols its assigned segment until it either runslow on power or it receives a message that indicates it needsto move to a different location. Once a robot reports that it islow on power, it leaves its assigned segment and returns tothe control tower. Each robot patrolling between the tower’squeue and the now empty segment will jump to the nextsegment out, filling in all but the segment closest to thecentral tower. That last segment will be filled by a robotdeployed from the queue. We assume that there is a supplyof charged batteries at the control tower, and that the timeto replace batteries in a robot when it returns to base isnegligible in comparison to the time taken to deplete them.The proactive recall algorithm (see Alg. 3) aims to reduceboth the communication requirements and the number ofrobots returning at any given moment. This algorithm makesuse of a group leader for the team of robots, which we haveset as the control tower in our examples and implementation,though it could be any of the robots instead. We use twothreshold levels in this algorithm, b l = b, the threshold atwhich a robot must be recalled; and b u = b i + e, where eis some small constant (0.1 volts in our experiments) thatacts as a warning level threshold. Every ten laps, the robotssend the leader a message with their battery level. The leadermaintains a sorted list of robot battery levels, which it uses Algorithm 3 Proactive Recall Algorithm1: Sort robots by increasing value of battery levels2: Let b 1 ,b 2 ,b 3 be respectively the battery levels of the firstthree robots3: if b 1 is below threshold b l then4: Recall first robot5: else if b 1 is below threshold b u then6: Check battery level b 2 of next robot7: if b 2 < b 1 + e/2 then8: if b 3 < b 2 + e/2 then9: Recall second robot10: else11: Recall the first robot12: end if13: end if14: end ifto determine when a robot needs to be recalled.The leap-frog algorithm improves upon the deploymentof replacement robots. In our base algorithm, the robot withthe most battery power remaining always ends up nearest thecontrol tower, while the robots with less power end up furtheraway. We hypothesized that this would be sub-optimal, asthose robots would then have to go further to get back tothe control tower, so they would need to be recalled soonerthan if they had stayed in their original places. In the leap-frog algorithm, the replacement robot makes its way to thesegment that was vacated, rather than simply filling in at thesegment closest to the control tower. To do this, we relaxedthe constraint that only one robot may be on a segment at atime, which we accomplished by adding a second segmentparallel to each existing segment to act as a passing lane.B. Performance Criteria.We use the performance criteria proposed in [3]. Unifor-mity refers to the frequency with which each point on theroute is visited. We would like to reduce the variance in thisfrequency. Maximal average refers to the average frequencyof visits to each point. We want to maximize this, so that eachpoint is visited as often as possible, on average. The maingoal here is to make sure that no point is left unvisited for toolong. Maximal minimum frequency is the minimal frequencyof visit for any point, which we want also to maximize. Thisis accomplished trivially by setting the overlap factor o = 1.When no robots are low on power, our patrol systemhas the same properties as that of [3]. As in the originalalgorithm, the frequency of visits is uniform only at thecenter of each segment, and the difference in visit frequenciesgrows larger as points are closer to the end of the segment.The endpoints will be visited twice in a row, so the timeinterval between visits is 0, but it will take an entire lapbefore the endpoint is visited again, which will average to Tbetween visits. At the center point of a segment, the robotwill move to the end and then back to the center, which takesT time to complete. For all other points the two intervalsvary, but the average time interval between visits is still T.Fig. 2. Two Scribbler robots with attached Flukes.Determining the maximal average of visits is more difficultwhen a robot returns to base and other robots fill in for it.For a short time, the interval between visits to each point isincreased, because one segment is not being covered. Whenthe robot, r 0 , patrolling segment s 0 , runs low on power, therobot to its left, r 1 must fill in. In the best case, r 1 willbe just arriving at the point between s 1 and s 0 and cansimply jump over to s 0 , in which case it will take only Tto return to the normal visit frequency for segment s 0 (r 1must reach the far end of s 0 for this to happen, which willtake T). In the worst case, r 1 just turned back to return tothe opposite end of s 1 , a process which we do not wishto disrupt for two reasons. First, we do not want to leaveany point uncovered for too long, and completing the lapensures that we can make guarantees about the frequencyof visit; and second, because of odometry errors r 1 mightget lost, which would be detrimental to the system’s overallperformance. Allowing r 1 to complete its current lap leadsto a 3T delay before s 0 will be patrolled with an averageinterval of T again. This process must be repeated for everyother segment between the vacated segment and the controltower, however robots can be jumping simultaneously, andthe new robot is deployed as soon as the near segment iscleared, so it will still only take 3T to return to normal.IV. P HYSICAL R OBOT E XPERIMENTSIn the physical experiments, we were most interested inshowing that our algorithm worked properly in a real worldimplementation. We wanted to ensure the algorithm wouldwork with the physical robots first, and use the results of theexperiments to build our simulation, so that the simulationwould be an accurate representation of the real world.A. Experimental Setup.We used the Scribbler robots augmented with the Fluke(see Fig. 2), which has a camera and Bluetooth capability.We used the line-following IR sensors located underneaththe Scribbler, which provide a binary response distinguish-ing light from dark, and the camera, which provides blobfollowing. The Scribblers have limited capabilities, so wehad to adjust our base algorithm to work within those TABLE IR ESULTS FROM A SIX ROBOT , FOUR SEGMENT EXPERIMENT . T IMES ARE MEASURED IN SECONDS .Name Anders Caprica Hera Leoben Sharon Tory OverallAvg. Lap Time 16.11 20.89 25.21 16.28 28.15 26.29 19.60Lap Time SD 3.02 3.60 2.52 2.99 2.06 3.92 4.80Avg. Return Time 3.25 3.43 0 3.83 0 3.75 3.48Idle Time 66.72 1533.75 0 792.77 152.19 2598.39 5143.82% Idle 1.64% 37.57% 0.00% 19.58% 21.28% 68.71% 24.82%Fig. 3. The physical experimental setup. Two Scribblers are alreadypatrolling segments, while a third stands by in the queue.limitations. For example, the availability of only Bluetoothcommunication, forced us to implement our algorithm in amore centralized manner, with all messages going throughthe control tower.The physical environment setup can be seen in Fig. 3.It consists of a straight line divided into six equal-lengthsegments. The tower is located in the middle with a queueleading to the main patrol line. Each segment is a black,one inch wide and 33 inch long strip, with an eight-inchapproach region on the end nearest to the control tower.All segments are separated by a nine-inch white space toprevent collisions between robots on adjacent segments.The following accommodations were made to attenuate thelimitations of these particular robots. The approach region iswider than the rest of the segment to allow for error whenthe robots jump between segments. The Scribblers followthe segments using the two IR sensors underneath them.Orange targets hung above the path mark the beginningof the segments, and were used for additional alignmentfunctionality using the Fluke’s camera. The camera is alsoused for locating and returning to the control tower, markedby a large green target. Obviously, for a real deployment wewould use more sophisticated robots and different methodsfor tracking the segments to be patrolled.B. Experiments and Results.We tested the longevity of the system using six robotsand four segments, with two robots idle in the queue. Therobots were run for one 75 minute experiment, including1.5 minutes to start-up (tower connecting with robots) and3.5 minutes of initial deployment time, giving 70 minutes ofpatrol time. The robots all started at the control tower, andwere deployed one by one. The results of this experimentcan be seen in Table I. The average lap time was 19.60s andthe average time spent idle was 24.82% of the total run time.We also measured the rate of decrease in battery level in aseparate, 40 minute experiment. The battery level decreasedby 0.33 volts every hour, with an average lap time of 18.12s.C. Discussion.From these experiments, we observed that the lap timeswere fairly consistent for each individual robot, but were notuniform across robots. We also saw an increase in lap timebetween the four robot and six robot experiments, which wascaused by two robots being much slower than the other four.We realized that the amount of idle time and active timedepends greatly on the ratio of robots to segments, and isvery important to the overall longevity of the system. Onereason for this is that too many robots in the queue resultsin more time spent idling, which is especially problematicif the robots are also expending power during the idle time.We have seen a robot run out of power and fail while idlingin the queue. Since we wanted the system as a whole tobe as autonomous as possible, we did not want to have tobuild in an interval in which we would manually switch on arobot only when it was needed, so the idle robots always hadto be ready. With r robots and s segments to patrol, wherer > s, the fraction of the time the robots are idle on averageis (r −s)/r. While we saw an idle time of only 24% of thetotal time in the second experiment, the reported times aremisleading, because one robot, Sharon, failed upon returningto base, and so 3319 seconds of idle time are missing fromthe totals. When this is accounted for, the percentage of idletime is 35%, which is closer to what we expected with 1/3of the robots in the idle queue at all times.Our base algorithm successfully maintained patrol ofevery segment. However, there was no way to expand ourexperiments to a longer line or multiple towers due tospace limitations in our lab. Time limitations were also aconcern because we wanted to scale the system up, buteven the small experiments we conducted required constantsupervision, making larger scale experiments impractical. Forthese reasons, we decided that a simulation, using the datacollected from the physical experiments as a model, wouldbe beneficial in further testing of our algorithm. A simulation Fig. 4. Partial view of the simulation environment. The control tower isdesignated as segment 3. The robot on the left is in the process of returningto base. The “whiskers” on the round robots denote the field of view of thecamera, which is used to track the tower and to avoid obstacles.would allow us to test larger and more complicated scenarios,and as well as allow us to do many more experimental runs.V. S IMULATIONSOur goal for the simulations was to run longer andmore complex experiments involving more robots. The mainproblem we encountered with the physical experiments wasthe sensor noise inherent in the environment.The line sensorsoperated in the IR spectrum and finding a material thatwould absorb IR and return the necessary values proved to bedifficult. Even with a suitable medium, inconsistencies suchas dirt, changes in lighting, and scuff marks from the robots’wheels caused errors in the sensor readings. In our simulationwe wanted to increase the reliability of the sensor data, whileretaining the system’s non-deterministic properties.We implemented our own simulation environment (seeFig. 4). Within the simulation environment, we assumedthat the robots have perfect sensor readings, but we addednoise–a random variable from a Gaussian distribution witha mean of 0 and a standard deviation of 0.125–into therobots’ linear and rotational velocities at each time step tosimulate environmental and hardware variances. This wascombined with the simulated sensors into a proxy that madeuse of the same API used by the physical robots, allowingus to switch between real robots and simulations with nochanges to the underlying patrol algorithms. We ran all threealgorithms in the simulations, continuing with the centralizedversion in order to obtain meaningful comparisons betweenthe simulations and physical experiment results.A. Experiments and Results.As a test of the comparability of the simulation to thephysical experiments, we measured deployment time for6 robots over 4 segments, just as we did in the physicalenvironment and found them to be very close (physical took3.5 minutes, simulation took 3.25 minutes).Since one of our main reasons for using simulation wasto increase the size of our experiments, we then ran a set ofsimulations using eight robots patrolling six segments, withthe same setup and procedure as the physical experiments.The simulation data was collected from multiple runs totalingover 5 hours of patrol time. With 2 robots always idle, weexpected to see idle times around 25%. In the runs usingthe base algorithm, the average lap time was 16.04s, and theTABLE IIL AP TIMES ( IN SECONDS ) FOR EACH EXPERIMENT AND ALGORITHM .Environment Algorithm Average St. Dev.Physical Base Algorithm 19.60 4.84Simulation Base Algorithm 19.22 1.27Simulation Proactive Recall 18.90 3.53Simulation Leap-Frog 18.65 1.44Simulation Leap-Frog + Proactive 19.44 3.05percentage of time spent idle was 34.18%. The simulationsusing the proactive recall algorithm had an average lap timeof 18.90s and only 11.26% idle time. We determined that thissignificant difference of idle time stemmed from the way wehad structured communication between the robots and thetower in the proactive recall algorithm. We restructured thecommunicationfor the base algorithm and found that we nowhad 19.22s average lap times and 12.21% idle time, similarto the proactive recall results.In our final set of experiments, we ran the simulations with10 robots patrolling six segments, and so expected at most40% idle time. We ran three simulations for comparison,one using the proactive recall algorithm, one using the leap-frog algorithm, and one using a combination of the twoalgorithms. For each setup, we collected 24 hours of data.Again, the average lap times are similar to those in both theoriginal physical experiments and in our previous simulations(see Table II for complete data). There was no significantdifference between any of the three algorithms (see Fig. 5).We also recorded the time between visits to one of theendpoints on each line segment (see Figure 6) for each ofthe algorithms. We see that there are some fluctuations inpoint visit intervals depending on the line segment, whichwe believe is due to how often a segment is traversed onthe way to a further out segment. However, we see that theleap-frog method has shorter intervals, because there can betwo robots on a segment for a short time, so the patrol is notinterrupted as much as in the base and proactive algorithms.B. Discussion.In comparing simulations to the physical experiments,using just the base algorithm, there were some minordifferences, but overall the results were comparable. Theaverage lap time, in particular, was more consistent than wehad expected, though the perfect sensor data reduced thevariability of the lap times in the simulation.We saw greater improvement than we had anticipatedafter implementing the proactive recall algorithm. Furtheranalysis showed that most of the performance improvementcame from the manner in which we implemented the com-munication between the control tower and the robots. Theproactive recall algorithm is still necessary for maintainingmaximal average frequency of point visits. In the physicalexperiments, there were long intervals between returningrobots, so it was not apparent that the proactive recallalgorithm would be useful, let alone necessary. However, in Fig. 5. Average percentage of time spent idle in simulations by algorithm:proactive recall, leap-frog, and leap-frog with proactive recall. Error barsshow 1 standard deviation.the simulation we saw all the robots return to the tower at thesame time. Not only did this increase the percentage of timespent idle for the entire system, but it also greatly reduced theaverage frequency with which the segments were patrolled,which is a significant issue when our objective is to maintaina high frequency of coverage. The proactive recall algorithmlimits the number of robots that are returning at any giventime to maintain the maximal average frequency at the levelof our original algorithm.The average return time with the leap-frog method isshorter than in our original recall method (47s and 65s,respectively), due to the fact that the robots that are returningare closer to the control tower. This is because we are nolonger pushing the robots with lower battery power out tothe end (since the first robot to return is almost always anend robot), but are instead getting the fresh robot out there.As an added benefit we have more time to recharge a robotafter it returns, which will reduce the number of backuprobots necessary to maintain the patrol. We expect that thisimprovement would be even more noticeable if there weremore than 3 segments on each side of the tower.VI. C ONCLUSIONS AND F UTURE W ORKWe extended a previous algorithm for frequency-basedpatrol on an open line, with a focus on maintaining the patrolover the long-term. We achieved this by keeping some robotsin reserve, while the other robots patrol assigned segments.A robot is removed from the line and replaced once its powerlevel drops below a threshold. We explored different ap-proaches to the recall and replacement actions. We performedboth physical robot and simulation experiments.We have begun work on creating a multi-tower scenario, inwhich there are multiple control towers, each with their ownset of segments and robots. This extension paves the wayfor a large scale implementation, with the added bonus thatneighboring towers will be able to lend or borrow robots ifnecessary, making the system more robust to robot failures.We are also exploring the best allocation of resources, so thatas few robots as possible are idle in the queue. One methodFig. 6. Time between visits (in seconds) to a specific point on each linesegment in a 10 robot, 6 segment simulation.is to continually move robots with lower power reservestowards the tower to minimize replacement time. Our thirdline of inquiry is into paths composed of complex polylines,with curves and unequal segment lengths, in order to simulatechanges in terrain.R EFERENCES[1] A. Almeida, G. Ramalho, H. Santana, P. Tedesco, T. Menezes,V. Corruble, and Y. Chevaleyre, “Recent advances on multi-agentpatrolling,” in Advances in Artificial Intelligence (SBIA 2004), April2004, pp. 474–483.[2] Y. Elmaliach, N. Agmon, and G. Kaminka, “Multi-robot area patrolunder frequency constraints,” in Proc. IEEE Int’l Conf. on Roboticsand Automation, April 2007, pp. 385–390.[3] Y. Elmaliach, A. Shiloni, and G. A. Kaminka, “A realistic model offrequency-based multi-robot polyline patrolling,” in Proc. Int’l Conf.on Autonomous Agents and Multi-Agent Systems, 2008, pp. 63–70.[4] N. Agmon, S. Kraus, and G. Kaminka, “Multi-robot perimeter patrolin adversarial settings,” in Proc. IEEE Int’l Conf. on Robotics andAutomation, May 2008, pp. 2339–2345.[5] N. Basilico, N. Gatti, and F. Amigoni, “Leader-follower strategies forrobotic patrolling in environments with arbitrary topologies,” in Proc.Int’l Conf. on Autonomous Agents and Multi-Agent Systems, 2009, pp.57–64.[6] H. Choset, “Coverage for robotics – a survey of recent results,” Annalsof Mathematics and Artificial Intelligence, vol. 31, no. 1-4, pp. 113–126, 2001.[7] K. Williams and J. Burdick, “Multi-robot boundary coverage with planrevision,” in Proc. IEEE Int’l Conf. on Robotics and Automation, May.2006, pp. 1716 –1723.[8] P. Amstutz, N. Correll, and A. Martinoli, “Distributed boundary cover-age with a team of networked miniature robots using a robust market-based algorithm,” Annals of Mathematics and Artificial Intelligence,no. 2-4, pp. 307–333, 2009.[9] A. Machado, G. Ramalho, J.-D. Zucker, and A. Drogoul, “Multi-agent patrolling: An empirical analysis of alternative architectures,” inMulti-Agent-Based Simulation, Third International Workshop, 2002,pp. 155–170.[10] A. Marino, L. E. Parker, G. Antonelli, and F. Caccavale, “Behavioralcontrol for multi-robot perimeter patrol: A finite state automata ap-proach,” in Proc. IEEE Int’l Conf. on Robotics and Automation, 2009.[11] I. Rekleitis, A. P. New, E. S. Rankin, and H. Choset, “Efficientboustrophedon multi-robot coverage: an algorithmic approach,” Annalsof Mathematics and Artificial Intelligence, vol. 52, no. 2-4, pp. 109–142, 2008.[12] Y. Chevaleyre, F. Sempe, and G. Ramalho, “A theoretical analysis ofmulti-agent patrolling strategies,” in Proc. Int’l Conf. on AutonomousAgents and Multi-Agent Systems, vol. 3, 2004, pp. 1524–1525.

关注我们

关注微信公众号

您选择了以下内容

页面底部区域 foot.htm