O táxi deve ser confortável e seguro. E isso depende não apenas da qualidade do carro e do serviço, mas também da concentração da atenção do motorista, que cai durante o excesso de trabalho. Portanto, no nível de serviço, limitamos o tempo que o motorista passa atrás do volante.
Às vezes, porém, os motoristas ficam cansados - por exemplo, uma pessoa estava ocupada em outro emprego o dia todo e, à noite, decidia "dirigir". O que fazer sobre isso? Como entender que o motorista intervém sem alterar o sono? Você pode, por exemplo, tentar avaliar até que ponto ele monitora a estrada e determinar sinais de fadiga, por exemplo, pela natureza do piscar. Isso parece simples? Tudo é mais complicado do que parece.
Hoje, primeiro contaremos aos leitores de Habr como criamos e desenvolvemos uma câmera que pode fazer isso.
Portanto, é dado: a frequência e a duração dos piscadas dependem do grau de fadiga. Quando estamos cansados, a cabeça fica menos móvel, a direção do nosso olhar muda com menos frequência, piscamos com mais frequência e deixamos os olhos fechados por longos períodos de tempo - a diferença pode ser medida em frações de um segundo ou vários graus de rotação, mas ela existe. Nossa tarefa era projetar um dispositivo que nos permitisse analisar piscadas, bem como a direção de nossos olhares, bocejos e movimentos da cabeça, a fim de avaliar o nível de atenção e cansaço do motorista.
Primeiro, decidimos: vamos criar um aplicativo para laptop, colocá-lo nos voluntários dentre os funcionários e ele usará a câmera embutida para rastrear os sinais de que precisamos? Portanto, coletaremos imediatamente um grande corpo de informações para análise e testaremos rapidamente nossas hipóteses.
Spoiler: nada aconteceu! Muito rapidamente ficou claro que a maioria das pessoas que trabalham no computador constantemente olha para o teclado e inclina a cabeça. Ou seja, os olhos não são visíveis, e nem está claro se estão fechados ou abertos, uma pessoa pisca ou simplesmente olha da tela para o teclado e vice-versa.
Então percebemos que, mesmo para fazer um protótipo, precisamos de algum tipo de dispositivo. Compramos o primeiro modelo de câmera IP disponível, que funciona na faixa de infravermelho.
Por que precisamos de infravermelho? A iluminação pode ser diferente, às vezes o usuário está na sombra, às vezes a luz vem de trás, de cima ou não há nenhuma. Se fabricarmos um dispositivo de medição, ele deverá funcionar da mesma forma sob quaisquer condições.
Para o experimento, surgiu uma câmera bastante popular da Xiaomi - CHUANGMI.
Aconteceu que ela dispara a uma frequência de 15 quadros por segundo, e precisamos do dobro: o piscar dura de 30 a 150 ms, a 15 quadros por segundo, arriscamos não ver um piscar menor que 60 a 70 ms. Portanto, tivemos que modificar seu firmware para ligar à força a iluminação IR, obter acesso direto ao fluxo de vídeo e capturar os 30 quadros necessários por segundo. Tendo conectado a câmera ao laptop e configurado para receber o fluxo de vídeo através do protocolo RTSP, começamos a gravar os primeiros vídeos. A câmera foi colocada 15 cm abaixo da câmera do laptop, e isso possibilitou "ver" melhor os olhos do usuário.
Sucesso? E novamente, não. Depois de coletar centenas de vídeos, percebemos que nada estava acontecendo. O comportamento do usuário do laptop durante o dia é diferente do comportamento do motorista: uma pessoa pode se levantar a qualquer momento, sair para dar uma mordida, apenas caminhar e fazer um aquecimento, enquanto o motorista passa muito mais tempo sentado. Portanto, esses dados não nos convêm.
Ficou claro que a única maneira é fabricar ou comprar uma câmera adequada e instalá-la no carro.
Parece que tudo é elementar: compramos um DVR, nos voltamos para o motorista, prendemos no carro e uma vez por semana pegamos cartões SD com gravações de vídeo. Mas aqui, na realidade, tudo acabou não sendo tão simples.
Em primeiro lugar, é extremamente difícil encontrar um DVR com iluminação IR e precisamos ver bem o rosto, principalmente à noite.
Em segundo lugar, todos os DVRs possuem uma lente grande angular, de modo que a área com o rosto do motorista acaba sendo muito pequena e você não consegue distinguir nada do registro. Sim, e a distorção da lente estraga a análise da posição da cabeça e a direção da visão.
Terceiro, esse empreendimento não escala bem em dez, cem ou mais máquinas. Precisamos coletar muitos dados de diferentes drivers para analisá-los e tirar conclusões. Trocar manualmente os cartões de memória em centenas de máquinas todas as semanas ou todos os dias é uma enorme perda de tempo. Tentamos até encontrar uma câmera que enviasse vídeos para a nuvem, mas não havia nada semelhante no mercado.
Havia até uma idéia de criar "seu próprio DVR" a partir do Raspberry Pi, uma câmera com iluminação IR e suportes.
O resultado não foi exatamente o que esperávamos: complicado, é impossível instalar a câmera separadamente do computador. O fato é que, com um comprimento de cabo superior a 50 cm, os problemas com o sinal foram iniciados e o próprio cabo CSI é bastante frágil, muito largo e, portanto, não é muito adequado para instalação em uma máquina.
Temos que ir para Hong Kong, decidimos. O objetivo da viagem foi bastante abstrato: ver o que diferentes fabricantes estão fazendo no campo de análise do comportamento do motorista, comprar amostras de produtos, se encontrarmos, e procurar soluções / componentes técnicos adequados que possamos instalar nos carros.
Fomos imediatamente a duas exposições populares de eletrônicos e componentes. No pavilhão eletrônico automotivo, vimos um domínio sem precedentes de gravadores de vídeo, câmeras de visão traseira e sistemas
ADAS , mas quase ninguém estava envolvido na análise do comportamento do motorista. Os protótipos de vários fabricantes determinaram adormecer, distrair, fumar e falar ao telefone, mas ninguém sequer pensou em fadiga.
Como resultado, compramos várias amostras de câmeras e computadores de placa única. Ficou claro que 1) não existem produtos acabados adequados para nós; 2) é necessário separar o computador e a câmera para não obscurecer a visão do motorista. Portanto, adotamos uma placa de câmera com uma interface USB e, como uma unidade de computação, um computador Banana Pi de placa única e, ao mesmo tempo, vários players Android baseados em processadores Amlogic.
"Por que os jogadores são?" - você pergunta. De fato, o
S912 e até o S905 são bastante poderosos em termos de desempenho e podem facilmente puxar a gravação de vídeo para nossos propósitos, mesmo com a análise de imagens no local. A análise de imagem no local era necessária para não enviar todo o fluxo de vídeo ao servidor.
Vamos contar: um minuto de vídeo bem compactado na resolução H.264 de 640 × 480 (30 FPS) leva pelo menos 5 megabytes. Assim, em uma hora haverá 300 megabytes e, para um turno padrão de 8 horas - cerca de 2-3 gigabytes.
Carregar 3 gigabytes de vídeo todos os dias com a ajuda de um modem LTE é muito "caro". Portanto, decidimos gravar periodicamente vídeos de 5 minutos e analisar tudo o que acontece no carro ali e enviá-lo para nossos servidores na forma de um fluxo de eventos analisado: um conjunto de pontos faciais, uma direção da visão, uma virada na cabeça etc.
Voltamos das exposições de bom humor, trouxemos um monte de lixo necessário (e desnecessário) e percebemos como continuaríamos a fazer o protótipo.
A câmera USB que encontramos em Hong Kong era quase perfeita para nós: tamanho 38 × 38 mm, lentes padrão (12 mm), a capacidade de soldar iluminadores IR diretamente na placa.
Portanto, solicitamos imediatamente ao fabricante que nos fizesse um protótipo com os componentes necessários. Agora entendemos: precisamos de uma câmera USB com luz de fundo e um PC de placa única para processamento de vídeo. Decidimos experimentar tudo o que foi apresentado no mercado e organizamos uma sessão de compras no AliExpress. Compramos quatro dúzias de câmeras diferentes, uma dúzia de PCs de placa única, players Android, uma coleção de lentes de 12 mm e muitos outros dispositivos estranhos.
O problema com o hardware foi resolvido. E quanto ao software?
Muito rapidamente, conseguimos um protótipo simples baseado no
OpenCV , que grava um vídeo, encontra o rosto do motorista, analisa-o, marca 68 pontos-chave no rosto, reconhece piscar, bocejar, virar a cabeça etc.
A próxima tarefa foi fazer nosso protótipo funcionar em um PC de placa única. O Raspberry PI caiu imediatamente: poucos núcleos, um processador fraco, mais de sete quadros por segundo não podem ser retirados. E sobre como escrever um vídeo simultaneamente, reconhecer um rosto e analisá-lo, não havia dúvida. Pelas mesmas razões, decodificadores e computadores de placa única no Allwinner (H2, H3, H5), Amlogic S905 e Rockchip RK3328 não se encaixavam em nós, embora o último estivesse muito próximo do desempenho desejado. Como resultado, ainda temos dois SoCs em potencial: Amlogic S912 e Rockchip RK3399.
Na Amlogic, a escolha de dispositivos era pequena: uma caixa de TV ou o Khadas VIM2. Tudo funcionou da mesma forma na caixa de TV e no Khadas, mas o resfriamento das decodificadores de TV deixou muito a desejar, e configurar o Linux nelas geralmente não é um exercício para os fracos de coração: fazer com que o Wi-Fi, o BT funcione, fazendo o sistema operacional ver toda a memória, - É longo, difícil e imprevisível. Como resultado, escolhemos o Khadas VIM2: ele possui um radiador de refrigeração padrão e a placa é compacta o suficiente para ocultá-la atrás do painel da máquina.
A essa altura, o fabricante da placa da câmera já havia nos enviado um lote de teste de cem peças, e estávamos ansiosos pela batalha: fazer um protótipo, colocá-lo em um carro e coletar dados.
Tínhamos uma câmera, havia software, havia um PC de placa única, mas não havia a menor idéia de como colocar tudo isso no carro e conectá-lo à fonte de alimentação integrada.
Obviamente, a câmera precisava de um corpo e montagem. Compramos duas impressoras 3D de uma só vez para imprimir peças, e o contratado nos tornou o primeiro modelo primitivo do gabinete.
Agora, surgiu a difícil tarefa de escolher: onde montar a câmera no carro para obter uma boa imagem, mas não para obscurecer a visão do motorista. Havia exatamente três opções:
- No meio do pára-brisa.
- No rack esquerdo.
- No espelho retrovisor.
Naquele momento, pareceu-nos que é melhor conectar a câmera diretamente ao espelho retrovisor: ela é sempre direcionada ao rosto do motorista, para que a câmera fotografe exatamente o que precisamos. Infelizmente, os fabricantes de espelhos retrovisores não se certificaram de que algo pudesse ser anexado de forma conveniente e confiável a eles. As câmeras não aguentaram bem, caíram e fecharam a análise.
No entanto, equipamos várias máquinas e começamos a coletar dados delas. Tornou-se claro que o design era imperfeito, e os problemas relacionados ao desempenho e ao aquecimento aumentaram ao gravar e analisar simultaneamente o rosto.
Decidimos montar a câmera no nível dos olhos no rack esquerdo: fechamos menos a revisão e temos um bom ângulo para a câmera para que o motorista possa ser visto. O estojo teve que ser refeito, pois os prendedores com dobradiças se mostraram extremamente confiáveis: eles se separam quando agitam, quebram e as ventosas descolam do vidro.
Decidimos que, para o protótipo e a coleta de dados, é melhor grudar firmemente as câmeras no vidro, para que nenhuma trepidação e influências externas possam mudar de posição. Modificamos levemente o gabinete e, ao mesmo tempo, realizamos o teste de carga da instalação usando uma fita dupla face especial. Para o teste, foi utilizado equipamento complexo e de alta precisão.
Devido a problemas de desempenho, decidimos mudar o SoC para um mais poderoso, por isso escolhemos o PC de placa única NanoPI M4 no processador Rockchip RK3399.
Comparado ao Khadas VIM2, é cerca de um terço mais produtivo, possui compactação de hardware e decodificação de vídeo e se comporta muito mais estável em condições de temperatura difíceis. Sim, tentamos colocar câmeras e placas de circuito no freezer, aquecê-las no forno e fizemos muitos outros testes desumanos.
Como gravamos vídeo não apenas assim, mas também na dinâmica ao longo do dia, era importante que a hora do sistema no dispositivo fosse precisa. Infelizmente, a maioria dos computadores de placa única não está equipada com um relógio com alimentação própria. Tivemos a sorte de o nosso NanoPI ter um conector de bateria.
Eu tive que projetar um gabinete para um computador que o protegesse fisicamente e atuasse como suporte para antenas WiFi e BT. Também fornecemos um local para a montagem da bateria do relógio com um suporte.
Além disso, planejamos equipar cem máquinas com protótipos que gravariam vídeos e transmitissem toda a telemetria para a nuvem on-line: existe um motorista, com que frequência e por um longo tempo ele pisca, boceja, fica distraído da estrada, vira a cabeça etc. etc. e não apenas) os parâmetros nos permitem treinar um modelo que avalia a concentração do motorista na estrada, distraído ou cansado. Para fazer tudo isso diretamente no dispositivo do carro, tivemos que reescrever o código completamente, fazer compressão de vídeo por hardware, girar logs e gravações de vídeo, enviá-lo regularmente para o servidor, atualizar remotamente o software e muito mais.
Ao mesmo tempo, ficou claro para nós que nossos cálculos e algoritmos funcionariam muito melhor com uma análise facial básica mais precisa. Nos primeiros protótipos, usamos o detector de rosto incorporado ao OpenCV com base no
modelo em cascata haar e o modelo para marcar 68 pontos de face com base na biblioteca
dlib . Nós mesmos calculamos a posição da cabeça
calculando a projeção dos pontos de face no plano focal. As soluções de código-fonte aberto para reconhecimento e marcação de rostos funcionam bem em quadros em que o rosto é fotografado na frente ou no perfil, mas em condições intermediárias, eles geralmente são confundidos.
Portanto, decidimos licenciar uma boa solução de reconhecimento de rosto e marcação de terceiros - VisionLabs SDK. Comparado aos algoritmos anteriores, consome mais recursos, mas proporciona um aumento notável na qualidade do reconhecimento e marcação de faces, o que leva a uma extração mais precisa dos fatores para o aprendizado de máquina. Com a ajuda de colegas da VisionLabs, conseguimos mudar rapidamente para o SDK e obter o desempenho que precisávamos: 30 quadros / s. em uma resolução de 640x480.
O VisionLabs SDK usa redes neurais para reconhecimento de faces. A tecnologia processa cada quadro, encontra o rosto do motorista e fornece as coordenadas dos olhos, nariz, boca e outros pontos-chave. Os dados obtidos são usados para criar um quadro normalizado de tamanho 250x250, onde a face está localizada estritamente no centro. Esse quadro já pode ser usado para calcular a posição da cabeça em graus ao longo de três eixos: guinada, inclinação e rotação. Para rastrear o status dos olhos do motorista, o sistema analisa a imagem dos olhos e, para cada olho, decide se está fechado ou aberto. O sistema é capaz de determinar, usando a tecnologia IR Liveness, se uma pessoa viva está na frente da câmera ou se o motorista anexou uma foto. Para análise, é usado um quadro normalizado e, na saída, obtemos o resultado vivo ou não vivo.
Conclusão
Enquanto reescrevíamos e depurávamos o software, nossas impressoras 3D imprimiam estojos para câmeras e PCs de placa única dia e noite. A impressão do kit (corpo da câmera + gabinete do PC) levou cerca de 3-4 horas de operação da impressora, portanto tivemos que expandir as capacidades de produção: usamos quatro impressoras. Mas conseguimos fazer tudo dentro do cronograma.
Em duas semanas, equipamos totalmente os primeiros cem carros em várias frotas de táxi - parceiros Yandex.Taxi. Agora, com a ajuda deles, coletamos vídeos, analisamos o comportamento do motorista, sinais de fadiga, aprimoramos algoritmos e treinamos modelos que avaliam o nível de atenção e fadiga. E somente depois disso (levando em consideração todos os dados, feedback dos motoristas e passageiros) estaremos prontos para avançar para a próxima etapa - produção e implementação em massa.
Infelizmente, para escalar para vários milhares ou dezenas de milhares de instalações, a solução técnica atual não é muito adequada por vários motivos. Tudo o que falamos neste artigo é um experimento rápido, cujo objetivo era aprender rapidamente como coletar dados diretamente das máquinas para treinar modelos. O próximo grande estágio para nós é desenvolver e começar a produzir um dispositivo com as mesmas dimensões, mas constituído por uma unidade: a câmera, os sensores e o modem estarão localizados em um estojo compacto, que instalaremos em massa nas máquinas.