Kemal Karagöz

Die Idee für Meerkat stammt von mir. Ich leitete die Konzeption der Systemarchitektur und die Entwicklungsarbeiten. Zu meinen Aufgaben gehörten die Übersetzung betrieblicher Bedürfnisse in technische Anforderungen, die Gestaltung der Arbeitsabläufe und des Datenmodells, die Festlegung von Entwicklungsprioritäten und die Koordination des Teams.

Beim Print Bridge Agent übernahm ich direkt technische Verantwortung. Er stellt die Verbindung zwischen dem Server und den Etikettendruckern im Produktionsbereich her. Druckaufträge werden über eine WebSocket-Verbindung an einen lokalen Agenten übermittelt, der sie an den Drucker weiterleitet und das Ergebnis an das System zurückmeldet. Ist die WebSocket-Verbindung nicht verfügbar, übernimmt ein alternativer Ablauf über eine Warteschlange. Unser Ziel war es, das richtige Etikett mit geringer Verzögerung zu drucken, ohne den Produktionsablauf zu unterbrechen.

Meerkat unterstützt die Chargenrückverfolgbarkeit vom Wareneingang über die Produktion bis zur Auslieferung an den Kunden. Die bei der Produktion eingesetzten und erzeugten Chargen werden miteinander verknüpft. Erstellte Dokumente werden mit Verweisen auf ihre Quelldaten gespeichert. Funktionen für die Fuhrpark- und Personalverwaltung ermöglichen es außerdem, weitere betriebliche Abläufe im selben System zu verfolgen.

Meine Rolle

Ich übernahm die mathematische Modellierung, die Elektronikentwicklung, die Entwicklung eingebetteter Software, den Prototypenaufbau und die experimentellen Tests. Meine Arbeit reichte vom Entwurf der Sende- und Empfangsschaltungen über die Vorbereitung der Platinenfertigung und die Bestückung bis zur Softwareentwicklung und Durchführung von Messungen. Auch nach meinem Studienabschluss arbeitete ich bis Oktober 2024 weiter am Prototyp.

Elektronikentwicklung und Prototypenaufbau

Auf der Senderseite arbeitete ich an Schaltungen zur Signalerzeugung und Modulation für die Ansteuerung der Ultraschallwandler. Auf der Empfängerseite entwarf ich Schaltungen zur Verstärkung und Filterung des reflektierten Signals sowie zur Anpassung der Signalpegel für die Auswertung durch den Mikrocontroller. Ausgewählte Schaltungsteile simulierte ich in LTspice.

Mit Altium Designer erstellte ich die Schaltpläne und Leiterplattenlayouts sowie die Fertigungsunterlagen und die Stückliste. Die gefertigten Platinen bestückte und verlötete ich selbst. Um die Verbindungen zwischen der Hauptplatine und dem Mikrocontroller zu ordnen, entwarf ich außerdem eine zusätzliche Anschlussplatine in KiCad.

Mathematische Modellierung und eingebettete Software

Mit Python untersuchte ich die Anordnung der Arrayelemente, die Richtcharakteristiken sowie die Berechnung von Phasenverschiebungen und Zeitverzögerungen. Ich modellierte die zeitlichen Zusammenhänge zwischen den Ansteuerimpulsen der Sender, um die Abtastung in unterschiedlichen Richtungen zu untersuchen.

Für den ESP32 entwickelte ich Software zur Sendersteuerung, PWM-Erzeugung, Erfassung der Empfangssignale und Entfernungsmessung. Ich übertrug die Phasen- und Verzögerungsberechnungen in die eingebettete Software und führte mit unterschiedlichen Senderanordnungen Versuche zur Strahlschwenkung durch.

Tests und Fehlersuche

Ich testete den Prototyp schrittweise: zunächst die Stromversorgung, anschließend die Signalerzeugung und Modulation sowie die Sende- und Empfangsschaltungen. Mit dem Oszilloskop untersuchte ich die Signale an verschiedenen Stellen der Schaltung und verglich das beobachtete Verhalten mit den erwarteten Ergebnissen.

Als das Empfangssignal auf dem Oszilloskop sichtbar war, vom Mikrocontroller jedoch nicht gelesen werden konnte, untersuchte ich die Spannungsversorgung und den Programmablauf. Zur Eingrenzung des Problems testete ich die Sende- und Empfangsaufgaben mit getrennten Mikrocontrollern und überarbeitete den Algorithmus zur Entfernungsmessung. Anschließend führte ich Entfernungsmessungen und Abtastversuche unter verschiedenen Winkeln mit einer Anordnung aus acht Sendern durch.

Erkenntnisse und Weiterentwicklung

Durch die Versuche konnte ich nachvollziehen, wie sich Sättigung und Schwellwertverarbeitung in der Empfangsschaltung auf die Erhaltung und Auswertung schwacher Signale auswirkten. Die begrenzte Ausstattung mit Messgeräten schränkte insbesondere die direkte Überprüfung der Phasenbeziehungen zwischen den Kanälen ein. Ich bewertete die Ergebnisse unter Berücksichtigung dieser Grenzen und ordnete die Arbeit als experimentellen Prototyp ein.

Heute greife ich das Projekt in technischen Blogbeiträgen wieder auf. Dabei erläutere ich die verwendeten Methoden, die aufgetretenen Probleme und die Entwurfsentscheidungen, die ich heute anders treffen würde. Diese Überlegungen bilden auch eine Grundlage für die geplante Weiterentwicklung Sonar V2.

Werkzeuge und Technologien

Altium Designer, LTspice, KiCad, Python, ESP32, Arduino IDE, Ultraschallwandler, analoge Signalaufbereitung, PWM und Oszilloskopmessungen.

Meine Rolle

Die Modellierung, die Erstellung der Schaltungsmodelle, die Durchführung der Simulationen und die Dokumentation übernahm ich selbstständig. Dabei erhielt ich fachliche Rückmeldungen und Unterstützung von meinem Dozenten für Optoelektronik.

Elektromagnetische Modellierung

Ich bildete die in der Veröffentlichung beschriebene Sensorgeometrie in CST nach. Anhand der Simulationsergebnisse untersuchte ich den Frequenzgang und das Resonanzverhalten des Modells mit seiner UGCPW-Struktur und den NS-SRR-Elementen. Anschließend band ich das Modell in eine Simulationsanordnung ein, um es gemeinsam mit zugehörigen HF-Schaltungen untersuchen zu können.

Untersuchung mit HF-Schaltungen

Ich untersuchte das Sensormodell in einer Schaltungsanordnung mit einem spannungsgesteuerten Oszillator (VCO), einem rauscharmen Verstärker (LNA) und einem 3-dB-Leistungsteiler. Mithilfe des Leistungsteilers betrachtete ich die Signale in verschiedenen Schaltungszweigen und wertete sowohl den Sensorausgang als auch das über den Verstärker geführte Signal aus.

Für den VCO verwendete ich ein Schaltungsmodell aus der CST-Bibliothek. Dadurch konnte ich das elektromagnetische Modell des Sensors zusammen mit den Funktionen zur Signalerzeugung und Verstärkung innerhalb derselben Arbeit untersuchen.

Umfang und gewonnene Erfahrungen

Das Projekt umfasste elektromagnetische Simulationen und Schaltungssimulationen in CST. Eine physische Fertigung und Labormessungen wurden nicht durchgeführt. Die Ergebnisse bewertete ich unter den jeweiligen Simulationsbedingungen.

Durch diese Arbeit sammelte ich Erfahrung darin, einen veröffentlichten Entwurf in ein numerisches Modell zu übertragen, Simulationen einzurichten, HF-Schaltungsblöcke gemeinsam zu untersuchen und die Ergebnisse technisch zu dokumentieren.

Werkzeuge und Technologien

CST Studio Suite, elektromagnetische Modellierung, HF-Schaltungssimulation, UGCPW, NS-SRR, VCO, LNA und Leistungsteilerschaltungen.

Meine Rolle

Gemeinsam mit meinem Projektpartner arbeitete ich an der Anforderungsanalyse, der Erstellung von Steuerungsszenarien, der SPS-Programmierung, den HMI-/SCADA-Anwendungen und den Simulationen. Wir entwickelten und überprüften sämtliche Projektbereiche gemeinsam.

SPS-Steuerungslogik

Mit Siemens TIA Portal entwickelten wir die Steuerungslogik in LAD, FBD und SCL für eine CPU 1214C der S7-1200-Familie. Das Anfahren, den Normalbetrieb und das Abfahren des Kraftwerks bildeten wir als miteinander verknüpfte Steuerungsschritte ab.

Wir definierten die Voraussetzungen für das Anfahren von Turbine und Generator, die Kühlwasserkontrollen sowie die Befehle für Erregung und automatische Synchronisierung. Für das normale Stillsetzen, die störungsbedingte Abschaltung und die Notabschaltung erstellten wir getrennte Steuerungsabläufe.

Hilfssysteme und Störungsszenarien

Neben der Hauptanlage zur Stromerzeugung berücksichtigten wir Hilfssysteme wie Entwässerungspumpen, Kühlwasserpumpen und Luftkompressoren. Wir legten Betriebsbedingungen in Abhängigkeit von Wasserstand, Druck, Drehzahl und Anlagenzustand fest.

Für elektrische und mechanische Störungen entwickelten wir die Alarm-, Quittierungs- und Rücksetzlogik. In den Steuerungsszenarien legten wir fest, unter welchen Bedingungen die einzelnen Anlagenkomponenten betrieben werden durften und wann sie abgeschaltet werden mussten.

HMI, SCADA und Simulation

Wir entwickelten HMI- und SCADA-Anwendungen zur Überwachung der Prozesszustände und zur Übermittlung von Bedienbefehlen an die Steuerung. Dazu verknüpften wir SPS-Variablen, Anlagenzustände und Alarminformationen mit den Überwachungs- und Bedienfunktionen.

In den Simulationen untersuchten wir die Steuerungsabläufe unter unterschiedlichen Betriebsbedingungen. Dabei betrachteten wir SPS, HMI und SCADA gemeinsam und arbeiteten am Zusammenspiel zwischen der Steuerungssoftware und den Bedienoberflächen.

Gewonnene Erfahrungen

Durch dieses Projekt sammelte ich Erfahrung darin, die Anforderungen einer realen Anlage in Automatisierungssoftware zu übertragen, miteinander verbundene Anlagenkomponenten als Gesamtsystem zu betrachten und Steuerungsszenarien für unterschiedliche Betriebszustände zu entwickeln. Außerdem konnte ich die gemeinsame Entwicklung und Überprüfung der verschiedenen Bereiche eines umfangreichen Automatisierungsprojekts im Team erproben.

Werkzeuge und Technologien

Siemens TIA Portal, Siemens S7-1200 / CPU 1214C, LAD, FBD, SCL, HMI, SCADA, Ablaufsteuerung, Alarm- und Verriegelungslogik.

Ziel unserer Arbeit war es, den Einfluss der Raketengeometrie auf die Flugleistung zu untersuchen und geeignete Entwürfe unter festgelegten Umgebungsbedingungen und konstruktiven Randbedingungen zu finden. Für einen systematischen Vergleich verschiedener Entwürfe kombinierten wir statistische Versuchsplanung (Design of Experiments — DoE), Flugsimulation und stochastische Optimierung.

Im Rahmen der Untersuchung wurden mithilfe von DoE 505 Entwurfsvarianten erstellt und in OpenRocket simuliert. Wiederkehrende Dateneingaben und Simulationsschritte wurden mit MacroRecorder automatisiert. Die daraus gewonnenen Flugleistungsdaten wurden zusammen mit den jeweiligen Entwurfsvariablen erfasst und bildeten die Grundlage für die mathematische Modellierung.

Mit Wolfram Mathematica entwickelten wir nichtlineare Regressionsmodelle, um die Zusammenhänge zwischen den Entwurfsvariablen und den Flugkenngrößen abzubilden. Die Vorhersagegüte der Modelle wurde anhand einer Aufteilung der Daten in Trainings- und Testdatensätze bewertet. Anschließend dienten diese Modelle als Grundlage für die stochastische Optimierung unter den festgelegten Zielsetzungen und Randbedingungen.

Für das Avioniksystem entwarfen wir im Team mit Altium eine eigene Elektronikplatine. Zum System gehörten STM-basierte Hardware, ein Raspberry Pi, ein sechsachsiger Bewegungssensor und ein Drucksensor. Außerdem entwickelten wir eine Bodenstationssoftware in C#, mit der wir Daten aus dem System empfingen. Als Avionikverantwortlicher arbeitete ich aktiv an der Platinenentwicklung, der Sensorik und der Bodenstationssoftware mit.

Wir arbeiteten auch an der Fertigung und bauten die Rakete mit Unterstützung von Şişecam als Sponsor. Flugtests konnten wir jedoch nicht durchführen. Unsere Bewertungen der Flugleistung beruhten daher auf den Ergebnissen der Simulationen und der mathematischen Modellierung.

Durch dieses Projekt sammelte ich Erfahrung darin, einen Entwicklungsprozess vom Aufbau eines interdisziplinären studentischen Teams über Entwurf und Analyse bis hin zur Fertigung zu leiten. Weitere Schwerpunkte waren die Abstimmung der Elektronik-, Software- und Mechanikarbeiten, die Nutzung von Simulationsergebnissen für Entwurfsentscheidungen und die technische Koordination innerhalb des Teams.

Ich erstellte den 3D-Entwurf eines etwa 35–40 cm langen Modellfahrzeugs. Die entworfenen Teile ließ ich aus Acrylglas zuschneiden, baute daraus die Fahrzeugkarosserie und richtete eine Arduino-basierte Steuerung ein. Mehrere Alkoholsensoren an unterschiedlichen Stellen des Fahrzeugs ermöglichten es mir, zu untersuchen, in welchem Bereich Alkohol erkannt wurde. Mit dieser Anordnung erprobte ich, ob sich Alkohol aus dem Fahrerbereich räumlich zuordnen ließ.

Zur Erfassung der Fahrzeugumgebung verwendete ich einen Abstandssensor und eine Kamera. Die Bildverarbeitung führte ich auf einem Computer aus. Dafür übertrug ich das Kamerabild an eine in Visual Studio entwickelte grafische Benutzeroberfläche und setzte grundlegende Bildverarbeitungsverfahren ein. Dieser Teil des Projekts war ein einfacher, experimenteller Ansatz zur Umgebungserfassung im Rahmen einer Schülerarbeit.

In der Steuerungssoftware setzte ich zwei grundlegende Szenarien um. Wurde bei stehendem Fahrzeug Alkohol erkannt, verhinderte das System das Losfahren. Bei einer Erkennung während der Fahrt fuhr das Modellfahrzeug nach rechts in einen geeigneten Bereich, und eine Nachricht wurde an Angehörige gesendet. Das Verhindern der Fahrt, das Anhalten in einem geeigneten Bereich und der Nachrichtenversand funktionierten in den Versuchen mit dem Modellfahrzeug.

Für den mobilen Teil entwickelte ich mit MIT App Inventor eine Smartphone-App und stellte eine Bluetooth-Verbindung zwischen der Anwendung und dem Fahrzeug her. So verband ich die sensorbasierte Erkennung, die Fahrzeugsteuerung, die Bildverarbeitung am Computer und die mobile Kommunikation in einem gemeinsamen Prototyp.

Mit dem Projekt belegte ich 2017 beim TÜBİTAK-Schülerforschungswettbewerb den ersten Platz im Fach Physik in der Regionalrunde Malatya. Dadurch qualifizierte ich mich für das nationale Finale, bei dem ich einen Förderpreis im Fach Physik erhielt.