Anatomía de un robot: sensores, controlador y actuadores

01 · Punto de partida

Del lazo a los componentes

En el tema anterior vimos al robot como un programa que percibe, decide y actúa. Ahora vamos a identificar qué pieza hace cada trabajo. Usaremos como ejemplo un pequeño vehículo de dos ruedas motrices que avanza por el suelo y se detiene cuando detecta un obstáculo.

Sus tres bloques principales son sensores, controlador y actuadores. Pero para que funcionen también necesita una fuente de energía, etapas de potencia, cables y una estructura mecánica. Un programa puede decidir perfectamente y el robot seguir quieto porque falta cualquiera de esas piezas.

El dibujo es funcional: las flechas representan relaciones entre bloques, no todos los conductores de un circuito. Todavía faltan retornos de corriente, protecciones y conexiones específicas. Un diagrama de bloques no es un esquema listo para cablear.

02 · Percibir

Sensores: convertir el mundo en datos

Un sensor transforma una magnitud física en una señal que el controlador puede leer. La magnitud puede pertenecer al entorno (distancia a una pared) o al propio robot (giro de una rueda). La lectura no llega necesariamente en centímetros o grados: a veces llega como tensión, duración de un pulso o cantidad de cuentas.

Conviene distinguir dato crudo, magnitud convertida y decisión. Por ejemplo: 1450 microsegundos de eco → aproximadamente 24,9 cm → «todavía puede avanzar». El sensor aporta evidencia; la regla de detenerse pertenece al programa.

En los temas 5 a 9 vamos a estudiar familias de sensores, ruido y medición de giro. Por ahora interesa saber qué dato entra al sistema, con qué unidades y qué limitaciones tiene.

03 · Decidir

Controlador: interpretar y decidir

El controlador ejecuta el programa, conserva estado en memoria y organiza el tiempo. En un vehículo pequeño puede ser un microcontrolador. Un robot con visión puede sumar una computadora que interpreta imágenes y envía objetivos a otro controlador encargado de los motores.

La decisión «avanzar» parece simple, pero requiere una secuencia concreta:

1. Adquirir la última lectura del sensor.
2. Comprobar si es válida y suficientemente reciente.
3. Convertirla a las unidades que espera el algoritmo.
4. Compararla con el umbral y consultar el estado del robot.
5. Emitir una orden limitada al rango permitido.
6. Registrar lo ocurrido para poder diagnosticarlo.

El controlador no entrega la energía que necesita un motor. Sus pines producen señales de control. Aunque el programa ponga un pin en nivel alto, sigue haciendo falta un circuito capaz de manejar la tensión y la corriente de la carga.

Cuando dividís el trabajo entre dos procesadores también aparece una interfaz: qué órdenes acepta cada uno, cada cuánto se renuevan y qué ocurre si dejan de llegar. Tener más procesadores no elimina la necesidad de diseñar el lazo.

04 · Actuar

Actuadores y etapas de potencia

El actuador transforma energía en una acción física. En nuestro vehículo son los motores que hacen girar las ruedas. En otros robots pueden ser servomotores, motores paso a paso, solenoides o cilindros neumáticos.

Entre controlador y actuador suele existir un driver o etapa de potencia. Recibe señales pequeñas y conmuta la energía de una fuente adecuada. Para un motor de corriente continua, un puente H permite cambiar el sentido de giro y modular la potencia aplicada.

Un servomotor de posición suele integrar motor, transmisión, sensor y electrónica de control en una misma carcasa. Desde afuera parece un único bloque, pero por dentro contiene su propio lazo. El límite del bloque depende del nivel de detalle que necesites.

05 · Soporte físico

Alimentación y mecánica también son parte del robot

La batería debe alimentar las cargas; los reguladores adaptan su tensión a la electrónica. Los motores demandan corrientes que cambian con el esfuerzo y pueden introducir perturbaciones en la alimentación. Por eso un robot puede reiniciarse justo cuando arranca, aunque el programa funcione bien con los motores desconectados.

Una cuenta orientativa ayuda a ver la diferencia entre lógica y potencia. Si dos motores consumen 0,6 A cada uno en cierta condición de marcha y la electrónica consume 0,15 A desde la misma fuente, el total en esa condición es:

Eso no alcanza para dimensionar toda la alimentación: al arrancar o bloquearse los motores pueden demandar más. También hay que revisar tensiones, pérdidas de reguladores y capacidad del driver. El tema 4 desarrolla estas decisiones.

La mecánica es el camino entre el eje y el trabajo útil: reductores, ruedas, correas, articulaciones, chasis y apoyos. Un tornillo flojo puede producir un síntoma parecido al de un error de software: el encoder registra giro, pero la rueda no transmite el movimiento.

• Sin energía suficiente: hay orden, pero el motor no desarrolla el esfuerzo esperado.
• Sin transmisión mecánica: el eje gira, pero la carga no se mueve.
• Sin referencia eléctrica adecuada: una señal puede no interpretarse correctamente.

En conexiones de señal no aisladas suele hacer falta una masa común entre controlador y driver. Eso no significa unir sin criterio todas las alimentaciones: hay que respetar el esquema del equipo y controlar por dónde circula la corriente de los motores.

06 · Conexiones

Cómo se comunican los bloques

Una interfaz define qué cruza una conexión y cómo se interpreta. «Tiene tres cables» no describe una interfaz: necesitás conocer función, niveles eléctricos y formato de la información.

No confundas compatibilidad eléctrica con compatibilidad de datos. Dos equipos pueden entender los mismos mensajes y usar tensiones lógicas incompatibles. También pueden trabajar con la misma tensión y discrepar en el significado de un número: centímetros frente a milímetros, por ejemplo.

Una señal de 5 V no debe conectarse a una entrada de 3,3 V salvo que esa entrada admita expresamente ese nivel o exista una adaptación adecuada. La tensión de alimentación de un módulo tampoco demuestra por sí sola qué niveles acepta en sus pines de señal.

07 · Ejemplo completo

Una vuelta completa del lazo

Supongamos que el robot usa un umbral de 20 cm. En una vuelta del programa ocurre lo siguiente:

1. Sensor: obtiene una lectura válida de 35 cm.
2. Controlador: compara 35 con 20 y decide avanzar.
3. Salida: envía dirección de avance y PWM al 40 % al driver.
4. Driver: conmuta energía de la batería hacia los motores.
5. Mecánica: los motores transmiten giro a las ruedas y el vehículo se desplaza.
6. Entorno: la pared queda más cerca; el sensor lo observará en otra lectura.

Cuando la lectura llega a 18 cm, la decisión pasa a detener. La forma eléctrica de hacerlo depende del driver: deshabilitar una salida, dejar el motor libre y aplicar frenado activo no son necesariamente la misma acción. La distancia real de parada depende de esa implementación y de la mecánica.

Hay dos lazos que conviene distinguir. El sensor frontal cierra el lazo respecto de la distancia al obstáculo. Un encoder puede cerrar otro lazo respecto de la velocidad de la rueda. Tener el primero no implica tener el segundo.

08 · Diseño de software

Datos con unidades, validez y tiempo

Una variable llamada distancia deja demasiadas preguntas abiertas. ¿Está expresada en centímetros? ¿Es una lectura real? ¿De hace cuánto? Un contrato entre módulos puede resolverlo con un pequeño registro:

MedidaDistancia:
    valor_cm: 35.0
    valida: verdadero
    instante_ms: 1240

Si el controlador está en el instante 1300 ms, la medida tiene 1300 − 1240 = 60 ms de antigüedad. Si el máximo permitido es 100 ms, todavía se acepta. En el instante 1400 ya tiene 160 ms: aunque el número siga siendo 35, la información está vencida.

Para este vehículo elegimos detener ante medida inválida o vencida. Eso no identifica la causa exacta: un sensor sin respuesta podría estar desconectado, fuera de rango o mal configurado. Solo establece qué hace el robot cuando no dispone de información suficiente.

La orden de salida también necesita un contrato: por ejemplo, PWM entero de 0 a 100 %, sentido permitido y motivo de parada. Los detalles de pines y polaridades quedan dentro del módulo que maneja el driver.

09 · Código ejecutable

La anatomía traducida a código

Separar lectura, decisión y actuación permite probar reglas sin conectar motores. Este ejemplo en Python usa lecturas simuladas: decidir no sabe qué modelo de sensor existe ni qué pines utiliza el driver.

from dataclasses import dataclass
from math import isfinite


@dataclass
class Medida:
    valor_cm: float
    valida: bool
    instante_ms: int


def decidir(medida, ahora_ms, umbral_cm=20, edad_max_ms=100):
    edad = ahora_ms - medida.instante_ms
    if (not medida.valida or not isfinite(medida.valor_cm)
            or medida.valor_cm < 0):
        return 0, "medida inválida"
    if edad < 0 or edad > edad_max_ms:
        return 0, "medida vencida o tiempo incoherente"
    if medida.valor_cm <= umbral_cm:
        return 0, "obstáculo"
    return 40, "camino libre"


def aplicar(pwm):
    # En el robot real, este módulo configura el driver.
    # Aquí solo mostramos la orden, sin simular frenado ni movimiento.
    return f"orden al driver: PWM {pwm} %"


ahora = 1300
casos = [
    ("libre", Medida(35, True, 1240)),
    ("cerca", Medida(18, True, 1240)),
    ("sin respuesta", Medida(0, False, 1240)),
    ("dato viejo", Medida(35, True, 1100)),
]

for nombre, medida in casos:
    pwm, motivo = decidir(medida, ahora)
    print(f"{nombre}: {aplicar(pwm)}; {motivo}")

Resultado esperado: solo el caso «libre» ordena PWM al 40 %. Los otros tres ordenan 0 %, cada uno con su motivo. Cambiá la distancia de «cerca» a 20: la igualdad también detiene. Cambiá el instante de «dato viejo» a 1200: su edad pasa a ser exactamente 100 ms y se acepta.

En un microcontrolador, las funciones de adquisición y actuación contendrían las operaciones del hardware. Este modelo supone tiempos de un mismo reloj creciente; al trasladarlo a un contador que se desborda hay que calcular el tiempo transcurrido con la aritmética adecuada.

10 · Exploración interactiva

Laboratorio: ¿en qué bloque está el problema?

El laboratorio muestra una instantánea de nuestro vehículo: lectura, decisión y respuesta del motor. No integra una trayectoria ni calcula frenado. Podés introducir fallos conocidos para observar qué evidencia queda en cada bloque.

El encoder usa un modelo didáctico: devuelve 120 rpm si se aplica potencia y el eje está libre, o 0 rpm en los demás casos. No representa la curva de un motor real. El laboratorio conoce el fallo seleccionado; un robot real necesita mediciones adicionales para identificar la causa.

Recorrido guiado

1. Con 60 cm y sin fallo, evaluá: el sensor mide 60 cm, el controlador ordena 40 %, el driver aplica potencia y el encoder informa 120 rpm.
2. Bajá la distancia a 18 cm: la orden pasa a 0 %. Que no gire es el resultado esperado.
3. Volvé a 60 cm y elegí «Sensor sin respuesta»: la regla solicita detener aunque el camino real esté libre. El controlador no puede usar una distancia que desconoce.
4. Elegí «Última medida vencida»: aparece un dato numérico, pero con 250 ms de edad. También se detiene.
5. Probá el driver deshabilitado y luego la alimentación ausente: en ambos casos se ordena 40 % y no se aplica potencia. El registro de software por sí solo no permite distinguirlos.
6. Elegí el eje bloqueado: hay orden y potencia aplicada, pero el encoder marca 0 rpm. En hardware real habría que limitar corriente y tiempo de esfuerzo; no se debe sostener un bloqueo para hacer la prueba.
7. Mantené el bloqueo y bajá a 18 cm: la parada por obstáculo impide aplicar potencia y oculta el fallo mecánico. Una condición correcta en una prueba no demuestra que todos los bloques funcionen.

11 · Método de trabajo

Integrar por etapas

Cuando conectás todo de una vez, cualquier síntoma tiene demasiadas causas posibles. Una secuencia de integración reduce la incertidumbre:

1. Dibujá los bloques. Marcá entradas, salidas, tensiones y camino de energía.
2. Probá las decisiones con datos simulados. Incluí obstáculos, valores inválidos y medidas vencidas.
3. Probá los sensores. Mostrá dato crudo, valor convertido, validez e instante antes de mover motores.
4. Verificá alimentación e interfaces. Comprobá rangos, masas y habilitación según los componentes usados.
5. Probá cada actuador con movimiento contenido. En el vehículo, empezá con las ruedas levantadas y órdenes pequeñas; comprobá sentido y respuesta.
6. Agregá realimentación. Compará lo ordenado con lo medido, sin confundir giro del eje con desplazamiento del robot.
7. Probá el conjunto a baja velocidad. Observá también alimentación y tiempos del lazo bajo carga.

Un registro útil muestra tiempo, medida, validez, edad, decisión, orden, respuesta. Imprimir solo «avanzando» mezcla intención y resultado, y deja fuera casi toda la evidencia necesaria para depurar.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Predecí antes de comprobar

1. Ubicar cada pieza

Clasificá en bloques: sensor de línea, microcontrolador, puente H, motorreductor, batería, rueda y encoder. ¿Qué pieza decide que el robot debe girar?

2. Edad de una lectura

Una lectura válida de 45 cm fue adquirida a los 2400 ms. Ahora son las 2550 ms y la edad máxima permitida es 100 ms. Con umbral de 20 cm, ¿qué orden corresponde?

3. Información frente a energía

El registro muestra PWM al 40 %, el driver está habilitado y el motor no gira. Descubrís que la batería de motores está desconectada, pero la lógica se alimenta por otra fuente. ¿Hay contradicción?

4. Unidades equivocadas

Un módulo entrega 150 mm. El algoritmo interpreta el número 150 como centímetros y lo compara con un umbral de 20 cm. ¿Qué decide y qué debería decidir?

5. Dos síntomas iguales

En dos pruebas se ordena 40 % y el encoder devuelve 0 rpm. En una el driver está deshabilitado; en la otra el eje está bloqueado. ¿Esos dos datos bastan para distinguirlas?

6. Arquitectura de una pinza

Dibujá los bloques de una pinza que cierra hasta detectar una pieza. Indicá qué medirías y qué harías si la medida deja de llegar.

14 · Síntesis

Ideas para recordar

¿Listo para el tema 3?

Antes de avanzar, dibujá el vehículo de dos ruedas con sus caminos de información y energía. Explicá cómo podría recibir una orden de avance sin moverse y qué medirías para encontrar la causa.

En el próximo tema elegimos plataformas y entorno de trabajo: Arduino, ESP32, Raspberry Pi y simuladores para llevar esta arquitectura a la práctica.