Plataformas y entorno de trabajo

01 · Punto de partida

Elegir desde los requisitos

En el tema anterior separamos sensores, controlador, potencia y mecánica. Ahora tenemos que elegir qué equipo ejecutará el programa. La pregunta útil es qué necesita hacer el robot y en cuánto tiempo.

Un seguidor de línea puede tomar decisiones con unas pocas lecturas y dos salidas de motor. Un robot que identifica objetos en imágenes necesita procesar muchos más datos. Ambos se mueven, pero eso no significa que deban usar el mismo controlador.

• Entradas y salidas: cantidad de sensores, canales analógicos, encoders, PWM y buses.
• Tiempo: período del lazo y máximo retardo aceptable ante una condición de parada.
• Datos: memoria para variables, imágenes, registros y comunicaciones.
• Entorno: consumo, alimentación, espacio y compatibilidad eléctrica.
• Herramientas: bibliotecas, documentación, simulación y facilidad para depurar.

No cuentes solo pines totales: dos funciones pueden competir por el mismo pin o periférico. El resultado de esta etapa debe ser una lista de recursos asignados, no únicamente el nombre de una placa.

02 · Dos formas de ejecutar

Microcontrolador o computadora de placa única

Un microcontrolador no garantiza por sí solo que el programa cumpla sus plazos: una lectura bloqueante o demasiados mensajes por serie pueden atrasarlo. Del mismo modo, una computadora puede resolver tareas temporales mediante periféricos o soluciones específicas; lo que no debemos suponer es que un bucle de usuario bajo un sistema operativo general mantenga un período exacto.

Distinguí velocidad de cálculo de previsibilidad temporal. Terminar una tarea muy rápido en promedio no sirve si alguna vez se retrasa más de lo que el robot puede tolerar.

03 · Primera plataforma

Arduino como punto de partida

Arduino nombra un ecosistema de placas, herramientas y bibliotecas, no un único procesador. Para fijar un ejemplo concreto usaremos el UNO R3 basado en ATmega328P. No hay que trasladar automáticamente sus características a un UNO R4, un Nano de otra familia o una placa compatible. La documentación oficial del UNO R3 identifica el modelo y sus recursos.

Su principal ventaja didáctica es un recorrido corto entre escribir código y observar una señal. Un programa Arduino tiene setup() para la inicialización y loop() para el trabajo repetido. Podés empezar por un registro serie y agregar sensores por etapas.

Las limitaciones aparecen cuando se acumulan buffers, bibliotecas o procesamiento pesado. Para un robot simple conviene mantener los datos acotados y evitar cargar tareas que no aportan al control. Antes de sumar una biblioteca revisá qué memoria, temporizadores y pines necesita.

Este tema usará una prueba Arduino sin sensores ni motores. Así comprobamos primero la cadena de herramientas, sin mezclar problemas de programación con problemas del montaje.

04 · Comunicación y más recursos

ESP32 y conectividad

ESP32 es una familia de chips y placas de desarrollo. Puede ser una opción para un robot que necesita control y comunicación inalámbrica, pero hay que identificar el chip y la placa exactos: los recursos y las funciones inalámbricas cambian entre variantes. La guía oficial de Arduino-ESP32 enlaza la compatibilidad de los chips y explica cómo instalar el soporte.

Usar el entorno Arduino en una ESP32 no convierte todos sus pines ni sus periféricos en equivalentes a los de un UNO. Hay que revisar numeración, restricciones de arranque, entradas disponibles y API de cada biblioteca. Una placa que recibe alimentación por USB tampoco admite necesariamente esa tensión en sus entradas de señal.

La red debe tener límites de tiempo. Si el robot espera la respuesta de un servidor dentro del lazo de motores, la conectividad puede hacer que reaccione tarde. Una arquitectura más robusta usa las comunicaciones para actualizar objetivos y reserva un camino local para la parada y el control.

05 · Procesamiento de alto nivel

Raspberry Pi y arquitectura mixta

Las computadoras Raspberry Pi permiten ejecutar Linux y aplicaciones para visión, archivos o interfaces. La familia Raspberry Pi Pico corresponde a microcontroladores y no ejecuta Linux. Esta diferencia está aclarada en la documentación oficial de hardware Raspberry Pi: compartir marca no implica compartir forma de trabajo.

Una posibilidad para un robot con cámara es dividir responsabilidades: la computadora identifica un objetivo y un microcontrolador mantiene los lazos de los motores. No es obligatorio usar dos equipos; es una decisión de arquitectura que debe justificar la complejidad adicional.

Por ejemplo, la computadora solicita una velocidad, no una secuencia interminable de pulsos. El controlador local valida la orden, actualiza las salidas y detiene si la comunicación vence. Así la pérdida de una aplicación de alto nivel tiene un comportamiento definido.

06 · Decisión razonada

Comparar sin confundir modelos

Para seguir el curso podés comenzar con un UNO R3 simulado o con una placa que ya tengas y conozcas. Cuando aparezca un periférico específico, habrá que adaptar sus conexiones y código. No hace falta incorporar visión ni conectividad para comprender los primeros lazos de movimiento.

07 · Preparación

Preparar el entorno paso a paso

Vamos a usar Arduino IDE como camino inicial. La guía de instalación oficial permite obtener la versión correspondiente a tu sistema. Los nombres de algunos controles pueden variar con la versión y el idioma.

1. Identificá la placa. Anotá modelo, revisión y chip; buscá su diagrama de pines.
2. Instalá el IDE. Después instalá el paquete de placas correspondiente mediante el gestor de placas. Para UNO R3 usá Arduino AVR Boards.
3. Si elegís ESP32: seguí la guía de Espressif citada antes; agregá el índice estable del paquete y seleccioná el modelo concreto.
4. Conectá solo la placa por USB. Usá un cable que transmita datos. Todavía no conectes motores ni alimentación externa.
5. Seleccioná placa y puerto. En Windows suele aparecer un puerto COM. Identificalo observando qué dispositivo aparece al conectar la placa.
6. Verificá y cargá la prueba siguiente. Compilar y transferir son etapas distintas; observá cuál falla si aparece un error.
7. Abrí el monitor serie a 115200 baudios. Confirmá que aparecen mensajes periódicos y una nueva cabecera al reiniciar.

Si el sistema requiere un controlador USB, identificá primero el dispositivo y obtenelo de su fabricante. Instalar controladores al azar no resuelve una selección incorrecta de placa ni un cable que solo sirve para cargar.

Guardá el modelo elegido y la versión del paquete. Un programa que compila para otra placa no constituye una prueba del hardware que tenés conectado.

08 · Código para la placa

Primera prueba sin motores

Este sketch usa solo el puerto serie. Genera una distancia ficticia que alterna entre 50 y 15 cm cada dos segundos, ejecuta la decisión cada 20 ms y publica un registro cada 200 ms. No lee un sensor ni activa salidas de motor.

const unsigned long PERIODO_CONTROL_MS = 20;
const unsigned long PERIODO_LOG_MS = 200;
unsigned long ultimoControl = 0;
unsigned long ultimoLog = 0;
unsigned long ciclos = 0;
int distanciaCm = 50;
int ordenPwmPct = 0;

void setup() {
  Serial.begin(115200);
  Serial.println("tiempo_ms,distancia_cm,orden_pwm_pct,ciclos");
}

void loop() {
  const unsigned long ahora = millis();

  if (ahora - ultimoControl >= PERIODO_CONTROL_MS) {
    ultimoControl = ahora;
    distanciaCm = ((ahora / 2000UL) % 2 == 0) ? 50 : 15;
    ordenPwmPct = (distanciaCm > 20) ? 40 : 0;
    ciclos++;
  }

  if (ahora - ultimoLog >= PERIODO_LOG_MS) {
    ultimoLog = ahora;
    Serial.print(ahora);
    Serial.print(',');
    Serial.print(distanciaCm);
    Serial.print(',');
    Serial.print(ordenPwmPct);
    Serial.print(',');
    Serial.println(ciclos);
  }
}

Deberías observar filas con una orden de 40 % cuando la distancia ficticia vale 50 cm, y 0 % cuando vale 15 cm. El contador de ciclos crece aproximadamente diez veces entre registros. Puede variar con los tiempos de ejecución; el ejemplo no garantiza un planificador de tiempo real.

Usamos resta de contadores sin signo para medir intervalos y evitar comparar fechas absolutas de forma ingenua cuando el contador vuelve a cero. La referencia de Arduino sobre millis() describe su retorno y desbordamiento. La prueba supone que el programa revisa los intervalos regularmente.

Asignar ultimoControl = ahora descarta las ejecuciones que se hayan perdido: evita una ráfaga de recuperaciones, pero no asegura una frecuencia exacta. Para este primer diagnóstico alcanza; más adelante estudiaremos temporización y organización de estados.

09 · Práctica sin montaje

Simular antes de montar

Podés ejecutar el sketch en un proyecto virtual. Wokwi permite simular placas y componentes electrónicos; antes de elegir una combinación, consultá su lista de hardware admitido. Una familia soportada no implica que todos sus periféricos estén modelados.

1. Creá un proyecto con Arduino UNO para esta primera práctica.
2. Reemplazá el sketch por el código de la sección anterior.
3. Iniciá la simulación y abrí su salida serie.
4. Comprobá la alternancia de distancias y órdenes.
5. Cambiá el umbral de 20 a 60 cm: ahora ambas distancias deben producir parada.
6. Guardá código y configuración del proyecto para poder repetirlo.

Que una prueba virtual funcione no demuestra que una batería sostenga el arranque ni que un sensor mida bien una superficie concreta. La simulación sirve para comprobar hipótesis dentro de un modelo; cada paso al hardware agrega fenómenos que hay que observar.

10 · Exploración interactiva

Laboratorio: ¿entra el trabajo en el período?

Una plataforma debe completar su trabajo antes del siguiente ciclo. Este modelo suma tiempos hipotéticos de lectura, decisión, actuación y registro. Podés agregar una demora ocasional para representar una operación que tarda más de lo habitual.

T es el período deseado y C el trabajo del ciclo. Con margen negativo hay un incumplimiento seguro en el modelo. Un margen positivo indica que esta suma cabe, pero no demuestra que un sistema real cumpla siempre sus plazos.

Los números son entradas didácticas: no son mediciones ni comparaciones de velocidad entre placas. El modelo supone tareas secuenciales, sin solapamiento, y omite otros costes. En un robot se deben medir máximos, variaciones y retardos de adquisición.

Recorrido guiado

1. Con los valores iniciales, el trabajo suma 10 ms en un período de 20 ms: queda el 50 % del período libre.
2. Subí el registro a 15 ms: el total llega a 22 ms y pierde el plazo por 2 ms. Agregar mensajes puede alterar el control.
3. Restablecé y agregá 15 ms de demora: el caso habitual sigue en 10 ms, pero el lento llega a 25 ms. El promedio oculta el incumplimiento.
4. Con esa demora, subí el período a 50 ms: ahora cabe, pero el robot lee y decide menos frecuentemente. Volvé a considerar el avance entre lecturas del tema 1.
5. Restablecé y elegí un período de 10 ms: trabajo y plazo son iguales. No queda margen para costes que el modelo haya omitido.

11 · Método de trabajo

Un proyecto reproducible

Reproducir una prueba requiere algo más que el archivo de código. Guardá lo necesario para que otra persona, o vos dentro de un mes, pueda ejecutar el mismo caso.

robot_prueba/
  robot_prueba.ino
  README.md              # placa, entorno y pasos de ejecución
  conexiones.md          # pines, niveles y esquema del montaje
  pruebas/               # entradas y resultados esperados
  registros/             # mediciones de una versión concreta

En Arduino, el sketch principal comparte nombre con su carpeta. Si usás simulación, guardá también su configuración. En el README anotá versiones del IDE, paquete de placa y bibliotecas, velocidad serie y cualquier ajuste que afecte el resultado.

• Una prueba, un objetivo: por ejemplo, «el contador serie avanza y la orden cambia al cruzar el umbral».
• Una configuración conocida: placa concreta, programa y parámetros identificables.
• Un criterio observable: qué salida confirma el resultado y qué queda sin verificar.
• Un registro: entradas, salidas, tiempos y condiciones del ensayo.

Versioná el proyecto cuando tengas una base que funcione. Después agregá un sensor o una función por vez. Si algo falla, vas a poder comparar con una configuración que sí producía el resultado esperado.

12 · Diagnóstico

Problemas frecuentes del entorno

13 · Práctica guiada

Predecí antes de comprobar

1. Elegir una arquitectura

Un vehículo lee tres sensores de línea y maneja dos motores sin cámara ni red. Otro reconoce objetos con una cámara y envía objetivos de movimiento. ¿Qué arquitecturas considerarías?

2. Presupuesto temporal

Lectura: 6 ms. Decisión: 3 ms. Actuación: 1 ms. Registro: 4 ms. El período es de 20 ms. ¿Cuál es el margen? ¿Qué pasa con una demora adicional de 8 ms?

3. Relajar el período

Un robot avanza a 40 cm/s. Para que entre más trabajo cambiás el período de 20 a 100 ms. ¿Cómo cambia el avance entre lecturas?

4. El alcance de la primera prueba

La salida serie alterna entre orden 40 y 0. ¿Demostraste que el sensor mide bien y que el motor se detiene?

5. Pérdida de enlace

Una computadora solicita avanzar a un microcontrolador y luego su aplicación se cierra. ¿Qué dato o regla falta si el vehículo sigue avanzando indefinidamente?

6. Repetir la prueba

Recibís un sketch que no compila y solo dice «funciona con ESP32». ¿Qué información pedirías o buscarías primero?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 4?

Antes de avanzar, ejecutá la primera prueba en una placa o simulador, explicá qué valida y anotá la configuración que usaste. Después justificá qué plataforma elegirías para un robot sin cámara que necesita detenerse aunque pierda comunicación.

En el próximo tema estudiamos alimentación, baterías y seguridad: cómo sostener la lógica y los motores y preparar las primeras pruebas con cargas reales.