Open-Source-Sicherheitskamera auf Raspberry-Pi-Basis

 (github.com/TzuHuanTai)
1 Punkte von GN⁺ 2024-09-17 | 1 Kommentare | Auf WhatsApp teilen
  • Raspberry Pi WebRTC ist ein auf C++20 basierendes Projekt, das einen Raspberry Pi oder NVIDIA Jetson in eine WebRTC-Streaming-Plattform mit etwa 200 ms Latenz verwandelt
  • Es nutzt natives WebRTC und unterstützt Hardware-/Software-Encoding, Schnappschüsse, Aufzeichnung, Broadcasting, Fernsteuerung und IoT-Messaging über WebRTC DataChannel
  • Als Signalisierung werden MQTT, WHEP und WebSocket unterstützt; MQTT dient dazu, dass Pi-Kamera und Client Informationen für die WebRTC-Verbindung austauschen
  • Unterstützte Geräte sind Raspberry Pi Zero/3/4/5 und NVIDIA Jetson Nano/NX/Orin; als Kamera kann CSI oder USB verwendet werden, und unterstützt werden müssen libcamera, libargus und V4L2
  • Auf Pi 5 oder Geräten ohne Hardware-Encoder muss --hw-accel aus den Startoptionen entfernt werden; WHEP benötigt keinen Broker, aber einen öffentlichen Hostnamen

Projektüberblick

  • Raspberry Pi WebRTC ist ein Projekt, das einen Raspberry Pi oder NVIDIA Jetson in eine WebRTC-Streaming-Plattform mit geringer Latenz verwandelt
  • Die angestrebte Latenz liegt bei etwa 200 ms
  • Die wichtigsten technischen Angaben sind wie folgt

    • libwebrtc m146.7680

    • C++20

      • Apache 2.0-Lizenz

Unterstützte Funktionen

  • Bietet Streaming auf Basis von nativem WebRTC
  • Für die Video-Encoding werden Hardware-Encoding und Software-Encoding unterstützt
  • Zu den Kamerafunktionen gehören Schnappschüsse, Aufzeichnung und Broadcasting
  • Unterstützt Fernsteuerung und IoT-Messaging über den WebRTC-DataChannel

Signalisierung und Clients

Anforderungen

  • Unterstützte Boards sind Raspberry Pi Zero/3/4/5 oder NVIDIA Jetson Nano/NX/Orin
  • Es können CSI- oder USB-Kameras verwendet werden
  • Der Kameraeingang muss libcamera, libargus oder V4L2 unterstützen

Raspberry Pi Schnellstart

  • Raspberry Pi OS installieren
  • Abhängigkeiten installieren
    • libmosquitto1, pulseaudio, libavformat61, libswscale8, libyaml-cpp0.8 installieren
  • Binärdatei herunterladen
  • MQTT-Signalisierung
    • HiveMQ, EMQX oder einen selbst gehosteten Broker verwenden
    • MQTT ermöglicht den Austausch von WebRTC-Verbindungsinformationen zwischen Pi-Kamera und Client
    • WHEP benötigt keinen Broker, aber einen öffentlichen Hostnamen

Ausführung und Hinweise

  • picamera-web öffnen, die MQTT-Einstellungen hinzufügen und dann eine UID erzeugen
  • Auf dem Pi ./pi-webrtc ausführen und Optionen für Kamera, FPS, Auflösung, MQTT-Host, Port, Benutzername, Passwort, UID usw. angeben
  • Beispieloptionen sind --camera=libcamera:0, --fps=30, --width=1280, --height=960, --use-mqtt, --no-audio usw.
  • --hw-accel ist eine Option für Hardware-Encoding auf Pi Zero 2W, 3B, 4B
  • Auf Pi 5 oder Geräten ohne Hardware-Encoder muss --hw-accel entfernt werden

Erweiterte Nutzung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-17
Hacker-News-Kommentare

  • Ich musste einmal ein Haus während einer Renovierung aus der Ferne überwachen und wollte dafür eines der stark beworbenen Sicherheitssysteme installieren, die mir Bekannte empfohlen hatten. Billig war das nicht, und erst bei der Einrichtung stellte sich heraus, dass die meisten Funktionen, die ich wollte, Breitband-Internet voraussetzten.
    In keinem Marketingmaterial stand etwas von dieser Voraussetzung, und das Haus hatte keinen Internetanschluss. Ich hatte auch keine Lust, 40 Dollar im Monat für das Sicherheitssystem plus mindestens 60 Dollar für Internet zu zahlen.
    Stattdessen habe ich eine Raspberry-Pi-Kamera an einen vorhandenen RPi Zero 2W gehängt, dazu einen LTE-Hotspot und eine T-Mobile-Prepaid-SIM für 5 Dollar im Monat gekauft.
    Als Software nutzte ich imgcomp, das jede Sekunde ein Foto auf eine RAM-Disk speicherte. Wenn sich zwei Bilder abgesehen von Rauschen unterschieden, lud der Pi das veränderte Bild in ein VPS-Verzeichnis hoch, was wiederum Gotify auslöste, damit ein Link zum Foto als Benachrichtigung aufs Handy geschickt wurde.
    Insgesamt war das zwar eine Rube-Goldberg-Konstruktion, hat aber über Jahre hinweg fast perfekt funktioniert.

    • „Das Sicherheitssystem war nicht billig“ und „das System kostete etwa 40 Dollar“ passen für mich nicht ganz zusammen. Ich frage mich, wie billig das Sicherheitssystem denn deiner Erwartung nach hätte sein sollen.
    • Ich finde, das passt perfekt zu Bastel- und Hackergeist. Du brauchtest etwas, hast mit dem, was du hattest, selbst eine Lösung gebaut, und für mich wirkt das nicht einmal besonders wie eine Rube-Goldberg-Konstruktion.
    • Hast du erwartet, eine Kamera ohne Internetanschluss über das Internet überwachen zu können? Es liest sich so, als hättest du erwartet, dass LTE ohne Abo in die Kamera eingebaut ist.
    • Ziemlich nettes Setup. Heute könnte man dahinter wohl noch ein GPU- oder TPU-basiertes Coral-Modul mit codeproject.ai hängen.

  • Ich hatte früher etwas Ähnliches gebaut: https://youtube.com/watch?v=5E7_40PWqiQ
    Während unser Haus gebaut wurde, wohnten wir in einer Wohnung, und ich wollte mit einer Kamera ein Zeitraffervideo erstellen und zusätzlich über das Internet darauf zugreifen können, um zu sehen, wie die Arbeiter vorankommen.
    Leider stellte sich bei jeder Idee heraus, dass sie schon jemand gebaut hatte, in diesem Fall aus China. Auf AliExpress gibt es ziemlich gute Kameras, die all das und noch mehr können, und sie sind besser verarbeitet als mein unbeholfenes 3D-gedrucktes Gehäuse.

    • Einige dieser Geräte, vielleicht die meisten oder sogar alle, brauchen externe Dienste. Das heißt, sie funktionieren nur so lange, wie dieser Dienst existiert, und man ist dem Hersteller ausgeliefert.
      Mein Traum ist es, so ein Gerät zu bauen und über Tor Fernzugriff darauf zu ermöglichen. Dann könnte es komplett lokal bleiben und trotzdem von überall auf der Welt erreichbar sein.

  • Als alternatives Projekt, das ich für einen Raspberry Pi Zero WH in Betracht gezogen hatte, gibt es mediamtx.
    https://github.com/bluenviron/mediamtx?tab=readme-ov-file#raspberry-pi-cameras

  • Das ist ein gutes Beispiel für den Einsatz von WebRTC, und seltsamerweise wird WebRTC immer noch nicht genug genutzt.
    Wenn man self-hosted arbeitet und über mobile Daten aus der Ferne auf einen Signaling-Server zugreifen will, muss man bei dynamischen IPs des ISP möglicherweise DDNS und Port-Forwarding einrichten.
    Allerdings setzt man den Server damit dem Internet aus. Stattdessen kann man eine Open-Source-Lösung nutzen, die eine private Verbindung zwischen Pi und Server herstellt. Dann muss man keinen Netzwerkzugang zum Server öffnen und braucht weder statische IP noch Port-Forwarding.

    • Zu sehen, wie WebRTC sein volles Potenzial ausschöpft, ist meine Leidenschaft im Leben. Seit ich P2P/NAT-Traversal verstanden habe, kann ich nicht mehr zurück.
      Mich würde interessieren, warum du meinst, dass WebRTC Schwierigkeiten hatte, sich breit durchzusetzen. Ob es an der Softwarequalität liegt, an Lernmaterialien oder etwas anderem – ich bin immer auf der Suche nach neuen Projekten.
    • Wenn man einen MQTT-Server auf dem Pi betreibt, ist das Problem gelöst :)

  • Ich verstehe den Teil nicht ganz, dass der Raspberry Pi 5 kein v4l2-Hardware-Encoding unterstützt. In Videodekodierung wurde doch so viel Aufwand gesteckt – warum gibt es dann keinen Encoder?

    • Ich vermute, weil viel weniger Leute encodieren als dekodieren.
      Zwischen Encoding und Decoding gibt es Überschneidungen, aber selbst bei meiner Arbeit am Opus-Codec gab es ziemlich viel Code, der nur auf eine der beiden Richtungen zutraf.
    • Man hat sich entschieden, die Siliziumfläche anderweitig zu nutzen. Die CPU des Pi 5 ist stark genug, um die meisten H.264-Streams in Software zu dekodieren, und der Pi 5 hat einen Hardware-Decoder für H.265.

  • Genau so etwas habe ich gesucht. Ich wollte Personenerkennung laufen lassen.
    Ich verwende yolov3-tiny, zwar nicht das Neueste, aber ein sehr leichtgewichtiges Computer-Vision- und Machine-Learning-Modell, und optimiere gerade die Inferenzleistung in C++, um rund ums Haus Personen in Echtzeit zu erkennen.
    Wenn nachts jemand das Grundstück betritt, sollen automatisch Sirene und Beleuchtung angehen, um Eindringlinge abzuschrecken.
    https://github.com/jmaczan/yolov3-tiny-openvino

    • Ich stelle mir schon vor, wie mitten in der Nacht zufällig der Alarm losgeht.
      Ich habe mir eher ein System vorgestellt, bei dem Licht und Sirene schrittweise aktiviert werden, je näher jemand kommt. So könnte man viel früher reagieren und einem potenziellen Eindringling ausreichend signalisieren, dass er verschwinden soll.
      Es scheint effektiver zu sein, in der Feedbackschleife das Adrenalin langsam zu steigern. Einen plötzlichen Effekt muss man nur einmal beurteilen.

  • Ich habe vor Kurzem ein dauerhaft laufendes Aufnahmegerät gebaut. Der Hauptzweck ist, Audio kontinuierlich weiter aufzuzeichnen – nicht zur Überwachung, sondern für Musiker und Kreative, die bei einer großartigen Performance nicht daran denken wollen, rechtzeitig den Aufnahme-Button zu drücken.
    Ich habe einen Zero-W, ein etwas heikles Shell-Skript für arecord/aplay und ein turboLua-Frontend verwendet, und das funktioniert ziemlich gut.
    Es nimmt dauerhaft auf, löscht aber nur „altes“ Audio, das die vom Nutzer gewählte Aufbewahrungsdauer überschritten hat. Zur Auswahl stehen 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde, 3 Stunden, 5 Stunden und bis zu 24 Stunden.
    Ich habe auch ein Frontend gebaut, mit dem Nutzer Zeitabschnitte, in denen sie etwas Gutes aufgenommen haben, auf Keep setzen können. Diese Heuristik ähnelt dem Deadman-Switch-/Sicherheitskamera-Mechanismus vieler Überwachungsprodukte.
    Es funktioniert so gut, dass ich mich frage, warum das noch kein Standard geworden ist. Vermutlich spielt noch immer die wirtschaftliche Präferenz mit hinein, Speicherplatz nicht vollzuschreiben, aber heutzutage hält selbst 128 GB ziemlich lange.
    Irgendwann wird sich so etwas wohl verbreiten. Es ist ziemlich inspirierend, das Ding aufzustellen, es zu vergessen, dann stundenlang zu jammen und am Ende nur noch das behalten zu müssen, was man wirklich sichern will, während der Rest automatisch aufgeräumt wird.

  • Das alte Projekt RPi Cam Web Interface sollte man auch nicht vergessen. Es ist ziemlich alt, läuft aber immer noch auf meinen Pis.
    Ich betreibe es in einer Umgebung für dauerhaften Einsatz, ohne die SD-Karte zu ruinieren, und speichere die Daten auf einem Server. Auch die Oberfläche ist ordentlich.
    https://elinux.org/RPi-Cam-Web-Interface

  • Für einen ähnlichen Zweck nutze ich https://github.com/TinkerTurtle/Sentry-Picam mit großem Erfolg.
    Den Ordner mit aufgezeichneten Bildern/Videos synchronisiere ich mit syncthing auf drei weitere Rechner, um Redundanz zu haben, und ich habe ein Push-Benachrichtigungsskript auf Basis von sendxmpp angebunden, damit ich auf allen Geräten in Echtzeit benachrichtigt werde, wenn etwas passiert.

  • Ziemlich cool. Ich habe früher bei https://securade.ai an etwas Ähnlichem gearbeitet und dafür Nvidia Jetson als Edge-Gerät verwendet.
    Jetzt bin ich gespannt auf reCamera: https://www.seeedstudio.com/blog/recamera/