A maze-solving educational robot with sensors simulated by a pen Thomas Levine and Jason Wright

Transcription

1 A maze-solving educational robot with sensors simulated by a pen Thomas Levine and Jason Wright Abstract We present an interface for programming a robot to navigate a maze through both text and tactile interaction that can be used to study the merits of reflective programming. This involves a mechanism for tactile programming of a robot that can be converted to text code and presented to the user. Tactile programming is performed by moving the robot by hand in the intended path. We used the myro software with the Parallax Scribbler and the IPRE Fluke to control the robot and an Anoto pen to sense the location of the robot and to simulate sensors on the robot. Currently, the tactile programming only infers a path. In order to create truly reflexive programming, this system still needs a mechanism for inferring a generalizable maze-solving program based on the tactile programming. Introduction The abstract nature of computer programming has always made it difficult to grasp. Programming can become more concrete through tactile interaction. We believe that computer programming can be learned more easily if it can be rendered concrete though tactile interaction. If a robot can be programmed through tactile interaction and the program can be displayed to the user, he will easily connect the abstract program to the concrete physical manifestation and more intelligently adjust his program. We call this type of type of programming reflexive programming. We present an interface for programming a robot to navigate a maze through both text and tactile interaction that can be used to study the merits of reflective programming. Related Work Robots are a common way of teaching computer programming in a more concrete way, but they can still be quite abstract. With LEGO Mindstorms [1] and Myro [2], for example, robots can execute a program that produced concrete movement, but the program is still created in an abstract language. Systems that allow for tactile programming, like Robot Park [3], generally present the abstract language in a physical form. Robot Park a programming language called Tern where programs are chains of blocks with each block representing command, including abstract structures like loops. Topobo [4] can record and play back physical movements. This form of programming is more concrete than Robot Park s, but it does not display the program that it generates and thus does not connect the concrete movements to the abstract program. System Overview Our system teaches people to program and debug by programming a robot through text and tactile interaction to navigate a maze. In order to make the system engaging, we want users to be able to focus immediately on solving the maze rather than first needing to make the robot move effectively. Rather than require users to develop their own ways of detecting walls, measuring how far they ve traveled, &c., we developed simplified movement commands that handle these issues silently. By doing this, we ensure that users can get the robot to move within just a few minutes. Instead of using a more common distance sensor to detect walls, we simulated such a sensor with the pen; knowing the maze s arrangement and the location and orientation of the robot, the system can determine whether there is a wall bordering the current cell in the direction of each sensor. Interface The robot has simulated wall sensors on its left, front and right, (figure 1) and the user has access to the coordinates of the robot's location within maze.

2 Figure 1: Simulated wall sensors on the left, front and right The software creates a maze (figure 2a), which the user sets up the maze on the physical component by placing walls mounted on dowels in the appropriate holes (figure 2b).

3 Figure 2a: Maze generated by the software Figure 2b: The same maze set up on the physical maze

4 Text programming is done in Python with simplified robot controls. For example, the main movement controls allow the robot to move exactly one cell forward, left, right or backwards (figure 3); correction for slight deviations from the intended path is handled automatically. Figure 3: Movements available to users move one cell forward, turn and move one cell left, turn and move one cell right, and turn around and move one cell back. In addition to running the program to test it, he can program the path that he intends that the robot take by moving the robot over each of the cells it should reach, in order (figure 4). The path that he intended can be saved and replayed. In the future, an algorithm could be inferred from the path and compared with the user's text program in order to help him understand bugs in his code and how to fix them. Figure 4: Recording a path through tactile interaction

5 Technical summary We used a Scribbler from Parallax [5, 6] with an IPRE fluke [5]. Using additional hardware and the Myro software package from the Institute for Personal Robotics in Education [2], we connected to the Scribbler via Bluetooth and controlled its operation using Python. In addition, we used a Bluetooth pen from Anoto and an array of specialty dot matrix paper to read the location of the robot. This interfaced with Python via the use of a local socket running through custom C# software and the Anoto API. A typical operation of the robot would begin with setting up the connection to the robot and the Anoto API through the socket. Following that, a maze is generated using the maze.py package, which contains a number of functions concerning maze generation & customization. For example, the package contains algorithms to dynamically generate perfect mazes using recursive backtracking, Kruskal s algorithm, and Prim s algorithm [7]. In addition, it contains functions to generate entrance and exit cells, label parts of mazes, solve mazes, and create images representing mazes for user interaction. Once a suitable maze is generated, the user would typically create a physical interpretation of that maze and place the robot on the starting cell. The robot then would enter its step routine, which is the code that tells the robot what to do every time it enters a new cell. The step routine consists of the following components: Orientation calculation. This can be done in one of two ways either by having the robot move forward and using trigonometry to calculate the robot s orientation based on the resultant movement vector, or simply calculate the orientation based on path (i.e. the cells the robot has previously traveled to) Absolute position calculation. Using the correctionangle.py package, the robot can take data from the pen in the format (x, y, page number) and interpret it relative to an absolute coordinate system. The user can modify the settings of this package to easily adapt this to the physical maze by altering the page dimensions, spacing between pages, and arrangement of pages. The robot can then easily determine which cell of the maze it is stationed in. Wall sensing. Using the orientation vector, the current cell, and a map of the relevant portion of the maze, the robot can easily determine if there are walls nearby, and where precisely they are. User ruleset. At this point, the user can use the above data to have the robot do anything they want. One common use would to have the robot follow the right wall, i.e. turn in the direction that is as right as possible. Target determination. Once the user ruleset executes and determines what cell to travel to, the absolute position of the robot s target is determined using a lookup table of page centers. Movement with error correction. The robot begins to move toward the defined target, relying on the pen for guidance. The robot takes individual steps forward and calculates the angle of orientation in a similar fashion as described above. This is then used to generate a desired turn correction that rotates the robot to face the target, using a function approximated from measured data. (In our setup, we simply used an attenuation coefficient in a linear formula, but more complicated systems could require a more complex method.) This process is done in small increments to achieve maximum accuracy, as well as to ensure that even a very lost robot would eventually be able to find its target. Goal detection. The user can define a goal radius, which is how close to a goal the robot needs to be before exiting the movement subroutine. Once the robot is within the goal radius, it begins this whole process again. Once the robot has reached a defined goal, e.g. the exit cell, this process terminates. Additional features of our system include a method to measure turning data to determine an appropriate attenuation coefficient (learnturncoefficient.py), a pre-written script to retrace paths created by physically moving a robot through a maze (demo_with_recording.py), and a script to create an interactive on-screen maze, in which one can draw a path that the robot will execute (draw.py). Future Work In a future iteration of this system, the program would be able to deduce, based on the path a user records, a reasonable algorithm that would generate such a path and display corresponding code, highlighting the difference between that code and the code that was used. This is the aspect of the system that makes the programming reflective. For now, the Wizard of Oz method can be used to simulate the creation of the intended code for testing.

6 More controls could be added for the tactile programming. Currently, the only input is the location of the robot. The orientation of the robot could be recorded. Buttons for the simulated wall sensors could let users specify which sensors are relevant. We also think the movements available to the user could be improved. Each of the four movements in the current system requires the robot to move to another cell; we did not include movements that were turns in place. This was necessary because the platform has no way of measuring orientation without moving; the pen cannot measure orientation based on just one point, and the robot cannot measure how much it has turned or moved. Because of this, precise turns in place could not be made reliably. The three movements of go forward one cell, quarter turn in place to the left and quarter turn in place to the right, would allow for finer control of the movement, so a future iteration should use these movements instead. References [1] The Lego Group. LEGO.com Mindstorms NXT Home. [ [2] Institute for Personal Robots in Education. Myro Robot Resources. [ [3] Michael S. Horn, Erin T. Solovey, R. Jordan Crouser, Robert J.K. Jacob. Comparing the Use of Tangible and Graphical Programming Languages for Informal Science Education. CHI [4] Hayes Solos Raffle, Amanda J. Parkes, and Hiroshi Ishii. Topobo: a constructive assembly system with kinetic memory. In Proc. of CHI, [5] IPRE Wiki. Myro Hardware. [ [6] Scribbler Robot. Parallax, Inc. [ txtsearch/scribbler/list/0/sortfield/4/productid/323/default.aspx] [7] Wikipedia. Maze generation algorithm. [