30  Braitenberg Vehicles: Sensing to Action

30.1 Start With the Measurement Story

A tiny robot can appear purposeful when two sensors directly shape two motor outputs. Start with that reflex story: the sensor reading changes, the wiring rule changes motion, and the behavior emerges before any planner is added.

30.2 In 60 Seconds

Braitenberg vehicles demonstrate that surprisingly intelligent-seeming behavior emerges from simple sensor-to-actuator connections. Same-side excitatory wiring creates avoidance (“fear”), cross-wired excitatory creates approach at speed (“aggression”), same-side inhibitory creates gentle approach and stop (“love”), and cross-wired inhibitory creates exploration. Many real IoT systems – thermostats, motion-activated lights, fan controllers – are essentially Braitenberg vehicles. Start simple before reaching for complex AI.

Phoebe’s Field Notes: The LDR’s Own Power Law – And Its Hidden Line In The Battery Budget

Phoebe’s Why

The two LDRs in this chapter’s light-following pot are not photodiodes – they are bulk photoconductors, where absorbed light changes the population of free carriers rather than driving a linear photocurrent through a junction. That builds in a real nonlinearity: resistance falls with light roughly as a power law, not a straight line, with an exponent set by the material’s trap physics, not by any circuit choice. Every Braitenberg wiring rule in this chapter (motor = sensor_ADC x gain) quietly assumes the ADC code is linear in light level – a fair local approximation, but an approximation whose actual shape is worth naming. The same divider that turns that resistance into a voltage also draws current the whole time it is biased, and this chapter’s own battery-life box never asks how much that habitually-on sensor circuit costs next to the 280 mA motor.

The Derivation

Photoconductive gain law – resistance versus illuminance \(E\), referenced to \(E_1\), with gamma exponent \(\gamma\) set by the cell’s material:

\[R_{LDR}(E) = R_1\left(\frac{E}{E_1}\right)^{-\gamma}\]

The divider’s continuous bias current at a given \(R_{LDR}\):

\[I_{div} = \frac{V_{CC}}{R_{fixed}+R_{LDR}}\]

Daily sensor energy if that divider stays powered around the clock:

\[E_{sensor} = I_{div}\times24\text{ h}\]

Worked Numbers: This Chapter’s Own 280 mA / 2,500 mAh Budget

• Catalog-typical CdS photoconductor (\(\gamma=0.7\), \(R_1=8{,}000\ \Omega\) at \(E_1=10\) lux): at 1,000 lux (bright window light), \(R_{LDR}=8{,}000\times100^{-0.7}=318\ \Omega\); at 1 lux (dim room), \(R_{LDR}=8{,}000\times0.1^{-0.7}=40{,}100\ \Omega\) – a \(126\times\) resistance swing for a \(1{,}000\times\) light swing, exactly \(1{,}000^{0.7}\), the nonlinearity the linear gain multiplier only locally approximates.
• Catalog-typical \(V_{CC}=3.3\) V, \(R_{fixed}=10{,}000\ \Omega\) divider: worst-case (brightest) bias current is \(I=3.3/(10{,}000+318)=0.320\) mA; dimmest is \(3.3/(10{,}000+40{,}100)=0.0659\) mA.
• If that divider were left continuously powered, the worst case adds \(0.320\times24=7.68\) mAh/day on top of this chapter’s own \(23.3\) mAh/day motor budget plus \(0.24\) mAh/day sleep – a \(32.6\%\) increase to \(31.2\) mAh/day, cutting the stated \(\approx107\)-day battery life to about \(80.1\) days, a \(24.6\%\) reduction.
• If instead the divider is only biased for a short ADC sample window each time the controller reads it (say \(100\ \mu s\) per read at the chapter’s own “about 10 times per second” update rate, a \(0.1\%\) duty cycle), the sensor’s contribution drops to \(0.00768\) mAh/day – genuinely negligible, matching the chapter’s “motor energy still dominates” claim. The two conclusions disagree, and the difference is entirely whether the LDR divider is switched or left always-on – worth stating explicitly rather than assuming.

30.3 Key Concepts

• Braitenberg Vehicle: sensors drive motors directly, creating approach, avoidance, attraction, or exploration without a planner
• Ipsilateral Coupling: same-side wiring; left sensor to left motor and right sensor to right motor
• Contralateral Coupling: crossed wiring; each sensor drives the opposite motor
• Excitatory/Inhibitory Coupling: stimulus can increase or reduce motor speed
• Reactive Architecture: fixed sensor-to-actuator rules with no memory or planning
• Phototaxis: motion toward or away from light
• Embodied Intelligence: behavior emerges from body, sensors, actuators, and environment together

30.4 A Tiny Robot With Only Reflexes

Imagine a toy car with two light sensors as eyes and two motors as wheels. Same-side wiring can turn it away from light; crossed wiring can turn it toward light; inhibitory wiring can make it slow and stop near the stimulus.

That is the promise of Braitenberg vehicles: behavior can come from a reflex loop, not from a planner. For IoT, many useful devices can start with thresholds, gains, and wiring rules. The hard part is choosing the right reflex, then proving where it stops being enough.

Chapter Roadmap

This chapter has five stops:

1. First you read the four Braitenberg wiring patterns and predict how each one turns.
2. Then you translate the same reflex idea into thermostats, lighting, fans, and plant watering.
3. Next you compare reactive control with AI/ML so the simple baseline stays visible.
4. After that you build and tune a light-following plant pot, including the 280 mA battery-life tradeoff.
5. Finally you use quizzes and mode-switching practice to prove the sensor-to-actuator chain.

Checkpoints recap the wiring decisions; interactive blocks let you test the rule before memorizing it.

Learning Objectives

After completing this chapter, you will be able to:

• Explain how Braitenberg vehicles map sensor inputs to actuator outputs using wiring topology and polarity
• Design simple reactive systems using direct sensor-to-actuator connections
• Predict emergent behaviors from different sensor-actuator coupling configurations
• Evaluate when Braitenberg-style reactive control is sufficient versus when AI/ML is required

30.5 Prerequisites

• Sensor Classification: Types of sensors
• Signal Processing: Sensor data handling

Figure 30.1: Light intensity versus LDR resistance curve, showing high resistance in darkness and low resistance in bright light

30.6 Sensor Readings to Behavior

~20 min | Intermediate | P06.C08.U04

Valentino Braitenberg’s thought experiments showed that a vehicle with only sensors and motors can appear to have fear, aggression, attraction, or exploration. The trick is not a hidden mind; it is the mapping from each sensor to each motor.

30.6.1 Four Reflexes From Two Wiring Choices

Braitenberg imagined simple vehicles with sensors connected directly to motors. The simplest, Vehicle 1, has a single sensor driving a single motor: more stimulus means more speed. The more interesting behaviors emerge with two sensors and two motors, where the connection type determines the behavior:

Figure 30.2: Braitenberg two-sensor vehicle wiring patterns: same-side or cross-wired, excitatory or inhibitory, creating avoidance, attack, approach, or exploration

30.6.2 Read the Wiring Before the Personality

Vehicle	Connection	Behavior	IoT Example
2a: Coward (Fear)	Same-side, excitatory	Runs away from stimulus	Light-avoiding robot
2b: Aggression	Cross-wired, excitatory	Attacks stimulus	Line-following robot
3a: Love	Same-side, inhibitory	Approaches and stays near	Plant-watering robot
3b: Explorer	Cross-wired, inhibitory	Explores, avoids obstacles	Roomba-like navigation

30.6.3 Try the Motor-Speed Rule

Adjust the sensor readings and wiring configuration to see how different Braitenberg vehicles respond. Observe how the same sensor values produce completely different motor speeds and turning behavior depending on wiring topology and polarity.

viewof left_sensor_val = Inputs.range([0, 4095], {value: 800, step: 50, label: "Left sensor reading"})
viewof right_sensor_val = Inputs.range([0, 4095], {value: 200, step: 50, label: "Right sensor reading"})
viewof vehicle_type = Inputs.select(
  ["2a: Fear (same-side, excitatory)", "2b: Aggression (cross-wired, excitatory)", "3a: Love (same-side, inhibitory)", "3b: Explorer (cross-wired, inhibitory)"],
  {value: "2b: Aggression (cross-wired, excitatory)", label: "Vehicle type"}
)
viewof base_speed_val = Inputs.range([0, 500], {value: 200, step: 10, label: "Base speed (used in inhibitory modes)"})
viewof gain_val = Inputs.range([0.05, 0.30], {value: 0.15, step: 0.01, label: "Gain factor"})

braitenberg_result = {
  let left_motor = 0;
  let right_motor = 0;
  let behavior = "";
  let direction = "";

  if (vehicle_type.startsWith("2a")) {
    // Fear: same-side, excitatory
    left_motor = Math.round(left_sensor_val * gain_val);
    right_motor = Math.round(right_sensor_val * gain_val);
    behavior = "Fear (avoidance)";
  } else if (vehicle_type.startsWith("2b")) {
    // Aggression: cross-wired, excitatory
    left_motor = Math.round(right_sensor_val * gain_val);
    right_motor = Math.round(left_sensor_val * gain_val);
    behavior = "Aggression (approach)";
  } else if (vehicle_type.startsWith("3a")) {
    // Love: same-side, inhibitory
    left_motor = Math.max(0, Math.round(base_speed_val - left_sensor_val * gain_val));
    right_motor = Math.max(0, Math.round(base_speed_val - right_sensor_val * gain_val));
    behavior = "Love (approach + stop)";
  } else {
    // Explorer: cross-wired, inhibitory
    left_motor = Math.max(0, Math.round(base_speed_val - right_sensor_val * gain_val));
    right_motor = Math.max(0, Math.round(base_speed_val - left_sensor_val * gain_val));
    behavior = "Explorer (avoidance)";
  }

  left_motor = Math.min(1023, Math.max(0, left_motor));
  right_motor = Math.min(1023, Math.max(0, right_motor));

  let diff = right_motor - left_motor;
  if (Math.abs(diff) < 5) {
    direction = "Drives straight";
  } else if (diff > 0) {
    direction = "Turns LEFT (right motor faster)";
  } else {
    direction = "Turns RIGHT (left motor faster)";
  }

  let stimulus_side = left_sensor_val > right_sensor_val ? "left" : (right_sensor_val > left_sensor_val ? "right" : "centered");

  return {left_motor, right_motor, behavior, direction, stimulus_side, diff: Math.abs(diff)};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<p><strong>Vehicle:</strong> ${braitenberg_result.behavior}</p>
<p><strong>Stimulus stronger on:</strong> ${braitenberg_result.stimulus_side} side</p>
<p><strong>Left motor:</strong> ${braitenberg_result.left_motor} &nbsp;&nbsp; <strong>Right motor:</strong> ${braitenberg_result.right_motor}</p>
<p><strong>Turn direction:</strong> ${braitenberg_result.direction} (difference: ${braitenberg_result.diff})</p>
<p style="margin-top: 0.5rem; padding-top: 0.5rem; border-top: 1px solid #dee2e6; font-size: 0.9em; color: #6c757d;">
${braitenberg_result.stimulus_side === "left" ?
  (braitenberg_result.behavior.includes("Fear") ? "Stimulus on left → vehicle turns RIGHT (away from stimulus)" :
   braitenberg_result.behavior.includes("Aggression") ? "Stimulus on left → vehicle turns LEFT (toward stimulus at speed)" :
   braitenberg_result.behavior.includes("Love") ? "Stimulus on left → vehicle turns LEFT (gently toward stimulus, slowing)" :
   "Stimulus on left → vehicle turns RIGHT (wanders away)") :
  braitenberg_result.stimulus_side === "right" ?
  (braitenberg_result.behavior.includes("Fear") ? "Stimulus on right → vehicle turns LEFT (away from stimulus)" :
   braitenberg_result.behavior.includes("Aggression") ? "Stimulus on right → vehicle turns RIGHT (toward stimulus at speed)" :
   braitenberg_result.behavior.includes("Love") ? "Stimulus on right → vehicle turns RIGHT (gently toward stimulus, slowing)" :
   "Stimulus on right → vehicle turns LEFT (wanders away)") :
  "Equal stimulus on both sides → vehicle drives straight"}
</p>
</div>`

30.6.4 Model vs Plant-Pot Motor

The calculator above uses a pure Braitenberg model for excitatory modes (motor = sensor * gain, no base speed), matching the original theoretical formulation. The worked example later in this chapter adds a base speed offset (motor = base_speed + sensor * gain) to overcome real motor friction. Both are valid – the base speed is a practical engineering addition, not a change to the Braitenberg wiring logic. Inhibitory modes use base speed in both the calculator and examples.

Checkpoint: Wiring Creates Behavior

You now know:

• Same-side excitatory wiring turns away from the brighter side; cross-wired excitatory wiring turns toward it.
• Same-side inhibitory wiring can approach and stop near a stimulus instead of charging into it.
• The calculator uses 0-4095 sensor readings, a 0.15 gain, and a 0-500 base-speed range to make the rule visible.

30.6.5 Why Fear Turns Away

Fear uses same-side excitatory mapping:

• Left light sensor controls the left motor.
• Right light sensor controls the right motor.
• More light means more motor speed.
• The brighter side moves faster, so the vehicle turns away from the light.

30.6.6 Why Aggression Turns Toward

Aggression uses cross-wired excitatory mapping:

• Left light sensor controls the right motor.
• Right light sensor controls the left motor.
• More light means more motor speed.
• The opposite motor speeds up, so the vehicle turns toward the light and approaches quickly.

30.6.7 Trace Vehicle 2b Step by Step

The aggressive light-seeking vehicle uses cross-wired excitatory connections:

1. Left light sensor detects brightness on left side
2. Signal crosses to right motor (cross-wired)
3. Right motor speeds up when left sensor sees light (excitatory)
4. Vehicle turns left toward the light source
5. Process repeats continuously, creating approach behavior

Why it works: When light is on the left, the right motor spins faster than the left motor, causing a differential drive turn toward the stimulus. The brighter the light, the faster the turn (excitatory connection). Result: vehicle “attacks” the light source.

Real IoT example: A line-following robot uses the same cross-wired principle – if the left IR sensor sees the dark line, the right motor speeds up to steer the robot left back onto the line, and vice versa. The stronger the deviation, the harder the correction (excitatory connection).

30.6.8 Same Light, Different Turns

Watch a top-down SVG vehicle respond to a light source in real time. Drag the light position slider to see how different wiring configurations cause the vehicle to turn toward or away from the stimulus.

viewof veh_light_x = Inputs.range([-200, 200], {value: -120, step: 5, label: "Light source position (left ← → right)"})
viewof veh_wiring = Inputs.select(
  ["Fear (same-side excitatory)", "Aggression (cross-wired excitatory)", "Love (same-side inhibitory)", "Explorer (cross-wired inhibitory)"],
  {value: "Aggression (cross-wired excitatory)", label: "Wiring configuration"}
)

{
  const W = 480, H = 260;
  const cx = W / 2, cy = H / 2 + 20;

  // Light stimulus: distance to left and right sensors
  const lightX = cx + veh_light_x;
  const lightY = 30;
  const sensorSpread = 30;
  const leftSensorX = cx - sensorSpread, rightSensorX = cx + sensorSpread;
  const leftDist = Math.sqrt((lightX - leftSensorX) ** 2 + (lightY - cy) ** 2);
  const rightDist = Math.sqrt((lightX - rightSensorX) ** 2 + (lightY - cy) ** 2);
  const maxDist = Math.sqrt(400 ** 2 + 230 ** 2);
  const leftIntensity = Math.max(0, 1 - leftDist / maxDist);
  const rightIntensity = Math.max(0, 1 - rightDist / maxDist);

  let leftMotor = 0, rightMotor = 0;
  const base = 0.4, gain = 0.8;
  if (veh_wiring.startsWith("Fear")) {
    leftMotor = leftIntensity * gain;
    rightMotor = rightIntensity * gain;
  } else if (veh_wiring.startsWith("Aggression")) {
    leftMotor = rightIntensity * gain;
    rightMotor = leftIntensity * gain;
  } else if (veh_wiring.startsWith("Love")) {
    leftMotor = Math.max(0, base - leftIntensity * gain);
    rightMotor = Math.max(0, base - rightIntensity * gain);
  } else {
    leftMotor = Math.max(0, base - rightIntensity * gain);
    rightMotor = Math.max(0, base - leftIntensity * gain);
  }

  const diff = rightMotor - leftMotor;
  const angle = diff * 35;
  const avgSpeed = (leftMotor + rightMotor) / 2;

  const leftBarH = leftMotor * 80;
  const rightBarH = rightMotor * 80;

  const turnLabel = Math.abs(angle) < 2 ? "Straight" : (angle > 0 ? "Turning LEFT (toward left)" : "Turning RIGHT (toward right)");

  return html`<svg viewBox="0 0 ${W} ${H}" style="max-width:${W}px; width:100%; background:#f8f9fa; border-radius:8px; border:1px solid #dee2e6;">
    <!-- Light source -->
    <circle cx="${lightX}" cy="${lightY}" r="18" fill="#E67E22" opacity="0.85"/>
    <text x="${lightX}" y="${lightY + 5}" text-anchor="middle" font-size="11" fill="white" font-family="Arial">Light</text>
    <!-- Light rays -->
    <line x1="${lightX}" y1="${lightY + 18}" x2="${leftSensorX}" y2="${cy - 25}" stroke="#E67E22" stroke-width="1" stroke-dasharray="4,3" opacity="0.5"/>
    <line x1="${lightX}" y1="${lightY + 18}" x2="${rightSensorX}" y2="${cy - 25}" stroke="#E67E22" stroke-width="1" stroke-dasharray="4,3" opacity="0.5"/>
    <!-- Vehicle body -->
    <g transform="translate(${cx},${cy}) rotate(${angle})">
      <rect x="-35" y="-22" width="70" height="44" rx="8" fill="#2C3E50" opacity="0.9"/>
      <!-- Left wheel -->
      <rect x="-42" y="-18" width="8" height="16" rx="2" fill="#7F8C8D"/>
      <!-- Right wheel -->
      <rect x="34" y="-18" width="8" height="16" rx="2" fill="#7F8C8D"/>
      <!-- Left sensor -->
      <circle cx="-${sensorSpread}" cy="-22" r="5" fill="#16A085"/>
      <!-- Right sensor -->
      <circle cx="${sensorSpread}" cy="-22" r="5" fill="#16A085"/>
      <!-- Direction arrow -->
      <polygon points="0,-30 -6,-22 6,-22" fill="#3498DB" opacity="${0.3 + avgSpeed}"/>
      <text x="0" y="6" text-anchor="middle" font-size="9" fill="white" font-family="Arial">Vehicle</text>
    </g>
    <!-- Motor speed bars -->
    <rect x="30" y="${200 - leftBarH}" width="22" height="${leftBarH}" rx="3" fill="#16A085" opacity="0.8"/>
    <text x="41" y="218" text-anchor="middle" font-size="10" fill="#2C3E50" font-family="Arial">L: ${(leftMotor * 100).toFixed(0)}%</text>
    <rect x="${W - 52}" y="${200 - rightBarH}" width="22" height="${rightBarH}" rx="3" fill="#9B59B6" opacity="0.8"/>
    <text x="${W - 41}" y="218" text-anchor="middle" font-size="10" fill="#2C3E50" font-family="Arial">R: ${(rightMotor * 100).toFixed(0)}%</text>
    <!-- Labels -->
    <text x="${W / 2}" y="${H - 8}" text-anchor="middle" font-size="12" fill="#2C3E50" font-family="Arial" font-weight="bold">${turnLabel}</text>
    <text x="41" y="${190 - leftBarH}" text-anchor="middle" font-size="9" fill="#7F8C8D" font-family="Arial">Left motor</text>
    <text x="${W - 41}" y="${190 - rightBarH}" text-anchor="middle" font-size="9" fill="#7F8C8D" font-family="Arial">Right motor</text>
  </svg>`;
}

30.7 Everyday IoT Devices Use the Same Reflex

Once you can read a vehicle’s wiring, the same idea shows up in ordinary IoT products: a sensor value crosses a threshold, changes an actuator output, and the device appears responsive without planning.

30.7.1 Smart Lighting System

Use a cross-wired inhibitory rule:

• Left ambient-light sensor controls the right LED.
• Right ambient-light sensor controls the left LED.
• Lower ambient light produces higher LED brightness.
• The room evens itself out without an optimization algorithm.

30.7.2 Temperature-Seeking Robot

Use a same-side inhibitory rule:

• Left thermistor slows the left motor as temperature rises.
• Right thermistor slows the right motor as temperature rises.
• A warmer side slows down, causing the vehicle to turn toward that side.
• When both sides are warm, both motors slow and the robot stops near the heat source.

30.7.3 Try Sensor-Actuator Mapping in IoT Terms

Choose a real-world IoT application and adjust the sensor reading to see how different Braitenberg wiring types translate into actuator output. This demonstrates that many everyday IoT devices use simple reactive mappings.

viewof iot_app = Inputs.select(
  ["Smart Thermostat", "Adaptive Lighting", "Fan Controller", "Plant Watering System"],
  {value: "Smart Thermostat", label: "IoT application"}
)
viewof iot_sensor_reading = Inputs.range([0, 100], {value: 50, step: 1, label: "Sensor reading (%)"})
viewof iot_setpoint = Inputs.range([10, 90], {value: 50, step: 1, label: "Setpoint / threshold (%)"})

iot_mapping_result = {
  const r = iot_sensor_reading;
  const sp = iot_setpoint;
  let sensorName = "", actuatorName = "", sensorUnit = "", actuatorUnit = "";
  let output = 0;
  let wiringType = "";
  let explanation = "";

  if (iot_app === "Smart Thermostat") {
    sensorName = "Temperature sensor";
    actuatorName = "Heater";
    sensorUnit = "°C";
    actuatorUnit = "% power";
    // Inhibitory: higher temp -> less heating
    output = Math.max(0, Math.min(100, (sp - r) * 3 + 50));
    if (r < sp) output = Math.min(100, (sp - r) * 5);
    else output = 0;
    wiringType = "Same-side inhibitory (Love)";
    explanation = r < sp
      ? `Temperature (${r}°C) is below setpoint (${sp}°C) — heater is ON at ${output.toFixed(0)}% to warm the room.`
      : `Temperature (${r}°C) is at or above setpoint (${sp}°C) — heater is OFF. The system has "arrived" at its target, like a love vehicle stopping near the stimulus.`;
  } else if (iot_app === "Adaptive Lighting") {
    sensorName = "Ambient light sensor";
    actuatorName = "LED brightness";
    sensorUnit = "lux (%)";
    actuatorUnit = "% brightness";
    // Cross-wired inhibitory: low ambient -> high LED
    output = Math.max(0, Math.min(100, 100 - r));
    wiringType = "Cross-wired inhibitory (Explorer)";
    explanation = `Ambient light is ${r}% — LED compensates at ${output.toFixed(0)}% brightness. Dark rooms get bright LEDs; bright rooms get dim LEDs. The cross-wired inhibitory mapping maintains even illumination.`;
  } else if (iot_app === "Fan Controller") {
    sensorName = "Temperature sensor";
    actuatorName = "Fan speed";
    sensorUnit = "°C (%)";
    actuatorUnit = "% speed";
    // Excitatory: higher temp -> faster fan
    output = r > sp ? Math.min(100, (r - sp) * 4) : 0;
    wiringType = "Same-side excitatory (Fear-like)";
    explanation = r > sp
      ? `Temperature (${r}%) exceeds threshold (${sp}%) — fan runs at ${output.toFixed(0)}% to cool down. Higher temperature drives stronger actuator response (excitatory).`
      : `Temperature (${r}%) is below threshold (${sp}%) — fan is OFF. No stimulus above threshold means no response.`;
  } else {
    sensorName = "Soil moisture sensor";
    actuatorName = "Water pump";
    sensorUnit = "% moisture";
    actuatorUnit = "% flow";
    // Inhibitory: high moisture -> no watering
    output = r < sp ? Math.min(100, (sp - r) * 3) : 0;
    wiringType = "Same-side inhibitory (Love)";
    explanation = r < sp
      ? `Soil moisture (${r}%) is below threshold (${sp}%) — pump runs at ${output.toFixed(0)}% flow. As moisture rises toward the setpoint, the pump gradually reduces (inhibitory), stopping when the soil is sufficiently moist.`
      : `Soil moisture (${r}%) is at or above threshold (${sp}%) — pump is OFF. The system has reached its "love" target.`;
  }

  return {sensorName, actuatorName, sensorUnit, actuatorUnit, output, wiringType, explanation};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
<p><strong>${iot_mapping_result.sensorName}:</strong> ${iot_sensor_reading}${iot_mapping_result.sensorUnit === "lux (%)" ? "%" : ""} → <strong>${iot_mapping_result.actuatorName}:</strong> ${iot_mapping_result.output.toFixed(0)}${iot_mapping_result.actuatorUnit === "% power" || iot_mapping_result.actuatorUnit === "% brightness" || iot_mapping_result.actuatorUnit === "% speed" || iot_mapping_result.actuatorUnit === "% flow" ? "%" : ""}</p>
<div style="display:flex; gap:1rem; align-items:center; margin: 0.75rem 0;">
  <div style="flex:1;">
    <div style="background:#dee2e6; border-radius:4px; height:18px; overflow:hidden;">
      <div style="background:#3498DB; height:100%; width:${iot_sensor_reading}%; border-radius:4px; transition: width 0.3s;"></div>
    </div>
    <div style="font-size:0.8em; color:#7F8C8D; text-align:center; margin-top:2px;">Sensor: ${iot_sensor_reading}%</div>
  </div>
  <div style="font-size:1.2em; color:#2C3E50;">→</div>
  <div style="flex:1;">
    <div style="background:#dee2e6; border-radius:4px; height:18px; overflow:hidden;">
      <div style="background:#16A085; height:100%; width:${iot_mapping_result.output}%; border-radius:4px; transition: width 0.3s;"></div>
    </div>
    <div style="font-size:0.8em; color:#7F8C8D; text-align:center; margin-top:2px;">Actuator: ${iot_mapping_result.output.toFixed(0)}%</div>
  </div>
</div>
<p><strong>Braitenberg wiring type:</strong> ${iot_mapping_result.wiringType}</p>
<p style="font-size: 0.9em; color: #6c757d; border-top: 1px solid #dee2e6; padding-top: 0.5rem; margin-top: 0.5rem;">${iot_mapping_result.explanation}</p>
</div>`

30.8 Start Simple, Then Prove You Need More

You have now seen the same rule in moving robots and everyday IoT devices. The next decision is architectural: when is a direct reflex enough, and when does the product need memory, mapping, or recognition?

Reactive control is not always enough, but it is often the correct first design. The next question is how long a simple reflex can carry a product before memory, mapping, or pattern recognition becomes necessary.

Figure 30.3: Sensor-actuator feedback loop from sensor reading through controller decision, actuator action, environment response, and feedback verification

30.8.1 Reactive Roomba Navigation

Early Roomba models are useful because they turned a small sensor set into useful floor coverage without building a map first. Their core behaviors were Braitenberg-like reflexes: sense a local condition, choose a wheel response, repeat.

Sensor	Behavior When Triggered	Braitenberg Equivalent
Front bumper (left hit)	Reverse 2 cm, rotate right 30-90 degrees random	Fear (same-side excitatory avoidance)
Front bumper (right hit)	Reverse 2 cm, rotate left 30-90 degrees random	Fear (same-side excitatory avoidance)
Cliff sensor (IR)	Immediate reverse, rotate 180 degrees	Fear (strong excitatory response to danger stimulus)
Wall-following IR	Maintain 3-5 cm distance from wall on right side	Love (same-side inhibitory – approaches wall and stays near)

The cleaning strategy combined three loops: spiral outward, follow a wall when useful, then bounce away at a randomized angle after bumper contact. It is not route planning; it is local reflexes arranged so repeated motion covers enough of the room.

The limit is just as important: random bounce can miss L-shaped spaces, bumper-only sensing can trap the robot under furniture, and redundant traversals make cleaning slow. Design lesson: start with the reflex, then add mapping, memory, or prediction only when a measured failure needs it.

Checkpoint: Reflexes in Products

You now know:

• Smart lighting, thermostats, fan controllers, and plant watering all fit the same sensor-to-actuator template.
• Early Roomba behavior combined local loops: spiral, wall follow, bumper reverse, and random turn.
• Random bounce is useful but limited; missed spaces and repeated paths are evidence for adding memory or mapping.

30.8.2 Sensor Squad Walkthrough

Sammy the Sensor built a tiny robot car with two light sensors and two motors. Same-side excitatory wiring made the bright-side wheel spin faster, so the car turned away from a flashlight. Cross the wires and the same flashlight made the car turn toward it.

Then Sammy kept the same-side wiring but reversed the effect: more light slowed the motor instead of speeding it up. The car approached gently and stopped near the light. Max summed it up: changing the mapping changed the behavior, even though the robot still had no AI.

30.9 Build a Light-Following Plant Pot

Scenario: create an IoT plant pot that rotates toward the nearest window. Two LDRs sense light direction, two small DC motors rotate the base, and the controller should maximize sunlight without camera vision or cloud logic.

Figure 30.4: H-bridge motor control circuit with forward, reverse, brake, and coast switching states

Choose the topology: the pot should approach and orient toward light, so use cross-wired excitatory mapping. The left LDR drives the right motor, the right LDR drives the left motor, and stronger light means more motor speed. If light is on the left, the right motor speeds up and the pot turns left.

Implement the controller loop:

The controller loop only needs four steps:

1. Read the left and right LDR values.
2. Use cross-wiring: left light drives the right motor; right light drives the left motor.
3. Add a small base speed so the motors overcome friction.
4. Update motor PWM about 10 times per second.

Rule of thumb: right_speed = base + left_light * gain, and left_speed = base + right_light * gain.

Measured behavior should match the wiring: far-left light makes the right motor faster so the pot turns left; centered light gives equal motor speeds; far-right light makes the left motor faster.

When the pot is nearly centered, sensor noise can make it jitter. Add a dead zone:

Use a simple dead-zone rule:

• Stop both motors when the two light readings differ by less than about 100 ADC counts.
• Otherwise apply the cross-wired Braitenberg motor rule.

Result: the pot rotates toward the brightest light source and stops when aligned. If the motors and ESP32 draw about 280 mA during rotation, duty cycle dominates battery life.

30.9.1 Battery Life Math Behind the Plant Pot

Battery life depends on duty cycle. For 5 minutes of 280 mA rotation per day:

\[E_{daily} = I \times t = 280 \text{ mA} \times \frac{5}{60} \text{ h} = 23.3 \text{ mAh/day}\]

With 2500 mAh AA batteries (4x in series = 6V, regulated to 5V):

\[\text{Battery life} = \frac{2500 \text{ mAh}}{23.3 \text{ mAh/day}} = 107 \text{ days}\]

Sleep current is tiny by comparison: 10 uA for 23.92 hours is about 0.24 mAh/day, so motor energy still dominates.

30.9.2 Try the Battery-Life Tradeoff

viewof motor_current = Inputs.range([50, 500], {value: 280, step: 10, label: "Active current draw (mA)"})
viewof active_minutes = Inputs.range([1, 60], {value: 5, step: 1, label: "Active minutes per day"})
viewof sleep_current = Inputs.range([1, 100], {value: 10, step: 1, label: "Sleep current (uA)"})
viewof battery_capacity = Inputs.range([500, 10000], {value: 2500, step: 100, label: "Battery capacity (mAh)"})

battery_result = {
  let active_hours = active_minutes / 60;
  let sleep_hours = 24 - active_hours;
  let daily_active = motor_current * active_hours;
  let daily_sleep = (sleep_current / 1000) * sleep_hours;
  let daily_total = daily_active + daily_sleep;
  let life_days = battery_capacity / daily_total;
  let life_months = life_days / 30.44;
  let sleep_pct = (daily_sleep / daily_total) * 100;
  return {daily_active, daily_sleep, daily_total, life_days, life_months, sleep_pct};
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<p><strong>Daily active energy:</strong> ${battery_result.daily_active.toFixed(1)} mAh (${active_minutes} min at ${motor_current} mA)</p>
<p><strong>Daily sleep energy:</strong> ${battery_result.daily_sleep.toFixed(2)} mAh (${(24 - active_minutes/60).toFixed(1)} h at ${sleep_current} uA)</p>
<p><strong>Total daily draw:</strong> ${battery_result.daily_total.toFixed(1)} mAh</p>
<p><strong>Estimated battery life:</strong> ${battery_result.life_days.toFixed(0)} days (~${battery_result.life_months.toFixed(1)} months)</p>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: #6c757d;">Sleep energy is ${battery_result.sleep_pct.toFixed(1)}% of total -- ${battery_result.sleep_pct < 5 ? "motor energy dominates, optimizing sleep current has minimal impact" : "sleep current is significant, consider deeper sleep modes"}.</p>
</div>`

Key insight: this reactive system is simpler than using a camera, vision pipeline, servo controller, and compass for the same task.

30.10 Choose Reactive Control or AI/ML

System Requirement	Reactive (Braitenberg-style)	AI/ML Required
Response to immediate stimulus	Yes: thermostat turns on heater when T < setpoint	Not needed
Pattern recognition	No: cannot detect “person” vs “dog” in camera feed	Yes: requires ML image classification
Memory of past events	No: cannot remember “this room was cleaned 1 hour ago”	Yes: requires state tracking or ML
Fail-safe behavior	Yes: loss of control sends actuators to safe default state	AI failure modes are unpredictable

Decision shortcut: start reactive when the rule is “sensor X crosses threshold Y, so actuator Z changes.” Add AI/ML for recognition, prediction, adaptation, or planning. For fail-safe or sub-100 ms behavior, keep the reactive path in control even when ML is added.

Worked examples:

IoT System	Correct Approach	Why
Smart thermostat	Reactive	If T < setpoint-1°C → turn ON heater. If T > setpoint+1°C → turn OFF. No ML needed.
Person detection for security camera	AI (computer vision)	Must distinguish “person” from “cat” or “tree shadow” → requires ML image classification
Emergency stop button	Reactive	Button press → IMMEDIATELY cut power to motor. No latency tolerance for AI.

On an ESP32-class system, the reactive path usually has smaller code, shorter active windows, less training work, and more predictable failure modes. Key recommendation: prototype it first, then add AI/ML only for genuine recognition, prediction, or adaptation problems.

Reflexes Before Complex Behavior

The mistake: a team builds an “AI-powered smart fan” before testing whether temperature can directly drive fan speed. The simple baseline is a Braitenberg-style mapping.

The core rule is direct: below 22°C the fan is off, from 22°C to 26°C speed increases linearly, and above 26°C the fan runs at maximum. That mapping is predictable, fast, and easy to test.

A quick bench test exposes why the reflex should be the baseline: at 28°C the model may underestimate fan speed, at 20°C it may false-activate, and after a sudden temperature spike it may wait for a prediction window. The Braitenberg rule has no hidden state, updates immediately, and remains easy to test.

When ML genuinely improves the system: add it after the reactive controller works, and let it refine edge cases without owning safety.

Use ML only as a refinement layer:

1. Always compute a safe reactive fan speed first.
2. Let ML adjust the speed only when its confidence is high.
3. Fall back to the reactive speed whenever the model is uncertain.

This keeps deterministic safety while allowing later optimization.

Key takeaway: prototype the reactive controller first. Add ML only when it gives a measured user benefit.

Checkpoint: Reactive Before AI

You now know:

• Reactive control is right when the rule is “sensor X crosses threshold Y, so actuator Z changes.”
• AI/ML is justified for recognition, prediction, adaptation, or planning, not for a basic threshold response.
• Safety-critical and sub-100 ms paths should keep a deterministic reactive fallback even when ML is added.

30.11 One-Button Behavior Switching

With the design decision made, return to the wiring itself. A one-button mode switch is a compact way to test whether you can predict behavior before watching the robot move.

This exercise switches a Braitenberg vehicle between fear, aggression, and love modes using a button. Focus on how wiring topology changes behavior:

The mode-switching controller has one repeated loop:

1. Read the button; if pressed, rotate through Fear, Aggression, and Love modes.
2. Read the left and right light sensors.
3. Apply the selected wiring rule:
   • Fear: left sensor -> left motor, right sensor -> right motor.
   • Aggression: left sensor -> right motor, right sensor -> left motor.
   • Love: stronger light reduces the same-side motor speed.
4. Update both motor PWM values and repeat at about 20 Hz.

The important learning point is the mapping, not the boilerplate pin setup.

Behavior observations when testing:

Mode	Flashlight on left	Flashlight on right	Flashlight centered
Fear	Turns right (away)	Turns left (away)	Drives straight ahead fast
Aggression	Turns left (toward)	Turns right (toward)	Drives straight into light
Love	Turns left (toward) slowly	Turns right (toward) slowly	Slows down, stops near light

30.11.1 Compare Four Modes Side by Side

Compare all four Braitenberg vehicle behaviors side by side. Set a single light stimulus and observe how each wiring configuration produces a completely different motor response and turning direction from the same sensor input.

viewof comp_left_light = Inputs.range([0, 100], {value: 75, step: 1, label: "Left sensor intensity (%)"})
viewof comp_right_light = Inputs.range([0, 100], {value: 25, step: 1, label: "Right sensor intensity (%)"})

{
  const modes = [
    {name: "Fear", sub: "Same-side excitatory", color: "#E74C3C"},
    {name: "Aggression", sub: "Cross-wired excitatory", color: "#E67E22"},
    {name: "Love", sub: "Same-side inhibitory", color: "#16A085"},
    {name: "Explorer", sub: "Cross-wired inhibitory", color: "#9B59B6"}
  ];

  const L = comp_left_light / 100;
  const R = comp_right_light / 100;
  const base = 0.5;

  const motors = [
    {left: L, right: R},
    {left: R, right: L},
    {left: Math.max(0, base - L * 0.8), right: Math.max(0, base - R * 0.8)},
    {left: Math.max(0, base - R * 0.8), right: Math.max(0, base - L * 0.8)}
  ];

  const colW = 112, rowH = 140, pad = 8;
  const W = colW * 4 + pad * 5, H = rowH + 60;

  const cards = modes.map((m, i) => {
    const lm = motors[i].left;
    const rm = motors[i].right;
    const diff = rm - lm;
    const turnAngle = diff * 30;
    const turn = Math.abs(diff) < 0.03 ? "Straight" : (diff > 0 ? "Turns LEFT" : "Turns RIGHT");
    const x = pad + i * (colW + pad);
    const cx = x + colW / 2;
    const cy = 75;

    return `
      <rect x="${x}" y="0" width="${colW}" height="${rowH}" rx="6" fill="white" stroke="${m.color}" stroke-width="2"/>
      <text x="${cx}" y="18" text-anchor="middle" font-size="12" font-weight="bold" fill="${m.color}" font-family="Arial">${m.name}</text>
      <text x="${cx}" y="30" text-anchor="middle" font-size="8" fill="#7F8C8D" font-family="Arial">${m.sub}</text>
      <g transform="translate(${cx},${cy}) rotate(${turnAngle})">
        <rect x="-18" y="-12" width="36" height="24" rx="4" fill="${m.color}" opacity="0.85"/>
        <rect x="-22" y="-9" width="5" height="8" rx="1" fill="#7F8C8D"/>
        <rect x="17" y="-9" width="5" height="8" rx="1" fill="#7F8C8D"/>
        <polygon points="0,-16 -4,-12 4,-12" fill="white" opacity="0.7"/>
      </g>
      <text x="${x + 8}" y="${rowH - 28}" font-size="9" fill="#2C3E50" font-family="Arial">L: ${(lm * 100).toFixed(0)}%</text>
      <text x="${x + colW - 8}" y="${rowH - 28}" text-anchor="end" font-size="9" fill="#2C3E50" font-family="Arial">R: ${(rm * 100).toFixed(0)}%</text>
      <text x="${cx}" y="${rowH - 10}" text-anchor="middle" font-size="10" font-weight="bold" fill="${m.color}" font-family="Arial">${turn}</text>
    `;
  }).join("");

  const stimLabel = L > R ? "Stimulus stronger on LEFT" : (R > L ? "Stimulus stronger on RIGHT" : "Equal stimulus");

  return html`<svg viewBox="0 0 ${W} ${H}" style="max-width:${W}px; width:100%; background:#f8f9fa; border-radius:8px; border:1px solid #dee2e6;">
    ${cards}
    <text x="${W / 2}" y="${rowH + 20}" text-anchor="middle" font-size="11" fill="#2C3E50" font-family="Arial">${stimLabel} (L:${comp_left_light}% R:${comp_right_light}%)</text>
    <text x="${W / 2}" y="${rowH + 38}" text-anchor="middle" font-size="10" fill="#7F8C8D" font-family="Arial">Same inputs → four completely different behaviors from wiring alone</text>
  </svg>`;
}

30.11.2 Label the Sensor-to-Behavior Chain

30.11.3 Code Challenge

Checkpoint: Practice Evidence

You now know:

• The label quiz follows the chain from sensor detection to wiring, coupling type, and emergent behavior.
• The code quiz checks the cross-wired rule: left sensor drives the right motor, and right sensor drives the left motor.
• Mode switching should preserve the same sensor readings while changing only the wiring rule.

30.12 Transfer Functions and Tuning

The core chapter above shows how wiring topology and polarity produce reactive behaviors. The companion page goes one layer deeper: sensor transfer functions, photoresistor compression, saturation, lag, and tuning evidence decide whether that simple wiring behaves predictably on real hardware.

30.12.1 Next Reactive Design Practice

Continue with Transfer Functions and Reactive Tuning to bench-test LDR curves, motor scaling, state-machine modes, matching/order practice, and common implementation pitfalls.

30.13 Summary

Key takeaways from Braitenberg vehicles:

1. Simple sensor-actuator links create emergent behavior – wiring topology and polarity alone produce fear, aggression, love, and exploration
2. Connection type determines behavior – same-side vs cross-wired sets direction; excitatory vs inhibitory sets intensity
3. Many IoT systems are essentially Braitenberg vehicles – thermostats, motion lights, and fan controllers use direct sensor-actuator mapping
4. Consider reactive design before complex AI – the majority of commercial IoT products use purely reactive logic for their core function

30.14 What’s Next

Now that you can map sensor inputs to actuator outputs using Braitenberg principles:

Next Topic	Description
Transfer Functions and Reactive Tuning	Tune sensor curves, motor scaling, and mode-switching evidence for real reactive systems
Infrastructure Sensing	Leverage existing infrastructure as sensor inputs for reactive systems
Calibration Techniques	Calibrate sensors to ensure accurate readings for reliable actuator mappings
Common IoT Sensors	Survey popular sensor types used in real-world Braitenberg-style IoT devices
Sensor Classification	Review how sensors are categorized by measurement principle and output type
Signal Processing	Apply filtering and conditioning to sensor data before actuator mapping