Fundamentos de electrónica para robótica: ruta guiada
Podrá alimentar un robot estable bajo carga, conectar múltiples sensores en un bus I²C y programar un bucle de control no bloqueante de alta frecuencia.
La mayoría de los problemas de un robot que parecen problemas de software no lo son. La placa se reinicia y se culpa al código; un sensor devuelve disparates y se culpa a la biblioteca; el robot ignora su parachoques y se culpa a la lógica. En cada caso la avería está una capa más abajo, en la parte del sistema de la que nadie escribió un tutorial porque parecía demasiado básica para necesitarlo.
Esta ruta es esa capa. Cubre la alimentación —por qué la tensión de una batería se desploma cuando arrancan los motores y qué hacer al respecto; el bus I²C —qué están haciendo realmente esos dos cables que comparten todos los sensores; y la temporización —por qué un bucle que se para a esperar es un robot que no puede reaccionar.
Nada de eso es difícil. Todo ello se da por supuesto en el resto de rutas de este sitio.
Antes de empezar
Necesita un microcontrolador que ya sepa programar y la disposición para poner un multímetro en bornas de una batería. Nada de teoría de control, ni matemáticas más allá de sumar y una división. Si ha construido cualquier cosa en absoluto —aunque sea un LED parpadeante— ya está listo.
Lo que podrá hacer
- Distinguir un reinicio de un cuelgue en menos de un minuto, y saber cuál de los dos está mirando antes de abrir cualquier código.
- Sumar el consumo de corriente de un robot y elegir el pack de batería a partir de ese número, en vez de a partir de lo que venía en el kit.
- Explicar por qué una pila de bloque de 9 V con el voltaje más alto del estante da el peor resultado bajo carga, y predecir cuánto caerá cualquier pack.
- Conectar varios sensores a un mismo bus I²C, encontrarlos con un escáner y resolver una colisión de direcciones de tres maneras distintas.
- Escribir un bucle que lea sensores, maneje motores e informe del estado a tres ritmos distintos sin bloquearse nunca, y acertar en la comparación del desbordamiento.
- Medir su propio tiempo de bucle en el peor caso en vez de asumirlo.
Dónde se atasca la gente
Tratar «no se reinició» como prueba de que la alimentación está bien. El detector de brownout de un Arduino está puesto a 2.7 V, pero un ATmega328P a 16 MHz necesita unos 3.8 V para estar dentro de su velocidad nominal. En esa banda el chip funciona fuera de especificación y nada interviene, y ahí es donde viven los fallos más raros de un robot: variables corruptas, un servo que da un salto, un sensor que devuelve disparates plausibles.
Añadir un condensador y esperar que arregle un reinicio. La aritmética dice lo contrario: un condensador de 1000 µF al que se le pide que aguante una sobretensión de 2 A durante 10 ms caería 20 V. Limpia el rizado de conmutación y los picos de conmutación de los bobinados, que merece la pena hacer, pero solo una batería más dura aguanta la sobretensión.
Apilar placas de expansión en un mismo bus. Casi todas las placas vienen con sus propias resistencias de pull-up, y esas quedan en paralelo. Tres placas es el límite y la cuarta baja el bus por debajo de la corriente que cualquier dispositivo puede absorber: así que tres sensores funcionan y el cuarto mata a todos, sin que haya nada realmente roto.
Leer una dirección de 8 bits de la hoja de datos. La hoja de datos de un MPU-6050 dice 0xD0;
la biblioteca de Arduino quiere 0x68, los mismos bits desplazados a la derecha una posición. Este
es el error de I²C más común que existe, y parece exactamente una placa muerta.
Escribir now >= last + interval. Se lee de forma más natural que la forma con resta, y se
rompe en el desbordamiento de los 49.7 días, disparando continuamente en vez de esperar. Siempre
reste.
Culpar a la lógica del bucle por un bucle bloqueado. Las interrupciones siguen corriendo
durante delay(), así que la cuenta de un encoder se mantiene perfectamente correcta mientras el
robot deja de reaccionar, lo que hace que el síntoma parezca un fallo de toma de decisiones y no uno
de temporización.
Qué necesita
| Qué | Por qué lo necesita esta ruta | Coste aproximado |
|---|---|---|
| Un microcontrolador que sepa programar | Todas las mediciones de aquí se toman sobre una placa en marcha, no sobre papel | Arduino Uno, clon de ~8 $ |
| Un multímetro | El único instrumento sin el que esta ruta no puede: cada afirmación que hace es una que usted verifica | ~15 $ |
| Un pack de batería bajo carga | Un pack medido con nada conectado no le dice nada; necesita uno que esté moviendo algo | Portapilas de 4×AA o un Li-ion 2S |
| Dos placas de expansión I²C | Una placa nunca le muestra el problema de los pull-up. Dos empiezan a mostrárselo. | MPU-6050 y lo que sea, ~5 $ |
| Uno o dos motores | La carga que hace que el raíl se desplome: la avería que esta ruta existe para explicar | Cualquier motorreductor de CC |
Nada de osciloscopio. Todas las mediciones de esta ruta son de corriente continua y un multímetro barato las puede tomar.
Por qué la ruta sigue este orden
El orden no es arbitrario: cada nodo elimina una forma en que el siguiente podría mentirle.
La temporización va antes de todo lo medido. Un bucle bloqueado hace sospechosa cualquier otra medición, porque ya no puede decir cuándo se tomó la lectura. Una vez que el bucle no bloquea puede confiar en una marca de tiempo, y solo entonces una medición vale la pena anotarla.
La alimentación va antes que lo analógico. analogRead en un Arduino es riatiométrico: informa
la entrada como fracción de su referencia, y la referencia por defecto es el mismo raíl de 5 V que
los motores están hundiendo. Mida una batería a través de un divisor sobre un raíl que se desploma y
la lectura sube mientras la batería baja. Leer un voltaje con honestidad es imposible hasta que sepa
qué está haciendo su raíl, así que el nodo de alimentación tiene que ir primero.
I²C va después de la alimentación pero es independiente de lo analógico. El bus es un subsistema aparte, y falla a su manera: por aritmética de pull-up y por colisiones de direcciones, no por caída de alimentación. Cuelga directamente del nodo de la placa, y por eso el árbol se ramifica ahí.
El laboratorio va al final. El simulador de sensores le deja añadir ruido, sesgo y caídas a una señal limpia de forma deliberada. Eso solo es instructivo una vez que ha visto a su propio hardware producirlos por accidente y sabe qué causó cada uno.
Puntos de control: cómo saber que una etapa caló
Cada uno de estos es un ensayo de banco, no un cuestionario. Si no puede dar el número, la etapa no está hecha.
| Etapa | La comprobación | Qué es un aprobado |
|---|---|---|
| Temporización no bloqueante | Imprima la duración en el peor caso de su bucle durante 10 segundos | Un número en microsegundos que ha medido, no que ha asumido, y que no crece cuando desconecta un sensor |
| Batería bajo carga | Mida la tensión del pack con los motores parados y luego en bloqueo | Puede decir la caída en voltios y dividirla por la corriente para obtener la resistencia interna del pack |
| Balance de potencia | Sume el consumo de cada dispositivo en papel y luego mida el total | Papel y medidor coinciden dentro de un ~20 %; si no, ha encontrado un dispositivo que consume más de lo que dice su hoja de datos |
| Entrada analógica | Lea la misma batería a través de su divisor con los motores parados y en marcha | La lectura no cambia cuando arrancan los motores; si cambia, su referencia se está moviendo |
| Bus I²C | Ejecute un escáner de bus añadiendo cada placa de una en una | Aparece cada dirección, y puede nombrar la resistencia total de pull-up del bus |
| Colisión de direcciones | Ponga a nivel alto el pin AD0 del MPU-6050 | El escáner informa 0x69 en vez de 0x68, y puede explicar por qué la hoja de datos dice 0xD0 |
Dónde termina esta ruta
Esta ruta termina deliberadamente en el punto donde la electrónica deja de mentirle. No cubre drivers de motores, laazos de control, ni nada que decida dónde debe ir un robot: eso son las rutas de control de motores y de control PID, y ambas dan por supuesto todo lo de aquí.
También se queda corta de tres cosas que vale la pena nombrar para que sepa que existen. No cubre los reguladores conmutados, que es la forma de obtener 5 V de un pack de 12 V sin quemar la diferencia en forma de calor en un regulador lineal. No cubre el desplazamiento de niveles entre dispositivos de 5 V y de 3.3 V, que necesitará la primera vez que ponga un ESP32 y un sensor de 5 V en el mismo bus. Y no cubre el diseño de PCB o la soldadura: todo lo de aquí se hace sobre una protoboard, lo cual está bien para aprender y es en sí mismo una fuente de fallos intermitentes en cuanto un robot empieza a moverse.
Ruta de aprendizaje
La ruta
Sigue los nodos en orden: cada uno desbloquea el siguiente cuando lo completas. Tu progreso se guarda en este dispositivo.
0 / 9 completados
Preguntas comunes
Preguntas frecuentes
¿Qué electrónica básica debo conocer antes de montar un robot?
Tres conceptos elementales. Primero, dimensionar la fuente de alimentación calculando la corriente pico real para evitar reinicios por microcortes al encender motores. Segundo, dominar el bus I²C para enlazar varios sensores en dos cables compartidos sin conflictos eléctricos ni colisiones de dirección. Tercero, programar bucles de control no bloqueantes para que el procesador sondee sensores sin detenerse a esperar. Todo el software y la teoría de control descansan sobre estos tres pilares.
¿Por qué se reinicia el microcontrolador cuando arrancan los motores?
La corriente de arranque transitoria de los motores genera una caída brusca de tensión al atravesar la resistencia interna de la batería. Un pico de 2 A sobre un pack con 0.5 Ω de resistencia interna hunde el carril en 1.0 V antes del regulador de la placa. Si dicha caída alcanza el umbral de brown-out del microcontrolador, este se reinicia inmediatamente. La solución es una batería de menor resistencia interna y separar la línea de potencia de los motores de la lógica, no añadir un condensador electrolítico arbitrario.
¿Cuántos sensores I²C pueden conectarse en un mismo Arduino?
El direccionamiento de 7 bits admite teóricamente 112 dispositivos, pero el límite eléctrico físico llega mucho antes. La inmensa mayoría de placas comerciales montan sus propias resistencias pull-up (típicamente de 4.7 kΩ), las cuales quedan conectadas en paralelo al unirlas. Con cuatro módulos, la resistencia combinada baja a ~1.2 kΩ, demandando más de 4 mA a nivel bajo (superando los 3 mA admisibles por el estándar I²C). Tres placas suelen operar pero la cuarta bloquea el bus entero; retirar los pull-ups redundantes resuelve el problema.
¿Es realmente perjudicial usar delay() en código robótico?
En robótica móvil es inaceptable. Mientras la CPU ejecuta delay(), queda ciega: no lee fotosensores, no detecta finales de carrera ni procesa algoritmos. Un retardo de delay(500) a una velocidad de 0.3 m/s supone avanzar 15 cm a ciegas antes de la siguiente comprobación. El síntoma simula fallos de lógica de control cuando el fallo real es el bloqueo temporal. Sustitúyalo por el patrón no bloqueante con millis(), asegurándose de emplear restas para evitar errores de desbordamiento.
¿Se requiere un osciloscopio para seguir esta ruta formativa?
No. Un multímetro digital básico de taller es suficiente para verificar todos los experimentos: medir la caída de batería bajo carga de bloqueo, contrastar divisores resistivos y comprobar niveles de tensión continua. Un osciloscopio aporta visibilidad directa de transitorios inductivos, pero todas las comprobaciones clave se realizan mediante magnitudes de corriente continua medibles con instrumentación económica.
¿Cuánto tiempo toma completar esta ruta de fundamentos?
Aproximadamente dos horas de lectura técnica y una o dos sesiones prácticas en el banco de prototipos para realizar las mediciones físicas. Las mediciones son la clave pedagógica: constatar en banco la caída real de tensión de su propia batería, la impedancia pull-up de sus sensores y la duración del ciclo de su código confiere la intuición de ingeniería que ningún manual puede sustituir.