(Insect Detect) config.yaml

Aus TippvomTibb
Version vom 16. November 2025, 08:38 Uhr von Chris T. Ludwig (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Allgemeines

Ich habe ich mir mal hier alles zusammengetragen, was ich zum Manipulieren und Verstehen der config.yaml benoetige.

Bei Github werden 3 verschiedene yaml-Dateen bereitgestellt.

  • config_custom.yaml
  • config_default.yaml
  • config_selector.yaml

Code Analyse

ChatGPT meint:

Was ich aber tun kann: dir sauber erklären, wie die drei Dateien im Projekt gedacht sind und wie sie sich strukturell / funktional unterscheiden – also quasi eine „Konzept-Diff“-Tabelle statt eines Zeilen-Diffs.



Rolle der drei Dateien im Insect-Detect-Setup

Aus README, Installer-Script und Doku geht folgendes hervor: (GitHub)

  • config_default.yaml

    • Wird vom Projekt als Basis-/Werkskonfiguration mitgeliefert.
    • Enthält alle Parameter mit „vernünftigen Standardwerten“ (Model, Auflösungen, Trigger-Intervalle, Speicherpfade, Power-Settings etc.).
    • Wird nicht vom Web-UI überschrieben; dient eher als Vorlage/Referenz.
  • config_custom.yaml

    • Ist die benutzerdefinierte aktive Konfiguration, die du entweder:

      • direkt per Editor, oder
      • über die WebApp bearbeitest.
    • Wird vom Installer explizit erwähnt:

      „Use the web app to configure your custom settings… or modify the insect-detect/configs/config_custom.yaml file directly.“ (GitHub)

    • Beim Start von trigger_capture.py / startup.py werden diese Werte genutzt.

  • config_selector.yaml

    • Dient als „Zeiger“ auf die aktive Config.

    • Laut README kannst du „mehrere Konfigurationsdateien generieren“ und „die aktive Config entweder über die Web-App oder durch Ändern von config_selector.yaml auswählen“. (GitHub)

    • Vermutlich enthält sie nur so etwas wie:

      active_config: config_custom.yaml
      

      oder alternativ einen Namen / Pfad zu deiner bevorzugten Konfiguration.



Vergleich in Tabellenform (funktionale Unterschiede)

Achtung: Keine exakten Zahlen/Parameter, sondern funktionale/unstrukturelle Unterschiede, weil ich den Inhalt nicht laden kann.

Aspekt config_default.yaml config_custom.yaml config_selector.yaml
Zweck Werks-/Standardkonfiguration des Projekts Deine anpassbare, aktuell verwendete Konfiguration Wählt aus, welche Konfigurationsdatei aktiv ist
Wer schreibt die Datei? Projekt-Autor (Repo) Du bzw. die WebApp Du / WebApp
Wird vom Installer/Web-UI geändert? Normalerweise nein (soll unangetastet bleiben) Ja – Haupteintragspunkt für Custom-Settings Ja, wenn du das aktive Profil umschaltest
Typische Inhalte Vollständiger Satz aller Parameter mit Standardeinstellungen (z. B. Pfade, Trigger-Intervalle, Timer, Kamera-Auflösung, Model-Pfad, Power-Management, Upload, Logging) Gleiche Struktur wie config_default.yaml, aber mit deinen geänderten Werten (z. B. anderes Model, andere Intervallzeiten, anderer Output-Pfad etc.) Wenige Schlüssel: z. B. active_config: config_custom.yaml oder Name eines Profils
Wird direkt vom Capture-Script benutzt? (trigger_capture.py) Indirekt (nur als Vorlage, wenn du config_custom danach modellierst) Ja, ist die eigentliche Runtime-Config Indirekt – das Startup-/WebApp-Logik liest sie, um zu wissen, welche Config geladen werden soll
Rolle im Workflow Referenz, um jederzeit „zurück auf Werkseinstellungen“ gehen zu können Tagesgeschäft: alle deine echten Einstellungen landen hier Profilumschalter: gibt an, welche YAML aktuell „aktiv“ ist
Risiko bei Bearbeitung Wenn du sie änderst, verlierst du die Standardwerte als Referenz Hier sollst du ändern – genau dafür ist sie da Falscher Name/Pfad → System findet aktive Konfig nicht (Fehler beim Start)



Praktische Konsequenz für dich

  1. Wenn du wissen willst, was vom Projekt „normal“ vorgesehen ist: → Schau in config_default.yaml.
  2. Wenn du wissen willst, was deine Kamera derzeit wirklich macht: → Schau in config_custom.yaml (das ist die „Wahrheit zur Laufzeit“, sofern config_selector.yaml darauf zeigt).
  3. Wenn du mehrere Profile nutzen willst (z. B. unterschiedliche Standorte, Modelle):
    • Lege mehrere config_*.yaml an (z. B. config_meadow.yaml, config_forest.yaml).
    • In config_selector.yaml stellst du jeweils den Namen/Pfad des aktiven Profils ein.
    • Oder du nutzt die Web-App, die das für dich umschreibt.



Parameterliste

Ich gehe die Datei Abschnitt für Abschnitt durch und erkläre dir, was jeder Eintrag praktisch bewirkt – also, woran das Programm sich dabei orientiert.



deployment: – Metadaten zum Einsatz

Reine Beschreibungsdaten, wichtig für spätere Auswertung, aber nicht für die Technik selbst.

  • deployment.start Zeitpunkt, ab dem der Kameraeinsatz beginnt (ISO-8601, z. B. 2025-05-12T08:30:00). → Dient der Dokumentation im Datensatz.
  • deployment.location.latitude / longitude GPS-Koordinaten des Standorts (Dezimalgrad). → Wird in Metadaten abgelegt (z. B. für Karten, Studien).
  • deployment.location.accuracy Genauigkeit der Position in Metern. → Info für spätere Auswertungen (wie präzise ist der Standort?).
  • deployment.setting Freitext zur Umgebung (z. B. „Blühstreifen, Phacelia“ / „Gelbe Schale“).
  • deployment.distance Abstand in cm von Kamera zum Hintergrund (Blüte/Plattform). → Wichtig, um Größen/Skalierung der Insekten im Bild einordnen zu können.
  • deployment.notes Freitext für Feldnotizen (Wetter, Besonderheiten, Aufbau, etc.).



camera: – Kameraeinstellungen für HQ-Bilder

  • camera.fps Bildrate der Kamera (1–30 fps). → Höhere fps = mehr Stromverbrauch, aber mehr Bilder pro Zeit.
  • camera.resolution.width / height Auflösung der aufgezeichneten HQ-Frames (z. B. 3840×2160).
    • Muss bestimmte Vielfache einhalten (Performance/Kompatibilität). → Bestimmt Dateigröße, Schärfe, Crop-Auflösung usw.
  • camera.jpeg_quality JPEG-Qualität der gespeicherten HQ-Bilder (0–100). → Höher = bessere Qualität, aber größere Dateien.

Fokus

  • camera.focus.mode Fokusmodus:
    • continuous: Kamera fokussiert automatisch dauerhaft
    • manual: fester Fokus (über distance oder lens_position)
    • range: Autofokus nur in einem Bereich
  • camera.focus.type Wie „manuell“/„range“ interpretiert werden:
    • distance: Fokus über Distanz in cm
    • lens_position: direkt über Linsenmotorposition (0–255)
  • camera.focus.distance.manual Zielentfernung in cm bei manueller Distanz-Fokussierung.
  • camera.focus.distance.range.min / max Minimaler und maximaler Fokusabstand (cm) im range-Modus.
  • camera.focus.lens_position.manual Feste Linsenposition bei type: lens_position im manuellen Modus.
  • camera.focus.lens_position.range.min / max Unterer/oberer Bereich der Linsenposition für range-Modus.

ISP (Image Signal Processor)

  • camera.isp.sharpness Schärferegler (0–4). → 0 = weniger Schärfungsartefakte, 4 = stärker nachgeschärft.
  • camera.isp.luma_denoise Luminanz-Rauschunterdrückung (Helligkeitsrauschen). → 0–4, mehr = glatteres Bild, aber evtl. Detailverlust.
  • camera.isp.chroma_denoise Farbrauschunterdrückung. → Ähnliches Prinzip wie oben.



detection: – Objekterkennung (Insekten)

  • detection.model.weights Dateiname des YOLO-Modell-Blobs im models-Ordner (OpenVINO formatiert).
  • detection.model.config Passende JSON-Konfig-Datei zum Modell (Labels, Anker, etc.).
  • detection.resolution.width / height Größe der LQ-Frames, die an das Modell geschickt werden (z. B. 320×320). → Bestimmt Rechenaufwand & Genauigkeit.
  • detection.conf_threshold Mindest-Konfidenz für eine Erkennung (0–1). → Höher = weniger, aber sicherere Detections.
  • detection.iou_threshold Intersection-over-Union-Schwelle (NMS). → Steuert, wann überlappende Boxen als duplikat zusammengefasst werden.
  • detection.exposure_region.enabled Wenn true: → Die erkannte Insekten-Box wird benutzt, um die Auto-Belichtung auf diesen Bereich zu fokussieren (Kamera passt Belichtung bevorzugt auf das Insekt an).



recording: – Aufnahmedauer & Intervall

Dauer (Sitzungslänge)

  • recording.duration.battery.high / medium / low / minimal Sitzungslängen (in Minuten) in Abhängigkeit vom Batteriestand (wenn Powermanager aktiv ist):
    • high: >70 % Akku
    • medium: 50–70 %
    • low: 30–50 %
    • minimal: <30 % → Steuert, wie lange eine Aufnahme pro Durchlauf läuft, je nach Restenergie.
  • recording.duration.default Sitzungsdauer (Minuten), wenn kein Powermanager verwendet wird (powermanager.enabled: false).

Aufnahmeintervalle

  • recording.capture_interval.detection Abstand (Sekunden) zwischen gespeicherten HQ-Frames während ein Objekt erkannt wird. → z. B. 1 s = jede Sekunde ein Bild, solange Insekt im Bild.
  • recording.capture_interval.timelapse Abstand (Sekunden) zwischen Time-Lapse-Aufnahmen unabhängig von Detections. → z. B. 600 s = alle 10 Minuten ein Bild, auch ohne Insekten.

Shutdown

  • recording.shutdown.enabled Wenn true: Raspberry Pi wird nach Ende/Abbruch einer Sitzung heruntergefahren. → Wichtig für Batteriebetrieb und Dateisicherheit.



post_processing: – Nachbearbeitung der Bilder

  • post_processing.crop.enabled Wenn true: → Es werden aus den HQ-Bildern Ausschnitte der Detections (Bounding Boxes) als eigene JPEGs gespeichert.
  • post_processing.crop.method
    • square: Quadratische Ausschnitte um die Box
    • original: exakte Boxform → beeinflusst Form/Größe der Crop-Bilder.
  • post_processing.overlay.enabled Wenn true: → Es wird eine Kopie des HQ-Bildes mit eingezeichneten Boxen/Labels/Confidence/Track-ID erstellt.
  • post_processing.delete.enabled Wenn true: → Originale HQ-Bilder mit Detektionen werden nach erfolgreichem Crop/Overlay gelöscht (Platz sparen). → Geht nur sinnvoll, wenn crop oder overlay ebenfalls aktiv sind.

Archivierung

  • archive.enabled Wenn true: → Daten (Bilder, Metadaten, Logs, Configs) werden zu Archivpaketen (uncompressed zip-Ordner) zusammengefasst und ggf. ältere gelöscht, um Speicherplatz zu managen.
  • archive.disk_low Untergrenze freier Speicherplatz (MB). → Wird diese unterschritten, reguliert das Archiv-Management die Daten (alte löschen/verschieben).

Upload

  • upload.enabled Wenn true: Archivierte Daten werden zu einem Cloud-Speicher hochgeladen (per rclone o. ä.). → Triggert Archivierung sogar, wenn archive.enabled eigentlich false ist.
  • upload.content Welche Inhalte hochgeladen werden:
    • all: alles
    • full: nur volle HQ-Bilder + Metadaten
    • crop: nur Crops + Metadaten
    • timelapse: nur Time-Lapse + Metadaten
    • metadata: nur Metadaten



startup: – Verhalten beim Boot

Diese Einstellungen werden von startup.py genutzt (systemd-Service nötig).

  • startup.hotspot_setup.enabled Wenn true: Falls es den Hotspot noch nicht gibt, wird ein RPi-WLAN-Hotspot angelegt (SSID & Passwort aus network.hotspot).
  • startup.network_setup.enabled Wenn true: Alle Wi-Fi-Netzwerke aus dem network.wifi-Block werden in NetworkManager eingetragen/aktualisiert (inkl. Hotspot).
  • startup.auto_run.enabled Wenn true: Nach dem Boot werden automatisch Python-Skripte gestartet.
  • startup.auto_run.primary Name des ersten Skripts (z. B. webapp.py), das im Verzeichnis insect-detect laufen soll.
  • startup.auto_run.fallback Name des Fallback-Skripts, das gestartet wird, wenn das primäre nach einer gewissen Zeit beendet wird oder fehlschlägt (kann leer bleiben).
  • startup.auto_run.delay Wartezeit (Sekunden), bevor das Primärskript gestoppt und ggf. der Fallback gestartet wird.



webapp: – Einstellungen für die Web-Oberfläche

Steuert die Preview-Streaming-Parameter, nicht die Aufzeichnung.

  • webapp.fps Bildrate des gestreamten Kamerabilds in der WebApp.
  • webapp.resolution.width / height Auflösung der gestreamten HQ-Frames für das Web-UI (nicht identisch mit Aufnahme-Auflösung).
  • webapp.jpeg_quality Qualität (0–100) der JPEG-Frames im Stream. → Höher = schärfer, aber mehr Bandbreite.
  • webapp.https.enabled Wenn true: WebApp läuft über HTTPS. → Voraussetzung, damit z. B. der Geolocation-API im Browser vertraut wird (GPS-Koordinaten per Browser).



powermanager: & Co. – Systemverhalten

Powermanager

  • powermanager.enabled Wenn true: Es ist ein Power-Management-Board vorhanden, und dessen Werte werden genutzt.
  • powermanager.model Typ des Boards:
    • wittypi oder pijuice.
  • powermanager.charge_min Minimaler Batteriestand (%) zum Starten/Fortsetzen einer Aufnahme.
  • powermanager.charge_check Intervall (Sekunden) für erneute Batteriestandsprüfung während der Aufnahme.

OAK (Kamera/AI-Board Temperatur)

  • oak.temp_max Maximale zulässige OAK-Chiptemperatur (°C). → Wird dieser Wert überschritten, kann die Aufnahme beendet/abgebrochen werden.
  • oak.temp_check Zeitintervall (Sekunden) zwischen Temperaturmessungen.

Speicher

  • storage.disk_min Minimal benötigter freier Speicher (MB), um zu starten/weiterzumachen.
  • storage.disk_check Intervall (Sekunden) zwischen Speicherplatzprüfungen.

LED

  • led.enabled Wenn true: Eine Status-LED an einem GPIO-Pin wird verwendet (z. B. in einem Taster).
  • led.gpio_pin GPIO-Pin-Nummer, an dem die LED hängt (BCM Nummerierung, Auswahl aus Liste).

Logging

  • logging.enabled Wenn true: Systeminformationen (Temperatur, RAM, CPU, Akku) werden regelmäßig geloggt.
  • logging.interval Intervall (Sekunden) zwischen Log-Einträgen während der Aufnahme.



network: – Netzwerkkonfiguration

  • network.mode
    • wifi: Verbinde dich mit bekannten WLANs, nutze Hotspot nur als Fallback.
    • hotspot: Fokus auf Hotspot-Modus (aber mit Fallback-Logik).
  • network.hotspot.ssid / password SSID & Passwort für den RPi-Hotspot. Passwort muss mind. 8 Zeichen haben.
  • network.wifi (Liste) Liste von WLAN-Netzen mit:
    • ssid
    • password Reihenfolge = Priorität (das erste Netz hat höchste Autoconnect-Priorität.