Simple Maze-Solving Robots solving search in real time

1
Simple Maze-Solving Robots solving search in real
time
2
On line and off line search
Robot knows start and goal locations
Robot knows coordinates
search
Off line
Robot knows description, can recognize when seen
Robot does not know the start and goal locations
Robot knows start and goal locations
Robot knows coordinates
On line
Robot knows description, can recognize when seen
Robot does not know the start and goal locations
Has a map
Robot
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, contd
Ultrasonic Sensor
LightSensors
7
Robot Design, contd
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 mazeMAX_HEIGHTMAX_WIDTH
• typedef struct
• bool isExplored ( false)
• Direction parentDirection ( NO_DIRECTION)
• WallStatus4 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 were gonna have to
  look north.

23

• Turn left

24

• Turn left again now were 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 cant go forward

28

• so well turn right.

29

• This way is clear

30

• so we go forward.

31

• Blocked.

32

• How about this way?

33

• Clear!

34
(No Transcript)
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 weve backtracked to a square that might have
  an unexplored neighbor. Lets check!

40

• Ah-ha!

41

• Onward!

42

• Drat!

43

• Theres gotta be a way out of here

44

• Not this way!

45

• Two 90-degree turns to face west

46

• Two 90-degree turns to face west

47

• No wall here!

48

• So we move forward and

49

• What luck! Heres 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 were 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, contd

• Sensing turns out not to be such a big problem
• If the ultrasonic sensor returns less than a
  certain distance, theres a wall in front of us
  otherwise theres not
• Goal sensing is similar (if the floor is bright
  enough, were at the goal)

52
Movement and Sensing, contd

• The motion operations are a major challenge,
  however
• Imagine trying to drive a car, straight ahead,
  exactly ten feet, with your eyes closed. Thats
  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.
• Well 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 weve seen before

55
NXT-G, contd

• 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, contd

• 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 cant 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 doesnt 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, contd

• To some extent, error is inevitable the robot
  doesnt 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, contd

• 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, contd

• Another possibility Use the ultrasonic sensor to
  make sure the robot doesnt run into walls, even
  if it thinks it should still be moving
  forwards.

62
Sources

• Peter Dempsey
• Pericles Kariotis
• Adam Procter