Robot Maze Navigation Problem

Problem Formulation and State Space Analysis

Exploring how different formulations affect complexity and efficiency

Problem Statement

Your goal is to navigate a robot out of a maze. The robot starts in the center facing north and can turn to face any direction or move forward until it hits a wall.

Sample Maze:
█████████████
█ █     █   █
█   █ █   █ █
█ █   █     █
█   █ █ R █ █
█ █     █   █
█   █ █   █ E
█████████████
R = Robot (facing North), E = Exit, █ = Walls
Robot Capabilities
  • Turn: Face North, East, South, or West
  • Move: Forward until hitting a wall
  • Sense: Know current position and surroundings
Learning Outcomes

By completing this exercise, you will be able to:

  • Formulate search problems by defining states, actions, transitions, and goals systematically
  • Analyze state space complexity and calculate how formulation choices affect computational efficiency
  • Apply abstraction techniques to simplify problems while preserving essential structure and solution quality
  • Question: Formulate this problem using the components of a search problem (states, actions, transition model, goal test, path cost). How large is the state space?
Instructor's In-Class Solution
1 State representation: The current position $(x, y, orientation)$
• $(x,y)$: The position coordinates of the robot in the maze
• $orientation \in \{North, East, South, West\}$
2 Initial State: $(x_{center}, y_{center}, North)$
3 Goal State: The exit location $(x_{exit}, y_{exit}, orientation)$
Note: Goal can be reached regardless of final orientation
4 Actions:
• $TurnLeft$: Change orientation 90° counterclockwise
• $TurnRight$: Change orientation 90° clockwise
• $MoveForward(k)$: Move forward $k$ steps
• $TurnAround$: Robot changes orientation 180°
5 Transition Model:
• Turn actions: Change orientation only
• Move actions: Transition changes the position
6 Path Cost (Two Options):
• Option 1: Number of steps moved to reach exit location (only motion counts, not orientation changes)
• Option 2: Number of transitions to reach exit location (both motion and orientation changes are penalized)
7 State Space Size:
The robot can be located only in free spaces and can have 4 different orientations in the same location/position.
If $n$ denotes the number of free spaces in the maze, then the state space size is $4 \times n$.
Example: If the maze has 100 free space locations, then in total we will have 400 possible states.
Explanation - Understanding State Representation

Think of the robot's state as "where it is and which way it's looking":

🤖 Real-world analogy: You're in a building with a blindfold:
  • Position (x,y): "I'm at the intersection of hallway A and corridor 3"
  • Orientation: "I'm facing the main entrance direction"
  • Both matter: Same position but different orientation = different capabilities
Example states:
(5,3,North)
(5,3,East)
(7,2,South)
Same position, different orientations = different states!
📚 Why this formulation makes sense:
  • Complete information: Tells us everything needed to plan next actions
  • Action-relevant: Both position and orientation affect what actions are possible
  • Goal-relevant: We need position to know if we've reached the exit
  • Question: In navigating a maze, the only place we need to turn is at intersections of two or more corridors. Reformulate this problem using this observation. How large is the state space now?
Instructor's In-Class Solution - Intersection-Based Reformulation
1 Key Observation: The robot only needs to rotate when it reaches an intersection and not at any location $(x,y)$
This insight dramatically simplifies our state representation
2 State representation: The current position $(intersection, orientation)$
• $intersections$: All possible $(x_{intersection\_i}, y_{intersection\_i})$ locations that represent an intersection. We assume we have $m$ intersections.
• $orientation \in \{North, East, South, West\}$
We consider robot locations at intersections only.
3 Initial state: $(starting\_intersection, North)$
4 Actions:
• Turn to face any available corridor
• Move forward until the next intersection or dead end
5 Transition model:
• Turning changes orientation
• Moving takes the robot to the next intersection in that direction
6 Goal test: Check if the robot is at an intersection that contains an exit
7 Path cost: Could be based on number of actions or distance between intersections
8 State space size:
If there are $m$ intersections in the maze, each intersection can be combined with 4 possible orientations.
Therefore, the state space size = $4 \times m$
Dramatic improvement: If $m$ denotes the number of intersections and $n$ the number of free spaces:
• Original formulation: $4 \times n$ states
• Intersection-based: $4 \times m$ states
Example: Maze with 100 free space locations and 10 intersections → 40 possible states instead of 400 (90% reduction!)
9 Note: An "intersection" here includes any point where the robot must make a decision, including T-junctions, 4-way crossroads, and dead ends.
Explanation - The Intersection Insight

Think of intersections as "decision points" where choices matter:

🛣️ Highway driving analogy:
  • On straight highway: You just keep driving - no decisions needed
  • At highway interchanges: You must decide which exit to take
  • Our maze: Long corridors = highways, intersections = interchanges
❌ Inefficient thinking:
"Track robot at every step of corridor"
Wastes states on non-decision points
✅ Efficient thinking:
"Track robot only at intersections"
Focus states on decision points
📊 Example reduction:
  • Maze with 100 free squares but only 15 intersections
  • Before: 4 × 100 = 400 states
  • After: 4 × 15 = 60 states (85% reduction!)
  • Question: From each point in the maze, we can move in any of the four directions until we reach a turning point. Reformulate the problem using these actions. Do we need to keep track of the robot's orientation now?
Instructor's In-Class Solution - Graph-Based Reformulation
1 Key Insight: When the intersections are connected as a graph, we can combine the motion and orientation
The graph structure captures the connections between intersections, eliminating the need for orientation tracking
2 State Representation: $(intersection\_id)$
• Intersections only - orientation is eliminated because the graph structure captures the connections between intersections
• The only state that we need to track in a graph structure is the name of the node, which is the intersection
3 Initial state: $(starting\_intersection)$
4 Actions: $Go(direction)$ or $Go(Node\_name)$
• Move along a corridor in the chosen direction until reaching the next intersection
• The action implicitly includes any necessary turning
• Actions are only available for directions that have corridors
5 Transition model: Each action takes the robot from the current intersection to an adjacent intersection
6 Goal test: Check if the current intersection includes an exit
7 Path cost: Could be based on the distance between intersections
8 Do we need to track orientation? No! Here's why:
• When the robot arrives at an intersection, its orientation doesn't matter for future decisions
• The important decision is which corridor to take next, not which way the robot is currently facing
• The $Go(direction)$ action implicitly handles any turning needed to face the correct direction
• Once the robot commits to a corridor, it will naturally arrive at the next intersection properly aligned
9 State Space Size: Just the number of intersections, which is $m$
We reduce the state space from $4 \times m$ (second formulation) to only $m$.
Dramatic improvement:
• Original formulation: $4 \times n$ states (every square × orientations)
• Intersection with orientation: $4 \times m$ states
• Graph-based: $m$ states (intersections only)
Example: Maze with 15 intersections → reduces from $15 \times 4 = 60$ states to only $15$ states
10 Computational Efficiency Insight: This demonstrates that for the same problem, the problem formulation makes a big difference in terms of:
• Execution time
• Storage requirements
• Computing power needed
It is easier to search in small state spaces compared to very large state spaces.
11 Graph Transformation: This reformulation transforms the problem into a graph search where:
• Nodes: Intersections in the maze
• Edges: Corridors connecting intersections
• Search goal: Find path from start intersection to exit intersection
• Algorithms: Any graph search algorithm (BFS, DFS, Dijkstra, A*) can be applied directly
Visual Transformation: Maze → Graph
Original Maze Representation
█████████████
█ A █     █   █
█   █ █   █ █
█ █ B   █ C █ █
█   █ █ R █ █
█ █ D     E   █
█   █ █   █ Ex
█████████████
● Start/Current positions, ● Intersections (A, B, C, D, E), ● Exit
Graph Representation
A
B
C
R
D
E
Ex
Nodes = Intersections, Edges = Corridors
State = Current Node (e.g., "at intersection C")
🔄 Transformation Benefits:
Original: Track (x,y,orientation)
Complex state with position + direction
Graph: Track (node_id) only
Simple state with just location
Actions: Go(North/South/East/West)
Direct navigation between nodes
Explanation - Why Orientation Becomes Irrelevant

Think about what really matters when making decisions:

🚇 Subway system analogy:
  • At a subway station: You decide "take the Red Line toward downtown"
  • You don't care: Which direction you walked into the station from
  • The train handles: Getting you properly oriented for the chosen route
  • Similarly: Robot's $Go(North)$ action handles turning toward north automatically
🔄 How the "turning problem" disappears:
  1. Robot arrives at intersection (facing some direction)
  2. We decide: "Go north to next intersection"
  3. Action automatically: Turn to face north, move until next intersection
  4. Arrival orientation: Doesn't matter for next decision
🎯 The key realization:
  • Old thinking: "Where am I and which way do I face?"
  • New thinking: "Where am I and where can I go next?"
  • Result: Orientation becomes just an implementation detail

State Space Complexity Comparison

How different formulations affect problem size

Initial Formulation
4 × n

Every position × orientations

Most detailed but largest
Intersection-Based
4 × m

Intersections × orientations

Reduced by factor of n/m
Graph-Based
m

Just intersections

Maximum reduction achieved
Example: 100 squares, 15 intersections → 400 → 60 → 15 states (96% reduction!)
  • Question: In our initial description, we already abstracted from the real world. List three simplifications we made and explain why they might be necessary or useful.
Solution - Real-World Simplifications
1 Continuous → Discrete Space
Reality: Robot moves in continuous coordinates (e.g., 23.7cm from wall)
Our model: Discrete grid cells or intersections only
Why useful: Makes state space finite and manageable
2 Physics Ignored
Reality: Mass, inertia, acceleration, turning radius constraints
Our model: Instant turning, constant speed, no momentum
Why useful: Focuses on high-level path planning, not low-level control
3 Perfect Sensing & Movement
Reality: Sensor noise, wheel slippage, localization errors
Our model: Robot knows exact position and moves perfectly
Why useful: Separates planning from execution uncertainty
Explanation - The Art of Abstraction

Good problem formulation is about choosing the RIGHT things to ignore:

🎨 Painting analogy:
  • Photorealistic painting: Every detail, takes forever, overwhelming
  • Impressionist painting: Captures essence, manageable, still meaningful
  • Our formulation: Like impressionism - keep what matters, abstract away details
Additional simplifications:
  • Static environment: No moving obstacles
  • Binary obstacles: Walls are either there or not
  • No resource constraints: Unlimited battery/time
  • Deterministic: Actions always work as expected
Benefits of simplification:
  • Manageable complexity: Can solve the problem
  • Clear reasoning: Focus on core challenges
  • Efficient algorithms: Fast search possible
  • Modular design: Handle other issues separately
⚖️ The abstraction tradeoff: Simpler models are easier to solve but may miss important real-world constraints. The art is finding the right level of abstraction.
  • Question: Based on the robot maze example, explain the relationship between problem formulation and state space size. Why is finding a good problem formulation important in AI? How do our different formulations demonstrate this?
Solution - Problem Formulation Principles
1 Formulation ↔ Complexity Relationship
Problem formulation directly determines:
• Memory requirements (to store states)
• Time complexity (to explore state space)
• Feasibility (whether problem is solvable)
2 Our Demonstration: 400 → 60 → 15 states
• Same problem, same optimal solution
• 96% reduction in complexity
• Transforms intractable → practical
3 Why Good Formulation Matters
• Computational efficiency: Faster search, less memory
• Algorithm choice: Enables different search strategies
• Solution quality: Better formulations → better solutions
• Problem insight: Reveals problem structure
4 Key Principles Demonstrated
• Identify essential information: What do we really need to track?
• Exploit problem structure: Use domain-specific insights
• Abstract appropriately: Right level of detail
• Think about actions: What decisions actually matter?
Explanation - The Big Picture of Problem Formulation

Problem formulation is like choosing the right map for a journey:

🗺️ Map analogy for our three formulations:
Street-level map:
Shows every building and direction you're facing
Too much detail for long trips
City district map:
Shows major intersections and orientations
Good balance of detail
Highway network map:
Just shows connections between cities
Perfect for route planning
📚 How to approach problem formulation systematically:
  1. Start with obvious formulation: Include everything that seems relevant
  2. Question each component: Is this really necessary for decision-making?
  3. Look for patterns: When do states become equivalent?
  4. Exploit domain knowledge: What insights does the problem domain provide?
  5. Test and iterate: Compare complexity and solution quality
🚀 The ultimate goal: Find the simplest formulation that still captures the essential structure of the problem - this often leads to the most elegant and efficient solutions.
What We Learned
  • Same problem, different complexities
  • Formulation dramatically affects efficiency
  • Domain insights enable better abstractions
  • Simpler isn't always better - but often is
Practical Guidelines
  • Question every state component
  • Look for problem-specific structure
  • Test multiple formulations
  • Balance simplicity with accuracy

Continue Learning

State Space Representation Maze Exercise BFS Programming Algorithm Comparison