das oben schon erwähnte imagemagick hat auch eine annotate-Funktion, welche dafür verwendbar ist. Wenn also dies tool ohnehin eingesetzt wird, ließe sich das verbinden
wegen stream-Verarbeitung (bzw. Standbilder aus streams) sicher komfortabler ist gstreamer. Dort gibt es für “selbstvergebenen” timecode (also keine externe Stringenz wie bei SMPTE-timecode) die Funktionen clockoverlay und timeoverlay. Beide lassen sich umfangreich konfigurieren (timeoverlay, clockoverlay )
gstreamer für RaspberryPi kennt als Kameraquelle rpicamsrc (rpicamsrc), und diese wiederum hat eine property annotation-mode, nicht ganz so flexibel wie timeoverlay, aber immerhin lassen sich auch date und time auswählen
source und sink müssen natürlich für das Zielsystem angepaßt werden. Für webcams unter Linux ist source dann meist v4l2src (oder libcamerasrc oder eben die rpicamsrc); für die Senke werdet ihr sicher filesink verwenden wollen.
Läuft der Timecode aus Datum und Uhrzeit dann klaglos bei den Einzelbildern einer Zeitrafferaufnahme immer mit?
Also ist beim anhalten des Films dann immer die korrekte Zeit im Standbild enthalten?
Oder kann es durch Stromausfälle und andere technische Probleme dann dazu kommen, dass die falsche Zeit im Standbild angezeigt wird?
Mein Gefühl ist, dass die richtige Wahl für uns eine Python-App wird, die regelmäßige Fotoaufnahmen durch picamera2 macht, und sie als Numpy-Arrays durch PIL und OpenCV verwaltet, und als sogenannte Daemon-Process läuft. Ich werde meinen Quellcode in ein paar Tage per Github teilen.
picamera2 erlaubt uns, Einstellungen wie Autofokus, HDR usw. gelegentlich zu verwalten, die vorher nur durch die libcamera Command-Line-Tool erreichbar waren, und wenn wir die Bilder nativ als Numpy-Daten verwalten, haben wir dann komplette Freiheit in Dingen wie Timestamps.
Eigentlich, aus Sicht der zukünftigen KI-Trainings, finde ich es am besten, statt den Bildern irgendwie zu verändern, ein schwarzes Informationsband hinzuzufügen, mit Annotationen wie Timestamp, BOBCam-Nummer. (Vielleicht auch andere Messwerte wie Temperatur, wenn wir die in der Zukunft auch erfassen werden.) Damit können wir, wenn es Zeit ist, ein KI-Modell zu trainieren, die Informationsbänder automatisch und ohne Mühe abschneiden.
gstreamer wäre vielversprechend, wenn wir eine Live-Kamera-Funktion über http einbauen wollten; es klingt theoretisch gut, aber dafür brauchten wir ständige Beleuchtung, was nicht so gut für die Bienen (oder den Stromverbrauch) wäre.
Ich habe es trotzdem vor, einen einfachen Webserver in die App einzubauen, damit man das letzte Bild von den eigenen Nistboxen über das lokale Netzwerk oder eine VPN / Meshnetzwerk-Lösung wie Nebula beobachten kann. Das ist natürlich ein bisschen weiter entfernt; zuerst möchte ich die Python-App mit der Erkennung von Bildänderungen fertig haben und teilen.
Hallo Hartmut,
Die Raspberry Pi 3 hat keinen Real-Time-Clock-Akku, also kann ohne Stromversorgung die Uhrzeit nicht folgen. Das ist für uns jedoch kein wirkliches Problem, weil alle Nistboxen einen Internetzugang haben, und die Pis ihre Uhren beim Start über das Internet synchronisieren. Also als die ersten Bilder gemacht werden, ist die Uhrzeit schon idealerweise korrekt.
picamera2 kannte ich bisher nicht, das sieht ja wirklich aus wie eine ausgewachsene Bibliothek. Sie haben ja sogar ein Beispiel für ein overlay per cv2.putText() in ihrer doku! ,)
Mein gstreamer-Vorschlag kam nur, da ich nicht wußte, welche sw die Bildverarbeitung-Objekte und -primitives zur Verfügung stellt. Aber mit PIL in Python und erst recht OpenCV hast Du alles Wünschenswerte bereits in der Hand. Und wenn Du dann noch die Bilddaten als arrays in NumPy verarbeiten willst… sehr schön, dann kann ich da nichts mehr helfen! :)
gstreamer kann auch mit stills umgehen, wenngleich das wirklich nicht dessen Hauptdomäne und es deshalb etwas umständlich ist; egal, ist hier erstmal abgewählt.
“Idealerweise” (:
Das kann tricky werden: so ein ntpd braucht auch mal länger, bis nach einer aufgebauten (Weitverkehrs-)Netzwerkverbidung der daemon die Referenz-Uhr(en) erfolgreich erreichen und die Systemzeit setzen konnte; im schnellsten Fall hat der access router für den RasPi einen ntpd sowie dessen server und propagiert das per DHCP seinen lokalen clients. Das kann man aber erstmal nicht voraussetzen.
Ich sehe zwei Möglichkeiten, etwas wie “1970-01-01” (oder so) zu vermeiden:
ntpd (resp. chrony) beherrscht hotplug-events. dbus im RasPi-Debian z.B. kann events wie ‘time steps’ oder stratum-Änderungen bedienen, sowas kannst Du per python zur Bedingung machen, die Systemzeit davon zu stellen. - So macht OpenWRT das z.B per shell: https://github.com/openwrt/packages/blob/master/net/ntpd/files/ntpd.hotplug-helper
Außerdem ist je nach distro entweder ntpd oder chronyd der Kandidat. - Es gibt ein panic-override (-g), wenn mehr als 1000 Sekunden offset sind, das (sowie einiges die Systemzeit betreffend) braucht root-Rechte.
Wir müssen zuerst noch Hardware-nahe Probleme lösen. Von den 6 Kameras, die ich in der letzten Woche nach Hannover gebracht habe, funktioniert eine nicht mehr.
Ausserdem haben wir nur von Direns Kamera Bilder von Wildbienenbrut, Hartmuts Kamera hatte nur Schlafgäste, meine hatte keinen Besuch. Da können wir noch nicht viel auswerten und eine KI trainieren.
Trotzdem können wir überlegen, wie wir noch bessere Bilder hinbekommen und ob wir noch mehr aus der Raspicam herauskitzeln können. Vor allem, ob es sich lohnt, in die IR-Beleuchtung zu investieren. Die Bilder werden nie so wie die mit gelben Licht. Erst wenn man häufig Bilder macht, kann das gelbe Licht stören. Wenn man z.B. Bewegungen erkennen will, ist die geringere Auflösung der IR-Aufnahmen ein Problem.
Das Zeitproblem ist nicht da, da die Kamera stabil mit Wlan verbunden ist, sonst kann man auch keine Bilder in die NextClout senden. Die Zeit ist also immer aktuell, da sorgt des PiOs schon dafür.
Inzwischen habe ich einmal reihum bei alle vier Nisthilfen (#3, #4, #1 und #2) mehrfach die CO2-Konzentrationen gemessen. Hinweis: Der flache H-MF Stapel zwischen den Nisthilfen #3 und #4 ist in die CO2-Betrachtungen nicht eingebunden.
Im folgenden Diagramm sind die Ergebnisse zusammengefasst. Der längste Balken zeigt die schon berichteten CO2-Werte der Röhrchen-Nisthilfe aus dem Graphen weiter oben vom 28.04.2025. Am Balkenende ist das Gewicht des jeweiligen Nestinhalts vermerkt.
Zur Steigerung der Empfindlichkeit habe ich die Öffnung am Messbehälter reduziert und dann für 8 Stunden eine Nachtmessung durchgeführt. Die MIN/MAX-Werte dieser Nachtmessung mit teiloffenem Messbehälter sind im Balken-Diagramm gelb-grün dargestellt.
Trotz der um Mitternacht eher niedrigen Temperaturen (MW=10,19 °C) gibt es mit teiloffenem Messbehälter ein deutliches Nutzsignal für die CO2-Detektion (MW=992 ppm). Zu berücksichtigen ist allerdings, dass unter den gegebenen Bedingungen ca. 320g Nestinhalt verfügbar war. D.h. aber auch, bei meinen beiden Brettchen-Stapel (#4, ‚#1) halte ich eine CO2-Detektion, bei den derzeit geringen Nestinhalten und mit teiloffenem Messbehälter, so nicht für zielführend.
hier auch noch mal ein Update von meiner Nistmöglichkeit.
Die Ameisen hatten ja einiges an Verwüstung angerichtet. Schließlich hat mir Ute ungereinigte Schafswolle zugeschickt. Außerdem hatte ich inzwischen Zeit eine neue Halterung zu schweißen, die hoffentlich Ameisensicher ist.
Bitte verzeiht mir alle die lange Abwesenheit, ich hatte die Hände voll mit meinem Privat- und Arbeitsleben.
BOBCam10 ist seit Mitte Juli aufgestellt, aber leider sind noch keine Bienen eingezogen. Die Standort ist im 4. Stock eines Berliner Wohnhauses, Hof, Richtung westlich. Ich muss auch noch mal nach dem Standort, um die Nistbox zu reparieren: Die Nistplatte ist irgendwie plötzlich nach hinten geschoben. Mein Gastgeber hat sie letzte Woche abgenommen und wieder aufgesetzt, also vielleicht ist es dadurch passiert.
Der Softwarestack BOBCam-App-II ist endlich funktionsfähig. Ich hatte über die letzten paar Wochen Zeit, um das Debugging und Testing durchzuführen, und jetzt ist alles auf GitHub veröffentlicht:
Ich kann also alle Fotos mit den gleichen Kameraeinstellungen machen (HDR, kein Autofokus, Bildzuschnitt).
Infrarotbilder sind im Graustufenformat verarbeitet, aus dem R-Kanal der Kamera.
Die Änderungsdetektion über Infrarotbilder scheint gut zu funktionieren und dauert weniger als eine Sekunde auf dem Raspberry Pi 3. Die direkte Sonne bei wolkigem Wetter kann zu Falschpositiven führen, aber bisher scheint es kein großes Problem zu sein.
Wenn Änderungen vorhanden sind, macht das Programm auch Vollfarbbilder mit Didis Gelblicht-Flash durch den Neopixels.
Es ist konfigurierbar, wie häufig wir Vollfarbbilder erlauben, damit wir die Bienen nicht zu viel mit Gelblicht stören.
Alle Bilder sind mit einem Zeitstempel versehen, der später für KI-Training einfach entfernbar wird.
Ein Infrarotbild (siehe das Problem mit der Platte xD):
Nun ist die Saison vorbei und wir wollen heute abend auf der Zoom-Konferenz beraten, wie es weitergeht. Von den 10 BOBCamxx gab es leider nur wenige gute Bilder. Nur von Direns Kamera gibt ein brauchbares Video. Die anderen waren nicht besiedelt, oder sind teilweise oder ganz ausgefallen.
Folgende Punkte sind mir aufgefallen:
1 - Das Nistbrettchen sollte von vorne austauschbar sein, ohne den Kasten zu öffnen
2 - Die Stromversorgung sollte über ein 5 m langes Kabel funktionieren
3 - Die Einbindung ins lokale WLAN ist zu kompliziert
4 - Die Software ist nicht stabil und verbesserungswürdig
5 - Das Handling ist zu aufwändig .
6 - Die IR-Beleuchtung wird kaum benötigt und macht Probleme bei der Stromversorgung.
Es kann also noch viel verbessert werden.
Ein Kollege aus Münster beobachtet Insekten ( Hornissen ) mit einer Blink-Überwachungskamera.
Ich habe an einer Vogelfutterstelle schöne Bilder von Vögeln, Eichhörnchen und Katzen mit einer solchen Kamera gemacht. Ich benutze insgesamt 7 Kameras von Blink seit fast 4 Jahren.
Deshalb habe ich mir eine Blink Mini 2 gekauft und Testbilder vom Nistbrettchen und von vorne gemacht. Durch den Weitwinkel erscheint das Bild etwas verzerrt, aber die Technik ist ausgereift und ist von Laien bedienbar. Die Bilder sind dann auf dem Handy in einer App sichtbar und werden in der Blink-Cloud gespeichert ( Abo )
Wir müssten noch sehr viel programmieren, um mit den RaspberryPi Cam 3 da mithalten zu können.
Zum Video des Rotkehlchens :
Es ist eins von über 10000 in ca . 3 Jahren. Man muss also immer nachschauen, ob was Gutes dabei ist.
Wenn die BOBCam 100 Bilder am Tag macht, muss man auch viel kontrollieren.
Ich denke wir brauchen da schon eine automatisierte Lösung, Filterung möglichst schon auf den Gerät (on the edge) damit nicht zu viel übertragen werden muss. Das war ja u.a. auch der Grund für den RasPi mit Kamera, damit der das gleich machen kann.
Ansonsten gibt es auch Überwachungskameras, die nur bei Bewegung Videos / Bilder schicken, die sind noch relativ “dumm”. Einige können schon nach Bildmaterial mit Personen vs. anderes unterscheiden, aber es gibt da keine eingebaute “Wildbienen-KI” o.ä. daher denke ich, dass RasPis mit Kamera schon noch immer ein guter Weg sind.
