Cámara Raspberry PI y control de luz Death Star: 5 pasos (con imágenes)

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:43

Como siempre, busco construir dispositivos que sean útiles, funcionen de manera robusta y, a menudo, incluso sean mejoras en comparación con las soluciones actuales disponibles en el mercado.

Aquí hay otro gran proyecto, originalmente llamado Shadow 0f Phoenix, un escudo Raspberry PI junto con la detección de movimiento y los controles de luz basados en Arduino.

Paso 1: El estado de las cámaras IP comerciales

Además de que construir su propio sistema de cámara / vigilancia es más genial, veamos por qué es una mejora de una solución estándar.

Lo compararé con la serie de cámaras IP inalámbricas NEO COOLCAM Full HD 1080P ya que he tenido muchos de estos modelos de cámaras neo coolcams (ONVIF). Vienen en diferentes formas y tamaños, en exteriores e interiores, la mayoría de ellos tienen soporte wifi integrado, pero veamos sus advertencias:

• Los fabricantes chinos que venden estas cámaras casi siempre mienten sobre la resolución del sensor de imagen incorporado, cuando compras una cámara de 5MP / 8MP en Ebay, puedes terminar con una cámara barata de 2MP con mala imagen (funciona pero la calidad es basura). Cuando compre la cámara Raspberry PI v2 de 8MP en el minorista original, obtendrá lo que pagó y un sensor real de 8MP con una resolución de 3280 × 2464 píxeles =>
• Desde el punto de vista de la seguridad, estas cámaras (incluso las más caras Dlink y otros modelos) son terribles, usan contraseñas predeterminadas como 123456 o usuarios integrados como administrador / operador / operador de administración, lo que tal vez ni siquiera pueda cambiar o el el cambio desaparece después de un reinicio. Completa con muchas de estas cámaras en el teléfono de casa (conéctate a sus servidores en China, algunos incluso transmiten videos / imágenes sin pedirte solo para que sea más fácil en caso de que decidas instalar su aplicación de Android / Iphone algún día para verificar tu hogar). Incluso si coloca estos dispositivos detrás de un enrutador, simplemente no es lo suficientemente bueno, lo mejor es si no establece una puerta de enlace predeterminada en ellos, los corta con un firewall o los coloca en una VLAN para que sea imposible que salgan. Internet o mejor aún: no los uses en absoluto.
• ¿Son más fiables? no, muchos de ellos, incluso los DLINK más caros, tienen la opción de reiniciar la cámara diariamente / semanalmente, etc. Esa opción está ahí por una razón, porque después de X días a menudo pierden la conectividad Wifi o se comportan mal de otras maneras. Solo piense en ellos como las viejas cajas Win95 que necesitaban reiniciarse la mayoría de las veces:) No digo que el hardware basado en Raspi sea tan sólido como una roca que pueda construirlas para controlar plantas de energía nuclear pero con el hardware / software adecuado configuración, disipadores de calor, ventiladores de enfriamiento automático y funcionamiento RW minimizado en la SDCARD pueden alcanzar fácilmente ese tiempo de actividad de más de 100 días sin problemas. En el momento de escribir este artículo, mi DeathStar funciona desde hace 34 días, han pasado más de 100, pero a veces estaba pirateando la fuente de alimentación que está alimentando algunos otros de mis circuitos, así que tuve que apagarlo:(
• Hardware dirigido: están hechos para un propósito específico, a menudo vienen con un área pequeña de nvram y un busybox, pero algunos modelos también hacen que el acceso a este shell sea imposible, por lo que solo puede usarlos para lo que están destinados a usarse mientras pueda use su cámara basada en Raspi para cualquier otra tarea: servidor de archivos, servidor tftp / dhcp, servidor web, servidor Quake… las opciones son ilimitadas.
• Espacio de almacenamiento: o no tienen ninguno o usan tarjetas microsd con sistema de archivos FAT32 VS en el raspberry pis, incluso puede conectar un disco duro de 2 TB si lo desea.
• Control de luces: algunos tienen una salida de ALARMA donde es posible que pueda conectar un pequeño relé para que se activen las luces. Como le mostraré en este tutorial, el uso de cámaras de infrarrojos es una completa pérdida de tiempo, ya que no podrá identificar a nadie en las imágenes de infrarrojos debido a la mala calidad. Si necesita grabar un video en la oscuridad, la mejor manera de hacerlo es encender un poco de luz primero y luego grabar el video.

Entonces, podría preguntarse ¿hay alguna ventaja de usar una cámara estándar? Sí, para empresas donde las horas de trabajo para configurarlo serían más caras que jugar con Raspberry pis (no para mí de todos modos:)) y sí, hay cámaras de primera línea (500 $ + con mejor resolución que la cámara pi de curso). Como otra ventaja podría decir que las cámaras que siguen el estándar ONVIF facilitaron el aprovisionamiento centralizado. Esto proporciona una interfaz estándar que se puede usar para enviar comandos a la cámara para configurar su IP / Máscara de red / Puerta de enlace y otras cosas. Para ello, puede descargar el administrador de dispositivos Onvif de Sourceforge. Muchos de estos dispositivos vienen con interfaces web rotas y cutres donde, por ejemplo, no le permite configurar la ip o la máscara de red correctamente porque el javascript que valida estos campos no funciona correctamente y su única forma de configurar estos parámetros correctamente es a través de ONVIF.

Paso 2: Planes de la Estrella de la Muerte

Puede construir este dispositivo con cualquiera de los Raspberry PI desde 1 hasta 3B +. Incluso el cero tiene puertos de cámara, pero dado que hay tantos raspis de segunda mano diferentes en el mercado, es posible que se pregunte cuál es el más ideal para esta construcción.

La respuesta depende de dónde desee procesar la transmisión de video.

Hay dos opciones:

1, procese los videos localmente con movimiento y reenvíe una transmisión de video cuando se detecte movimiento (nota: el movimiento reenvía una transmisión lenta y constante al servidor sin importar qué, esto puede ser dependiendo de la resolución y las velocidades de cuadro que use desde un par de cientos de megabytes a varios gigabytes al día, solo un recordatorio si desea realizar una configuración en una conexión medida). Aquí la CPU importa y, desafortunadamente, el movimiento (en el momento de escribir este artículo) no aprovecha los múltiples núcleos, sin embargo, el sistema operativo intentará equilibrar la carga ligeramente. Siempre tendrá uno de los núcleos al 100% de uso.

2, procese los videos en un servidor central: aquí simplemente reenvía la transmisión de video sin procesar desde la cámara a un servidor de transmisión externo (como iSpy ejecutándose en una computadora x86 o MotionEyeOS ejecutándose en otra minicomputadora dedicada). Dado que no hay procesamiento localmente, el modelo de PI que utilice no importa, un PI1 enviará el mismo flujo que un PI3B +.

En este tutorial iré con la primera opción.

La regla general aquí es que cuanto más rápida la CPU pongas en movimiento, mejores resultados obtendrás. Por ejemplo, mi cámara basada en Raspi 2 que miraba un pasillo a veces no captaba cuando alguien pasaba rápido y cuando estaba grabando la grabación era lenta, cayendo muchos fotogramas en comparación con el modelo 3. El modelo 3 también tiene el 802.11 abgn wifi, que es útil para poder transmitir videos de mayor calidad, funciona de inmediato y es bastante confiable. Al momento de escribir que el modelo 3B + está disponible, solo recomendaría que lo obtenga con una CPU de 1.4 Ghz Quad Core.

Lista de materiales

• DeathStar de plástico de 30 cm:)
• Frambuesa Pi 3 B +
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x relé de interruptor de láminas SIP-1A05
• 1x PCS HC-SR501 IR Módulo detector de sensor de movimiento PIR infrarrojo piroeléctrico IR
• 1 resistencia de 10 kohmios para LDR
• 1x LDR
• Adaptador DC 1x12V 4A
• 1xWarm White LED 5050 SMD Tira de lámpara de luz flexible 12V DC
• Regulador de voltaje 1xBuck

Como puede ver en los esquemas, este proyecto fue diseñado originalmente para controlar una sola luz con un relé porque no planeaba agregar iluminación interna (lo cual es bastante bueno), así que simplemente conecté un segundo relé al Arduino. Lo mejor del SIP-1A05 es que tiene un diodo de retorno interno y el consumo en mA está muy por debajo de la limitación de potencia por pin de Arduino.

La razón por la que el PIR está en el escudo de las imágenes es porque al principio se planeó poner S0P en una caja de plástico IP simple en lugar de un DeathStar. Como puede adivinar, la cámara está directamente en la pistola láser, el PIR y el LDR necesitaban otros orificios perforados y están pegados con pistola ya que no planeo quitarlos.

Se hizo un agujero en la parte inferior del DeathStar donde pegué un perno grande con un pegamento fuerte de 2 componentes. Esto se puede atornillar en el soporte original de Neo Coolcams (después de todo, era bueno para algo:)). Para un soporte adicional, utilicé cables de cobre duro para sujetar la parte superior de la estrella.

Nota importante sobre la fuente de alimentación: dado que la misma fuente alimentará tanto el PI, Arduino como la tira de LED, debe ser lo suficientemente robusta para poder manejarlos todos, por lo que se basará en la tira de LED que elija para el proyecto. Una tira de LED comercial 5050 12v 3 metros drena alrededor de 2A, eso es mucho. Para el PI y Arduino tienes que calcular en + 2A (aunque esto es sobredimensionado no te hará daño). El uso de una tira de LED sobre bombillas halógenas estándar, neón u otra iluminación de alta potencia es que puede colocar todo este circuito en una bonita batería de plomo-ácido de 12V @ 10Ah como respaldo para que incluso funcione en caso de un corte de energía.

El dólar reducirá el voltaje de 12-> 5V para alimentar el Arduino y el PI mientras que la alimentación directa de 12V está conectada al relé para encender la tira de LED.

Paso 3: software Arduino

Puede encontrar el código fuente completo a continuación, que está bien comentado, pero aquí hay una breve explicación de cómo funciona: Al comienzo de cada ciclo, se llama a la función xcomm () habitual para ver si hay un comando proveniente de Raspberry PI que puede ser LIGHT_ON / OFF para encender las luces del pasillo o DS_ON / OFF para encender / apagar la luz de fondo DeathStar, los he implementado solo por el bien de la perfección, ya que si alguien pasa por el PIR debe levantarlo y encenderlo las luces, pero tal vez quieras mirar el lugar por alguna razón, incluso cuando no hay nadie allí.

Después de esto, se lee el valor de la fotocélula y se comprueba el movimiento del pin de movimiento. Si hay movimiento, el código verifica si está lo suficientemente oscuro y luego verifica si no estamos en espera. Si todo esto pasa, simplemente enciende la luz del pasillo y envía PHOENIX_MOTION_DETECTED a la Raspberry PI, si no está lo suficientemente oscuro, todavía envía la señal a la computadora pero no enciende la luz. Una vez que se detecta un movimiento, se inicia un temporizador de retención de 5 minutos.

Inmediatamente después de esto, la siguiente sección de código verificará si estamos en espera (que debería ser el caso si solo hubiera un evento de movimiento, así que supongamos que pasaron los 5 minutos para que esta verificación pueda confirmar). El código verifica si hay movimiento nuevamente, si no, apague las luces. Como puede ver, si no hay movimiento, esta función se repetirá una y otra vez, siga intentando apagar las luces para que no haya retroalimentación en la PC.

Tenemos otro temporizador de espera para la iluminación interna del DeathStar que depende puramente de photocellReading <dark_limit.

Aunque las 2 rutinas no se conocen entre sí, funcionarán perfectamente juntas ya que cuando la luz del pasillo se enciende proporciona tanta luz que el LDR pensará que es de día nuevamente y apaga la iluminación interna. Sin embargo, hubo algunas advertencias sobre este proceso que se explican en el código si está interesado, si no, tome la respuesta de Nvidia de que "¡simplemente funciona!".

Paso 4: Software Raspberry PI

El último Raspbian funciona para mí:

Raspbian GNU / Linux 9.4 (estirado)

Linux Phoenix 4.9.35-v7 + # 1014 SMP Vie 30 de junio 14:47:43 BST 2017 armv7l GNU / Linux ii motion 4.0-1 Programa de captura armhf V4L que admite detección de movimiento

Si bien puede usar otras distribuciones, si tiene algún problema con la cámara, solo obtendrá soporte del equipo si está usando su sistema operativo oficial. También se recomienda encarecidamente eliminar bloatware no deseado como systemd.

Motion también se puede construir fácilmente desde la fuente:

apt-get -y install autoconf automake pkgconf libtool libjpeg8-dev build-essential libzip-dev apt-get install libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev

apt-get -y install libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev apt-get -y install git git clone https://github.com/Motion-Project/motion cd motion / autoreconf -fiv. / configure --prefix = / usr / motion make && make install / usr / motion / bin / motion -v

Recomiendo iSpy como servidor de grabación / recopilación de vídeo. Desafortunadamente, en el momento de escribir este artículo, no existen buenas alternativas para Linux. La cámara se puede agregar con una URL MJPEG https:// CAMERA_IP: 8081 como puerto predeterminado.

El procesamiento de movimiento puede ser útil, por ejemplo, no tiene que seguir mirando su servidor iSpy durante todo el día, puede recibir un correo electrónico en caso de movimiento. Aunque iSpy tiene esta funcionalidad para alertar por correo electrónico en caso de movimiento, activa la grabación de vez en cuando para eventos diversos, como que se refleja algo de luz en el área. Con la detección de movimiento PIR nunca tuve una sola falsa alarma. Las alertas se pueden procesar localmente:

Se detectó un evento de movimiento pir en el sensor> alerta de Arduino> Raspberry pi recibe en la consola> programa de procesamiento C> aplicación de correo externo

Sin embargo, prefiero procesar tanto los registros como los videos de forma remota, por lo que en este caso agregué una sección al programa de control C mientras registra los registros localmente en un archivo de texto sin formato, también lo registra en syslog y se reenvía a un SIEM para más procesamiento.

registrador de vacío (char * text) {

ARCHIVO * f = fopen ("phoenix.log", "a"); if (f == NULL) {printf ("¡Error al abrir el archivo de registro! / n"); regreso; } fprintf (f, "% s =>% s / n", cur_time (0), texto); fclose (f); #ifdef SYSLOG char loggy [500]; sprintf (loggy, "% s =>% s / n", cur_time (0), texto); setlogmask (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); // syslog (LOG_NOTICE, "Programa iniciado por el usuario% d", getuid ()); syslog (LOG_NOTICE, loggy); closelog (); #endif return; }

En el extremo receptor, syslog-ng puede desmultiplicar estos eventos del flujo de registro principal:

filter f_phx {

match ("DeathStar"); }; destino d_phx {archivo ("/ var / log / phoenix / deathstar.log"); }; log {fuente (s_net); filtro (f_phx); destino (d_phx); };

y se puede pasar a otra herramienta (motion.php ver adjunto) para su análisis y alerta.

En este script, simplemente puede establecer la hora habitual durante la semana cuando no está en casa:

$ opt ['alert_after'] = '09:00:00'; // Mañanas $ opt ['alert_before'] = '17:00:00'; // Tardes

El programa php utiliza la excelente utilidad logtail para analizar los registros.

$ cmd = "logtail -o". $ archivo de compensación. ' '. $ archivo de registro.'> '. $ archivo de registro2;

Logtail rastrea la posición en un archivo de compensación para que el programa principal no tenga que saber a partir de qué momento comenzar a mirar los registros, se le proporcionarán los últimos datos sin procesar.

Motion.php se puede ejecutar desde crontab con un pequeño truco para los fines de semana, cuando pasará por los registros, pero no se procesará más.

* / 5 * * * 1-5 / usr / local / bin / php ~ / motion.php &> / dev / null * / 5 * * * 6-7 / usr / local / bin / php ~ / motion.php fin de semana &> / dev / null

Paso 5: Lista de problemas y tareas pendientes

Si está utilizando Raspberry pi 3 o más reciente, puede omitir esta sección, lo más probable es que ya no se encuentre con estos problemas.

Durante los años tuve algunos problemas con las placas basadas en Raspberry pi 2, que podrían ejecutar la misma pila de software, pero se compraron en diferentes momentos y en diferentes lugares. Después de un cierto período de tiempo que podría ser de 2 días o 20 días cuando SSH en el dispositivo, el SSH simplemente se colgaría, por lo que tanto el demonio de movimiento como el código C local que hablaba con Arduino se cargaron en la RAM, por lo que el dispositivo estaba funcionando. pero ya era imposible hacer otra cosa con él en este estado.

Después de mucha resolución de problemas, he encontrado una solución:

homesync.sh

#! / bin / sh -e

### BEGIN INIT INFO # Proporciona: homesync # Required-Start: mountkernfs $ local_fs # Required-Stop: camera phoenix # Default-Start: S # Default-Stop: 0 6 # Descripción breve: Home sync # Descripción: Home sync por NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/ home /" DISK = "/ realhome /" set -e case "$ 1" en start | forward) echo -n "Inicio $ DESC: "rsync -az --numeric-ids --delete $ DISK $ RAM &> / dev / null echo" $ NAME ".;; stop | back) echo -n "Deteniendo $ DESC:" rsync -az --numeric-ids --delete $ RAM $ DISK &> / dev / null echo "$ NAME".;; *) echo "Usage: $ 0 {start | stop}" exit 1;; esac salida 0

El script va junto con una modificación de fstab:

tmpfs / home tmpfs rw, tamaño = 80%, nosuid, nodev 0 0

La partición de inicio está montada como un disco RAM que produciría aproximadamente 600 MB de espacio libre en la Raspberry pi 2, que es más que suficiente para almacenar algunos binarios y pequeños archivos de registro:

tmpfs 690M 8.6M 682M 2% / hogar

Resultó que el bloqueo de PI se atribuyó a las operaciones de escritura en la tarjeta SD, aunque probé diferentes tarjetas (Samsung EVO, Sandisk) que se escanearon en busca de errores varias veces antes y después y no tuvieron ningún problema en otras computadoras portátiles, esto fue solo subiendo. No tuve el mismo problema (todavía) con Raspberry PI 3 y hardware superior, por eso también los recomiendo en este tutorial.

Aunque el movimiento actual en una Raspberry PI 3 es lo suficientemente bueno para mí, aquí hay algunas ideas que vale la pena explorar:

1. No utilice movimiento, utilice una transmisión áspera a través de la red y deje que un servidor potente realice la detección de movimiento y la codificación de vídeo (por ejemplo, iSpy). -> Problema: acaparamiento constante del ancho de banda de la red.
2. Use movimiento y deje que ffmpeg haga la codificación de video. -> Problema: la CPU no puede manejar las resoluciones más altas
3. Use movimiento, grabe video sin procesar y deje que un servidor poderoso haga la codificación. -> El uso de CPU en RPi es bajo y el ancho de banda de la red está limitado a cuando hay movimiento real. Para este escenario, podríamos escribir en una tarjeta SD / disco RAM para un rendimiento máximo y luego crontab y copiar el video a otro servidor.

También me gustaría señalar que la construcción de este proyecto es posible sin un Arduino. Todos los componentes (relés, LDR, PIR) podrían conectarse a la raspberry pi de alguna manera, pero prefiero microcontroladores en tiempo real para interactuar con sensores y dispositivos de salida. En los casos en los que mi raspberry pi se colgaba, por ejemplo, o fallaba, el control de luz ejecutado por Arduino funcionó bien.

Si te gustó este instructivo, estad atentos, ya que continuaré la serie con mi cámara domo cero raspberry pi para exteriores de 360 grados el próximo año.