RutikRUTIK
Volver al blog
Cómo funciona5 de junio de 2026·5 min de lectura

Cómo funciona el conteo automático de pasajeros (APC) por visión computacional

Una explicación clara —sin matemáticas— de cómo un computador del tamaño de una cajetilla cuenta personas en un bus en movimiento, y por qué eso resuelve un problema que controles humanos no pueden cerrar.

por Equipo Rutik

Si nunca habías escuchado el término APC (Automatic Passenger Counting), probablemente no eres el primero. En transporte interurbano de Latinoamérica el conteo automático todavía es relativamente nuevo, aunque en ciudades europeas y norteamericanas lleva más de una década en operación. Lo que ha cambiado en los últimos años no es la idea —contar pasajeros con sensores existe hace tiempo— sino el costo y la calidad de hacerlo con visión computacional.

Este post intenta explicar el funcionamiento del APC moderno sin requerir ningún conocimiento técnico previo. La meta es que un gerente de operaciones pueda terminar el post sabiendo qué le están vendiendo, cómo evaluar la calidad de la propuesta y dónde están las decisiones de diseño que importan.

Las dos generaciones del APC

Para entender qué hace Abordo, ayuda saber qué hacía la generación anterior.

Los APC clásicos usaban sensores infrarrojos o placas de presión. Sensores infrarrojos: dos haces invisibles cruzan el umbral de la puerta; al interrumpirse uno y después el otro, el sistema infiere dirección (sube vs baja) y cuenta +1 o -1. Placas de presión: en algunos buses urbanos se han usado planchas debajo del primer peldaño que detectan el pisotón.

Son mecanismos honestos pero limitados. Los infrarrojos se confunden con paquetes, coches de bebé, equipajes voluminosos, abrazos en la puerta. Las placas se descalibran y solo registran el primer paso. Su tasa de error en operación real ronda entre el 10% y el 20% — suficiente para producir un orden de magnitud, no para tomar decisiones operativas finas.

La segunda generación, que es la que usa Abordo, reemplaza el sensor por una cámara cenital y delega la interpretación a un modelo de visión computacional. El cambio es importante: ya no estamos contando interrupciones de haz, estamos viendo lo que pasa.

Lo que hace la cámara

Una cámara apuntando hacia abajo desde el techo del pasillo, sobre la puerta de acceso, ve la coronilla de cada persona que sube o baja. No ve rostros — la geometría hace muy difícil identificar a alguien desde arriba. Eso ya es una buena noticia desde el punto de vista de privacidad.

La cámara graba video a una resolución razonable (típicamente 1280×720 o 1920×1080) y a unos 15 a 30 cuadros por segundo. Ese video no sale del bus. Es importante decirlo claramente: el video se procesa dentro del propio vehículo, en un computador pequeño que también va instalado a bordo. Lo único que se transmite a la nube son los conteos numéricos.

Lo que hace el modelo de IA: dos piezas

El modelo de visión que cuenta a las personas no es una sola cosa, son dos piezas trabajando juntas. Cada una hace algo específico:

Pieza 1 — Detección. Para cada cuadro de video, un detector de personas analiza la imagen y dice: "veo una persona aquí, otra acá, otra acá". El detector que usamos se llama YOLO (You Only Look Once); es uno de los modelos abiertos más probados y eficientes para este tipo de tarea. Funciona bien con poca luz, con personas parcialmente ocluidas, y con ángulos cenitales —que es la posición específica que necesitamos. Lo importante: no identifica a la persona, solo dice "aquí hay una".

Pieza 2 — Seguimiento. Si solo detectáramos en cada cuadro, contaríamos varias veces a la misma persona mientras avanza por la puerta. Para evitarlo, un segundo modelo llamado ByteTrack toma las detecciones y las asocia entre cuadros, asignándole a cada persona detectada un identificador efímero (un número, "persona 47", "persona 48"). Ese identificador dura solo mientras la persona está visible en la escena.

Combinando las dos piezas, el sistema puede decir: "la persona 47 cruzó la línea virtual de entrada a las 14:23:08, en dirección entrante". Eso es un evento de "subió 1". Cuando otra persona cruza en sentido contrario, es "bajó 1".

La línea virtual

Una sutileza importante: el sistema no cuenta "personas vistas en la escena". Cuenta cruces de una línea virtual definida en el umbral de la puerta. Esa línea se calibra al instalar el dispositivo en cada bus, porque la geometría exacta de cada puerta es distinta.

Definir el conteo por cruce de línea (en lugar de por aparición) elimina falsos positivos por personas que se asoman pero no suben, por choferes que pasan dos veces, por la persona que ayuda a alguien a subir y se baja sin entrar. El sistema cuenta exactamente lo que importa: gente que entró o salió del bus.

Por qué corre en el bus y no en la nube

Una pregunta natural es: ¿por qué no mandamos el video a un servidor y lo procesamos allá, donde hay máquinas más potentes? Tres razones, todas decisivas:

  1. Ancho de banda. Transmitir video continuo de una flota de 20 buses, 12 horas al día, requiere planes de datos celulares prohibitivos. Procesar local y transmitir solo eventos numéricos baja el consumo a fracciones de megabyte por día.

  2. Privacidad. Mover video con personas identificables a un servidor remoto introduce un problema regulatorio inmediato bajo la Ley 19.628 chilena y la nueva normativa de datos personales. Procesar en el borde y descartar el video lo elimina.

  3. Tolerancia a fallas. En rutas interurbanas hay tramos sin cobertura. Si el conteo dependiera de subir video a la nube, perdería esos tramos. Procesar local + buffer de eventos + sincronización oportuna asegura que ningún conteo se pierda.

Lo que viaja a la nube

Esto es deliberadamente mínimo. Por cada evento de conteo, el dispositivo envía un mensaje compacto que contiene:

  • ID del bus
  • Timestamp UTC
  • Coordenada GPS
  • Tipo de evento (subió 1, bajó 1)
  • Ocupación actual (cuántas personas hay arriba)

Eso es todo. Sin imágenes, sin video, sin identificación de personas. Un día de operación de un bus genera del orden de unos pocos cientos de KB de datos.

Lo que ocurre del otro lado: reconciliación

Una vez que los eventos llegan a la nube, ocurre la magia del producto: la reconciliación contra boletos emitidos. El sistema cruza la curva de ocupación medida por la IA con la curva de boletos emitidos por el sistema de pasajes. Donde la primera supera consistentemente a la segunda, hay pasajeros sin boleta.

Pero esa es otra historia, y le dedicamos otros posts. El punto de este es: lo que parece magia en realidad es ingeniería conocida combinada con buenas decisiones de arquitectura. Nada exótico, nada inverificable, nada que dependa de capacidades sobrenaturales del proveedor.

Cierre

El APC moderno por visión computacional es una tecnología madura, comprensible y verificable. La decisión clave de Abordo —cámara cenital + procesamiento en el borde + reconciliación contra boletaje— no es magia: es una combinación pragmática que optimiza simultáneamente precisión, privacidad y economía. Si te lo venden como caja negra inexplicable, desconfía. Si te lo explican con piezas nombrables, es probablemente buen producto.


En /abordo dejamos el diagrama completo del flujo, desde el sensor hasta el dashboard. Si quieres ver cómo se vería en uno de tus buses, escríbenos: el prototipo es gratis.

¿Lo conversamos para tu flota?

Prototipo gratis sobre un bus. Sin compromiso, sin licencias enredadas. Si los datos no cuadran, ahí queda.