Simple Maze- Solving Robots solving search in real time

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

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

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

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

Robot Design, cont’d Light Sensors Ultrasonic Sensor

Robot Design, cont’d

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

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 }

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

Simple example 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…

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

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

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.

Sources Peter Dempsey Pericles Kariotis Adam Procter