simple maze- solving robots solving search in real time
TRANSCRIPT
Simple Maze-Simple Maze-Solving Robots Solving Robots
solving search in solving search in real timereal time
On line and off line search
search Off lineRobot 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 lineRobot 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
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
DFS Tree Data Structure
• Two-Dimensional ArrayCell 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 Simple example of robot traversing robot traversing
unknown labyrinth to unknown labyrinth to get to the goalget to the goal
• …so we go forward.– “When you come to a fork
in the road, take it.”–Yogi Berra on depth-first search
• Wall here too!• Now there are no unexplored neighboring
squares that we can get to.• So, we backtrack! (Retrace the red arrow)
• …and go forward.• Now we’ve backtracked to a square that
might have an unexplored neighbor. Let’s check!
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, 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.