Dutch Nao Team - Universiteit van Amsterdam

More documents

Recommendations

Info

4.1 Architecture The program solves the game problem using a double state machine in the file soul.py. At the highest level are the states, which are the game states as specified by the gamecontroller. At a lower level are the phases, which are specific situations during a game. Transitions between the states and phases are made based on external input (conditions). For the states the external input are messages from the GameController and/or the button interface (see section 4.4). For the phases the external input are based on observations (see section 4.2). Zoiets? BallFound BallNotFound ball seen ball lost ball lost ball too far Kick ball close In each of these phases, checks are made to see if conditions for transition are met (e.g. if in BallFound phase and ball close enough for a kick, go to Kick phase). An advantage of this approach is that the main problem, playing a game of soccer, is divided into smaller problems which can be solved independently and locally. A second advantage is that phases can be tested without executing the entire program. In effect, the tests are less time-consuming. On the other hand, the Nao is not able to process circumstances that aren’t specified in a phase. The solution implemented is a straightforward one where phases can not be interrupted until they have finished. This would not, or less so, be the case if a single program covered the entire game problem. [Arnoud]: Unpenalized phase not introduced! Except for the Unpenalized phase, a phase contains the following: • A call to receive visual information and, if needed, further processing of this information • One or more condition checks for transition to other phases • One or more motion calls • Optional: print statements for debugging purposes As each phase is implemented as a Python function, it can be called independently. Our system thus works as a loop calling the function corresponding to a game phase. It should be noted that the phase can be changed in each state but the corresponding function is only called in the Playing state. 4.2 Vision Justin, Michael, Anna, Robert? 4
4.3 Motion All of the motions designed are keyframe motions, the kicks being a special case. The kick and back kick are given an angle (angle to the goal) as input. The result is an open-loop motion kicking the ball in the specified angle. The keeper movements are of our own design. We use the walk engine by Aldebaran which is a stable omnidirectional walk. Get-up motions are improved versions of the motions provided in Choreographe. [Arnoud] is het verschil tussen de Get-Up motion te demonstreren m.b.v. twee foto’s? 4.4 Communication At first, our program was tuned to listen to a specific I.P. address. It would receive the input stream, parse it, and store the information in a GameController object. Recieving the data was done by the textitrefresh() method, and the object had several get methods to acquire the data from the object. The refresh method returned true if it had recieved data, and false if it hadnt While we were at the Rome Open, we made the program display the right L.E.D.s on the chest and feet, depending on the current team color and the game state (green for playing, rd for penalized, etc.). After the Rome Open, we implemented the button interface, and combined it with the game controller to make a state controller, a threaded module which could be called to get the game state according to the buttons and game controller (if it was there). We also implemented the textitcontrolledRefresh method, which kept calling the refresh method for some time to see if the game controller was still online (default 4 seconds). If it was, it would return true. If the connection timed out, it would return false, and the state controller would start listening to the buttons for a while, before trying to connect with the game controller again. In Istanbul we found that some teams were broadcasting their own game controllers on the same IP, which caused problems as our program would listen to all of them. There, we made sure it would only listen to game controllers broadcasting a match with our team number in it. 4.5 Localization While not yet implemented into soul a novel localization method has been developed: Dynamic Tree Localization (DTL). The algorithm is tested with the Gutmann dataset [5] and is currently extended to work on a NAO. All the DTL code, the used datasets and the code used to test the algorithm can be found at: http://hesselvandermolen.dyndns.org/BachelorProject/index.php?page=Doc. To run the code, Python 2.61, OpenCV 2.1 and Pygame 1.9.1 have to be installed. The code is only tested with the 32bit Windows versions of the necessary programs. It is however assumed that it should be able to work on multiple platforms and with newer versions which are backwards compatible. 4.5.1 The Algorithm Dynamic Tree Localization is a localization method which uses a k-d tree [2] to represent the belief of a robot. The root node of the belief-tree represents the complete environment. Each sub-node (child) represents a smaller area of the environment than its parent node. The total surface-size described by all children of a node equals the surface-size of the parent-node: surface(child1) ⊕ surface(child2) ⊕ ... ⊕ surface(childn) = surface(parent) 5
Page 1 and 2: 1 Introduction Dutch Nao Team Techn
Page 3: Figure 2: Title page of the Researc
Page 7 and 8: dmax = 10. Figure 5: Accuracy-test
Page 9 and 10: Figure 7: Beacon detection. Instruc
Page 11 and 12: The UDK version of UsarSim can be d
Page 13 and 14: References [1] M. van Bellen, R. Ie
Page 15 and 16: 12.2 Open Challenge Document June T
Page 17: 12.4 Sponsor Letter 12.5 Travel Doc

Dutch Nao Team - Universiteit van Amsterdam

Create successful ePaper yourself

Delete template?

Save as template?