Raspberry Video Camera – Teil 25: Zweite Kamera

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.


Zur Wahrung deiner Privatsphäre wird erst eine Verbindung zu YouTube hergestelt, wenn du den Abspielbutton betätigst.

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:

12 Kommentare

  1. niwu

    Hallo

    ich ahbe mein System angepasst ,
    nutze inzwischen deine version und eine abgewandelte.
    beide funktionieren klasse

    danke erstmal.

    Idee:: Für die Nutzung zum Tierfilmen und Fotographie.

    in der Nacht. Alles nutzen ohne opencv,
    und dann als Gegenkamera mit recordremote.py nutzen. letzte Nacht versucht.
    geht klasse.

    Antworten
  2. Niwu

    Hallo

    Viele test gemacht, nun kommt das

    Ok .
    1. option , da wlan alles ist. Connect problem
    2. Option , gute frage.

    pi@nightwatch:~ $ python3 /media/usbdisk/home/pi/scripte/trigger/bin/recordremote.py Ready for trigger
    Trigger detected!
    2017-08-09-19-03-52
    18.069679
    Traceback (most recent call last):
    File „/media/usbdisk/home/pi/scripte/trigger/bin/recordremote.py“, line 88, in
    stream.copy_to((video_path + ‚b-‚ + triggerfile + ‚.h264‘), seconds=beforetime)
    File „/usr/lib/python3/dist-packages/picamera/streams.py“, line 758, in copy_to
    output = io.open(output, ‚wb‘)
    FileNotFoundError: [Errno 2] No such file or directory: ‚Videos/b-2017-08-09-19-03-52.h264‘
    pi@nightwatch:~ $

    Antworten
    1. Helmut (Beitrag Autor)

      Prüfen Sie mal das Verzeichnis „Videos“

      Antworten
  3. niwu

    Hallo

    ich habe mal durchgeprüft.

    so wie es ausseiht gibt es ein miniproblem.

    meine Verzeichnis auf dem Master Raspi liebt /medis/usbdisk/ usw.
    Ich habe ein Symlink gemacht und da scheit das problem zu liegen

    user und gruppenrecht sind sauber in home und usb

    client Raspi

    in der recordmemote.py wollte ich anpassen

    video_path = ‚/media/usbdisk/usw /Videos/‘
    trigger_fileextension = ‚.trg‘
    trigger_path = ‚/media/usbdisk/usw /trigger/‘

    und das funktioniert nicht

    den Pfad für homedirek. für pi umschreiben. mag ich ja nicht so ;)

    evtl noch eine idee

    auf dem master raspiwerden die Filme direkt ind /media/usbdiskusw/videos abgelegt

    Antworten
    1. Helmut (Beitrag Autor)

      Da kann ich nur empfehlen, mit der original recordremote.py zu starten. Wenn das läuft können Sie Schritt für Schritt versuchen Ihre eigenen Anpassungen zu implementieren. Dann findet sich der Fehler sicher leicht.

      Antworten
  4. niwu

    HI

    klar , werde auch meiner Erfahrungen an dich weitergeben. was wie wo.
    Bin ja ein grosses Raspispielkind. ;)

    aber wenn dann ganz groß

    4×2 Raspicam ( 1x tag +1 x NOPIR) an jeder Ecke meines Grundstückes.
    jeder raspi mit PIR sensor ;)
    als Rundumüberwachung:) großtest

    was da rauskommt , kann ich nicht sagen.

    wenn irre dann ganzirre

    Antworten
  5. niwu

    Hallo mein erster ZwischenBericht

    2 Raspi
    1. cappa server , gestartet mit record2.py und motioninterrupt ohne cv
    2. cappa01 cleint , remoterecord.py & post**
    beide über wlan verbunden

    cleint per ssh verdunden

    doch beim auslösen des PIR schreibt nur server file a & b
    client schreibt kein File

    Beim starten des remoterecord

    kommt
    Ready for trigger

    aber keine Anzeige das er aktiviert ist. wie motion start oder sonstiges

    Habe auf Server im Homeverzeichnis den ordner Videos angelegt
    dort liegt nichts drin

    beim ssh pi@cappa ls -l trigger
    insgesamt 0

    ich habe den verdacht das bei Wlan nutzung irgend was hängt
    ggf nuss es über lan Kabel laufen

    ist es nicht besser wenn auch die Auslösung beim Client auf PIR reagiert ?

    Gedankengang : aufstellung der Raspicam im V format
    links ( client) vom V recht Server
    kommt tier von links löst client per PIR aus beide zeichnen auf
    kommt tier von rechts standart

    ggf. auch eine doofe IDEE

    Antworten
    1. Helmut (Beitrag Autor)

      Welche Kamera triggert und welche davon abhängig aufzeichnet, oder ob evtl. jede Kamera einen eigenen Trigger haben sollten, das kommt immer ganz auf den Anwendungsfall an. Mit geht es darum, bei jedem Triggerereignis zwei gleichzeitige Videos zu erhalten. Die müssen dann von Hand von den beiden Kameras abgeholt werden und auch von Hand geschnitten. Aber wie gesagt, das hängt immer vom Anwendungsfall ab.

      Antworten
  6. niwu

    Nachtrag zu meinem obrigen

    also per Lan

    slave

    pi@slave01:~ $ python3 -u recordremote.py &> record.log &
    [1] 1831
    pi@slave01:~ $ !tail
    tail -f record.log
    Ready for trigger
    Trigger detected!
    2017-08-18-12-44-19
    16.296832
    Trigger stopped!
    Connect files
    Appending file Videos/b-2017-08-18-12-44-19.h264
    No suitable destination track found – creating new one (type vide)
    Appending file Videos/a-2017-08-18-12-44-19.h264
    Saving Videos/2017-08-18-12-44-19-slave01.mp4: 0.500 secs Interleaving

    Jedenfalls erstellt er jetzt erstmal pro Client auch ein Video
    leider kein gemeinsames.

    aber sonst OK, also per Wlan sieht es schlecht aus mit einer Dauerverbindung

    Antworten
    1. Helmut (Beitrag Autor)

      Wenn ich Sie richtig verstehe, dann funktioniert es wenn beide Kameras am LAN hängen. Wenn sie per WLAN verbunden sind, dann funktioniert es nicht. Das kann ich mir nicht ganz vorstellen, da Sie ja von Hand per ssh auch per WLAN auf das Triggerverzeichnis zugreifen können. (Antwort: „insgesamt 0“). Die Verbindung sollte also schon da sein. Recordremote.py sollte auch Fehler rausschreiben, wenn die Kommunikation mit dem anderen Gerät fehlschlägt, wie hier in der zweiten Zeile:
      Ready for trigger
      out :: err :Timeout:
      Trigger detected!
      2017-08-18-06-08-24
      14.258094
      Trigger stopped!
      Connect files
      Appending file Videos/b-2017-08-18-06-08-24.h264
      No suitable destination track found - creating new one (type vide)
      Appending file Videos/a-2017-08-18-06-08-24.h264
      Saving Videos/2017-08-18-06-08-24-raspi167.mp4: 0.500 secs Interleaving

      Haben Sie denn auch am Client ein Verzeichnis Videos angelegt? Sie schreiben nur vom Server.

      Antworten
  7. niwu

    Hallo Helmut,

    klar so sehe ich das auch.

    Feststellung, wenn ein Wlan unter speed von 10 MBit liegt
    kommt fehler : => out :: err :Timeout:

    Alles über 10 MBit kein Problem.

    Wenn der Speed unter 10 MBit liegt, dann den Router einfach mal 1-2 Meter näher an des Raspi ran.

    Läuft

    Timeout: erledigt

    Antworten
    1. Helmut (Beitrag Autor)

      Dann geht WLAN jetzt bei Dir und es hat nur an der schwachen Verbindung gelegen? Du hattest doch keine Timeouts, als es nicht gegangen ist. Na egal, Hauptsache es funktioniert jetzt.

      Antworten

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert