ESP32

El ESP32 es el que decide

En el esquema de percibir, decidir y actuar, el ESP32 es el del medio: recibe las señales de los sensores, corre el programa y maneja el driver que mueve los motores. Es la única parte del robot que no es ni sensor ni actuador: no toca el mundo, lo interpreta.

El ESP32 es el que se usa en esta unidad, porque cubre todo lo que un robot de aprendizaje necesita y además trae Wi-Fi. Cómo se instala el soporte en el IDE, cómo se conecta a una red y todo el detalle del Wi-Fi están en Programación con ESP32 (EFSI I). Acá se ve lo que cambia cuando el ESP32 va arriba del robot.

Los pines que hacen falta

Antes de conectar el primer cable conviene decidir qué pin hace cada cosa y anotarlo. Cambiar un pin después de armar el robot significa mover cables, y mover cables es la forma más rápida de aflojar otro. Un robot de seguidor de línea, por ejemplo, usa más o menos esto:

Son unos ocho pines, y cualquier ESP32 tiene de sobra. Los problemas no vienen por la cantidad, sino por cuáles:

• Primero se reservan las entradas analógicas, porque no cualquier pin puede medir. El resto se reparte después, y las salidas no importan tanto: en el ESP32 el PWM funciona en cualquier pin.
• El pinout se mira, no se adivina. La documentación de Espressif avisa que hay pines con restricciones especiales y que no todos están disponibles en todos los modelos: algunos no sirven como salida, y otros intervienen en el arranque del ESP32. Si un pin de arranque se usa como salida, el ESP32 puede no encender o reiniciarse solo al apretar un botón.
• Se anota la asignación y se escribe al principio del programa como constantes con nombre. Así, cuando haya que cambiar un cable, se cambia un solo número.

// Asignacion de pines: se copia del pinout del ESP32 que se esta usando
const int sensorIzq  = 34;   // entrada digital o analogica, segun el sensor
const int sensorDer  = 35;
const int boton      = 32;
const int dirMotorA  = 26;
const int velMotorA  = 27;
const int dirMotorB  = 16;
const int velMotorB  = 17;

Los 3,3 V y los sensores

Esta es la diferencia que más problemas causa en el taller. El ESP32 trabaja a 3,3 V, y una buena parte de los módulos que hay en los cajones están hechos para 5 V. Cuando un sensor devuelve 5 V a un pin que espera 3,3 V, no es que "lea mal": el pin se está forzando.

El divisor de tensión, con números

El ejemplo clásico es el sensor de distancia por ultrasonido HC-SR04: se alimenta con 5 V y su patita ECHO entrega 5 V cuando vuelve el eco. Con dos resistencias —una de 1 kΩ en serie y una de 2 kΩ hacia masa— la tensión de esa línea baja a los 3,3 V que el pin tolera:

PWM para la velocidad y la dirección

El driver de motores necesita dos señales por motor: una digital que decide para dónde gira, y una PWM que decide a qué velocidad. El ESP32 manda las dos; la corriente la pone la fuente del robot.

const int dirMotorA = 26;   // direccion del motor A
const int velMotorA = 27;   // velocidad del motor A (PWM)
const int dirMotorB = 16;
const int velMotorB = 17;

void setup() {
  pinMode(dirMotorA, OUTPUT);
  pinMode(velMotorA, OUTPUT);
  pinMode(dirMotorB, OUTPUT);
  pinMode(velMotorB, OUTPUT);

  analogWriteFrequency(velMotorA, 5000);   // 5 kHz
  analogWriteFrequency(velMotorB, 5000);
}

void avanzar(int velocidad) {        // velocidad de 0 a 255
  digitalWrite(dirMotorA, HIGH);
  digitalWrite(dirMotorB, HIGH);
  analogWrite(velMotorA, velocidad);
  analogWrite(velMotorB, velocidad);
}

void frenar() {
  analogWrite(velMotorA, 0);
  analogWrite(velMotorB, 0);
}

Tres cosas para tener en cuenta:

• La dirección se cambia con las dos señales invertidas. Si el robot gira sobre sí mismo o va para atrás cuando debería ir adelante, el error más común no es el programa: son los cables del motor puestos al revés, o los dos valores HIGH y LOW intercambiados.
• La frecuencia del PWM se elige. Con frecuencias bajas el motor zumba y arranca a los tirones; subiéndola a unos pocos miles de hercios el movimiento se vuelve suave y silencioso. Es una diferencia que se escucha. Por encima de 20 kHz, además, deja de oírse.
• El motor nunca va conectado a un pin. Ni al ESP32 ni a ningún otro: la corriente que necesita lo destruiría. Entre el ESP32 y el motor siempre hay un driver. Está explicado con números en Motores.

Alimentar el robot sin que se reinicie

Es el problema que más tiempo hace perder, porque el síntoma no se parece a la causa: el robot anda bien hasta que arrancan los motores, y ahí el ESP32 se reinicia. El programa vuelve a empezar de cero, el robot se queda quieto, y parece un problema de código cuando es de alimentación.

La regla es una sola: los motores y el ESP32 no comparten el consumo. El ESP32 se alimenta por su cable, y los motores y servos toman la energía de la fuente del robot, con el driver en el medio. Lo que sí se une son las masas: sin un GND común, las señales no tienen referencia y nada funciona.

Si el robot ya está armado y el reinicio aparece recién ahora, el método para encontrarlo es el de Diagnóstico de problemas: cambiar una cosa por vez, de lo simple a lo complejo, y anotar qué se probó.

Wi-Fi para la telemetría

La ventaja de tener Wi-Fi en el ESP32 es que se puede ver lo que el robot está midiendo mientras se mueve, sin desarmarlo ni perseguirlo con un cable. Eso se llama telemetría, y es la forma más rápida de ajustar un umbral: en lugar de adivinar por qué el robot se va de largo, se mira la sucesión de valores en la pantalla.

Para eso alcanzan las librerías que vienen con el core, y el detalle está en Programación con ESP32. Lo que cambia acá es una regla:

En la práctica eso significa no usar delay() largos ni esperas por la red dentro del ciclo principal. La consulta se hace entre ciclos, cada tanto, comparando tiempos con millis():

unsigned long ultimoEnvio = 0;

void loop() {
  leerSensores();              // el control del robot corre siempre
  decidir();
  mover();

  // el envio es cada 500 ms y no frena el control
  if (millis() - ultimoEnvio >= 500 && WiFi.status() == WL_CONNECTED) {
    ultimoEnvio = millis();
    enviarTelemetria();        // los valores de los sensores y el estado
  }
}

La frecuencia del envío es una decisión de diseño: alcanza con dos o tres envíos por segundo para ver una gráfica, y no tiene sentido mandar cientos. Cada envío ocupa la red y consume tiempo del ESP32, que es el mismo que necesita para controlar los motores. La latencia del Wi-Fi, además, hace imposible pilotear el lazo de control por red: la red es para supervisar, no para manejar el robot cable a cable. La forma de organizar ese ciclo está en Programación estructurada, y los proyectos posibles, en IoT (Internet of Things).

Problemas típicos del ESP32

Resumen

• El ESP32 es la parte que decide: lee los sensores, corre el programa y le manda la orden al driver.
• Los motores no se alimentan desde el ESP32. El ESP32 da la señal; la corriente la da la fuente del robot.
• Se planifica la asignación de pines antes de cablear, reservando primero las entradas analógicas, y se anota.
• El pinout del ESP32 se mira, no se adivina: hay pines con restricciones, y algunos intervienen en el arranque.
• El ESP32 trabaja a 3,3 V: lo que devuelva 5 V pasa por un divisor de tensión o un adaptador de nivel.
• Cada motor necesita una señal de dirección y una de velocidad, y la frecuencia del PWM se elige: más alta, más suave.
• El reinicio al arrancar los motores es un problema de alimentación, no de programa.
• El Wi-Fi sirve para telemetría y órdenes, nunca para sostener el control del robot.