Raspberry Video Camera – Teil 25: Zweite Kamera

Helmut 1. August 2017 12 Kommentare

Seit den ersten Tagen der Raspberry Video Cam gibt es das Konzept der Multi-Kamera-Fähigkeit. Nun wird es Zeit, dass ich auch hier im Blog endlich vorstelle, wie sich eine zweite (und dritte und vierte) Kamera zuschalten lässt. Dabei geht es vor allen Dingen darum, dass eine Kamera das Triggern übernimmt und weitere abhängige Kameras auf dieses Auslösesignal reagieren. Damit wird erreicht, dass eine Szene gleichzeitig aus mehreren Blickwinkeln aufgenommen wird. Später kann dann ein Video aus dem Material von mehreren Kameras geschnitten werden.

Zuerst aber wieder ein Oachkatzl-Video. Mehr davon gibts in meinem YouTube-Kanal.

Warum brauche ich das (und andere vielleicht auch)?

Bei der Raspberry Video Cam handelt es sich ja um eine fest installierte Außenkamera. Da gibt es keinen Kameramann, der den Kamerastandort wechseln oder einen Schwenk vollführen könnte. Nicht mal ein Regisseur ist dabei, der dem Eichhörnchen sagen würde, wie es sich vor der Kamera positionieren soll. Um also mehrere Blickwinkel einzufangen, oder um Nahaufnahme und Totale kombinieren zu können, braucht es mehrere Kameras. Nur so bin ich immer auf der richtigen Seite, egal ob sich das Oachkatzl beim Wegmümmeln der Nuss nach links oder nach rechts wendet.

Im Sommer 2017 habe ich selbst seit einem Dreivierteljahr genau zwei Kameras im Einsatz, das hier vorgestellte Konzept ist mengenmäßig aber nicht beschränkt, es können ruhig mehr Kameras aufgestellt werden, die alle zentral ausgelöst werden.

Wie funktioniert das?

Das zentrale Ansteuern von mehreren Kameras beruht auf zwei Konzepten, die ich früher bereits vorgestellt habe:

• Ringpuffer: Jede Kamera speichert ständig den Videodatenstrom der letzten Sekunden in einem internen Puffer. Damit besteht zu jeder Zeit eine Rückgriffsmöglichkeit auf die Bilder der nahen Vergangenheit. Wenn ich – sagen wir mal – die letzten 30 Sekunden immer noch zur Verfügung habe, dann kann ich mir entsprechend Zeit lassen für die Erkennung der Eichhörnchen, aber auch für die Ansteuerung weiterer Kameras.
• Trennung von Auslösung und Aufzeichnung: Programmmäßig habe ich von der ersten Version ab konsequent zwei Dinge getrennt: Einmal die Recordingfunktion und zum zweiten die Objekterkennung. So ist es jetzt ohne großen Aufwand möglich, die Objekterkennung einmal zentral zu machen und daran mehrere Recorder, sprich Kameras, die nur aufzeichnen, anzuschließen.

Nun ist es genau genommen nicht so, dass eine Objekterkennung mehrere Kameras aktiv ansteuern würde. Vielmehr setzt die Objekterkennung im Fall der Fälle nur einen Trigger (also ein Auslösesignal), der von mehreren Remote-Kameras erkannt werden kann.

Wie kommunizieren die Kameras?

Oder genauer formuliert: Wie kommunizieren Objekterkennung und Recordingfunktion? Im Teil 11 dieser Serie mit dem Titel „Python für die Kamera“ habe ich das näher beschrieben. Es funktioniert über eine Triggerdatei. Der Programmteil, der ein Objekt vor der Kamera entdeckt, schreibt eine Triggerdatei ins Verzeichnis trigger/. Diese Datei hat keinen Inhalt, aber als Dateiname einen Zeitstempel. Und zwar den Zeitstempel des Augenblicks, zu  dem das Objekt (also in meinem Fall das Eichhörnchen) erkannt wurde. Weil alle nötigen Informationen bereits im Dateinamen stehen, ist es für die angeschlossenen Recorder nicht nötig, die Triggerdatei zu öffnen und zu lesen, ein Blick in das Triggerverzeichnis reicht schon. Das Recorder-Programm beobachtet das Triggerverzeichnis und reagiert, wenn dort eine Triggerdatei auftaucht. Der Zeitstempel wird gelesen, für die Zeit, die seit dem verstrichen ist, werden die Videodaten aus dem Ringpuffer geholt und dann wird so lange aufgezeichnet, bis die Triggerdatei wieder verschwindet.

Das ist alles nichts Neues, so funktioniert die Raspberry Video Cam seit ihren ersten Anfängen. Wirklich neu ist nun die Tatsache, dass Objekterkennung und Videorecording nicht mehr zwangsweise auf dem selben Gerät passieren müssen. Wir haben zwei oder mehrere Raspberry Pis, also zwei unabhängige Computer, die jetzt miteinander kommunizieren müssen. Am Prinzip der Triggerdatei ändert sich nichts, aber das Triggerverzeichnis gibt es nur einmal auf dem Raspberry Pi, der die Objekterkennung vornimmt. Alle anderen abhängigen Kameras müssen über das Netzwerk (sprich WLAN) auf dieses Triggerverzeichnis zugreifen können. Dazu brauchen wir ein Datenübertragungsprotokoll, das es ermöglicht, von einem Rechner auf Dateien eines anderen zuzugreifen. Dafür gibt es eine Reihe von Standards, zum Beispiel FTP, SMB (Samba) oder NFS. Ich will es einfach belassen und verwende ein Protokoll, das wir beim Remotezugriff auf den Raspberry Pi eh bereits eifrig im Einsatz haben, nämlich SSH Secure Shell.

Per SSH kann man nicht nur vom Windows- (oder Linux-)Rechner textbasierend auf die Raspberry Pi Konsole zugreifen, da geht noch mehr. Machen wir ein Experiment und öffnen an einem Linuxrechner ein Terminalfenster, aber ohne uns mit dem Raspberry Pi zu verbinden. Und dann setzen wir ein paar Kommandos (fett) ab, wobei mein Raspberry Pi den Namen raspi166 hat:

$ ssh pi@raspi166 pwd
/home/pi
$ ssh pi@raspi166 uname -a
Linux raspi166 4.4.26-v7+ #915 SMP Thu Oct 20 17:08:44 BST 2016 armv7l GNU/Linux
$ ssh pi@raspi166 ls -l
insgesamt 159560
-rw-r--r--  1 pi   pi      15235 Jul  5 18:05 analyze3.py
-rw-r--r--  1 pi   pi   21080170 Jul 14 10:32 analyze.log
-rw-r--r--  1 pi   pi        953 Jun  7 10:23 freedisk.py
drwxr-xr-x 12 pi   pi       4096 Okt 25  2016 opencv-3.1.0
drwxr-xr-x  5 pi   pi       4096 Dez 17  2015 opencv_contrib-3.1.0
-rw-r--r--  1 pi   pi        312 Mär 26 17:22 postprocess.py
-rwxr-xr-x  1 pi   pi       3385 Mär 26 16:18 record2.py
-rw-r--r--  1 pi   pi       2546 Jul 14 10:27 record.log
drwxr-xr-x  2 pi   pi       4096 Jun 15 12:32 samples
drwxr-xr-x  2 pi   pi       4096 Jul 14 10:26 trigger
drwxr-xr-x  2 pi   pi     880640 Jul 14 10:31 Videos
$

Da wird also per SSH keine Terminalsession zum Raspberry Pi aufgebaut, sondern es werden Linux-Kommandos abgesetzt und die Antwort kommt prompt zurück. Das dritte Kommando, also der remote per SSH abgesetzte ls-Befehl ist auch bereits die Lösung unseres Problems, denn damit können wir selbstverständlich auch den Inhalt des trigger/ Verzeichnisses listen:

$ ssh pi@raspi166 ls -l trigger/
insgesamt 0
$

Gut, da liegt im Moment gerade keine Triggerdatei drin, aber das Prinzip ist klar geworden:

Per SSH können wir von einem anderen Linuxrechner aus ins Triggerverzeichnis derjenigen Raspberry Video Cam schauen, die die Objekterkennung durchführt.

Aber muss man bei SSH Aufrufen nicht jeweils das Passwort des Users Pi angeben? Normalerweise schon – in meinen Beispielen eben war das aber nicht der Fall. Das liegt daran, dass ich eine Public Key Authentifizierung verwende, die ich in diesem Artikel schon einmal detailliert beschrieben habe und die das Passwort obsolet macht. Und genau das müssen wir zwischen den beiden Raspberry Kameras auch etablieren, damit ohne Passwortabfrage kommuniziert werden kann.

Public Key Authentifizierung einrichten

Client -Server

Zuerst müssen wir uns klar werden, welche Kamera welche Rolle übernimmt. Da gibt es den Client, das ist die Maschine, die einen Zugriff initiiert, die in unserem Fall von einem anderen Rechner eine Datei haben möchte und die typischerweise das Passwort für den anderen Rechner kennen müsste. Und da ist der Server, auf den zugegriffen wird. Bei mir haben die beiden Raspberry Video Camera Rechner folgende Namen, die bei den folgenden Kommandos natürlich an die eigenen angepasst werden müssen:

• raspi166: Server, hat ein Triggerverzeichnis, auf ihm läuft die Objekterkennung
• raspi167: Client, abhängiger Videorecorder, er muss am Server ins Triggerverzeichnis schauen

Public Key Schlüsselpaar erzeugen

Als Vorarbeit müssen wir am Server im Homeverzeichnis des Users Pi ein verborgenes Verzeichnis mit dem Namen .ssh anlegen. Den Punkt nicht vergessen!

Die Schlüsselgenerierung machen wir dann am Client. Anstelle immer ein Passwort zu gebrauchen, um auf den Server zuzugreifen, generiert der Client einmalig ein RSA-Schlüsselpaar, dessen öffentlichen Teil wir danach auf den Server übertragen werden. Also jetzt eine Terminalverbindung mit dem Client aufnehmen:

ssh pi@raspi167

Dann können wir dort ein Schlüsselpaar erzeugen (dabei den Dateinamen bestätigen und keine Passphrase eingeben):

pi@raspi167:~ $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.
The key fingerprint is:
5f:ff:c4:37:89:13:57:4f:50:c4:04:71:4d:83:a0:ca pi@raspi167
The key's randomart image is:
+---[RSA 2048]----+
|           .. =XB|
|          .  . o+|
|         .      o|
|      . .      .o|
|       ES   ..
|         . . .+..|
|          .  o.o+|
|              .oo|
|                .|
+-----------------+
pi@raspi167:~ $ 

Public Key auf Server übertragen

Wir bleiben am Client angemeldet und übertragen nun den öffentlichen Teil des eben erzeugten Schlüssels auf den Server in das Verzeichnis .ssh, das wir zu diesem Zweck vorher angelegt hatten:

pi@raspi167:~ $ cat ~/.ssh/id_rsa.pub | ssh pi@raspi166 'cat >> .ssh/authorized_keys'

Dabei wird letztmalig noch einmal das Passwort des Servers abgefragt. Nun testen wir die Funktion:

raspi167:~ $ ssh pi@raspi166 ls -l
insgesamt 159560
-rw-r--r--  1 pi   pi      15235 Jul  5 18:05 analyze3.py
-rw-r--r--  1 pi   pi   21080170 Jul 14 10:32 analyze.log
-rw-r--r--  1 pi   pi        953 Jun  7 10:23 freedisk.py
drwxr-xr-x 12 pi   pi       4096 Okt 25  2016 opencv-3.1.0
drwxr-xr-x  5 pi   pi       4096 Dez 17  2015 opencv_contrib-3.1.0
-rw-r--r--  1 pi   pi        312 Mär 26 17:22 postprocess.py
-rwxr-xr-x  1 pi   pi       3385 Mär 26 16:18 record2.py
-rw-r--r--  1 pi   pi       2546 Jul 14 10:27 record.log
drwxr-xr-x  2 pi   pi       4096 Jun 15 12:32 samples
drwxr-xr-x  2 pi   pi       4096 Jul 14 10:26 trigger
drwxr-xr-x  2 pi   pi     880640 Jul 14 10:31 Videos
raspi167:~ $ 

Die Antwort des Servers muss nun kommen, ohne dass ein Passwort verlangt wird.

Wir haben nun eine Public Key Authentifizierung zwischen den beiden Kamera-Rechnern eingerichtet, so dass die untergeordnete Recording-only-Kamera (Client) ohne Passwort auf das Triggerverzeichnis der steuernden Kamera (Server) zugreifen kann. Für den Fall, dass noch weitere Recording-Kameras im Einsatz sind, müssen wir die Schlüsselerzeugung und Übertragung deren Schlüssel auf den Server auf allen vornehmen. Am Server selbst brauchen wir aber kein Schlüsselpaar erzeugen, der Server (also die Kamera mit der Objekterkennung und Triggergenerierung) braucht keinen Zugriff auf die untergeordneten Kameras.

Im übrigen empfehle ich auf dem Desktoprechner ebenfalls ein Schlüsselpaar zu generieren und den Public Key auf alle Raspberries zu übertragen. Damit spart man sich ein für alle Mal die Passwortabfrage und das Verfahren ist äußerst sicher.

Python-Programm für eine Remote-Kamera (recordremote.py)

Nachdem wir nun per SSH einen ls-Befehl auf einem anderen Rechner absetzen können, brauchen wir das nur noch in Python zu programmieren und das bekannte record2.py Programm für die Remotebedürfnisse anpassen:

import os
from datetime import datetime
import io
import picamera
import subprocess


secs_before = 10
video_path = 'Videos/'
trigger_fileextension = '.trg'
trigger_path = 'trigger/'
triggerfile = ''
triggered = False


# Format of trigger file name:          2016-08-26-08-05-00.trg


# Look for remote trigger file
def detect_trigger(camera):
  global triggerfile, triggered
  dir = subprocess.Popen(['ssh','pi@raspi166','ls', trigger_path],
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE,
                         universal_newlines=True)
  try:
    out, err = dir.communicate(timeout=5)
  except subprocess.TimeoutExpired:
    dir.kill()
    out = ""
    err = "Timeout"
  if err != "":
    print("out :{0}: err :{1}:".format(out, err))
# on communication error return current status
    return triggered
  triggerfiles = [f for f in out.splitlines() if f.endswith(trigger_fileextension)]
  if not triggered:
# Not triggered before - look for trigger file
    if triggerfiles:
# Trigger file detected, trim file extension
      triggerfile = triggerfiles[0].split('.')[0:1][0]
      triggered = True
      print('Trigger detected!')
      print(triggerfile)
      return True
    else:
      return False
  else:
# Trigger already active - check whether trigger file ist still present
    if (triggerfile + trigger_fileextension) in triggerfiles:
      return True
    else:
      triggered = False
      return False



with picamera.PiCamera() as camera:
  camera.resolution = (1920, 1080)
  camera.framerate = 25
#  camera.hflip = True
#  camera.vflip = True
  stream = picamera.PiCameraCircularIO(camera, seconds=(secs_before+10))
  camera.start_recording(stream, format='h264')
# Fill ringbuffer
  print('Ready for trigger')
  try:
    while True:
      camera.wait_recording(1)
      if detect_trigger(camera):
# Convert filename to datetime object
        triggertime = datetime.strptime(triggerfile, '%Y-%m-%d-%H-%M-%S')
# Calc seconds to fetch from ringbuffer
        currenttime = datetime.now()
        if triggertime > currenttime:
          triggertime = currenttime
        beforetime = (currenttime - triggertime).total_seconds() + secs_before
        print(beforetime)
# As soon as we detect trigger, split the recording to record the frames "after" trigger
        camera.split_recording(video_path + 'a-' + triggerfile + '.h264')
# Write the seconds "before" motion to disk as well
        stream.copy_to((video_path + 'b-' + triggerfile + '.h264'), seconds=beforetime)
        stream.clear()
# Wait for file to disappear, then split recording back to the in-memory circular buffer
        while detect_trigger(camera):
          camera.wait_recording(1)
        print('Trigger stopped!')
        camera.split_recording(stream)
# Start postprocessing
        print('Connect files')
        postprocess = 'python3 postprocess.py '+video_path+' '+triggerfile+' &'
        os.system(postprocess)
  finally:
    camera.stop_recording()

Dieses Programm recordremote.py entspricht in etwa der lokalen Variante record2.py mit zwei großen Unterschieden:

• Es erfolgt kein sekündlicher Bilderexport, da auf einem Remoterechner keine Bildanalyse durchgeführt wird.
• Die Abfrage des Triggerfiles erfolgt nicht lokal am selben Rechner sondern greift per SSH remote auf die Kamera zu, die Triggerdateien generiert. Die entscheidende Zeile ist diese:

  dir = subprocess.Popen(['ssh','pi@raspi166','ls', trigger_path],
                          stdout=subprocess.PIPE,
                          stderr=subprocess.PIPE,
                          universal_newlines=True)

Mit subprocess.Popen wird ein eigener Linuxprozess auf den Weg geschickt, der den SSH-Befehl (ls)  ausführt. Dazu muss am Programmbeginn subprocess natürlich importiert worden sein. In den darauffolgenden Zeilen werden Fehler und Timeouts abgefangen und als Ergebnis wird der Inhalt des remoten ls-Befehls in der Variablen out stehen, die nun weiterverarbeitet werden kann, um eine eventuelle Triggerdatei zu isolieren.

Alles andere erfolgt genau wie bei record2.py.

Was braucht es noch?

Hardware

Eine Remotekamera, die keine Objekterkennung vornimmt, braucht natürlich auch keinen PIR-Bewegungssensor. Hardwareseitig ist die Kamera also ein Modell 850A.

Betriebssystem

Raspbian wird bei der Remotekamera ganz genauso eingerichtet, wie bei einer Kamera mit Objekterkennung, nämlich so, wie im Artikel zum Betriebssystem beschrieben. Die dort beschriebenen Zusatzmodule bis auf GPIO werden ebenfalls installiert.

Python-Programm für die Video Nachbearbeitung (postprocess.py)

postprocess.py brauchen wir um die beiden Videoteile zusammen zu kopieren und nach MP4 zu wandeln.

Unterverzeichnisse

Die beiden Pythonprogramme recordremote.py und postprocess.py liegen im Homeverzeichnis des Users Pi. Hier brauchen wir noch ein Unterverzeichnis Videos/, in dem die Videodateien abgelegt werden. Ein Unterverzeichnis trigger/ braucht es hier dagegen nicht. Ebensowenig ein Unterverzeichnis samples/ und natürlich auch keine Beilspielbilder zur Farberkennung. Und es ist auch nicht nötig, das /tmp-Verzeichnis in eine Ramdisk zu verschieben.

Autostart und Überwachung

Wie nach einem Boot des Raspbian-Betriebssystems die Pythonprogramme für das Kamerasystem automatisch aktiv werden, habe ich in Teil 13 dieser Serie beschrieben. Selbstverständlich wenden wir das auch auf die Remotekamera an. Der Eintrag in die /etc/rc.local Datei sieht für die Remotekamera wie folgt aus:

# Autostart RaspiCam Remote
cd /home/pi
su pi -c 'python3 -u recordremote.py &> record.log &'

exit 0

Das abschließende exit 0 muss bestehen bleiben.

Den automatischen nächtlichen Reboot und die Überwachung auf Speicherüberlauf, die ich ebenfalls im Artikel Teil 13 beschrieben habe, empfehle ich auch auf die Remotekamera anzuwenden.

Computer Vision brauchen wir nicht

Das spart viel Installationsarbeit – eine Remotekamera braucht kein OpenCV, weil die ganze Farberkennung zentral erledigt wird. Auch auf Matplotlib können wir verzichten.

Zusammenarbeit mehrerer Kameras

Mit recordremote.py haben wir nun ein Programm zur Verfügung, mit dem wir weitere Kameras an eine bereits bestehende zentrale Raspberry Video Cam anhängen können. An der zentralen Kamera mit der Objekterkennung brauchen wir dazu keine Programmänderungen vornehmen. Lediglich dem Betriebssystem müssen wir die öffentlichen RSA-Schlüssel aller Remotekameras bekannt machen. Damit haben wir eine zentrale Kamera, die die Eichhörnchen erkennt und mehrere, die auf das Auslösesignal reagieren und die Szene filmen. Natürlich lässt auch die zentrale Kamera neben der Objekterkennung weiterhin auch die Videoaufzeichnung mitlaufen. So erhalten wir am Ende des Tages von jeder Kamera für jedes Triggerereignis eine Videosequenz. Die können wir dann mit einem Videobearbeitungsprogramm am Desktoprechner schneiden und so immer die Schokoladenseite der Eichhörnchen ins Bild bringen.

---

Weitere Artikel in dieser Kategorie:

• Raspberry Video Camera – Teil 1: Oachkatzl-Cam
• Raspberry Video Camera – Teil 2: Komponenten & Konzepte
• Raspberry Video Camera – Teil 3: Raspberry Pi Kamera Modul V2.1
• Raspberry Video Camera – Teil 4: Aufnahmeauslöser
• Raspberry Video Camera – Teil 5: Passiver Infrarot Bewegungssensor
• Raspberry Video Camera – Teil 6: Stromversorgung
• Raspberry Video Camera – Teil 7: Spannungsregler 5V
• Raspberry Video Camera – Teil 8: Montage Modell 850
• Raspberry Video Camera – Teil 9: Montage Kamera Modul
• Raspberry Video Camera – Teil 10: SW Installation Betriebssystem und Module
• Raspberry Video Camera – Teil 11: SW Python für die Kamera
• Raspberry Video Camera – Teil 12: SW Trigger per Bewegungssensor
• Raspberry Video Camera – Teil 13: SW Autostart und Überwachung
• Raspberry Video Camera – Teil 14: SW Installation Computer Vision (OpenCV 3.2)
• Raspberry Video Camera – Teil 15: SW Einzelbilder exportieren für die Farberkennung
• Raspberry Video Camera – Teil 16: SW Trigger per Farberkennung
• Raspberry Video Camera – Teil 17: Exkurs – Wie Computer Farben sehen
• Raspberry Video Camera – Teil 18: SW Farbkalibrierung
• Raspberry Video Camera – Teil 19: SW Kombinationstrigger
• Raspberry Video Camera – Teil 20: Exkurs – Farbdarstellung per 2D-Histogramm
• Raspberry Video Camera – Teil 21: Konzept einer selbstlernenden Farberkennung
• Raspberry Video Camera – Teil 22: SW selbstlernende Farberkennung in Python
• Raspberry Video Camera – Teil 23: Verbesserung durch ROI und Aufnahmezeitbegrenzung
• Raspberry Video Camera – Teil 24: Anpassung von Programmparametern
• Raspberry Video Camera – Teil 26: Optimierungen gegen Frame Drops
• Raspberry Video Camera – Teil 27: Was kostet der Spaß?
• Raspberry Video Camera – Teil 28: Kamera Modell 200 mit Raspberry Pi Zero
• Raspberry Video Camera – Teil 29: Stromversorgung für Kamera Modell 200
• Raspberry Video Camera – Teil 30: Software für Kamera Modell 200