Os tópicos de uso do Raspberry pi para controle de FPV e monitoramento de movimento em um quadro ao longo dos vetores H.264 não são novos. O empreendimento não pretende ser original e gastou-se relativamente pouco tempo (de julho aos fins de semana, às vezes).

Mas talvez minha experiência (e a fonte) seja útil para qualquer pessoa.

A idéia de que você precisa fazer videovigilância no apartamento surgiu depois que um vizinho disse que alguém estava investigando a fechadura da porta.

A primeira coisa que foi criada foi a instalação do famoso programa de movimento no Raspberry pi zero com uma câmera v1.3. Em princípio, resolve o problema. Se você estiver satisfeito com a notificação por correio e fps = 4-5.

Mas isso não parecia interessante. Na mão havia uma plataforma com rodas e arnês de experiências antigas e 18650 baterias de laptops antigos.

O resultado é uma mistura divertida de vigilância por vídeo móvel e detecção de movimento.
Como eu tenho um VPS alugado, não houve problemas para acessar de fora (rede doméstica por trás do NAT). A duração da bateria é de cerca de 4 dias se você não abusar da direção e do farol.

Você pode andar pelo apartamento, controlando remotamente a câmera e a plataforma e deixá-la em modo de detecção de movimento em qualquer local desejado.

Hardware

Todo o hardware pode ser dividido em duas partes, a primeira das quais não depende da segunda e pode ser usada separadamente:

Módulo de vigilância por vídeo

• Raspberry pi zero
• Dongle USB WiFi
• Câmera Raspberry Pi v1.3
• 2x motor de passo 28BYJ-48 + ULN2003 driver

Plataforma móvel gerenciada via SPI a partir de framboesas

• Placa 4S 16x18650 Li-ion + Placa 4S 30A Li-ion 18650 (BMS) + carregamento DC-DC com estabilização de corrente e tensão
• conversor abaixador dc-dc (15v -> 5v).
• placa stm32f103c8t6
• 4x motores de engrenagem + placa L298N
• Lâmpada LED de 12v (farol) + controle no IRF3205 (+ smd pnp e npn)

A imagem Raspbian foi configurada no modo somente leitura. Nessa configuração, as framboesas sobrevivem facilmente a desligamentos inesperados porque não usam cartões SD para gravação.

De software

O software consiste em 3 componentes separados.

Aplicativo para Android (testado no LG6 Oreo e no antigo Samsung S5 Lollipop)

Modo FPV

• Exiba o fluxo de vídeo H.264 da câmera na resolução e taxa de bits especificadas
• Controles de câmera e plataforma
• Grave vídeos e fotos do fluxo.

Modo de serviço Android

• Pesquisa de host (com frequência especificada)
• Carregando a foto do evento de “movimento” no quadro a evento.

Host Raspberry Pi em python (picamera + spidev + RPi.GPIO)

Modo FPV

• Transmissão H.264 stream (com os parâmetros especificados pelo aplicativo Android)
• recepção de comandos de controle para motores de passo e seu gerenciamento.
• Comandos de controle de transmissão via SPI (se o modo estiver ativado)

Movimento do modo de rastreamento no quadro.

• Detecção de movimento no quadro (de acordo com os parâmetros especificados pelo aplicativo Android)
• Recepção de pedidos "e se há movimento no quadro" e upload de fotos a pedido
• Enviando para o host (independentemente do aplicativo) uma foto dos movimentos no quadro.

O firmware mais simples em stm32f103

• Receba comandos SPI
• Controle o sentido de rotação das rodas e motores PWM.
• Controle de farol.

Rastreamento de movimento

O rastreamento dos vetores h.264 acabou sendo muito temperamental e propenso a falsos positivos. Existem muito poucas implementações de detecção de movimento para o H.264 na rede. Eu tentei todos eles.

A opção mais primitiva é contar o número de vetores cujo comprimento excede um determinado valor limite. E se algum vetor for maior que o limite, esse é um sinal de que há movimento no quadro.

Infelizmente. Esta opção é adequada apenas para demonstrar o princípio. Existem muitos falsos positivos. Especialmente em superfícies de cor e textura uniformes.

Todas as outras opções fornecem muitos falsos positivos ou simplesmente não atendem ao critério de desempenho: "deve ser processado dentro do prazo".

Como resultado, escolhi minha opção. Embora praticamente não dê falsos positivos, requer movimento em vários quadros seguidos. Mas é melhor assim do que alarmes falsos várias vezes ao dia devido a mudanças na iluminação ou em geral devido a incompreensíveis "movimentos" no quadro pela "decisão" da câmera. O tópico de algoritmos de detecção confiáveis ​​para mv H.264 é geralmente um tópico separado e complexo. Os algoritmos requerem muito tempo para depuração prática e eu tenho limites estritos no tempo de execução.

Exemplo de vetores de movimento (modos do utilitário de captura instantânea):





Nos eventos “movimento no quadro”, as notificações são geradas.



em princípio, para os meus propósitos, era bastante garantido que disparasse quando uma figura humana (> 15% do quadro) estivesse se movendo por pelo menos 2 segundos. Com tal aumento de sensibilidade, simplesmente não vi falso-positivos.

Controle de movimento.

Gerenciamento de plataforma "por trator". I.e. Controle PWM e direção de rotação do lado esquerdo e direito. Elementos de controle (tiras) sob os polegares das duas mãos. Acabou sendo o mais natural para mim.



Controle da câmera - duas faixas que tocam dão um comando para girar um certo ângulo (quanto mais distante do centro da faixa - maior o ângulo). O controle contínuo dos motores era desconfortável (novamente subjetivo para mim).

Lags FPV

As defasagens de vídeo eram relativamente pequenas (<1 segundo).

Controlar uma plataforma com rodas com uma velocidade máxima de 3-4 km / h para um atraso de 100% PWM em 0,6 s - isso é bastante normal e quase não é percebido.

No entanto, parece-me que mesmo 0,3 segundos de atraso para, por exemplo, um quadrocóptero é muito.

Testes mostraram que a implementação da tradução em python leva cerca de 50 a 70ms para o atraso, em comparação com a saída do mesmo fluxo H.264 via rapivid. Para mim, esses 70ms não são importantes. Mas se alguém quiser espremer o máximo, deve levar isso em conta.

Ao trabalhar com "WiFi local" (o telefone como um ponto de acesso), o atraso é de 350..600ms. Mas não mais que 0,6 segundos e estável nesse intervalo. Embora, 50-70 metros em áreas abertas - isso é apenas para brincar. E a uma distância maior, o WiFi do telefone não funciona.
Vale a pena notar que isso ocorre em um ambiente muito "barulhento de RF" de prédios de apartamentos, com muitas redes Wi-Fi na área.



Fiquei surpreso com o resultado na configuração “roteador WiFi -> provedor de par trançado -> VPS -> MTC 4G no telefone” via encaminhamento de porta ssh de framboesas para VPS.
Um atraso típico acabou sendo um pouco melhor do que através de WiFi local (!)
Mesmo em movimento em um carro ou perto de um hipermercado de grande atraso é de apenas 300ms.

No entanto, às vezes (muito raramente e imprevisivelmente), o atraso passou a vários segundos. O Recontext ajuda. Provavelmente, esses são alguns recursos de 4G / MTS / provedores da cadeia, etc.



Depois que tudo funcionou, houve um desejo de conectar o canal de som nas duas direções. Tecnicamente, isso é possível e nem mesmo muito difícil. Mas não sinto vontade de mexer com um ferro de soldar.

Se não fosse o Rasberry pi "extra", seria mais fácil usar o telefone antigo como host para vigilância por vídeo e gerenciamento de plataforma. A única vantagem das framboesas em relação a um telefone antigo é menos peso. E, talvez, menos consumo de energia (não comparou).

Todas as fontes