Walking the Grid: Robotics in CS 2

Transcription

1 Walking the Grid: Robotics in CS 2 Myles F. McNally Department of Mathematics and Computer Science Alma College Alma, MI, 48801, USA mcnally@alma.edu Abstract This paper describes the use of inexpensive robotics platforms to create engaging student projects for a second course in computer programming. These projects employ the stack and queue data structures, reinforce basic concepts such as two dimensional arrays, and are situated in the context of modern, object-oriented programming. Advanced concepts from autonomous mobile robotics are introduced in a gentle manner, including occupancy grids, path planning, and sensor fusion. The fundamentals of depth and breadth first search are used in the solutions to the various projects described.. Keywords: Data structures, graph search, robotics, path planning. 1 Introduction The goal of the GridWalker project is to create engaging object-oriented programming projects that introduce themes from Artificial Intelligence and Robotics into the second programming course, often referred to as CS2. These projects can be used once students have been introduced to the stack and queue data structures, and reinforce material usually covered in an earlier course such as classes, interfaces, and inheritance, two dimensional arrays, and exception handling. Students find projects employing robotics motivating, leading to increased time on task and enhanced learning. Such projects also allow students to see the practical applications of programming, often overlooked in introductory courses. Many different robot designs can be used in the solutions to the following projects, but whatever design is chosen it must employ differential drive the left and right side wheels must be able to turn independently, hence allowing the robot to rotate in place by turning its wheels in opposite directions. In our course we use Lego Mindstorms robots and the Java programming language, in particular LeJOS (well described in Bagwell 2002), but these projects could be easily adapted to other robotic platforms and programming languages. We choose Mindstorms because of its inexpensive cost, easy of Copyright 2006, Australian Computer Society, Inc. This paper appeared at the Eighth Australasian Computing Education Conference (ACE2006), Hobart, Tasmania, Australia, January Conferences in Research in Practice in Information Technology, Vol. 52. Denise Tolhurst and Samuel Mann Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included. customisation, and its widespread adoption among computer science educators (cf. Barnes 2002, Kay 2003, and Lawhead et al 2003 for good discussions and a number of references). We call our robot the GridWalker and optionally equip it with a sonar sensor to allow it to detect obstacles at a distance. The laboratory projects described below are available on our website, and sample solutions will be provided to instructors on request. 2 Occupancy Grids Each of the projects has at its foundation the use of an occupancy grid. This notion, drawn from work in autonomous mobile robots (cf. Murphy 2000, Siegwart and Nourbakhsh 2004), is often used in the solution of navigation (How do I get where I want to go?) and localization (Where am I?) problems. Such a grid is a discrete approximation of the environment the robot finds itself in. Each cell represents an area of the environment and is either marked free (the corresponding area contains no obstacles) or occupied. If any part of the area the cell represents contains an obstacle the cell is considered occupied. Robots cannot move into occupied cells. Figure 1 shows an example occupancy grid. The black shapes are obstacles, the grey grid cells are considered occupied, and the white cells free. Figure 1: An Occupancy Grid Grids representing real world environments are often fine grained, representing areas 4 to 6 inches square. The finer the grain of the occupancy grid the better it represents the environment. But fine grained grids lead to computational challenges and require large amounts of memory, two challenges the RCX (the Mindstorms computer control brick) cannot easily handle. On the other hand, coarse grids can mask a number of environmental features, such as narrow passageways. So in real world applications robots (and their designers) must take these trade offs into consideration. Our GridWalker projects will avoid these issues by using simplified environments such as that shown in Figure 1.

2 Using a large scale printer, we have printed a grid for the GridWalker to roam around in that is the physical embodiment of the occupancy grid the GridWalker will use when computing its movements. Blocks from a children s toy set are used to define the occupied cells. Figure 2 shows the GridWalker placed on the grid with occupied cells defined by blocks. Figure 2: Basic GridWalker Environment In the advanced projects the goal will be path planning: the computation of a path from a starting point to goal point in a known (or in one project an unknown) environment. But to begin we need to be able to move reliably from cell to cell, which is a major goal of Project 1. 3 Project 1: A Random Walk (and Back!) The goal of the first project is easy to state: Placed on the grid in an arbitrary (but known) starting position, the GridWalker goes on a random walk for a fixed number of steps, and then retraces its steps back to its starting point. The GridWalker is only permitted to move one cell to the north, south, east, or west at a time (the so-called 4-rule). No diagonal or other movements are permitted. The solution of this project involves the straightforward use of a stack. During the random walk phase, the direction of each movement is in turn pushed on the stack. When the GridWalker returns it pops items off of the stack and travels a single square in the opposite direction. When the stack is empty the GridWalker has returned to its starting point. Often during the random walk phase the robot will move forward and then immediately back. On the return trip the robot can skip this oscillation by peeking onto the stack after each pop. If the peek reveals a movement in the opposite direction from that which was just popped, both are ignored. Such an improvement is considered in Johnson-Laird We chose not to use the Java collection classes in our course. Students implement a simple stack class and a single stack exception class in their solution. An instructor might prefer to have their students implement separate underflow and overflow exception classes. The more difficult part of this assignment is getting the GridWalker to accurately move from cell to cell. This requires the solution of the odometry problem: getting a robot to move around in an environment while reliably tracking its location. We ask students to define a GridWalker class that contains: A constructor that specifies the number of rows and columns in grid, the grid cell size, and the starting location of the robot. A goto method that takes as a parameter a grid location and causes the robot to move from its current location to that location. Parameterless methods north, east, south, and west that cause the robot to move one cell in the respective direction. These methods use the goto method in their solution. A first approach to a solution might use timing. Students would measure how long it takes their robot to move a fixed distance, and then use that amount to compute required travelling times. Similarly they would measure turn times. Experience shows that this is not a particularly accurate approach, as robot speed depends on battery strength, which erodes over time. However this approach could be used. A more accurate approach uses axle encoders (also know as rotation sensors), which measure wheel rotations. Such sensors are not part of the standard Mindstorms kit, but can be inexpensively purchased from Lego. One threads an axle through the sensor, and each revolution of the axle is 16 clicks on the sensor, which means that the sensor can measure a change in axle orientation of 22.5 degrees. This would be a rather coarse reading if it was a direct wheel reading. So the sensor is usually connected to a gear train that gears it down. In our experience a 1 to 5 reduction is sufficient, giving 80 clicks for each revolution of the wheel, for a sensitivity of 4.5 degrees. Figure 3 shows a modification of the standard Roverbot design (found in the Lego Constructopedia which comes with the Mindstorms Invention 2.0 kit) that has a rotation sensor connected to each wheel. The RCX then sits on top. Figure 3: Chassis with Rotation Sensors Using such sensors, once the wheel size, distance between the wheels, and gear ratio is known, the robot can be made to both accurately travel distances and make turns by the solution of well-known kinematic equations. Such equations are a topic better left to a later robotics course. Fortunately the Java system LeJOS for Mindstorms provides a Rotation Navigator class in which

3 these equations are already implemented (cf. Bagnall 2002). Students are merely asked to extend this class in their solution. The constructor for the RotationNavigator takes as its parameters the wheel diameter, the axle width, and the ratio of encoder revolutions to wheel revolutions. Important RotationNavigator methods for this project are the following: public void gotopoint(float x, float y). Rotates the RCX robot towards the target point and moves the required distance. public float getx(). Returns the current x coordinate of the RCX. public float gety(). Returns the current y coordinate of the RCX. public float getangle(). Returns the current angle the RCX robot is facing. The student extends this class, maintaining instance variables for the current grid location, the size of the grid, and the size of a grid cell. In implementing the goto method, the student needs to check that the new location is legal (i.e., in the grid). If it is not, an exception should be thrown (optional, but a good opportunity to reinforce the use of programmer defined exceptions). The student also needs to convert grid locations to absolute locations. The RotationNavigator assumes the robot starts at 0,0 with an orientation of 0 degrees. The GridWalker allows the programmer to specify any cell as the starting location, but still assumes orientation of 0 degrees. 4 Project 2: Wavefront Propagation The Path Planning Problem is the determination of a path from a starting position to a goal position in an environment containing obstacles. Numerous solutions to this problem exist (cf. Murphy 2000, Siegwart and Nourbakhsh 2004). In a later project we consider using classical graph searching algorithms on the implicit adjacency graph defined by the occupancy grid. But in this project we employ a technique well known in the robotics community but not as well known elsewhere. To solve this problem, imagine a wavefront moving out from the goal cell. The wave moves according to the 4- rule. When the wave first reaches a cell it is labelled with the amount of time it took to reach it. If there are obstacles the wave simply flows around them. Figure 4 shows the distance values in our occupancy grid after the wavefront propagates from the bottom-right cell. Each cell label represents the number of steps required to reach the goal from the so labelled cell. For a robot to reach the goal from any starting location, it repeatedly moves to an adjacent cell with a lesser label until the goal is reached. Figure 4 shows a solution path in light grey from the cell at the bottom left. There are usually many equivalent but different solution paths. Figure 4: Wavefront Times and a Solution Path from Starting Point (bottom-left) to Goal (bottom-right) Labelling the occupancy grid cells employs an algorithm that is corresponds to breadth-first search, using a queue of points as the basic data structure. Here are the basics: Allocate a new two dimensional array D the size of the occupancy grid. Set cells in D which correspond to occupied cells to high values and all others to -1. Set the value of the goal cell to 0. Enqueue the location of the goal cell (a point). While (queue is not empty) Dequeue a point L. Find the value V associated with point L in D. Find the neighbours of L with a -1 value. Set the values of these neighbours to V+1. Enqueue each of these points. Once the distance array D has been populated the robot can easily move to the goal cell as described above. However, if the starting cell still has a -1 value after initialisation the goal cell is unreachable and no solution path exists. Students are asked to implement the queue class and an associated queue exception class, and a separate grid class that encapsulates the details of the occupancy grid. They hard code the starting and ending locations, and which cells in the occupancy grid are occupied, among other things. It would be easy to extend this assignment so that this information was supplied to the RCX by a remote program on a base computer (cf. Scholz 2005), but issues of data communication are not really goals of this project. 5 Project 3: Adding Sonar Sonar sensors are not part of the basic Mindstorms kit, but can be inexpensively purchased from third party vendors. With such a sensor mounted on our robot, obstacles can be sensed from a distance, and hence the robot can decide which cells in the grid are occupied as it moves about its environment. Figure 5 shows our GridWalker robot augmented with a sonar unit.

4 free or occupied, it is marked with the degree of confidence the robot has that it is occupied, based on past sensor readings. A threshold value is set and the robot considers any cell with such a value or higher to be occupied. Each time the robot employs its sonar it updates its confidence factors. Students can experiment with the range of confidence values and the associated threshold value to see what works best in their environment. 6 Project 4: Classical Search Algorithms Figure 5: GridWalker with Sonar Project 3 extends the previous project by beginning with an occupancy grid in which all cells are marked free, and dynamically recomputes its route as it encounters obstacles during its travel. Here is the outline of the approach: Perform the wavefront labelling routine using an occupancy grid with all cells marked free. Do Determine a direction to travel. Orient robot in that direction. Use sonar to check if next cell in that direction is occupied. If it is, update occupancy grid and rerun labelling routine. If it is not, move to that cell. while (goal not reached and the cell label not -1) Simple orientation of the robot is not part of the original GridWalker specification, so students will need to add that capability. As stated here, students are only asked to check if the next cell in the desired travel direction is occupied. But most sonar systems available for robotic system are reasonably accurate up to about eight feet (cf. Mindsensors 2005 for the specifications of the sonar system we employed). Students can thus be asked to experiment with detecting occupied cells at further distances. Since the sonar beam spreads at an approximately 30 angle, false readings due to adjacent occupied cells occur as distances increase, and distance readings can be inaccurate as well. A cell that appears to be occupied may not be, and students need to take this into consideration, perhaps only considering obstacles detected close by. An advanced option for this project is to model the uncertainty of sonar readings by combining their results over time an instance of the so-called sensor fusion problem. See Murphy 2000 for a survey of such approaches. We have found the HIMM method of Borenstein and Koren 1991 to be simple enough for good students in a second programming course to handle. This straightforward approach uses confidence factors to model uncertainty. Instead of a cell being either marked Any of the well known graph search algorithms can be used by the GridWalker to do plan planning. Depth-first and breadth-first recommend themselves due to their simplicity, but best-first or hill-climbing could be implemented. Details of these search algorithms can be found in almost any artificial intelligence textbook (e.g., Russell and Norvig 2002) and in many data structures texts (e.g., Goodrich and Tamassia 2003). Since the adjacency graph is implicit in the occupancy grid, no explicit graph needs to be represented and the data structure requirements are limited to arrays, stacks, and queues. This project is independent of project 2, requiring only the successful completion of project 1. It can also be extended in basically the same way the project 3 extends project 2. Since these are very well known algorithms we only sketch an example here, namely a variation of depth-first search. Students are asked to write the class definition for the search algorithm that has A constructor that takes an occupancy grid as a parameter. A findpath method, which takes as parameters starting and ending points and returns the solution path in a vector. The findpath method uses a stack of points as the basic data structure, and a two dimensional array of points in which the path is labelled. Allocate a new two dimensional array of points F the size of the occupancy grid. Set each of the point references in F to null. Push the location of the start cell (a point). While (stack is not empty and goal not found) Pop a point L. If L is the goal, break. Find the unoccupied neighbours of L with a null value in F. Set the values of these neighbours in F to L. Push each of these points. If the goal is found, the path can be found in array F. Since each visited cell contains the location of the cell it was visited from, the path is retrieved by working back from the goal cell to the start cell using the recorded locations.

5 It is recommended that students be asked to formally implement a search interface, so that later other implementations, say breadth-first search, can be compared and contrasted. Students at this level need to be well scaffolded on the search algorithms, so we provide rather explicit pseudocode in the laboratory write-up. In particular we discuss recording the found path, which is glossed over in many textbooks. Once the path is found, the GridWalker merely needs to traverse that path to the goal cell using the methods the students developed in their solution to project 1. 7 Conclusion This paper described a series of laboratory projects that introduce robotics themes in a second course in computer programming. These projects provide examples of practical applications of computer programming in a realm students find motivating. They employ basic data structures such as arrays, stacks and queues, and reinforce the object-oriented approach to programming by having students define classes, use inheritance, implement interfaces, and handle exceptions. The laboratories themselves are available at our website (Klassner, Lawhead, and McNally 2005) and, although written to be used with the Lego Mindstorms platform, can easily be adapted to a number of other robotics platforms. road map for teaching introductory programming using LEGO Mindstorms robots. ACM SIGCSE Bulletin 35(2): Mindsensors Inc. (2005): Sonar Sensors. Accessed 18 Aug Murphy, R. (2000): Introduction to AI Robotics. Cambridge, MIT Press. Russell, S., and Norvig, P. (2002): Artificial Intelligence: A Modern Approach. Upper Saddle River, Prentice Hall. Siegwart, R., and Nourbakhsh, I. (2004): Introduction to Autonomous Mobile Robots. Cambridge, MIT Press. Sholz, M (2005): The LeJOS Tutorial, Accessed 18 Aug Acknowledgements This work was partially supported by a National Science Foundation CCLI grant DUE Programming solutions to some of the projects described above were first created by Josh Borgerding, the teaching assistant for the course. 9 References Bagwell, B. (2002): Core Lego Mindstorms Programming. Upper Saddle River, Prentice Hall PTR. Barnes, D. (2002): Teaching introductory Java through Lego Mindstorm models. ACM SIGCSE Bulletin 34(1): Borenstein, J. and Koren, Y. (1991) Histogramic In- Motion Mapping for Mobile Robot Obstacle Avoidance. IEEE Transactions on Robotics and Automation 7(4): Goodrich, M., and Tamassia, P. (2003): Data Structures and Algorithms in Java. New York, Wiley. Johnson-Laird, P. (1988): The Computer and the Mind. Cambridge, Harvard. Kay, J. (2003): Teaching robotics from a computer science perspective. Journal of Computing Sciences in Colleges 19(2): Klassner, F., Lawhead, P. and McNally, M. (2005): Lego Mindstorms in Computer Science Education, Accessed 18 Aug Lawhead, P., Duncan M., Bland, C., Goldweber, M., Schep, M., Barnes, D. and Hollingsworth, R. (2003): A