O DMS Study Lab nasceu de uma ideia que parecia pequena o bastante para caber em um experimento rápido: usar visão computacional para observar os olhos e identificar sinais que poderiam estar relacionados à sonolência. Eu já tinha trabalhado numa versão mais simples desse conceito, mas, conforme fui estudando o assunto, ficou difícil ignorar tudo o que existia ao redor de uma única medida. Um condutor não deixa de estar atento apenas porque piscou, da mesma forma que manter os olhos abertos não prova que está tudo bem.
Foi aí que o projeto começou a mudar de tamanho. Em vez de continuar tratando cada teste como uma demonstração isolada, resolvi construir um ambiente no navegador onde diferentes sinais pudessem ser observados juntos. O nome também mudou porque “detector de sono” já não descrevia direito o que eu estava fazendo. O DMS Study Lab virou um laboratório pessoal para explorar monitoramento de condutores, interface, simulação e processamento em tempo real sem fingir que uma experiência de estudo é um sistema automotivo pronto.
Um sinal sozinho conta muito pouco
Quando a gente vê uma demonstração de visão computacional funcionando, é fácil cair na tentação de transformar qualquer valor em uma resposta definitiva. Os olhos fecharam por certo tempo, então a pessoa está cansada. A cabeça virou, então ela se distraiu. Um telefone apareceu, então existe perigo. O problema é que o mundo real não costuma colaborar com regras tão limpas.
Iluminação ruim, óculos, uma mão passando pelo rosto ou a câmera posicionada num ângulo estranho já podem alterar bastante aquilo que o sistema enxerga. Até comportamentos normais, como piscar, bocejar ou olhar rapidamente para o lado, precisam de contexto. Por isso o DMS observa sinais como abertura dos olhos, piscadas, possíveis bocejos, direção aproximada da cabeça e do olhar, visibilidade do rosto e alguns gestos, mas não trata nenhum deles como uma sentença isolada.
Essa mudança de raciocínio foi uma das partes mais importantes do projeto. O objetivo deixou de ser “acertar um alerta” e passou a ser entender como combinar observações imperfeitas de uma forma que faça sentido na interface. Ainda existem falsos positivos e situações interpretadas de maneira errada, porque o DMS continua experimental. Mostrar essa limitação não diminui o projeto; na verdade, deixa mais claro o problema que estou tentando estudar.
Levar o experimento para o navegador
Outra decisão importante foi transformar tudo em uma experiência web. Hoje o projeto usa React e TypeScript na interface, MediaPipe para parte da visão computacional e tecnologias como WebAssembly para executar o processamento diretamente no navegador. Isso permite abrir a demonstração em um navegador moderno, autorizar a câmera e acompanhar a análise sem instalar uma aplicação separada.
Fazer isso no navegador também trouxe desafios próprios. A aplicação precisa lidar com permissão de câmera, desempenho em dispositivos diferentes, carregamento dos recursos usados na análise e estados em que o rosto some parcial ou completamente. Ao mesmo tempo, a interface precisa informar o que está acontecendo sem virar um painel cheio de números que só fazem sentido para quem escreveu o código.
Eu queria que a tela lembrasse um sistema de monitoramento, mas sem usar o visual para esconder a natureza experimental. Por isso ela apresenta estados e sinais de forma organizada, enquanto mantém avisos claros sobre o que o projeto é capaz de fazer. Não se trata de dar um diagnóstico de fadiga nem de autorizar o uso durante uma condução real; é uma forma visual e interativa de acompanhar o estudo.
Testar sem depender da webcam
Durante o desenvolvimento apareceu um problema bem prático: como testar diferentes comportamentos de forma repetível? Posso fechar os olhos ou virar a cabeça diante da câmera, mas isso não cria um cenário muito controlado. Também fica difícil demonstrar certas situações sem depender da iluminação, do enquadramento e da pessoa que está na frente do computador naquele momento.
A resposta foi criar um modo de demonstração com um personagem humano 3D. Ele pode piscar, manter os olhos fechados, bocejar, mover a cabeça, alterar a direção do olhar, usar óculos, obstruir parte do rosto, realizar gestos e interagir com um telefone. Com Three.js e WebGL, esses cenários entram na mesma experiência e permitem observar como a interface reage sem precisar ativar uma câmera real.
Essa parte cresceu mais do que eu imaginava. O personagem não é uma prova de precisão e não substitui testes reais; ele representa situações simuladas. Mesmo assim, virou uma ferramenta muito útil para desenvolver a experiência, comparar estados e explicar o projeto para alguém que só quer conhecer a ideia sem liberar acesso à webcam.
Privacidade precisava fazer parte da arquitetura
Trabalhar com câmera muda completamente o nível de cuidado necessário. Eu não queria que a demonstração dependesse de conta, cadastro ou envio de imagens para um servidor. No modo ao vivo, o acesso à webcam só acontece depois da autorização do usuário, e o processamento principal permanece no próprio navegador. O vídeo não é armazenado pelo projeto, não existe um banco de dados biométrico e os estados usados durante a análise duram apenas enquanto a sessão está aberta.
Isso não é um detalhe escondido em alguma política longa; faz parte da proposta técnica. Fechar a página encerra o processamento. Além de ser uma decisão mais coerente com um laboratório de estudo, trabalhar localmente reduz a quantidade de dados sensíveis que a aplicação precisaria movimentar e guardar.
Ainda assim, privacidade não transforma automaticamente a aplicação em um produto de segurança. O DMS não possui certificação automotiva, não foi homologado para veículos e não passou pelos processos de engenharia e validação que um sistema real exigiria. Também não fornece diagnóstico médico. Essa fronteira precisa continuar bem explícita, principalmente porque uma interface convincente pode dar a impressão de que o sistema sabe mais do que realmente sabe.
Por que a demonstração é pública, mas o código não
A versão atual do DMS Study Lab pode ser acessada online, mas o código-fonte fica em um repositório privado. O repositório público no GitHub funciona como apresentação do projeto: reúne objetivo, recursos, tecnologias, estado atual e os limites da demonstração. Ele não contém a implementação usada na aplicação.
Escolhi manter o código fechado porque o DMS é um projeto autoral que continua mudando bastante. A arquitetura ainda está sendo reorganizada, abordagens diferentes entram e saem, e eu quero ter espaço para experimentar sem tratar o projeto como uma biblioteca pronta para reutilização. Neste momento, também não estou buscando contribuições, forks ou pull requests.
Isso não impede que o processo seja documentado. Pelo contrário: o Jornal existe justamente para contar o que estou construindo sem precisar publicar cada arquivo do projeto. Consigo mostrar as decisões, dificuldades e aprendizados, enquanto a demonstração permite que qualquer pessoa explore o resultado atual diretamente no navegador.
O laboratório continua aberto
Hoje já dá para experimentar a interface principal, o monitoramento por webcam e o ambiente humano 3D. A observação de olhos, piscadas, direção da cabeça, direção do olhar e sinais relacionados à fadiga está funcional em caráter experimental. Contextos envolvendo telefone, gestos e oclusão facial ainda estão sendo estudados e ajustados.
O mais interessante é que o projeto já não cabe naquela descrição inicial de um detector de olhos fechados. Ele juntou visão computacional, experiência web, gráficos 3D, privacidade e análise de comportamento dentro do mesmo ambiente. Cada parte nova também revelou mais situações em que uma resposta simples não era suficiente — o que, para um projeto de estudo, é um ótimo sinal.
Ainda há bastante coisa para calibrar, testar e provavelmente refazer. Por enquanto, a melhor forma de entender o DMS é abrir a demonstração e explorar tanto o modo ao vivo quanto a simulação. Só não vale usar isso como copiloto numa viagem: o laboratório foi feito para estudar na frente do computador, não para assumir responsabilidade dentro de um carro.