1. Simple Maze- Solving Robots solving search in real time

2. On line and off line search search Off line Robot knows start and goal locations Robot does not know the start and goal locations Robot knows coordinates Robot knows description, can recognize when seen On line Robot knows start and goal locations Robot does not know the start and goal locations Robot knows coordinates Robot knows description, can recognize when seen Robot Has a map Creates a map

3. Goals of this lecture Illustrate real-time search in maze by a simple mobile robot Investigate the capabilities of the NXT robot. Can we use Mindstorms NXT for serious research in Search? Explore development options

4. Problem Outline Robot is placed in a “grid” of same-sized squares – (Due to obscure and annoying technical limitations, the robot always starts at the “southwest” corner of the maze, facing “north”) Each square can be blocked on 0-4 sides (we just used note cards!) Maze is rectangularly bounded One square is a “goal” square (we indicate this by covering the floor of the goal square in white note cards ) The robot has to get to the goal square

5. Using NXT you can build quickly all kind of robot prototypes Uses basic “driving base” from NXT building guide, plus two light sensors (pointed downwards) and one ultrasonic distance sensor (pointed forwards) The light sensors are used to detect the goal square, and the distance sensor is used to detect walls

6. Robot Design, cont’d Light Sensors Ultrasonic Sensor

7. Robot Design, cont’d

8. Search Algorithm Robot does not know the map. Simple Depth-First Search Robot scans each cell for walls and constructs a DFS tree rooted at the START cell As the DFS tree is constructed, it indicates which cells have been explored and provides paths for backtracking The DFS halts when the GOAL cell is found

9. Maze Structure GOAL START

10. DFS Tree Example GOAL START

11. DFS Tree Data Structure Two-Dimensional Array Cell maze[MAX_HEIGHT][MAX_WIDTH] typedef struct { bool isExplored; (= false) Direction parentDirection; (= NO_DIRECTION) WallStatus[4] wallStatus; (= {UNKNOWN}) } Cell; Actually implemented as parallel arrays due to RobotC limitations

12. DFS Algorithm while (true) { if robot is at GOAL cell victoryDance(); if there is an unexplored, unobstructed neighbor Mark parent of neighbor as current cell; Proceed to the neighbor; else if robot is not in START cell Backtrack; else return; //No GOAL cell exists, so we exit }

13. Simple example of robot traversing unknown labyrinth to get to the goal

14. Simple example Example 3x3 maze GOAL

15. We start out at (0,0) – the “southwest” corner of the maze Location of goal is unknown

16. Check for a wall – the way forward is blocked

17. So we turn right

18. Check for a wall – no wall in front of us

19. So we go forward; the red arrow indicates that (0,0) is (1,0)’s predecessor.

20. We sense a wall

21. Turn right

22. We sense a wall here too, so we’re gonna have to look north.

23. Turn left…

24. Turn left again; now we’re facing north

25. The way forward is clear…

26. …so we go forward. – “When you come to a fork in the road, take it.” –Yogi Berra on depth-first search

27. We sense a wall – can’t go forward…

28. …so we’ll turn right.

29. This way is clear…

30. …so we go forward.

31. Blocked.

32. How about this way?

33. Clear!

35. Whoops, wall here.

36. We already know that the wall on the right is blocked, so we try turning left instead.

37. Wall here too! Now there are no unexplored neighboring squares that we can get to. So, we backtrack! (Retrace the red arrow)

38. We turn to face the red arrow…

39. …and go forward. Now we’ve backtracked to a square that might have an unexplored neighbor. Let’s check!

40. Ah-ha!

41. Onward!

42. Drat!

43. There’s gotta be a way out of here…

44. Not this way!

45. Two 90-degree turns to face west…

47. No wall here!

48. So we move forward and…

49. What luck! Here’s the goal. Final step: Execute victory dance.

50. Movement and Sensing The search algorithm above requires five basic movement/sensing operations: – “Move forward” to the square we’re facing – “Turn left” 90 degrees – “Turn right” 90 degrees – “Sense wall” in front of us – “Sense goal” in the current square

51. Movement and Sensing, cont’d Sensing turns out not to be such a big problem – If the ultrasonic sensor returns less than a certain distance, there’s a wall in front of us; otherwise there’s not – Goal sensing is similar (if the floor is “bright enough”, we’re at the goal)

52. Movement and Sensing, cont’d The motion operations are a major challenge, however Imagine trying to drive a car, straight ahead, exactly ten feet, with your eyes closed. That’s more or less what “move forward” is supposed to do – at least ideally. In the current implementation, we just make our best estimate by turning the wheels a certain fixed number of degrees, and make no attempt to correct for error. – We’ll talk about other options later

53. Language Options There are several languages and programming environments available for the NXT system: – NXT-G – Microsoft Robotics Studio – RobotC – etc…

54. NXT-G Lego provides graphical “NXT-G” software based on LabVIEW which we’ve seen before

55. NXT-G, cont’d NXT-G is designed to be easy for beginning programmers to use We found it rather limiting – Placing blocks/wires on the diagram takes longer than typing Furthermore, NXT-G lacks support for arrays, which is problematic for our application

56. RobotC Simple “C-like” language for programming NXT (and other platforms) developed at CMU Compiles to bytecode that is executed on a VM More-or-less complete support for NXT sensors, motors

57. RobotC, cont’d Limited subset of C – All variables allocated statically (so no recursion) – Somewhat limited type system For example, arrays are limited to two dimensions, and you can’t have arrays of structs as far as we can figure – Maximum of eight procedures and 256 variables

58. Error Correction So as you may have noticed, it doesn’t work perfectly. Ideally, the robot should always turn exactly 90 degrees and should always be exactly centered inside the square. As we said, the “movement primitives” – go forward, turn left, turn right – are not perfectly precise. – Any “slips” or problems with traction will throw everything off. Error tends to compound

59. Error Correction, cont’d To some extent, error is inevitable; the robot doesn’t really have “vision” per se. However, if we fudged the environment a little bit, it would probably be possible to correct for much of the error.

60. Error Correction, cont’d One possibility: Mark the floor of each tile with lines that can be picked up by the light sensors. If placed correctly, the “alignment markers” could help the robot both to center itself along the X/Y axes, and to make sure it turns exactly 90 degrees.

61. Error Correction, cont’d Another possibility: Use the ultrasonic sensor to make sure the robot doesn’t run into walls, even if it “thinks” it should still be moving forwards.

62. Sources Peter Dempsey Pericles Kariotis Adam Procter