Maze-Solving Mindstorms NXT Robot

1
Maze-Solving Mindstorms NXT Robot

• Peter Dempsey
• Pericles Kariotis
• Adam Procter

2
Our Mission

• Investigate the capabilities of the NXT robot
• Explore development options
• Build something interesting!

3
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

4
Robot Design

• 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

5
Robot Design, contd
Ultrasonic Sensor
LightSensors
6
Robot Design, contd
7
Search Algorithm

• 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

8
Maze Structure
GOAL



START
9
DFS Tree Example
GOAL



START
10
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

11
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

12

• Example 3x3 maze

GOAL
13

• We start out at (0,0) the southwest corner of
  the maze
• Location of goal is unknown

14

• Check for a wall the way forward is blocked

15

• So we turn right

16

• Check for a wall no wall in front of us

17

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

18

• We sense a wall

19

• Turn right

20

• We sense a wall here too, so were gonna have to
  look north.

21

• Turn left

22

• Turn left again now were facing north

23

• The way forward is clear

24

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

25

• We sense a wall cant go forward

26

• so well turn right.

27

• This way is clear

28

• so we go forward.

29

• Blocked.

30

• How about this way?

31

• Clear!

32
(No Transcript)
33

• Whoops, wall here.

34

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

35

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

36

• We turn to face the red arrow

37

• and go forward.
• Now weve backtracked to a square that might have
  an unexplored neighbor. Lets check!

38

• Ah-ha!

39

• Onward!

40

• Drat!

41

• Theres gotta be a way out of here

42

• Not this way!

43

• Two 90-degree turns to face west

44

• Two 90-degree turns to face west

45

• No wall here!

46

• So we move forward and

47

• What luck! Heres the goal.
• Final step Execute victory dance.

?
48
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

49
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)

50
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

51
Language Options

• There are several languages and programming
  environments available for the NXT system
• NXT-G
• Microsoft Robotics Studio
• RobotC
• etc

52
NXT-G

• Lego provides graphical NXT-G software based on
  LabVIEW which weve seen before

53
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

54
Microsoft Robotics Studio

• To be honest, we just couldnt get the darn thing
  to work!
• Were sure its great, though.

55
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

56
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

57
RobotC, contd

• Still in beta
• Currently available for free download
  (time-limited demo)
• Will eventually be released commercially, with
  licenses costing 20-30
• Requires modified firmware
• This breaks compatibility with NXT-G programs
• Some features seem to be just plain buggy and/or
  incomplete
• But it supports arrays!

58
Okay, lets see a demonstration!
59
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

60
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.

61
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.

62
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.
• Unfortunately we didnt get a chance to try and
  implement these ideas.

63

• In any case, we think its pretty cool.
• Questions?

64

• Have a nice holiday!