Caméra de sécurité open source basée sur Raspberry Pi

 (github.com/TzuHuanTai)
1 points par GN⁺ 2024-09-17 | 1 commentaires | Partager sur WhatsApp
  • Raspberry Pi WebRTC est un projet basé sur C++20 qui transforme un Raspberry Pi ou un NVIDIA Jetson en plateforme de streaming WebRTC avec une latence d’environ 200 ms
  • Il utilise WebRTC natif et prend en charge l’encodage matériel/logiciel, les instantanés, l’enregistrement, la diffusion, le contrôle à distance et la messagerie IoT via WebRTC DataChannel
  • Les modes de signalisation pris en charge sont MQTT, WHEP et WebSocket ; MQTT sert à l’échange des informations de connexion WebRTC entre la caméra Pi et les clients
  • Les appareils pris en charge sont les Raspberry Pi Zero/3/4/5 et NVIDIA Jetson Nano/NX/Orin ; les caméras peuvent être CSI ou USB et doivent prendre en charge libcamera, libargus ou V4L2
  • Sur un Pi 5 ou un appareil sans encodeur matériel, il faut retirer --hw-accel des options d’exécution ; WHEP ne nécessite pas de broker, mais requiert un nom d’hôte public

Présentation du projet

  • Raspberry Pi WebRTC est un projet qui transforme un Raspberry Pi ou un NVIDIA Jetson en plateforme de streaming WebRTC à faible latence
  • La latence cible annoncée est d’environ 200 ms
  • Les principales technologies indiquées sont les suivantes

    • libwebrtc m146.7680

    • C++20

      • Licence Apache 2.0

Fonctionnalités prises en charge

  • Fournit un streaming basé sur WebRTC natif
  • L’encodage vidéo prend en charge l’encodage matériel et l’encodage logiciel
  • Les fonctions caméra incluent les instantanés, l’enregistrement et la diffusion
  • Prend en charge le contrôle à distance et la messagerie IoT via WebRTC DataChannel

Signalisation et clients

Prérequis

  • Les cartes prises en charge sont Raspberry Pi Zero/3/4/5 ou NVIDIA Jetson Nano/NX/Orin
  • Il est possible d’utiliser une caméra CSI ou USB
  • L’entrée caméra doit prendre en charge libcamera, libargus ou V4L2

Démarrage rapide sur Raspberry Pi

  • Installer Raspberry Pi OS
  • Installer les dépendances
    • Installer libmosquitto1, pulseaudio, libavformat61, libswscale8, libyaml-cpp0.8
  • Télécharger le binaire
  • Signalisation MQTT
    • Il est possible d’utiliser HiveMQ, EMQX ou un broker auto-hébergé
    • MQTT permet à la caméra Pi et aux clients d’échanger les informations de connexion WebRTC
    • WHEP ne nécessite pas de broker, mais requiert un nom d’hôte public

Mode d’exécution et points d’attention

  • Ouvrir picamera-web, ajouter la configuration MQTT, puis générer un UID
  • Sur le Pi, exécuter ./pi-webrtc en indiquant en options la caméra, les FPS, la résolution, l’hôte MQTT, le port, le nom d’utilisateur, le mot de passe, l’UID, etc.
  • Les options d’exemple incluent --camera=libcamera:0, --fps=30, --width=1280, --height=960, --use-mqtt, --no-audio, etc.
  • --hw-accel est l’option à ajouter pour utiliser l’encodage matériel sur Pi Zero 2W, 3B, 4B
  • Sur un Pi 5 ou un appareil sans encodeur matériel, il faut retirer --hw-accel

Utilisation avancée

À lire aussi

1 commentaires

 
GN⁺ 2024-09-17
Avis sur Hacker News

  • Il y a quelque temps, je devais surveiller à distance une maison en rénovation. J’ai essayé d’installer un système de sécurité très présent dans les pubs, recommandé par des connaissances, mais ce n’était pas donné, et ce n’est qu’au moment de la configuration que j’ai découvert que la plupart des fonctions voulues exigeaient une connexion Internet haut débit.
    Cette condition n’apparaissait nulle part dans les documents marketing, la maison n’avait pas Internet, et je n’avais pas l’intention de payer au moins 60 $ d’Internet en plus des 40 $ par mois du système de sécurité.
    À la place, j’ai branché une caméra Raspberry Pi sur un RPi Zero 2W que j’avais déjà, puis j’ai acheté un hotspot LTE et une SIM prépayée T-Mobile à 5 $ par mois.
    Côté logiciel, avec imgcomp, je prenais une photo chaque seconde et l’enregistrais sur un disque RAM ; si deux photos différaient autrement que par du bruit, le Pi envoyait la photo modifiée dans un répertoire sur un VPS, ce qui déclenchait Gotify pour m’envoyer une notification sur mon téléphone avec un lien vers la photo.
    Dans l’ensemble, c’était une installation à la Rube Goldberg, mais elle a fonctionné presque parfaitement pendant des années.

    • « Le système de sécurité n’était pas donné » et « le système coûtait environ 40 $ » ne s’enchaînent pas très bien. Je me demande à quel point il s’attendait à ce qu’un système de sécurité soit bon marché.
    • Je trouve que c’est exactement dans l’esprit bricoleur et hacker. Il avait un besoin, il a fabriqué une solution avec ce qu’il avait, et ça ne me semble pas particulièrement Rube Goldberg.
    • Il s’attendait à pouvoir surveiller une caméra via Internet sans connexion Internet ? On dirait qu’il espérait que la caméra intègre de la LTE sans abonnement.
    • Configuration plutôt correcte. Aujourd’hui, on pourrait probablement ajouter derrière ça un GPU ou un module Coral TPU avec codeproject.ai pour le traitement.

  • J’avais commencé à fabriquer quelque chose de similaire il y a quelque temps : https://youtube.com/watch?v=5E7_40PWqiQ
    Je vivais en appartement pendant la construction de ma maison, et je voulais faire une vidéo en timelapse avec la caméra, tout en me permettant en plus d’y accéder par Internet pour voir comment les ouvriers s’en sortaient.
    Malheureusement, chaque idée qui me venait à l’esprit avait déjà été réalisée par quelqu’un, en l’occurrence en Chine. Sur AliExpress, on trouve des caméras plutôt correctes qui font ça et plus encore, avec une finition meilleure qu’un boîtier bricolé en impression 3D.

    • Certains de ces appareils, peut-être la plupart voire tous, ont besoin d’un service externe. Autrement dit, ils ne fonctionnent que tant que ce service existe, et vous êtes à la merci du fournisseur.
      Mon rêve serait de fabriquer ce genre d’appareil et de permettre l’accès distant via Tor. On pourrait ainsi le garder entièrement en local tout en y accédant à distance depuis n’importe où dans le monde.

  • Un projet alternatif que je regardais pour l’utiliser sur un Raspberry Pi Zero WH est mediamtx.
    https://github.com/bluenviron/mediamtx?tab=readme-ov-file#raspberry-pi-cameras

  • C’est un bon exemple d’utilisation de WebRTC, et bizarrement WebRTC reste assez sous-exploité.
    Pour l’auto-hébergement avec un accès distant au serveur de signalisation via données mobiles, il peut falloir configurer du DDNS et de la redirection de ports si le FAI fournit une IP dynamique.
    Mais cette approche expose le serveur à Internet. À la place, on peut utiliser une solution open source qui crée une connexion privée entre le Pi et le serveur. Ainsi, il n’est pas nécessaire d’ouvrir l’accès réseau au serveur, ni d’avoir une IP statique ou de la redirection de ports.

    • Voir WebRTC réaliser tout son potentiel est une passion dans ma vie. Depuis que j’ai découvert le P2P et la traversée NAT, je ne peux plus revenir en arrière.
      Je suis curieux de savoir pourquoi, selon vous, WebRTC a eu du mal à s’imposer largement. Est-ce une question de qualité logicielle, de ressources pédagogiques ? Je cherche toujours de nouveaux projets.
    • Monter un serveur MQTT sur le Pi résout le problème :)

  • Je ne comprends pas bien le fait que le Raspberry Pi 5 ne prenne pas en charge l’encodage matériel v4l2. Ils ont fait tant d’efforts pour intégrer le décodage vidéo ; pourquoi ne pas avoir d’encodeur ?

    • Je suppose que c’est parce qu’il y a beaucoup moins de gens qui encodent que de gens qui décodent.
      L’encodage et le décodage ont des parties communes, mais quand je travaillais sur le codec Opus, il y avait tout de même pas mal de code propre à un seul des deux chemins.
    • Ils ont décidé d’utiliser la surface de silicium ailleurs. Le CPU du Pi 5 est assez puissant pour décoder la plupart des flux H.264 en logiciel, et le Pi 5 dispose d’un décodeur matériel H.265.

  • C’est exactement ce que je cherchais. Je voulais faire tourner de la détection de personnes.
    J’utilise yolov3-tiny : ce n’est pas le plus récent, mais c’est un modèle de machine learning en vision par ordinateur très léger, et je suis en train de maximiser les performances d’inférence en C++ pour faire de la détection de personnes en temps réel autour de la maison.
    J’aimerais que, si quelqu’un entre sur le terrain la nuit, une sirène et des lumières s’allument automatiquement pour faire fuir l’intrus.
    https://github.com/jmaczan/yolov3-tiny-openvino

    • J’imagine déjà l’alarme qui se déclenche au hasard en pleine nuit.
      J’ai imaginé une approche où les lumières et la sirène s’activent progressivement à mesure que la personne approche. On pourrait ainsi réagir beaucoup plus tôt tout en donnant au potentiel intrus suffisamment de signaux pour faire demi-tour.
      Faire monter progressivement l’adrénaline dans une boucle de rétroaction me semble plus efficace. Un effet soudain ne demande qu’une seule décision.

  • J’ai récemment fabriqué un enregistreur audio toujours allumé. Son objectif principal est d’enregistrer l’audio en continu ; ce n’est pas destiné à la surveillance, mais aux musiciens et créateurs qui ne veulent pas devoir penser à appuyer sur le bouton d’enregistrement au milieu d’une excellente performance.
    J’ai utilisé un Zero-W, un script shell un peu délicat autour de arecord/aplay, et un frontend turboLua ; ça fonctionne plutôt bien.
    L’enregistrement est continu, mais l’audio « ancien » est supprimé uniquement une fois dépassée la durée de conservation choisie par l’utilisateur, avec des options de 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 heure, 3 heures, 5 heures et 24 heures.
    J’ai aussi créé un frontend qui permet à l’utilisateur de garder la plage horaire où il estime avoir capturé quelque chose de bon. Cette heuristique ressemble au mécanisme d’homme mort/caméra de sécurité de nombreux produits de surveillance.
    Ça fonctionne tellement bien que je me demande pourquoi ce n’est pas encore devenu une sorte de standard. Il semble rester une préférence économique pour ne pas remplir le stockage, mais aujourd’hui 128 Go tiennent déjà assez longtemps.
    J’ai l’impression que cette approche finira un jour par se généraliser. On l’installe, on l’oublie, puis après plusieurs heures de jam, on revient chercher uniquement ce qu’on veut conserver et le reste se nettoie tout seul ; c’est assez inspirant.

  • Il ne faut pas oublier l’ancien projet RPi Cam Web Interface. Il date un peu, mais il tourne encore sur mes Pi.
    Il est conçu pour fonctionner en continu sans massacrer la carte SD, avec le stockage envoyé vers un serveur. L’interface est propre aussi.
    https://elinux.org/RPi-Cam-Web-Interface

  • Pour un usage similaire, j’utilise avec beaucoup de succès https://github.com/TinkerTurtle/Sentry-Picam.
    Je synchronise le dossier des images/vidéos enregistrées avec trois autres machines via syncthing pour assurer la redondance, et j’ai ajouté un script de notifications push basé sur sendxmpp afin de recevoir des alertes en temps réel sur tous mes appareils quand quelque chose se passe.

  • Plutôt cool. J’ai déjà travaillé sur quelque chose de similaire chez https://securade.ai en utilisant un Nvidia Jetson comme appareil edge.
    Maintenant, j’attends reCamera avec impatience : https://www.seeedstudio.com/blog/recamera/