Dentro de ZetAI Vision: leer un rally de bádminton a 240 fotogramas por segundo

Un volante rematado sale de la raqueta a más de 300 kilómetros por hora y desacelera más rápido que casi cualquier objeto del deporte. A 30 fotogramas por segundo es un borrón a lo largo de dos fotogramas y luego desaparece. No se puede extraer nada útil de eso.

Por eso ZetAI Vision funciona a 240 fps, y por eso la frecuencia de fotogramas no es un detalle de especificación sino aquello en torno a lo que se organiza todo el diseño.

Tres problemas con un mismo disfraz

«Visión por computador para el deporte» suena a una única capacidad. En la práctica, un rally hay que descomponerlo en tres tareas que casi no tienen nada en común.

• Detección y seguimiento: dónde están los jugadores, las raquetas y el volante en este fotograma, y cuál es cuál a lo largo de los fotogramas. Espacial, por fotograma, extremadamente sensible a la latencia.
• Clasificación de eventos: ¿fue un remate, una dejada, un despeje o un tiro en la red? Temporal, requiere una ventana de fotogramas y entender la intención tanto por la posición del cuerpo como por la trayectoria del volante.
• Segmentación: ¿dónde termina un rally y empieza el siguiente? Es estructural y de ella depende todo lo posterior, porque un límite de rally mal detectado corrompe todas las estadísticas derivadas.

La tercera es la que sorprende. Equivocarse en un golpe en el límite no degrada ligeramente el análisis; desplaza toda la atribución de quién ganó cada rally, lo que invalida por completo los datos de patrones.

Por qué inferencia en el borde y no en la nube

Subir vídeo a 240 fps de ocho pistas a una GPU en la nube no es viable en un recinto de distrito. El ancho de banda no existe y, aun cuando exista, el viaje de ida y vuelta destruye el presupuesto de latencia que hace posibles los gráficos en directo y la puntuación automática.

Por eso la inferencia se ejecuta en el recinto, en hardware junto a las cámaras. Los modelos se cuantizan para cumplir el presupuesto de menos de 10 ms en hardware modesto, y lo que sale del recinto no es vídeo sino eventos estructurados: unos cientos de bytes que describen lo ocurrido, en lugar de gigabytes que describen su aspecto.

Esto también importa por una razón que nada tiene que ver con la ingeniería: las imágenes en bruto de menores practicando deporte son datos que no deberían salir innecesariamente de un gimnasio escolar. Procesar en el borde y transmitir eventos permite que el vídeo se quede en local por defecto.

Qué produce

• Reconstrucción del rally golpe a golpe: cada golpe, su tipo, su velocidad y dónde cayó.
• Mapas de calor de cobertura de pista: dónde pasa realmente su tiempo un deportista, frente a dónde cree que lo pasa.
• Patrones de movimiento y recuperación: con qué rapidez vuelve un jugador a su posición base y cómo se degrada a lo largo de un partido.
• Momentos clave automáticos: los rallies largos y los cambios de impulso de los que se nutren tanto la generación de resúmenes como el análisis de partidos.
• Señales de puntuación que ZetAI Score usa para proponer puntos al árbitro.

Limitaciones, con honestidad

La calidad de la visión depende más de la colocación de las cámaras que de la calidad del modelo. Una sola cámara en un extremo de la pista produce una buena segmentación de rallies y datos espaciales pobres; dos cámaras en esquinas opuestas producen buenos datos espaciales. Preferimos decirlo a que una federación compre un sistema y lo descubra en el segundo mes.

La iluminación importa enormemente: un pabellón con luz natural y fluorescente mezcladas provoca parpadeo a altas frecuencias de fotogramas que hay que compensar. Y los modelos son más sólidos en los deportes de raqueta, donde tenemos más datos etiquetados, y más limitados en los deportes que añadimos hace poco. Esa brecha se cierra con el uso, pero hoy es real.