kramann.info
© Guido Kramann

Login: Passwort:










kramann.info
© Guido Kramann

Login: Passwort:




Projektstudium im Wintersemester 2025/26

(EN google-translate)

(PL google-translate)

  • Studierendengruppen: 5-3-MT
  • Hier bei "day by day" werden chronologisch im Verlauf des Semesters die behandelten Inhalte vermerkt.
  • Meistens werden Links innerhalb von kramann.info angegeben, wo der jeweils behandelte Stoff dargestellt wird.
  • Zur Orientierung finden Sie auf kramann.info auch noch das "day by day" der gleichen Lehrveranstaltung vom vorangehenden Jahr.
  • Die Prüfung in diesem Fach ist Semester begleitend und besteht in der Präsentation einer Projektarbeit am Ende der Vorlesungszeit.

Projektstudium Montag, 17.11.2025

Themen

  1. Organisatorisches
  2. Vorstellung möglicher Projektthemen
  3. Projekt Museumsroboter
  4. Vorlesung OOP
  5. Gruppenbildung und Themenwahl
  6. Start der Projektgruppen
  7. GETROFFENE VEREINBARUNGEN

1. Organisatorisches -- Idee zur zeitlichen Organisation der Fächer "Projektstudium" und "Simulations- und Regelungstechnik" 


MONTAG
10:15-11:45 Vorlesung, Thema OOP (gehört zu Simulations- und Regelungstechnik, Grundlagen sowohl für das Projektstudium als auch für Simulations- und Regelungstechnik)
12:15-15:15 Projektstudium und Konsultationen

DIENSTAG
8:30-10 Kernvorlesung Simulations- und Regelungstechnik
10-11:30 erster Übungsblock
12:15-13:45 zweiter Übungsblock 

MITTWOCH
10:30-13:30 Projektstudium und Konsultationen (erste zwei Stunden überlappen sich mit der Projektarbeit eines Masterkurses)

Code 0-1: Idee zur zeitlichen Organisation der Fächer "Projektstudium" und "Simulations- und Regelungstechnik"

2. Vorstellung möglicher Projektthemen

  1. Es gibt einige Themen, die in der Vergangenheit eine Rolle gespielt haben, diese könnten in Ein-Personen-Projekten fortgeführt werden.
  2. Es soll ein Angebot zu einem Mehr-Personen-Projekt geben, bei dem alle gemeinsam an einer Sache arbeiten, sich aber im Verlauf der Arbeit jeweils auf ein besonderes Thema spezialisieren, Arbeitstitel ist "Museumsroboter"

3. Projekt Museumsroboter

Ein historisches Beispiel
  • Im Museum für Kommunikation in Berlin gab es im Atrium dort vor vielen Jahren (2000er) eine Gruppe an drei Robotern, die die Aufgabe hatten, sich um die Besucher*Innen zu kümmern.
  • Mit der damaligen Technik war die Aufgabenteilung der drei Roboter sehr klar festgelegt und der tatsächliche Nutzen recht begrenzt.
  • Siehe beispielsweise:
http://www.seins-form.de/work/projekte/roboter/
https://www.youtube.com/watch?v=RR1yTaHp2g4

Die drei Roboter hatten klare Aufgaben:

  1. Spielen, mit einem Gymnastikball
  2. Historische Darstellung des Museums
  3. Leute geleiten / herumführen

Das Design orientierte sich an der jeweiligen Aufgabe.

"Spielen" -- der "Mach was"-Roboter
Aktuelles überarbeitetes Konzept: https://www.mfk-berlin.de/
Aufbau eines Roboter-THB-Guides unter Verwendung eines lokalen großen Sprachmodells als verteiltes System
  • Bei Projekten tritt häufig das Problem der überbordenden Komplexität auf:
  • Dinge werden mit der Zeit so komplex, dass sie von den Projektverantwortlichen nicht mehr bewältigt werden können.
  • Oder es gibt einen Generationenwechsel bei den Projektverantwortlichen und die nachfolgende Generation kommt mit der zuvor geleisteten Arbeit nicht zurecht.
  • Grundsätzlich lässt sich Komplexität durch Modularisierung und Hierarchisierung verringern.
  • Jedoch erfordert dies eine klare Definition, wie die Module miteinander interagieren sollen.
  • Es müssen deshalb klare Kommunikationsschnittstellen definiert werden.

Idee für ein Grundkonzept: Die Module kommunizieren über WiFi unter Ausnutzung von Websockets, oder UDP oder des MQTT Protokolls


https://de.wikipedia.org/wiki/User_Datagram_Protocol
https://de.wikipedia.org/wiki/MQTT
https://blog.doubleslash.de/software-technologien/mqtt-fuer-dummies/
Hinweise zu Internetprogrammierung

Vorteil von Modulen, die über WiFi miteinander kommunizieren:

  1. Erleichtert die Arbeitsteilung im Projekt
  2. Teilergebnisse können auch in anderen Zusammenhängen getestet und verwendet werden
  3. Module können leicht durch Nachfolgemodule ersetzt werden
  4. Das Gesamtkonzept lässt sich leichter verändern und weiterentwickeln
Lokales Large Language Model (LLM)

Auf der Grundlage des nachfolgenden kostenfreien und quelloffenen Projektes ist es sehr leicht geworden, ein LLM lokal zu installieren:

WIE ES GEHT: https://www.linux-community.de/ausgaben/linuxuser/2024/09/ki-chatbots-lokal-ohne-cloudanbindung-nutzen/
INSTALLER: https://www.nomic.ai/gpt4all
https://de.wikipedia.org/wiki/Large_Language_Model
Roboter-THB-Guide rund um ein LLM

Ein Test mit gpt4all unter Verwendung des deutschen Sprachmodells "Mistral":

Ein Test mit gpt4all unter Verwendung des deutschen Sprachmodells

Bild 0-1: Ein Test mit gpt4all unter Verwendung des deutschen Sprachmodells "Mistral".

Folgende Komponenten liegen nahe zu besitzen:

  1. Sprachmodell
  2. TTS (Text to Speech)
  3. STT (Speech to text)
  4. Fahrwerk
  5. Kommunikationseinheit (Tablet?)
  6. Raumüberwachung und Telemetrie
  7. Koordinationseinheit bei der alle Fäden zusammenlaufen
Komponenten und ihre Vernetzung beim THB-Guide.

Bild 0-2: Komponenten und ihre Vernetzung beim THB-Guide.

Fragen
  1. Kann das LLM mittels eines Chats Infos über die THB lernen und kann dieser Chat dann beliebig fortgesetzt werden?
  2. Wie kann mit fehlerhaften Texten aus dem STT Modul umgegangen werden?
  3. Gibt es eine freie lokale Version eines STT?
  4. Findet sich zu jeder Plattform eine Library für WiFi und beispielsweise MTTY?
  5. Welches WiFi Protokoll macht am meisten Sinn (Verfügbarkeit auf verschiedenen Plattformen / Aufwand / Effizienz)?
  6. Schwarm oder Monolith? (vergl. weiter unten)
  7. Was läuft auf dem Roboter, was auf externen Systemen? (Frage der Informationsmenge, die über die Schnittstellen läuft, je nach Wahl, wo man schneidet)
  8. Was könnte leicht umgesetzt werden, was wäre zu aufwändig, was wäre lohnenswert im Hinblick auf spätere Entwicklungen?
Frühere Konzeptstudie im Vergleich:
THB-Robot: https://youtu.be/0B8kjcCu4zk
THB-Robot.

Bild 0-3: THB-Robot.


Warum einen einzelnen Roboter verwenden, wenn man flexibler mit einem Schwarm ist?


Schwarm statt einzelner Roboter: https://youtu.be/YS-1RRLGtgQ
siehe auch: 05_esp32AV/30_esp32swarm
Variante mit induktiver Ladevorrichtung: https://youtu.be/60fEn0f_MnM
siehe auch: 83_AV/03_Umsetzung/05_TURTLE
Thunfischschwarm aus "Findet Nemo": https://www.youtube.com/watch?v=gArrbrjUlnA

Warum einen Roboter bauen, wenn Besucher*Innen ebensogut die Funktionalität als Smartwatch mit sich tragen können?


Steuerung einer Smarthome-Lampe per Smartwatch über UDP https://youtu.be/KKv1UixNgjY
siehe auch: 06_TWATCH
ähnliche Ansteuerung, aber Verwendung eines Arduino nano 33 IoT: https://youtu.be/22C3ua4X7wA
Erstsemesterprojekt Staubsaugroboter: https://youtu.be/wX4kJfI7e8A
siehe auch: 83_AV/07_Saugroboter
Linienverfolgung mit esp32 mit Videostream per WiFi: https://youtu.be/N0bxvH8GV-A
Verwendung einer GPU: 84_Jetson

4. Vorlesung OOP

  • Es handelt sich um eine ergänzende Veranstaltung, um notwendige Grundlagen zu vermitteln.
  • Unterthemen sind: Internetprogrammierung, Programmierung von Android Devices, aber vor allem auch Objekt Orientierte Programmierung.
  • Bei Simulations- und Regelungstechnik werden Fertigkeiten in der Programmierung gebraucht, um Simulationen zu visualisieren, optimieren, oder besondere Systeme, wie Fuzzy-Regler, zu implementieren.

Präsentation zu TTS auf der Basis Android-Processing


siehe auch: 94_VSI/03_TTS
https://android.processing.org/
36_Java
78_Processing
79_Deep_Learning

5. Gruppenbildung und Themenwahl

6. Start der Projektgruppen

7. GETROFFENE VEREINBARUNGEN
  • Es gibt eine "Kart-Gruppe" und eine "Roboter Guide-Gruppe"
BEIDE GRUPPEN...
  • ...bereiten für Montag den 24.11. ein Projektangebot vor,
  • ...sehen eine WiFi-Schnittstelle, voraussichtlich mit UDP Protokoll für ihre Systeme vor,
  • ...setzen ihre Software, sofern neu, objektorientiert um,
  • ...präsentieren am letzten Unterrichtstag ihr System und geben dazu einen Bericht ab,
  • ...nehmen eine Differenzierung der Aufgaben vor, für die die Mitglieder verantwortlich sind, was sich dann in der Präsentation und den Berichtsteilen abbildet,
AUFGABENTEILE der Kart-Gruppe, KLEINES FAHRZEUG (vorläufig / unvollständig)
  • Programmeirung eines elektrischen Differentials
  • WiFi basierte Fernsteuerung samt Übertragung aller Sensordaten
  • Aufzeichnung der Sensordaten und exemplarische Analyse mittels Laptop
  • Rudimentäre Programmierung eines Fahrmanövers (Einparken?), geregelt von der WiFi Gegenstelle (Mobile Device oder Laptop)
AUFGABENTEILE der Kart-Gruppe, GROSSES FAHRZEUG (vorläufig / unvollständig)
  • Entwurf und 3D-Druck fehlender Komponenten
  • Konsolidierung des CAN-Bus-Systems
  • Fertigstellung der Verbindung zwischen Gaspedal und Antrieb (Fehlende Sensoren ergänzen)
AUFGABENTEILE der Roboter Guide-Gruppe (vorläufig / unvollständig)
  • Recherche zu möglichen Fahrplattformen und Bau / Anpassung / Kauf
  • Implementierung des LLM und Bereitstellung einer Web-Schnittstelle
  • Implementierung eines TTS Moduls (beispielsweise Android-Processing)
  • Implementierung eines STT Moduls und Bereitstellung einer Web-Schnittstelle
  • Entwurf einer generellen Kontrolleinheit / Gesamtkonzept (Was kann das System am Ende?)
  • Bereitstellung einer Web-Schnittstelle im Hauptsystem
  • Entwicklung der Kommunikationseinheit
  • Konzept und Entwicklung der Navigation