Why Robots Need Decisions

A robot standing still is easy to program. A robot moving through a changing world needs to make decisions — hundreds of them per second.

The Real World is Messy

Consider a delivery robot navigating a building:

• The elevator door might be open or closed
• People might step into its path
• Its battery might drop below 20%
• A wheel encoder might fail mid-mission

Each of these situations requires a decision. Without structure, your code becomes a tangled mess of if statements spanning thousands of lines.

Two Types of Behavior

Roboticists distinguish between two types of decision-making:

Reactive Behavior

Reactive systems respond directly to sensor input without planning ahead. Think of a light switch: photons hit a sensor, and the light turns on. No memory, no deliberation.

Pros:

• Fast — sub-millisecond response
• Predictable — same input always produces the same output
• Reliable — no complex reasoning to fail

Cons:

• Can't plan ahead — no concept of "the goal is three rooms away"
• Can get stuck — oscillating between two behaviors (e.g., "avoid left, avoid right, avoid left...")
• Limited intelligence — can only react to what it sees right now

Deliberative Behavior

Deliberative systems think ahead. They build models of the world, predict outcomes, and choose actions based on goals.

Pros:

• Can plan complex sequences — "charge battery, then deliver packages"
• Can optimize — choose the fastest route, not just any route
• Can reason about uncertainty — "this path is risky but faster"

Cons:

• Slow — planning takes time
• Can fail unexpectedly — bad world model = bad plan
• Brittle — plan assumes the world stays as expected

The Hybrid Approach

Modern robots use both strategies:

High-level (deliberative):
  "I need to deliver to room 305. Plan: take elevator to floor 3, turn right, go to door 305."

Mid-level (reactive with state):
  "I'm in the 'navigating' state. If I see an obstacle, switch to 'avoiding' state."

Low-level (reactive):
  "Front sensor detects obstacle within 0.5m → stop motors immediately."

The key is structure. You need a framework to organize these decisions so they're:

• Readable — a new developer can understand the logic
• Testable — you can verify behavior in simulation
• Modular — you can swap out "deliver package" for "clean floor" without rewriting everything

This is where state machines and behavior trees come in.

Why Not Just Use If Statements?

You can build small robots with nested if statements. But as complexity grows:

if battery_low:
    if charger_visible:
        if path_clear:
            move_to_charger()
        else:
            if obstacle_on_left:
                turn_right()
            elif obstacle_on_right:
                turn_left()
            else:
                stop()
    else:
        search_for_charger()
elif mission_active:
    if at_waypoint:
        if task_complete:
            return_home()
        else:
            do_task()
    else:
        if obstacle_ahead:
            # ... 50 more lines of nested ifs

This becomes unmaintainable. You can't visualize it, can't test individual pieces, and adding a new condition requires editing deeply nested code.

State machines and behavior trees give you:

• Visual representation — see your robot's logic as a diagram
• Composability — build complex behaviors from simple pieces
• Reusability — "avoid obstacle" can be reused in multiple contexts
• Debuggability — know exactly which state or node is active at any moment

What's Next?

We've seen why robots need structured decision frameworks. In the next lesson, we'll dive into state machines — one of the oldest and most widely-used tools for organizing robot behavior.