Estadios
Miles de sillasRecorridos por tribunas o sectores, con subtotales que se suman al final.
PropuestaOctubre 2026 · Para PICA vía WAFA IBD
Una app para Android e iOS que reconoce las sillas de PICA con visión por computadora, directamente en el teléfono y sin conexión. Si PICA lo decide, cada conteo alimenta una capa de datos para saber dónde están sus sillas, cuánto duran y cada cuánto se reponen.
PICA fabrica sillas que se usan en volumen en estadios, salones de eventos, restaurantes y centros de convenciones. Hoy se cuentan a mano: es lento y se cometen errores. La necesidad es simple: abrir la app, pasar la cámara por encima y obtener el número.
Recorridos por tribunas o sectores, con subtotales que se suman al final.
Conteo al montar y al recoger, para cuadrar lo entregado con lo devuelto.
Una foto por zona basta para tener el inventario del local al día.
Conteos por sala, guardados con el nombre del lugar, la fecha y el responsable.
Prototipo navegable de la Fase 1, sobre una escena 3D de un salón con más de 300 sillas. Use la guía o el teléfono directamente: dispare en modo Foto, corrija marcadores a mano o recorra el salón en modo Escaneo.
La app arranca en la cámara y ya marca las sillas en vivo. Con un solo disparo, cuenta todas las sillas visibles.
Toque una silla para quitarla o un espacio vacío para agregar una. Cada corrección queda registrada.
Recorra el espacio: cada silla suma una sola vez al cruzar la guía. Minimapa de cobertura y subtotales por bloque.
Total, desglose, foto con marcadores, lugar por GPS y comparación con el conteo anterior.
Los conteos se guardan en el teléfono y se consultan sin señal. Con la Fase 2, se sincronizan solos con el panel de PICA cuando vuelve la conexión.
Prototipo ilustrativo sobre una escena simulada. La sincronización corresponde a la Fase 2; el diseño final se define con PICA.
El núcleo es lo que PICA pidió. Además, como desarrolladores, recomendamos un conjunto de funciones que marcan la diferencia en uso real: que el conteo sea verificable, defendible ante un cliente y que la IA mejore con el tiempo.
Sin menús ni inicio de sesión para contar. Detección en vivo desde el primer segundo.
Un disparo cuenta todas las sillas visibles, con un marcador numerado sobre cada una.
El conteo se acumula al recorrer el espacio sin contar dos veces la misma silla.
Toda la IA corre en el teléfono. Pensado para estadios y salones con mala señal.
Total con lugar, fecha y responsable. Se comparte por WhatsApp o correo.
Tocar para quitar o agregar. El usuario deja el conteo final exacto y queda constancia de cuántas sillas se corrigieron.
Subtotales por tribuna, sala o bloque que se suman solos. Un estadio se puede repartir entre varias personas.
Cada conteo guarda la imagen con marcadores. Sirve de evidencia ante un cliente o una reclamación.
Poca luz, movimiento rápido o ángulo extremo: la app avisa y sugiere qué hacer antes de que el conteo pierda precisión.
El lugar se sugiere por ubicación y el resultado se compara con el último conteo del mismo sitio.
Resumen con marca PICA: total, desglose, foto, lugar y nombre del responsable.
Las correcciones manuales se convierten en datos de entrenamiento. Cada nueva versión del modelo aprende de los casos corregidos.
Lo que pasa dentro del teléfono en cada fotograma, la tecnología que recomendamos y los objetivos de rendimiento con los que nos comprometemos a medir el trabajo.
CameraX / AVFoundation en modo Foto; en modo Escaneo, los fotogramas los entrega la sesión de ARCore / ARKit. Hasta 30 por segundo.
Modelo propio optimizado para móvil (≈ 5–10 MB, INT8 en Android y FP16 en iOS), acelerado por la GPU o la NPU cuando el teléfono lo permite.
ByteTrack mantiene la identidad de cada silla entre fotogramas mientras la cámara se mueve.
ARCore y ARKit estiman la posición de cada silla en el espacio para no contarla de nuevo si la cámara vuelve sobre ella.
Total, subtotales y foto con marcadores, guardados de forma cifrada en el teléfono (base de datos y fotos).
| Capa | Tecnología | Por qué |
|---|---|---|
| App | Flutter + módulos nativos en Kotlin y Swift | Una sola interfaz para Android e iOS; cámara, IA y AR corren en nativo, donde importa el rendimiento. |
| Inferencia | LiteRT (TensorFlow Lite) · Core ML | Aceleración por hardware en cada plataforma y funcionamiento sin conexión. |
| Modelo | Detector de una etapa (p. ej. RTMDet o YOLOX, licencia Apache 2.0) | Rápido en gama media y apto para uso comercial. |
| Seguimiento | ByteTrack + ARCore / ARKit | Evita el doble conteo al mover la cámara. |
| Datos locales | SQLite cifrado (SQLCipher) | Nada se pierde sin señal; los datos quedan protegidos si se pierde el teléfono. |
| Servidor · Fase 2 | Supabase (PostgreSQL, Auth, Storage) | Cuentas y datos a nombre de PICA desde su creación. |
| Panel · Fase 2 | Next.js en Vercel (plan Pro) | Rápido, seguro y fácil de mantener; hosting a nombre de PICA. |
| Calidad | Crashlytics + métricas de conteo anónimas | Errores y precisión medidos en uso real, no solo en pruebas. |
| Modelo remoto | Versionado y actualización remota del modelo | El modelo mejora sin reinstalar la app, con vuelta atrás; cada conteo guarda la versión que lo generó. |
Si PICA prefiere lanzar solo en Android, la primera versión puede hacerse 100% nativa en Kotlin y llevarse a iOS después.
Objetivos propuestos, medidos en un teléfono de referencia acordado con PICA (p. ej. Samsung Galaxy serie A de 2024) y validados en la prueba de concepto.
Las imágenes se analizan en el teléfono. Los rostros se difuminan en las fotos de respaldo, y la ubicación y el nombre del responsable se tratan con aviso de privacidad, conforme a la Ley Orgánica de Protección de Datos Personales del Ecuador (2021) y su Reglamento.
Algunos modelos populares (p. ej. Ultralytics YOLO) usan licencia AGPL-3.0, incompatible con una app comercial de código cerrado. Usamos componentes con licencias permisivas (Apache 2.0 o MIT, como RTMDet, YOLOX y ByteTrack) o adquirimos la licencia comercial.
Código, modelo entrenado, datos y cuentas de tiendas a nombre de PICA. Sin dependencia de Elevatec para operar.
Un detector entrenado con los modelos de silla de PICA, fotografiados en espacios reales. La precisión se mide con conteos manuales en sitio antes de publicar, y el objetivo se acuerda antes de desarrollar.
Fotos y video de las sillas de PICA en filas, mesas y pilas, con distinta luz, ángulo, distancia y ocupación. La prueba de concepto parte de 500–1.000 imágenes; el conjunto crece a 3.000–5.000 durante el desarrollo y el piloto.
Cada silla se marca a mano y una segunda persona revisa. Un 15 % de las imágenes, de lugares distintos a los de entrenamiento, se reserva solo para medir.
Ajuste sobre un modelo preentrenado, optimizado y cuantizado para móvil.
Conteos de la app frente a conteos manuales, por escenario, en espacios reales.
Tres métricas, reportadas por separado para cada tipo de escenario. Nada de un único porcentaje que esconda los casos difíciles.
Diferencia entre el total de la app y el conteo manual, en porcentaje. Es la métrica que importa al usuario.
AP@0.5 (sillas bien detectadas y bien ubicadas) sobre imágenes que el modelo nunca vio.
Sillas contadas más de una vez en modo Escaneo. Mide el seguimiento y el anclaje.
| Escenario | Ejemplo | Objetivo propuesto |
|---|---|---|
| Favorable | Salón iluminado, sillas en filas, vacías | Error ≤ 2 % |
| Intermedio | Restaurante con mesas, luz mixta, vista inclinada | Error ≤ 5 % |
| Difícil | Estadio completo, poca luz, sillas ocupadas | A definir tras la prueba de concepto |
Valores de partida para la conversación. La precisión se acepta con un protocolo firmado con PICA antes del desarrollo: lugares, número de conteos manuales de referencia, quién los hace y cómo se calcula el error.
Si en escenarios difíciles la IA sola no alcanza el objetivo acordado, la app puede leer una etiqueta adhesiva o un código QR impreso en cada silla. Es más preciso y abre la puerta a medir la vida útil de cada unidad en la Fase 2. La decisión se toma con los datos de la prueba de concepto. La producción de etiquetas queda fuera del alcance.
Opcional. Cada conteo se registra con fecha, ubicación, responsable y cliente, y alimenta un panel web para PICA: dónde están sus sillas, cómo evoluciona el inventario de cada lugar y cada cuánto hay reposición. Seleccione un lugar en la tabla para ver su histórico.
Último conteo · todos los lugares
| Lugar | Cliente | Último conteo | Var. 90 días | Reposición |
|---|
Para medir cuánto dura cada silla, cada una necesita una identidad única. Esta decisión define si la Fase 2 incluye etiquetado, y conviene tomarla junto con el resultado de la prueba de concepto.
La idea es sencilla; algunos escenarios no lo son. Los ponemos sobre la mesa desde el principio para acordar el objetivo de precisión con criterio.
La cámara no ve lo que está tapado. Contar pilas es un problema distinto y bastante más difícil.
Cómo lo tratamos. La Fase 1 cuenta sillas visibles. El conteo de pilas se evalúa como estudio aparte o con etiquetas físicas.
En un estadio, el escaneo largo y evitar el doble conteo son la parte más compleja del proyecto.
Cómo lo tratamos. Seguimiento de objetos, anclaje espacial con ARCore/ARKit y, en espacios grandes, recorridos por sectores con subtotales.
Espacios oscuros, vistas lejanas o muy inclinadas reducen la precisión.
Cómo lo tratamos. Datos de entrenamiento en condiciones reales y avisos en pantalla con sugerencias.
Con personas sentadas, el conteo es menos confiable.
Cómo lo tratamos. Recomendamos contar antes o después del evento; el modelo también se entrena con sillas ocupadas.
El rendimiento cambia entre gamas, y los escaneos largos con IA y AR consumen batería y calientan el teléfono.
Cómo lo tratamos. Matriz de pruebas con teléfonos reales, dos tamaños de modelo, pausa automática y escaneo por sectores en estadios.
Pueden detectarse, con menor precisión que los modelos de PICA.
Cómo lo tratamos. El modelo se optimiza para PICA; el reporte de precisión separa ambos casos.
Lo que se entrega, lo que queda fuera salvo acuerdo y lo que damos por supuesto para arrancar.
Empezamos por demostrar la precisión con las sillas reales de PICA. Con ese resultado se decide si basta la IA o si se suman etiquetas físicas, y la app se construye sobre una base probada. Cronograma indicativo en semanas, a confirmar tras el descubrimiento.
Decisiones que cierran el alcance antes de arrancar. Márquelas a medida que se acuerden; el avance se guarda en este navegador.
Un precio cerrado para la Fase 1 completa, de la prueba de concepto a la app publicada. Los pagos van ligados a hitos que PICA puede verificar.
Precio cerrado del proyecto · ~13 semanas
Si la prueba de concepto muestra que la IA sola no alcanza el objetivo acordado, PICA decide con ese reporte en la mano si seguir con etiquetas físicas o detener el proyecto en ese punto.
Se cotizan por separado cuando PICA lo decida.
Una app con IA no termina el día del lanzamiento: cambian los teléfonos, las versiones de Android e iOS, las reglas de las tiendas y los modelos de silla de PICA. El plan mensual mantiene la app al día y a PICA con un equipo técnico de referencia.
Se define junto con PICA según el uso real tras el lanzamiento, y puede ampliarse a un acuerdo global si se suman nuevos proyectos.
Cuatro pasos para arrancar el proyecto.
Sesión con PICA y WAFA IBD para validar este documento y cerrar las decisiones abiertas.
Aceptación de la propuesta y pago del 40 % para iniciar.
Sillas de muestra y uno o dos espacios reales para tomar las primeras fotos y videos.
Primer modelo y reporte de precisión con sillas de PICA, en condiciones reales, en la semana 5.
Contar sillas con la cámara resuelve el día a día. Registrar cada conteo le da a PICA, como fábrica, una vista que hoy no tiene: dónde están sus sillas y cuánto duran.