Seite - 65 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

to observe the environment and to gather information. This is achieved by using a laser scanner for localization and cameras for machine detection. To explore the game-field in an efficient manner with mul- tiple robots, a scheduling algorithm has to be implemented. For this, our software architecture described in SectionIII comes into play. With the centralized team server, it is possible to generate a global exploration strategy and to combine the information delivered by all the robots into one reliable and consistent database. During the exploration phase, all robots have the non- blocking task to report all seen machines, i.e. the zone, orientation (in discrete steps) and light pattern as well as the corresponding confidence. These updates are sent to the team server if parts of the information changes (e.g. orientation is corrected), new information is added (e.g. a lightpattern isdetected)or theconfidence ofa property rises. This information is then collected at the team server as an observations database. To start the exploration with no observed date (i.e. at the beginning of the exploration phase) the default task for the first robot is to explore the top most left zone of the game field if the team starts at the right start box or the top right zone of the game field if the team starts at the left start box (see Figure 1). Using this simple strategy, the probability is very high that on the way to the destination zone the robot observed other machines and reported them to the team server. As soon as another robot is ready for a task or the first robot has finished its navigation, the robot gets the task assigned to visited a zone. During the visiting of a zone, the robot detects if a machine is within the zone. If a machine is present, the robot performs a light detection of the machine. If no machine position is reported so far, the robot gets a backup task to visit a randomly chosen zone which was not visited before. Otherwise, the robot is sent to a zone with a high probability that a machine is in this zone (one robot has reported that there should be a machine) but was not visited before. If all zones are visited, the zone with the lowest confidence is chosen as the next task. This allows maximizing the confidence of the machine information. The simplified algorithm can be seen in Algorithm 1. With the start position in the team boxes (as it can be seen in Figure 1) it is very likely that at least one machine is seen already in the start position. Thus the usual procedure is that the first robot directly reports at least one machine at start- up. The team server creates a task for this robot and sends it to discover the light state and the correct orientation. On its way, the robot reports other machines, and so the other robots can be sent to zones with machines too. Thus the backup solution to drive to some randomly chosen zone is rarely used. This dynamic scheduling allows a very efficient and fast exploration of the whole game field. This is necessary as the game field is rather large (12m×6m) for the low speed these robots are able to move. Another advantage of the global view of the team server can be used here too. The machines are distributed at the Algorithm 1: Exploration Algorithm Input: observations, notVisitedZones, #MPS, thresh Output: task 1: if observations=∅ then 2: if oppositeZone∈ notVisitedZones then 3: return exploreZone(oppositeZone) 4: else 5: zone = chooseRandom(notVisitedZones) 6: return exploreZone(zone) 7: end if 8: else 9: if numZonesNotVisited(observations)> 0 then 10: zones = zonesNotVisited(observations) 11: zone = getZoneWithLowestConfidence(zones) 12: return exploreZone(zone) 13: end if 14: if mFound(observations, thresh)< #MPS then 15: zone = chooseRandom(notVisitedZones) 16: return exploreZone(zone) 17: else 18: zones = zonesNotVisited(observations) 19: zone = getZoneWithLowestConfidence(zones) 20: return exploreZone(zone) 21: end if 22: end if game-field in a symmetric fashion to allow fair conditions for both teams. This constraint can be used for a sanity check of the reports, i.e. before the final result is sent to the referee box, it is checked if it makes sense and the most probable consistent set of observations is reported. After the exploration phase, the set of reliable machine po- sitions and orientations is then broadcasted to the connected robots to allow them to work during the production phase with the gathered information. Also if one robot has to be restarted during the production phase, the information about the position of the machines is provided as a new (or in this case restarted) robot connects to the team server. V. RELATED RESEARCH In the previous section we have discussed our software architecture how to solve the challenges in the RoboCup logistic league. Within this section we will discuss another approach to solve the problems inRoboCup Logistic League. We will compare our approach to the Carologistics Team which won the world championships several times. As the Carologistics Team describes in its team description paper [15], they also use a three-layer architecture. A. Carologistics The main difference is that no central coordinator is used. Instead a distributed, local-scope and incremental reasoning approach [16] is chosen. This has the advantage of no single point of failure but also the disadvantage that no optimal global strategy can be derived. To keep a consistent view of 65