Por dentro do ZetAI Vision: lendo um rally de badminton a 240 quadros por segundo

Uma peteca batida em smash sai da raquete a mais de 300 quilômetros por hora e desacelera mais rápido do que quase qualquer objeto do esporte. A 30 quadros por segundo, ela vira um borrão em dois quadros e desaparece. Nada de útil se extrai disso.

É por isso que o ZetAI Vision opera a 240fps, e por isso a taxa de quadros não é um detalhe de especificação, e sim aquilo em torno do que todo o projeto é organizado.

Três problemas com a mesma fantasia

"Visão computacional para o esporte" parece uma capacidade única. Na prática, um rally precisa ser decomposto em três tarefas que quase não têm nada em comum.

• Detecção e rastreamento: onde estão os jogadores, as raquetes e a peteca neste quadro e quem é quem de um quadro para o outro. Espacial, quadro a quadro e extremamente sensível à latência.
• Classificação de eventos: foi um smash, uma largada, um clear ou uma bola de rede? Temporal, exige uma janela de quadros e precisa entender a intenção tanto pela posição do corpo quanto pela trajetória da peteca.
• Segmentação: onde termina um rally e começa o próximo? Estrutural, e a etapa de que tudo o mais depende, porque um limite de rally mal detectado corrompe todas as estatísticas derivadas dele.

A terceira é a que surpreende. Errar o limite por um golpe não degrada a análise só um pouco: desloca toda a atribuição de quem venceu cada rally, o que invalida por completo os dados de padrões.

Por que inferência na borda, e não na nuvem

Enviar vídeo de 240fps de oito quadras para uma GPU na nuvem é inviável em um local de porte regional. A banda não existe e, mesmo onde existe, o tempo de ida e volta destrói o orçamento de latência que torna possíveis os gráficos ao vivo e a pontuação automática.

Por isso a inferência roda no local, em equipamentos ao lado das câmeras. Os modelos são quantizados para cumprir o orçamento de menos de 10ms em hardware modesto, e o que sai do local não é vídeo, e sim eventos estruturados: algumas centenas de bytes descrevendo o que aconteceu, em vez de gigabytes descrevendo a aparência.

Isso também importa por um motivo que nada tem a ver com engenharia: imagens brutas de menores praticando esporte são dados que não deveriam sair de um ginásio escolar sem necessidade. Processar na borda e transmitir eventos permite que o vídeo permaneça local por padrão.

O que ele produz

• Reconstrução do rally golpe a golpe: cada golpe, seu tipo, sua velocidade e onde caiu.
• Mapas de calor de cobertura da quadra: onde o atleta realmente passa o tempo, em comparação com onde ele acha que passa.
• Padrões de movimento e recuperação: com que rapidez o jogador volta à posição-base e como isso piora ao longo da partida.
• Momentos-chave automáticos: os rallies longos e as viradas de momento que a geração de melhores momentos e a análise de partidas aproveitam.
• Sinais de pontuação que o ZetAI Score usa para sugerir pontos ao árbitro.

Limitações, sem rodeios

A qualidade da visão depende mais do posicionamento das câmeras do que da qualidade do modelo. Uma única câmera em uma das extremidades da quadra produz uma boa segmentação de rallies e dados espaciais fracos; duas câmeras em cantos opostos produzem bons dados espaciais. Preferimos dizer isso a ver uma federação comprar um sistema e descobrir no segundo mês.

A iluminação importa enormemente: um ginásio com luz natural misturada à fluorescente causa cintilação em altas taxas de quadros, que precisa ser compensada. E os modelos são mais fortes nos esportes de raquete, onde temos mais dados rotulados, e mais fracos nos esportes que adicionamos recentemente. Essa diferença diminui com o uso, mas hoje ela existe.