Transcript Maze-Solving Mindstorms NXT Robot

Maze-Solving Mindstorms NXT
Robot
Our Mission
• Investigate the capabilities of the NXT robot
• Explore development options
• Build something interesting!
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
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
Robot Design, cont’d
Ultrasonic Sensor
Light
Sensors
Robot Design, cont’d
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
Maze Structure
GOAL
START
DFS Tree Example
GOAL
START
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
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
}
• Example 3x3 maze
GOAL
• We start out at (0,0) – the
“southwest” corner of the
maze
• Location of goal is unknown
• Check for a wall – the way
forward is blocked
• So we turn right
• Check for a wall – no wall
in front of us
• So we go forward; the red
arrow indicates that (0,0)
is (1,0)’s predecessor.
• We sense a wall
• Turn right
• We sense a wall here too,
so we’re gonna have to
look north.
• Turn left…
• Turn left again; now we’re
facing north
• The way forward is clear…
• …so we go forward.
– “When you come to a fork
in the road, take it.”
–Yogi Berra on depth-first
search
• We sense a wall – can’t go
forward…
• …so we’ll turn right.
• This way is clear…
• …so we go forward.
• Blocked.
• How about this way?
• Clear!
• Whoops, wall here.
• We already know that the
wall on the right is
blocked, so we try turning
left instead.
• Wall here too!
• Now there are no unexplored neighboring
squares that we can get to.
• So, we backtrack! (Retrace the red arrow)
• We turn to face the red
arrow…
• …and go forward.
• Now we’ve backtracked to a square that
might have an unexplored neighbor. Let’s
check!
• Ah-ha!
• Onward!
• Drat!
• There’s gotta be a way
out of here…
• Not this way!
• Two 90-degree turns to
face west…
• Two 90-degree turns to
face west…
• No wall here!
• So we move forward
and…
• What luck! Here’s the
goal.
• Final step: Execute victory
dance.

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
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)
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
Language Options
• There are several languages and programming
environments available for the NXT system:
– NXT-G
– Microsoft Robotics Studio
– RobotC
– etc…
NXT-G
• Lego provides graphical “NXT-G” software based on LabVIEW
which we’ve seen before
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
Microsoft Robotics Studio
• To be honest, we just couldn’t get the darn
thing to work!
• We’re sure it’s great, though.
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
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
RobotC, cont’d
• 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!
Okay, let’s see a demonstration!
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
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.
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.
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.
• Unfortunately we didn’t get a chance to try
and implement these ideas.
Sources
Peter Dempsey
Pericles Kariotis
Adam Procter