Los temas sobre el uso de Raspberry pi para el control de FPV y la supervisi贸n del movimiento en un marco a lo largo de los vectores H.264 no son nuevos. El desarrollo no pretende ser original, y se dedic贸 relativamente poco tiempo (a veces los fines de semana de julio).
Pero quiz谩s mi experiencia (y la fuente) ser谩 煤til para cualquiera.
La idea de que necesita hacer videovigilancia en el apartamento surgi贸 despu茅s de que un vecino dijo que alguien estaba profundizando en la cerradura de la puerta.
Lo primero que se agit贸 fue la instalaci贸n del famoso programa de movimiento en el Raspberry pi zero con una c谩mara v1.3. En principio, resuelve el problema. Si est谩 satisfecho con la notificaci贸n por correo y fps = 4-5.
Pero esto no parec铆a interesante. A la mano hab铆a una plataforma con ruedas y arneses de viejos experimentos y 18650 bater铆as de viejas computadoras port谩tiles.
El resultado es una mezcla divertida de video vigilancia m贸vil y detecci贸n de movimiento.
Como tengo un VPS alquilado, no hubo problemas para acceder desde el exterior (red dom茅stica detr谩s de NAT). La duraci贸n de la bater铆a es de aproximadamente 4 d铆as si no abusa del viaje y los faros.
Puede pasear por el apartamento, controlando de forma remota tanto la c谩mara como la plataforma y dejarlo en modo de detecci贸n de movimiento en cualquier ubicaci贸n deseada.
Hardware
Todo el hardware se puede dividir en dos partes, la primera de las cuales no depende de la segunda y se puede usar por separado:
M贸dulo de video vigilancia
- Frambuesa pi zero
- USB WiFi Dongle
- C谩mara Raspberry pi v1.3
- 2 motores paso a paso 28BYJ-48 + ULN2003 driver
Plataforma m贸vil gestionada a trav茅s de SPI desde frambuesas
- 4S 16x18650 Li-ion + 4S 30A Li-ion 18650 (BMS) placa + carga DC-DC con estabilizaci贸n de corriente y voltaje
- convertidor reductor dc-dc (15v -> 5v).
- placa stm32f103c8t6
- 4 motores de engranajes + placa L298N
- L谩mpara LED de 12 v (faro) + control en IRF3205 (+ smd pnp y npn)
La imagen Raspbian se ha configurado en modo de solo lectura. En tal configuraci贸n, las frambuesas sobreviven f谩cilmente a apagados inesperados porque no usan tarjetas SD para grabar en absoluto.
Software
El software consta de 3 componentes separados.
Aplicaci贸n de Android (probada en LG6 Oreo y Samsung S5 Lollipop)
Modo FPV- Muestra la transmisi贸n de video H.264 de la c谩mara en la resoluci贸n y velocidad de bits especificadas
- Controles de c谩mara y plataforma.
- Graba videos y fotos de la transmisi贸n.
Modo de servicio de Android- Encuesta de host (con frecuencia especificada)
- Cargando foto del evento de "movimiento" en el cuadro por evento.
Raspberry pi host en python (picamera + spidev + RPi.GPIO)
Modo FPV- Transmitir transmisi贸n H.264 (con los par谩metros especificados por la aplicaci贸n de Android)
- recepci贸n de comandos de control para motores paso a paso y su gesti贸n.
- Transmitir comandos de control mediante SPI (si el modo est谩 habilitado)
Modo de seguimiento de movimiento en el cuadro.- Detecci贸n de movimiento en el marco (de acuerdo con los par谩metros especificados por la aplicaci贸n de Android)
- Recepci贸n de solicitudes "y si hay movimiento en el marco" y subir fotos a pedido
- Env铆o al host (independientemente de la aplicaci贸n) foto de movimientos en el marco.
El firmware m谩s simple en stm32f103- Recibir comandos SPI
- Controle la direcci贸n de rotaci贸n de las ruedas y los motores PWM.
- Control de faros.
Seguimiento de movimiento
El seguimiento de los vectores h.264 result贸 ser muy malhumorado y propenso a falsos positivos. Hay muy pocas implementaciones de detecci贸n de movimiento para H.264 en la red. Los prob茅 todos.
La opci贸n m谩s primitiva es contar el n煤mero de vectores cuya longitud excede un cierto valor umbral. Y si alg煤n vector es mayor que el umbral, entonces esta es una se帽al de que hay movimiento en el marco.
Por desgracia Esta opci贸n solo es adecuada para demostrar el principio. Hay demasiados falsos positivos. Especialmente en superficies de color y textura uniformes.
Todas las dem谩s opciones dan demasiados falsos positivos o simplemente no cumplen con el criterio de rendimiento: "deben procesarse dentro del tiempo de trama".
Como resultado, eleg铆 mi opci贸n. Aunque pr谩cticamente no da falsos positivos, requiere movimiento en varios cuadros seguidos. Pero es mejor as铆 que falsas alarmas varias veces al d铆a debido a cambios en la iluminaci贸n o en general debido a "movimientos" incomprensibles en el marco por la "decisi贸n" de la c谩mara. El tema de los algoritmos de detecci贸n confiables para mv H.264 es generalmente un tema separado y complejo. Los algoritmos requieren mucho tiempo para la depuraci贸n pr谩ctica y tengo l铆mites estrictos en tiempo de ejecuci贸n.
Ejemplo de vectores de movimiento (modos de utilidad de instant谩nea):
En los eventos "movimiento en el marco", se generan notificaciones.
en principio, para mis prop贸sitos, result贸 bastante seguro que se disparara cuando una figura humana (> 15% del cuadro) se mueve durante al menos 2 segundos. Con tal grosor de sensibilidad, simplemente no vi falsos positivos en absoluto.
Control de movimiento.
Gesti贸n de la plataforma "por tractor". Es decir Control PWM y direcci贸n de rotaci贸n del lado izquierdo y derecho. Elementos de control (tiras) debajo de los pulgares de ambas manos. Result贸 ser lo m谩s natural para m铆.
Control de la c谩mara: dos tiras que se tocan dan la orden de girar un cierto 谩ngulo (cuanto m谩s lejos del centro de la tira, mayor es el 谩ngulo). El control continuo de los motores fue inc贸modo (nuevamente subjetivo para m铆).
Lags FPV
Los retrasos de video fueron relativamente peque帽os (<1 seg).
Para controlar una plataforma con ruedas con una velocidad m谩xima de 3-4 km / h para un retraso de 100% PWM en 0.6 segundos, esto es bastante normal y casi no se nota.
Sin embargo, me parece que incluso 0.3 segundos de retraso para, por ejemplo, un quadrocopter es mucho.
Las pruebas han demostrado que la implementaci贸n de la traducci贸n en Python genera entre 50 y 70 ms de retraso, en comparaci贸n con la emisi贸n de la misma transmisi贸n H.264 a trav茅s de Rapivid. Para m铆, estos 70ms no son importantes. Pero si alguien quiere exprimir al m谩ximo, entonces debe tener esto en cuenta.
Cuando se trabaja a trav茅s de "WiFi local" (el tel茅fono como punto de acceso), el retraso es de 350..600 ms. Pero no m谩s de 0.6 segundos y estable en este rango. Aunque, 50-70 metros en 谩reas abiertas, esto es solo para jugar. Y a una distancia mayor, el WiFi del tel茅fono no funciona.
Vale la pena se帽alar que esto se encuentra en un entorno muy "RF ruidoso" de edificios de apartamentos, con muchas redes WiFi en el 谩rea.
Me sorprendi贸 el resultado en la configuraci贸n "Enrutador WiFi -> proveedor de par trenzado -> VPS -> MTC 4G en el tel茅fono" a trav茅s del reenv铆o de puerto ssh de frambuesas a VPS.
Un retraso t铆pico result贸 ser incluso un poco mejor que a trav茅s de WiFi local (!)
Incluso en el camino en un autom贸vil o cerca de un gran hipermercado de retraso es de solo 300 ms.
Sin embargo, a veces (muy raramente e impredeciblemente), el retraso se convirti贸 en varios segundos. Recontext ayuda. Probablemente, estas son algunas caracter铆sticas de 4G / MTS / proveedores en la cadena, etc.
Despu茅s de que todo funcion贸, hubo un deseo de conectar el canal de sonido en ambas direcciones. T茅cnicamente, esto es posible y ni siquiera muy dif铆cil. Pero ya no quiero meterme con un soldador.
Si no fuera por el Rasberry pi "extra", ser铆a m谩s f谩cil usar el tel茅fono antiguo como host para la videovigilancia y la gesti贸n de la plataforma. La 煤nica ventaja de las frambuesas sobre un tel茅fono antiguo es menos peso. Y, tal vez, menos consumo de energ铆a (no se compara).
Todas las fuentes