Saltar al contenido
Concepción, Chile

Hola, soy

Luis San
Martín

Visión computacional, IA y sistemas de datos

scroll
persona (99.8%) Luis San Martín, computer vision engineer en Concepción, Chile
Detección en vivo

Corriendo en planta

Contando y clasificando en la línea de empaque · 13.000 kg al día

Ver los proyectos →
Formación
  • Universidad del Bío-Bío
Clientes y proyectos en producción
  • St. Andrews Mussels
  • El Maravilloso
  • LetsFit
  • Exwood
toca una card para ver el caso completo
01 13.000 kg / día Jun 2024 — Jul 2025 Cliente St. Andrews Mussels

Conteo y clasificación automática en línea de empaque

St. Andrews es el mayor productor de mejillones del mundo. Cultiva más de 1.500 hectáreas en Chiloé y procesa sobre 70.000 toneladas al año en dos plantas.

ESTACIÓN 01/ 03 contando en vivo
2024-10-10 13:05:54 · 500grs (81.7%) el scroll mueve la cinta
Octubre 2024. Contadores separados por formato y registro de estancamientos de la línea.
ESTACIÓN 02/ 03 seguimiento por ID
19-06-2025 11:17 · 500grs: 134 · 1kg: 0 Segunda estación: cuatro paquetes detectados, cada uno con su identificador de seguimiento
Segunda estación, junio 2025. Cada paquete lleva su identificador —ID 276, 277, 280 y 281— que el sistema le mantiene mientras cruza el cuadro. Eso evita contar dos veces el mismo paquete cuando la cinta se detiene o el operario interviene la línea.
ESTACIÓN 03/ 03 otro formato de producto
23-01-2025 08:58:40 · vista de cámara Tercera estación: vista de la cámara sobre la cinta, con una bolsa al vacío de mejillones
Tercera estación, enero 2025. Gran angular, cinta modular y bolsa al vacío en vez de bandeja: este formato no es el mismo que cuentan las otras dos. La foto es la vista cruda de la cámara — la caja está dibujada por esta página, no sale del sistema. Marca dónde engancharía el detector, con el mismo criterio que las otras dos estaciones.
DASHBOARDQuemchi el sistema completo
Quemchi Entero 2 · panel en vivo
El mismo sistema en la planta de Quemchi: el conteo por cámara alimenta un panel con los kg acumulados del día, la producción por hora, el desglose por formato y el registro detallado — todo en vivo, sobre la línea corriendo.
Cómo se hizo

Conteo manual sobre 13.000 kg diarios

St. Andrews necesitaba saber cuántos paquetes de cada formato salían de sus estaciones de empaque y cuánto tiempo se detenía la línea. El conteo lo hacía un operario a la vista, sobre una línea de 13.000 kg diarios.

Tres cámaras que cuentan, clasifican y detectan atascos

Sistema multicámara para 3 estaciones: cuenta los paquetes que cruzan la línea, los clasifica por formato y registra los estancamientos de la cinta. Opera con iluminación cambiante, cámaras que se mueven y superficies mojadas. El modelo se entrena en la nube pero corre en los equipos de la propia planta, no en un servidor remoto: si se cae internet, la línea sigue contando.

Temporada completa en producción sin intervención manual

Las 3 estaciones operaron en producción toda la temporada, sin intervención manual.

YOLOv8 para detección · SORT para el seguimiento entre cuadros · OpenCV · RTSP sobre cámaras IP · Python
02 696 en ~3 s No desplegado Cliente St. Andrews Mussels

Conteo automático de larvas de mejillón

Proyecto distinto al de la línea de empaque, en otra área de la empresa: el laboratorio donde se cuentan las larvas que definen la siembra.

Salida real del modelo · 696 larvas Conteo automático de 696 larvas en una muestra de laboratorio
Salida real del sistema: cada larva detectada, numerada y contabilizada en una sola pasada.
Del código al resultado · 696 larvas
Del código al conteo: el script corre —difuminado por privacidad— y aparece el resultado con las 696 larvas detectadas y numeradas en una sola pasada. Prueba de concepto validada completamente.
Cómo se hizo

Conteo manual bajo lupa: 45 minutos por muestra

Contar las larvas de una muestra bajo lupa tomaba 45 minutos. De ese número dependen las decisiones de siembra, y el resultado variaba según quién hiciera el conteo y cuánto tiempo llevara mirando.

Cientos de individuos translúcidos y superpuestos

Modelo de detección que localiza y numera cada larva en una sola pasada, entrenado con un dataset capturado en la propia planta. La dificultad es la densidad: cientos de individuos superpuestos, translúcidos y del tamaño del ruido de fondo.

Prueba de concepto: ~3 segundos por muestra

Prueba de concepto validada. Quedó demostrado que el conteo se puede automatizar —696 individuos en unos 3 segundos, contra los 45 minutos del conteo manual— pero no llegó a desplegarse como sistema de operación diaria, a diferencia del caso anterior.

PyTorch · detección de objetos pequeños y densos · dataset propio etiquetado en planta · OpenCV
03 9,6 cuadros / s May 2026 Cliente Exwood

Detección de casco sobre cámara embebida

Monitoreo de scooters eléctricos: el sistema distingue scooter, con casco y sin casco sobre el video de una cámara del tamaño de una moneda. Ella captura; el modelo corre en una GPU local.

EN VIVO/ 02 detectando
SafeRide · modelo propio afinado · 9,6 cuadros/s
La cámara apunta al desarrollador y el sistema lo marca sin casco, en vivo, a 9,6 cuadros por segundo. Es una prueba sobre sí mismo: no hay usuarios de terceros grabados.
EL HARDWARE/ 02 del tamaño de una moneda
XIAO ESP32-S3 Sense + OV2640 La cámara embebida conectada por su cable, con el registro del sistema corriendo detrás en el monitor
Esa es toda la cámara: captura y manda el video. Detrás, el registro del sistema corriendo — la inferencia va en una GPU local, no en la placa. La restricción del proyecto era el costo de lo que se monta en el scooter, no dónde corre el modelo.
Cómo se hizo

Tres clases: scooter, con casco, sin casco

El modelo distingue scooter, casco y sin casco. Separar el vehículo de la persona permite contar cuántos circulan y qué proporción va protegida, que es el dato que sirve para decidir, en vez de una alarma suelta.

Afinado sobre 12.321 imágenes

YOLOv8 afinado durante 80 épocas a 640 píxeles. Medido contra el conjunto de prueba: mAP@50 de 85,5%, precisión 85,0% y recall 80,9%.

Rendimiento por clase

En la matriz de confusión, scooter acierta 0,99 y casco 0,86, mientras que sin casco se queda en 0,65: se confunde con el fondo. Es la clase central para el objetivo del sistema, así que el trabajo pendiente se concentra en ella, con más ejemplos reales de cabezas descubiertas en movimiento.

Entrenamiento en la nube, inferencia en GPU local

El entrenamiento se hizo en la nube y la inferencia corre en una GPU local sobre el video que entrega la placa. La placa es de bajo costo y va montada en el scooter; el cómputo queda en tierra. Igual que en los otros casos, la inferencia corre en un equipo local y no depende de un servidor remoto.

YOLOv8 afinado · 3 clases · XIAO ESP32-S3 Sense + OV2640 para la captura · inferencia sobre GPU local · PyTorch · OpenCV · Python
04 5 cámaras en paralelo Feb 2026 — hoy Cliente El Maravilloso

Conteo de personas por cruce de línea sobre CCTV existente

Mismo cliente del caso 05: distribuidora de abarrotes y papelería en Concepción. El sistema corre sobre las cámaras de circuito cerrado que el local ya tenía instaladas. No se agregó ni una cámara ni un equipo de captura.

CAM 2 · Bebidas · cruce de línea
Cámara de bebidas. La línea amarilla cruza el pasillo: cada persona que la atraviesa suma una entrada o una salida, y el HUD lleva el aforo en vivo (ENTRADAS · SALIDAS · DENTRO).
CAM 3 · Mostrador · seguimiento por ID Cámara del mostrador: personas detectadas con su identificador y porcentaje de confianza
Cámara del mostrador. Cada persona lleva su identificador y su confianza; el seguidor lo mantiene aunque quede tapada tras la góndola y reaparezca.
CAM 4 · Sala · personas únicas
Cámara de la sala. Contador de personas únicas del día: cada identificador nuevo suma una, sin volver a contar a quien ya pasó.
Cómo se hizo

Conteo por cruce de línea

Sobre cada escena va dibujada su propia línea, calibrada a mano sobre la imagen real de esa cámara. Quien la cruza en un sentido suma una entrada; en el otro, una salida. Contar personas presentes en el cuadro no serviría: alguien parado frente a la góndola sumaría en cada cuadro.

Sobre el sub-stream de cada cámara

El sistema toma el sub-stream H.264 de cada cámara en vez del principal en H.265 a 1080p. Aguanta mejor la red del local y para el modelo da lo mismo: la detección trabaja a 640x360. Pedir más resolución habría sumado caídas de conexión sin sumar aciertos.

Seguimiento independiente por cámara

Cada canal tiene su propio seguimiento multiobjeto, con una tolerancia de 45 cuadros antes de dar por perdida a una persona. Esa holgura es la que sostiene el identificador cuando alguien queda tapado detrás de una góndola y reaparece dos segundos después.

Detección en lote

Las cámaras que necesitan inferencia se agrupan y se procesan en una sola pasada, en vez de una llamada por canal. Y si el ciclo corre más rápido que la cámara, reutiliza el resultado anterior en lugar de detectar dos veces sobre el mismo cuadro.

Diseñado para operación continua

En cada ciclo se descartan las etiquetas de las personas que ya salieron de escena: sin eso la memoria crece indefinidamente y el sistema se cae a los días. Aparte, un hilo liviano consulta el grabador cada 30 segundos para marcar cámaras caídas sin frenar el video. Esos dos detalles —limpieza de memoria y monitoreo del grabador— son los que sostienen la operación continua.

Una segunda versión sobre GPU

De ese mismo motor armé una variante acelerada en GPU con DeepStream (pyservicemaker): decodificación en NVDEC, YOLO batcheado sobre TensorRT y seguimiento con nvtracker, para sostener las cinco cámaras en paralelo sin saturar la CPU. El sistema en operación corre sobre la versión en OpenCV; esta es la ruta para escalar a más canales.

YOLO · seguimiento multiobjeto SORT por cámara · RTSP sobre las cámaras IP existentes · conteo por cruce de línea · OpenCV · Python
05 78 ventas / día Nov 2025 — hoy Cliente El Maravilloso

Integración de punto de venta y reportería tributaria

Distribuidora de abarrotes en Concepción, con local y punto de venta propio. Registra alrededor de 78 ventas diarias.

Resumen · agosto 2026 · datos de demostración Panel de ventas del sistema: ventas del mes, gastos y utilidad
Vista de escritorio. Consolida lo que antes solo existía en el computador del local.
Ingreso a la app
Resumen del mes
Gastos por categoría
Análisis ABC de productos
desliza para ver más →
La misma aplicación en el teléfono: se instala como app y funciona sin conexión. Todas las cifras de estas capturas son de demostración; los datos del cliente no se publican.
Cómo se hizo

Los datos no salían del punto de venta local

La distribuidora operaba sobre un punto de venta cerrado, con base de datos local y sin API. La información no salía del computador del local. El dueño no podía consultar las ventas del día a distancia, el cuadre de caja se hacía a mano y los documentos tributarios se descargaban del SII uno por uno.

Sincronizar el punto de venta y leer el SII

Mapeé el esquema del punto de venta y construí la sincronización hacia PostgreSQL en la nube: hoy hay 11.900 ventas y 40.000 líneas de producto consultables, que antes no salían del computador del mesón.

Encima, un ETL desatendido que se autentica en el SII y calcula los indicadores mensuales de impuestos: 305 facturas clasificadas sobre 87 proveedores. Y un control de calidad que cruza tres fuentes —documentos tributarios, pagos electrónicos y ventas— y emite alertas cuando no calzan: 283 hasta hoy. Por diseño no corrige ningún dato del cliente.

Reportería y operación en producción

Dashboard en tiempo real, informe mensual y Excel de gastos categorizado, generados sin intervención. La reportería tributaria se volvió un producto aparte.

También lo opero: diagnostiqué y corregí incidentes de integridad en producción y recuperé los datos afectados.

Firebird del punto de venta → PostgreSQL · reloj lógico híbrido para la sincronización · scraping autenticado del SII · cron en Linux · Python
06 2 sedes · 14 profesionales Feb 2023 — hoy Cliente LetsFit

Migración de plataforma y sistema de gestión multi-sede

Centro de entrenamiento y kinesiología con 2 sedes en el Gran Concepción. Opera con planes, reservas por horario y profesionales que cobran por sesión.

Pantalla de acceso · identidad propia de la app Pantalla de acceso de LetsFit con su identidad de marca propia
Identidad visual propia de la app.
Comisiones · 240 atenciones · datos de demostración Panel de comisiones: facturado, comisión del centro y pago por profesional
Lo que se le debe a cada profesional en el mes, calculado desde la asistencia marcada. El detalle se abre por profesional y se exporta a Excel.
Agenda · 3 al 9 de agosto · datos de demostración Agenda semanal con las reservas por día, profesional y servicio
La semana completa con cupos por día. Cada reserva muestra hora, paciente, profesional y servicio.
Cómo se hizo

170 alumnos en una plataforma de terceros, sin acceso a la base

El centro operaba sobre una plataforma comercial de pago mensual que no daba acceso a su propia base de datos. ~170 alumnos activos, con su historial de asistencia y sus planes, estaban en un sistema de terceros. Las comisiones se calculaban a mano y las reglas de negocio propias del centro no cabían en el producto arrendado.

Migrar la base por scraping y reemplazar la plataforma

Extraje la base completa por web scraping, la normalicé y trasladé clientes e historial sin pérdida de registros.

Diseñé el modelo de datos en PostgreSQL —multi-sede, con control de acceso por fila y migraciones versionadas— y construí el panel de administración: asistencia, ocupación, ingresos y liquidación de comisiones. Las reglas se levantaron con los dueños y los profesores antes de modelarlas.

Liquidación automática de 14 profesionales, sin licencia mensual

Sistema propio sin licencia mensual a terceros, con la liquidación de 14 profesionales sobre 768 sesiones calculada automáticamente. La migración continúa sede por sede, sin interrumpir la operación.

PostgreSQL con Row Level Security por sede · migraciones versionadas · TypeScript · scraping para la migración · Python
YOLOv8 PyTorch Python OpenCV Roboflow ONNX SORT DeepStream TensorRT NVIDIA PostgreSQL Firebird TypeScript FastAPI Next.js Supabase pandas Docker Linux Jupyter GitHub Actions C++ Claude Whisper rembg WhatsApp Cloud API Mercado Pago ESP32-S3 NumPy
commits en GitHub, últimos 12 meses
menosmás

Incluye contribuciones privadas. Parte del trabajo de clientes vive en repos privados o fuera de GitHub.

Freelance · cobro por proyecto entregado
  1. Jun 2024 — Jul 2025
    St. Andrews · Mussels Chiloé Freelance · Visión computacional

    Conteo y clasificación multicámara en la línea de empaque, corriendo en los equipos de la propia planta.

    YOLOv8SORTOpenCVRTSPPython
  2. Feb 2023 — hoy
    LetsFit Freelance · Desarrollo Full Stack

    Plataforma de gestión de gimnasio multi-sede: reservas, planes, pagos y comisiones con Row Level Security.

    Next.jsSupabasePostgreSQLRLSMercado Pago
  3. Nov 2025 — hoy
    Distribuidora El Maravilloso Freelance · Datos y Full Stack

    Punto de venta sin API sincronizado a PostgreSQL, ETL al SII y dashboards de gestión en producción.

    PostgreSQLETLSupabasePWAPython
  4. May 2026
    Exwood · movilidad eléctrica Freelance · Visión computacional (PoC CORFO)

    YOLOv8 afinado con inferencia en GPU local sobre cámara ESP32-S3 para monitoreo de scooters.

    YOLOv8ESP32-S3PyTorchEdge
Luis San Martín

Tesista de Ingeniería Civil en Automatización

Tesis: Detección de EPP en ambientes industriales a través de Computer Vision

Universidad del Bío-Bío · Gran Concepción, Chile

12semestres de duración

Llevo más de tres años desarrollando software en producción para clientes de acuicultura, distribución y salud. En todos los casos trabajé directo con el dueño de la operación, levantando los requerimientos en terreno antes de escribir código.