Mono-Vision für ein autonomes Fahrzeug

Abb. 1: Basler GigE Vision System

Autor:	Nils Koch
Modul:	Projektarbeit, MTR-B-2-6.01
Starttermin:	29.01.2024
Abgabetermin:	20.08.2025
Prüfungsform:	Modulabschlussprüfung als Hausarbeit (Praxisbericht, Umfang 30-50 Seiten Textteil)
Betreuer:	Prof. Dr.-Ing. Schneider, Tel. 806
Mitarbeiter:	Marc Ebmeyer, Tel. 847

Einführung

Für das SDE Praktikum werden drei autonome Fahrzeuge im Maßstab 1:10 aufgebaut. Zwei davon verfügen bereits über dieselbe Kamera (VR Magic VRmDC). Da diese nicht mehr lieferbar ist, wird das dritte Fahrzeug mit einer Basler acA2000-50gc Kamera ausgestattet. Die Bildverarbeitung soll zukünftig für alle Systeme identisch sein. Bei Start der Kamerasoftware auf dem Fahrzeug-PC soll die verbaute Kamera automatisch identifiziert werden und die dazugehörigen Parameter geladen werden.

Aufgabenstellung

1. Einarbeitung in das bestehende System
2. Morphologischer Kasten der möglichen Optionen (Version von OpenCV, VisualStudio, Kameratreiber, x64,...)
3. Bewertung und Auswahl einer Option - Besprechung mit Prof. Schneider
4. Umsetzung in Visual Studio mit OpenCV
5. Übernahme der bestehenden Bildverarbeitungssoftware im neuen System
6. Systemtests (Kompatibilitätstests) aller 3 Fahrzeuge
7. Optimierung
8. Dokumentation im HSHL-Wiki

Anforderungen

Das Projekt erfordert Vorwissen in den nachfolgenden Themengebieten. Sollten Sie die Anforderungen nicht erfüllen müssen Sie sich diese Kenntnisse anhand im Rahmen der Arbeit anhand von Literatur/Online-Kursen selbst aneignen.

• Bildverarbeitung mit OpenCV
• Programmierung C++
• Dokumentenversionierung mit SVN

Anforderungen an die wissenschaftliche Arbeit

• Wissenschaftliche Vorgehensweise (Projektplan, etc.), nützlicher Artikel: Gantt Diagramm erstellen
• Wöchentlicher Fortschrittsberichte (informativ), aktualisieren Sie das Besprechungsprotokoll - Live Gespräch mit Prof. Schneider
• Projektvorstellung im Wiki
• Tägliche Sicherung der Arbeitsergebnisse in SVN
• Tägliche Dokumentation der geleisteten Arbeitsstunden
• Studentische Arbeiten bei Prof. Schneider
• Anforderungen an eine wissenschaftlich Arbeit

SVN-Repositorium

• SVN-Repositorium

Getting started

Lesen Sie zum Einstieg diese Artikel

• Basler_GigE_Vision_System
• Kismann, J.; König, D: OSE:_Bildverarbeitung_mit_Spurerkennung
• Gantt Diagramm erstellen
• Tipps zum Schreiben eines Wiki-Artikels
• PAP Designer Einstieg
• Einführung in SVN

Projektplan

Vergleich der Kameras

Vergleich der Basler- und VRmagic-Kamera

Merkmal	Basler acA2000-50gc	VRmagic VRmDC
Sensorauflösung	2046 × 1086 Pixel	1280 x 1024 Pixel
Sensor-Typ	CMOS	CMOS
Sensorgröße	2/3"	1/3"
Maximale Bildrate	50 fps	bis zu 30 fps
Schnittstelle	GigE Vision (Gigabit Ethernet)	USB 2.0
Stromversorgung	PoE oder externer Anschluss	USB-powered
Objektivanschluss	C-Mount	C-Mount
Abmessungen	29 mm × 29 mm × 42 mm	ca. 40 mm × 40 mm × 25 mm
Betriebssystemkompatibilität	Windows, Linux (über Pylon SDK)	Windows, Linux (über VRmagic SDK)
SDK / Treiber	Basler Pylon Software Suite	VRmagic SDK (z. B. vrmagic.dll)
Unterstütztes Betriebssystem (SDK)	32‑bit & 64‑bit	32‑bit
Temperaturbereich	0 °C bis +50 °C	-30 °C bis +80 °C
Belichtungssteuerung	Automatisch & manuell über Pylon API	Manuell über SDK
Farbraum / Bildformat	Monochrom & Color (z. B. Bayer RG8)	Monochrom, Bayer RG8
Besonderheiten	GigE-Streaming, Triggering, Hardware-Zeitsync	Klein, leicht, direkt integrierbar in Embedded-Systeme

Quelle VRmagic-Kamera: [AF: Kamera] Quelle Basler: Basler shop

Besonders relaevant für das Projekt sind die höhere Auflösung und die höhere maximale Bildrate der Basler Kamera, sowie die häufige Inkompatibilität der VRmagic SDK mit 64-Bit-Betriebssystemen. Außerdem stellt die Möglichkeit der automatischen Belichtungssteuerung der Basler-Kamera eine Möglichkeit zur vereinfachung dar.

Grundsätzliche Überlegungen

Zu Beginn des Projekts mussten einige grundsätzliche Überlegungen angestellt werden. Hierzu gehörte vor allem die Frage, ob die genutzte Software als 32-Bit-Version behalten werden soll oder ob eine Umstellung auf 64-Bit potenziell einige Vorteile bringen würde. Wie in diesem Artikel zu lesen ist, lief auf den Fahrzeugen vor dem Umbau noch eine 32-Bit-Version von Windows. Deshalb war es zwingend erforderlich, dass sämtliche Software als 32-Bit-Version genutzt wurde. Nachdem die Hardware getauscht wurde, ist mittlerweile ein 64-Bit-Betriebssystem installiert und somit ist auch die Verwendung von 64-Bit-Software möglich. Diese hat die Möglichkeit, größere Speicherbereiche zu adressieren und somit Ladezeiten zu verkürzen.

Da die 64-Bit-Plattform fast keine Nachteile bietet, hat sie die 32-Bit-Plattform fast vollständig verdrängt. Lediglichdie Verfügbarkeit von Treibern für alte Hardware ist nicht immer gegeben. Das sollte im Verlauf des Projektes noch relevant werden, da sich herausstellte, dass die Treiber für die VRmagic Kamera nur als 32-Bit-Version verfügbar und somit nicht mit der neuen Software kompatibel sind.

Durch die weitestgehende Verdrängung der 32-Bit-Plattform wird moderne Software, wie zum Beispiel das für die neue Kamera verwendete Programm Basler pylon, seit der Version 6.2.0 vom März 2021, nur noch als 64-Bit-Version zum Download angeboten.

Trotz des Problems der mangelnden Abwärtskompatibilität mit der bisher verwendeten Kamera wurde der Entschluss gefasst, die Software vollständig auf 64-Bit umzustellen, da dies zum einen eine zukünftige Versorgung mit relevanten Updates sicherstellt und zum anderen mögliche Leistungssteigerungen mit sich bringt. Dementsprechend muss auch die Bildverarbeitungssoftware als 64-Bit Programm kompiliert werden. Die Nutzung der aktuellen Software (Stand Juli 2025) mit der VRmagic Kamera ist also nicht möglich!

Auswahl Kamerasoftwareversion

Für die Kamerasoftware und das damit verbundene Software Development Kit werden drei unterschiedliche Versionen in Betracht gezogen. Die Version 5.0.12 ist aktuell auf den Laborrechnern installiert. Die Version 6.1.1 ist die aktuellste Version, die als 32-Bit-Version zum Download angeboten wird und die Version 7.4.0 ist die aktuellste verfügbare Version (Stand 04.03.2024). Um die Software zu testen, wurde die Kamera zunächst mittels eines Ethernet-Kabels und eines PoE-Injektors an einen Laborrechner angeschlossen und über den pylon Viewer ein Video gestartet.

Hierbei traten bei der ältesten Version gravierende Probleme auf, welche einen praktischen Einsatz dieser Version unmöglich machen. Der Versuch, die Kamera effektiv nutzbar zu machen, blieb erfolglos. Die auftretende Fehlermeldung empfiehlt das Inter-Packet Delay, also die Zeit zwischen zwei gesendeten Datenpaketen, zu erhöhen, was den Fehler zwar eliminiert, aber die Bildrate erheblich verringert (3-10 fps) und die Reaktionszeit deutlich erhöht (3-5 sek). Mit diesen Werten ist ein Einsatz zur Bildverarbeitung schlicht unmöglich.

Die Version 6.1.1 weist in diesem Test nur geringfügige Störungen auf. Etwa 0,5% der Frames werden nicht korrekt übertragen. Eine weitere Untersuchung dieser Fehler findet nicht statt, da die neuere Version 7.4.0 nutzbar ist und eine höhere Bildrate bietet.

Auch die Version 7.4.0 läuft im ersten Versuch nicht störungsfrei. Zu Beginn läuft die Videoübertragung problemlos. Hierbei wird eine konstante Bildrate von 24 Bildern pro Sekunde erreicht. Auch die Reaktionszeit ist mit deutlich unter einer Sekunde gut. Nach der Übertragung von etwa 4.300 Frames, also nach etwa 180 Sekunden, verliert das Programm plötzlich die Verbindung zur Kamera. Eine Fehlermeldung des Programms empfiehlt, den GigE Configurator auszuführen. Nachdem dieser ausgeführt worden war, trat das Problem nicht erneut auf. Weitere Tests zeigten, dass das Problem behoben werden kann, indem die IP-Adresse der Kamera manuell auf einen statischen Wert festgelegt wird. Die Version 7.4.0 kann also genutzt werden.

Übersicht der überprüften Versionen

Version	Probleme	Bilder
Pylon 5.0.12	Fehler bei der Datenübertragung; Bildfehler; Verbindungsverlust	Datenübertragungs- und Verbindungsprobleme Bildfehler
Pylon 6.1.1	Fehler bei Datenübertragung	Kamerabild mit Fehler-Log
Pylon 7.4.0	Plötzlicher Verbindungsverlust nach ca. 3 Minuten; vorher problemfreie Übertragung	problemfreie Übertragung

Aktualisierung auf pylon Version 8.1.0

Während der Laufzeit des Projekts wurde durch Basler eine aktualisierte Version der pylon-Software herausgebracht. Da diese Version ebenfalls stabil läuft und weitere, in der Zukunft potenziell nützliche Funktionen für die CBaslerUniversalInstantCamera-Klasse implementiert, wurde beschlossen, die Software zu aktualisieren. Hierbei ist zu beachten, dass zunächst die vorherige Version von pylon deinstalliert werden muss. Nachdem diese deinstalliert ist, muss sichergestellt werden, dass die Systemumgebungsvariable $(PYLON_DEV_DIR) hierbei gelöscht wurde, da sonst keine Installation der neuen Version erfolgen kann. Anschließend sollte der Rechner einmal neugestartet werden. Im Anschluss kann die aktuelle Version 8.1.0 installiert werden. Während der Installation sollte das Profil "Developer" ausgewählt werden, um den vollen Funktionsumfang zu installieren. Die Systemumgebungsvariable $(PYLON_DEV_DIR) sollte hierbei automatisch wieder angelegt werden. Sollte dies nicht der Fall sein, muss diese manuell angelegt werden. Das Vorgehen ist hierbei identisch zur Installation der OpenCV-Umgebungsvariable, welche im folgenden Kapitel genauer erläutert wird, mit dem Unterschied, dass der Name $(PYLON_DEV_DIR) und der Wert <Pylon Installationsverzeichnis>\pylon8\Development sein muss; <Pylon Installationsverzeichnis> muss hierbei durch das lokale Installationsverzeichnis (z.B. C:\Program Files\Basler) ersetzt werden.

Die Installation an den Laborrechnern musste in einigen Fällen wiederholt werden, da beim Start des Programms zur Spurerkennung eine Fehlermeldung angezeigt wurde, die besagt, dass einige Elemente der Basler Software nicht gefunden werden konnten und dass eine Neuinstallation diesen Fehler eventuell beheben könnte. In diesem Fall muss zunächst über die Windows Funktion "Programme hinzufügen und entfernen" der Eintrag "pylon 8 Camera Software Suite" wieder deinstalliert werden. Anschließend kann die Installation erneut gestartet werden. Warum dieser Fehler entsteht, wie man ihn vermeiden kann und wie er schneller behoben werden könnte, ist nicht bekannt.

Installation OpenCV

eingestellte Systemumgebungsvariablen

OpenCV ist eine Softwarebibliothek, welche in den autonomen mobilen Robotern (AMR) genutzt wird, um die Kamerabilder - möglichst in Echtzeit - zu verarbeiten. Hierfür stellt die Bibliothek verschiedene Klassen und Funktionen bereit, welche im Modul Objekt- und Spurerkennung verwendet werden. Um diese Funktionen allerdings nutzen zu können, muss die Bibliothek zunächst auf dem PC installiert werden. Um den vollen Funktionsumfang nutzen zu können, ist eine Installation mittels CMake erforderlich. Für diesen Anwendungsfall ist die Installation der Prebuilt-Libraries jedoch ausreichend.

Die genutzte Version 4.11.0 kann für Windows hier heruntergeladen werden. Wenn die heruntergeladene Datei gestartet wird, muss nur ein Zielordner für die Installation ausgewählt und mit "Extract" bestätigt werden.

Sobald die Installation abgeschlossen ist, ist es wichtig zu beachten, dass Visual Studio bzw. das jeweilige Projekt auf die Bibliothek zugreifen kann. Hierfür ist die Angabe eines Dateipfads in den Projekteigenschaften nötig. Dieser ist für die bestehenden Projektdateien als $(OPENCV_DIR)\..\..\include festgelegt. Dabei handelt es sich bei $(OPENCV_DIR) um eine System-Umgebungsvariable. Damit diese von Visual Studio korrekt interpretiert werden kann, muss sie in den Systemeinstellungen des PCs angelegt werden.

Hierfür muss über die Windows-Systemeigenschaften im Reiter "Erweitert" das Fenster "Umgebungsvariablen" geöffnet werden. Hier muss in der Liste "Systemvariablen" zunächst die Variable "Path" ausgewählt werden. Über den Button "Bearbeiten..." wird ein weiteres Fenster geöffnet. Hier muss über den Button "Neu" der Wert <Installationsverzeichnis OpenCV>\build\x64\vc16\bin (<Installationsverzeichnis OpenCV> durch das lokale Installationsverzeichnis ersetzen, z.B. D:\opencv) hinzugefügt werden.

Nachdem die Änderung mit dem Button "OK" übernommen wurde, muss über den Button "Neu..." im Bereich Systemvariablen eine weitere Systemvariable hinzugefügt werden. Als Name muss OPENCV_DIR vergeben werden. Der Wert muss <Installationsverzeichnis OpenCV>\build\x64\vc16\ sein (auch hier <Installationsverzeichnis OpenCV> durch das tatsächliche lokale Installationsverzeichnis ersetzen).

Eine detaillierte Schritt-für-Schritt Anleitung auf Englisch inkl. Bebilderung ist hier in Kapitel 3 zu finden: Getting Started with pylon 6 and OpenCV (Bitte beachten, dass andere pylon- und OpenCV-Versionen verwendet werden und einige Variablen dadurch abweichen können).

Inbetriebnahme der Kamera über ein VS-Projekt

Plattformtoolset in den Projekteigenschaften

Dank guter Beispielprogramme des Herstellers sowie einer umfassenden Dokumentation war das Erstellen eines einfachen Programms, welches die Kamera startet, wichtige Einstellungen vorgibt und anschließend das Livebild der Kamera anzeigt ohne größere Probleme möglich. Das Kamerabild ist flüssig und die Übertragung läuft auch über längere Zeit störungsfrei. Die Verzögerung ist minimal.

Dieses Programm ist im SVN-Repositorium zu finden. Das Programm wurde ursprünglich in VS2022 erstellt, kann jedoch auch mit VS2019 kompiliert werden. Hierfür muss das jeweils installierte Plattformtoolset (v143 für VS2022 und v142 für VS2019) in den Projekteigenschaften ausgewählt werden (siehe Abbildung rechts). Außerdem muss Basler pylon in der aktuellen Version 8.1.0 oder einer neueren Version installiert sein. Hierfür wird bei der Installation der Software automatisch eine Systemvariable $(PYLON_DEV_DIR) vergeben, damit nur ein allgemeiner Verweis im Projekt nötig ist.

Ermitteln der Kameraparameter

Um die Bildverzerrung auszugleichen, müssen die intrinsischen und extrinsischen Parameter der Kamera ermittelt werden. Für die Ermittlung der intrinsischen Paramter bietet Matlab die Camera Calibrator App, welche anhand zuvor aufgenommener Bilder eines Schachbrettmusters die entsprechenden Parameter berechnet. Das genaue Vorgehen wird im Artikel Kalibrierung der Kamera erläutert. Die extrinsischen Parameter müssen gemessen werden, sobald die Kamera am Fahrzeug angebaut ist, wie hier zu sehen ist:

Messung des Neigungswinkels

Die ermittelten Parameter werden in der Datei Bildtransformation.cpp eingetragen und werden dort in einer OpenCV-Funktion zum Entzerren der Kamerabilder genutzt.

Integration der Kamera in das bestehende Projekt

Nach der erfolgreichen Inbetriebnahme folgt die Integration in das bestehende Projekt. Hierfür wurde im SVN-Repositorium der Branch 2024_07_13_OSE_Einbindung_neue_Kamera angelegt, in welchem die Integration schrittweise durchgeführt wird.

Nachdem die alten Befehle für die VRmagic-Kamera durch die für die Basler-Kamera ersetzt wurden, sowie erste Syntax- und Laufzeitfehler behoben wurden, konnte die Kamera im Projekt in Betrieb genommen werden. Hierbei kam es allerdings zu einer sehr niedrigen Bildrate von etwa einem Bild pro Sekunde, was vermutlich darauf zurückzuführen ist, dass die zu verarbeitende Datenmenge sich durch die neue Auflösung von 2046×1086 (zum Vergleich: vorher 752×478) Pixel, etwa auf das 6,2-fache angewachsen ist. Um die Datenmenge zu reduzieren, wurden die Bilder vor der Bildverarbeitung zunächst im Programm auf 1023×543 Pixel herunterskaliert, da eine Reduktion der Auflösung direkt an der Kamera nicht möglich ist. Diese Maßnahme brachte eine Verbesserung auf etwa 10 Bilder pro Sekunde.

Zusätzlich könnte an der Kamera eine Reduzierung des AOI (Area of interest) vorgenommen werden. Dies hätte zur Folge dass nur ein bestimmter Ausschnitt des Bilds übertragen wird. So müssten ungenutzte Bildteile erst gar nicht verarbeitet werden. Um die ungenutzen Bildausschnitte zu identifizieren, sind ausgiebige Tests am Fahrzeug erforderlich, welche den Umfang dieser Arbeit übersteigen würden. Außerdem wäre es möglich, das Bild von der Kamera direkt in Graustufen zu erhalten, wodruch in der Bildverarbeitung auf das umwandeln von RGB in Graustufen verzichtet werden könnte, was Rechenleistung am PC und damit Zeit sparen würde. Da die Umwandlung von RGB in Graustufen im aktuellen Build jedoch weniger als 1 ms dauert, ist das Einsparpotential hier relativ gering.

Übersicht der genutzten Funktionen

Dies sind die wichtigsten Funktionen und Klassen, welche zur Einbindung der Kamera genutzt wurden:

• PylonAutoInitTerm: initialisiert die pylon Kamera und die nötigen Funktionen; gibt zum Ende der main-Funktion automatisch die belegten Ressourcen frei
• CBaslerUniversalInstantCamera OSE_device_st(Pylon::CTlFactory::GetInstance().CreateFirstDevice()): deklariert OSE_device_st als Instanz der CBaslerUniversalInstantCamera Klasse, sucht nach Balser-Kameras und nutzt die erste gefundene Instanz
• OSE_device_st.BalanceWhiteAuto.SetValue(Basler_UniversalCameraParams::BalanceWhiteAuto_Continuous): aktiviert den fortlaufenden Weißabgleich, kann bei Bedarf deaktiviert werden und an geeigneter Stelle durchgeführt werden
• OSE_device_st.GainAuto.SetValue(Basler_UniversalCameraParams::GainAuto_Continuous): aktiviert die fortlaufende Anpassung des Verstärkungsfaktors; passt automatisch die Helligkeit des Bildes an, aber kann Rauschen verstärken
• OSE_device_st.ReverseX.SetValue(true) und OSE_device_st.ReverseY.SetValue(true): spiegelt das Bild an der X- und Y-Achse, da die Kamera "auf dem Kopf" montiert wurde
• OSE_device_st.StartGrabbing(Pylon::GrabStrategy_LatestImageOnly): startet das Abgreifen des Kamerabilds und legt fest, dass immer das zuletzt aufgenommene Bild übertragen wird
• OSE_device_st.RetrieveResult(5000, ptrGrabResult): ruft das aktuelle Bild von der Kamera ab
• ptrGrabResult->GrabSucceeded(): überprüft, ob das Bild erfolgreich empfangen wurde, true wenn erfolgreich
• formatConverter.Convert(OSE_EingabeBild_st, ptrGrabResult): konvertiert das Bild in ein geeignetes Farbformat
• VP_Img_Mat = cv::Mat(OSE_EingabeBild_st.GetHeight(), OSE_EingabeBild_st.GetWidth(), CV_8UC3, (uint8_t*)OSE_EingabeBild_st.GetBuffer()): wandelt das Bild in eine OpenCV-Matrix für die Verarbeitung um

Installation der Kamera an Fahrzeug 2 (weiß)

Vorgefundener Status:

1. Pylon 7 Camera Software Suite 7.4.0.14900 installiert
2. Pylon Runtime 7.4.0.14900 installiert
3. Kamera: VR Magic

Änderungen 23.01.2025:

1. Kamera ausgetauscht durch Basler acA2000-50gc
2. pylon 7.4.0 deinstalliert
3. pylon 8.1.0 installiert
4. OpenCV 4.10.0 installiert

Nachdem die nötige Hard- und Software installiert wurde, konnte das Programm problemlos gestartet werden. Hierbei fiel auf, dass die eingestellten Kameraparameter in Bildtransformation.cpp angepasst werden müssen, um die Bildverzerrung der Kamera korrigieren zu können. Hierzu wurden über die pylon-Software mehrere Fotos von einem Schachbrettmuster aufgenommen, welche anschließend mithilfe der Matlab Camera Calibration App analysiert wurden. Hierbei erkennt das Programm das Schachbrettmuster und berechnet die verschiedenen Kameraparameter, welche dann in OpenCV genutzt werden können, um das Bild zu entzerren. Neben der Bildentzerrung wird im Programm eine ROI festgelegt, in welcher nach der Spur gesucht werden soll. Nur dieser Bereich wird in die Vogelperspektive transformiert. Da die Position und Ausrichtung der Kamera nicht exakt gleich wie bei der vorherigen Kamera sind, mussten auch die Grenzen für diese Transformation neu festgelegt werden. Die linke Abbildung zeigt dies Festlegung dieser Grenzen.

Nachdem alle Parameter für die neue Kamera festgelegt und in das Programm eingepflegt wurden, funktionierte die Spurerkennung im Test problemlos, wie die rechte Abbildung zeigt:

Da Fahrzeug 3 (schwarz) noch nicht aufgebaut ist, wurden die hier für Fahrzeug 2 ermittelten Werte kopiert und mit diesen ein Platzhalter für Fahrzeug 3 in das Programm eingebunden. Schließt man eine passende Kamera an das Mainboard von Fahrzeug 3 an, kann auch hier das Programm ausgeführt werden. Die tatsächlichen Kameraparameter müssen nach Aufbau des Fahrzeug kontrolliert und gegebenenfalls korrigiert werden.

Troubleshooting

Nachdem die aktuelle Software auf allen AMR installiert wurde, traten verschiedene Probleme auf. Das gravierendste Problem hierbei war, dass die .exe auf den Robotern zwar gestartet werden konnte, allerdings nach Auswahl des Modus und des Fahrzeugs ohne Fehlermeldung o.Ä. abstürzt.

Zum Debuggen wurde das Programm über Visual Studio gestartet, wobei der Fehler hier nicht auftrat. Nach einiger Recherche konnte die Fehlerquelle stark eingegrenzt werden, da der Start über Visual Studio und der Start über die .exe-Datei nur einen wesentlichen Unterschied bieten: der Ausgabepfad des Projektes entspricht nicht zwangsläufig dem Pfad, von dem aus das Programm ausgeführt wird, wenn es über VS gestartet wird. Das wirkt sich auf das Programm aus, da während der Laufzeit anhand des Dateipfads von dem aus das Programm gestartet wurde, nach weiteren für das Projekt relevanten Dateien, gesucht wird. Werden bestimmte Fälle bei der Programmierung nicht bedacht, kann es hier zu Fehlern kommen.

Während VS das Programm stets im Projektverzeichnis (im SVN: /trunk/Software/OSE_Draufsicht_Spurpolynom_RS232/Bahnspurpolynom_verlinkt/) ausführt, lag der Ausgabeordner und damit auch die .exe in einem anderen Unterverzeichnis von OSE_Draufsicht_Spurpolynom_RS232 (im SVN: /trunk/Software/OSE_Draufsicht_Spurpolynom_RS232/x64/Release/). Dies führte zu einem kritischen Fehler in der Codeausführung, da zu Beginn des Programms die Datei config.ini gesucht wird, in der die wichtigsten Parameter für die Programmausführung gespeichert sind. Diese Datei liegt im SVN im Verzeichnis /trunk/Software/OSE_Draufsicht_Spurpolynom_RS232/.

Da der lokale Speicherort auf dem PC sich aber bei jedem Nutzer unterscheiden kann, wird der genaue Pfad während der Laufzeit mithilfe des Ordners bestimmt, aus dem das Programm gestartet wurde. Hierzu wurde zunächst aus dem Ausführungsordner eine Verzeichnisbene nach oben gesprungen und dort wurde versucht, die Datei config.ini zu lesen. Das funktioniert für die Ausführung in VS auch sehr gut. Bei der Ausführung über die .exe war das jedoch nicht möglich, da der Ausgabeordner des Projektes eine Ebene tiefer lag als der Order, aus dem VS das Programm startet. Dieser Fehler konnte durch das Anpassendes Ausgabeordners zu /trunk/Software/OSE_Draufsicht_Spurpolynom_RS232/Release/ bzw. /trunk/Software/OSE_Draufsicht_Spurpolynom_RS232/Debug/ behoben werden. Anschließend konnte die .exe im Modus "Live-Bild" gestartet werden.

Trotzdem gab es noch Probleme beim Starten der Simulation, welche ein zuvor aufgenommenes Video einliest und Bild für Bild verarbeitet, als wäre es das Live-Bild der Kamera. Auch hier lies sich der Fehler auf Nutzung relativer Pfade zurückführen. Da verschiedene Videos im SVN hinterlegt sind, wird in der config.ini festgelegt, unter welchem Dateipfad das gewünschte Video zu finden ist. Um den hier angegebenen Pfad zu finden, wurde erneut der Dateipfad des Ordners genutzt, aus dem das Programm gestartet wurde. Diesmal wurde in dem ausgelesenen Pfad, welcher als String zwischengespeichert wird, nach "Bahnspurpolynom_verlinkt" gesucht. Wird die gesuchte Zeichenfolge gefunden, gibt die Funktion die Position im String zurück an der die Folge beginnt. Anschließend werden ab dieser Position alle folgenden Zeichen aus dem String entfernt. Da die Zeichenfolge "Bahnspurpolynom_verlinkt" im Pfad der .exe allerdings nicht enthalten ist, liefert die Suchfunktion den Fehlerwert -1. Dieser wurde anschließend ohne weitere Überprüfung in die Funktion zum Entfernen der Zeichenfolge übergeben. -1 stellt in diesem Zusammenhang keine sinnvolle Eingabe dar und das Ergebnis, also der Pfad, an dem das Programm das Video erwartet, konnte nicht korrekt ermittelt werden.

Um diesen Fehler zu beheben, wurde zum einen eine Überprüfung des Rückgabewertes der Suchfunktion implementiert, welche den kritischen Fehler verhindert, der direkt zum Programmabsturz führt sowie die Funktion um das Suchen der Unterordner Debug und Release erweitert, damit auch vom Ausführungspfad der .exe der korrekte Pfad gefunden werden kann. Anschließend konnten sowohl Simulation, als auch Live-Bild problemlos über die .exe gestartet werden.

Außerdem trat an einem der AMR eine Fehlermeldung auf, welche darauf verwies, dass eine Komponente der Basler-Bibliothek nicht gefunden werden konnte. Diese Fehlermeldung kann nur durch eine Deinstallation der installierten pylon Version, einen anschließenden Neustart und die Neuinstallation der Basler Software behoben werden.

Empfohlenes Vorgehen bei Problemen mit der Software

Sollte das Programm nicht gestartet werden können oder ohne ersichtlichen Grund abstürzen, so können folgende Schritte helfen das Problem zu beheben:

1. Sicherstellen, dass Ethernet- und Stromkabel an der Kamera angeschlossen sind (Falls PoE genutzt wird, dann nur das Ethernet-Kabel)
   • Um die Funktionsfähigkeit der Kamera zu prüfen, kann diese mithilfe des pylon Viewers getestet werden.
2. Sicherstellen, dass Basler pylon und OpenCV in der jeweils benötigten Version installiert sind
3. Sicherstellen, dass die Umgebungsvariablen für OpenCV und pylon richtig hinzugefügt wurden
   • Eine Anleitung zum Hinzufügen einer Umgebungsvariablen findet sich im Abschnitt Installation OpenCV
4. Sicherstellen, dass die aktuelle Version der Software aus dem SVN ausgecheckt wurde
   • Um Auszuschließen, dass es an der Softwareversion liegt, kann aus dem SVN die Revision 10769 augecheckt werden. Diese ist lauffähig.
5. Sicherstellen, dass die Datei config.ini im über dem Ausführungsordner liegenden Ordner gespeichert ist

Lessons learned

• Der Aufwand für die Installation einer benötigten Software ist niemals zu unterschätzen. Er kann sogar den Aufwand der eigentlichen Programmierung übersteigen.
• Auch die Fehlersuche und das Debuggen könne erhebliche Zeitanteile in Anspruch nehmen.
• Die Kompatibilität der einzelnen Komponenten untereinander ist stets vorher zu prüfen. So kann eine aufwendige, aussichtslose Fehlersuche vermieden werden.
• Nur weil in einem Bereich des Programms keine Änderungen vorgenommen wurden, bedeutet das nicht, dass dieser Bereich auch weiterhin funktioniert.
• Nach der Integration sollte jeder mögliche Anwendungsfall getestet werden. Werden hier bestimmte Fälle ausgelassen, kann dies später zum Problem werden.

Nützliche Artikel

---

→ zurück zum Hauptartikel: Studentische Arbeiten