0. Motivation

Ein zentraler Schwerpunkt meines Studiums liegt im Bereich der Künstlichen Intelligenz. In diesem Zusammenhang setze ich mich intensiv mit der Frage auseinander, wie Interaktionen zwischen Mensch und KI gestaltet werden können. Ich hoffe meine Kompetenzen in diesem Bereich weiter auszubauen.

1. Einführungsveranstaltung

Am Ersten Termin setzen wir uns mit den Grundlagen von AI auseinander. Setzen diese in den Historischen Kontext und nahmen die Unterteilung von ML als auch DL Systemen vor. Zudem legten wir den Rahmen für den Kurs fest.

2. Hausaufgabe-KI die dich fasziniert

Ich habe mich für die Themen Soft Robotics und den SRT-H entschieden, weil mich der Kontrast von klassischen, starren Robotern fasziniert. Anstatt auf schwere Metallarme setzt man hier auf Systeme, die fast organisch wirken und sich flexibel an ihre Umgebung anpassen können.

Spannend ist für mich vor allem das Zusammenspiel: Der SRT-H dient als „intelligentes Gehirn“, das durch KI-Methoden wie Reinforcement Learning lernt, eigenständig zu handeln. Die Soft Robotics liefert dazu den passenden „Körper“, der durch weiche Materialien (wie beim Oktopus-Vorbild) sicher und schonend ist. In dieser Arbeit zeige ich kurz auf, wie diese Technik die Chirurgie verändern könnte, wo die ethischen Grenzen liegen und warum weiche Materialien die Robotik grundlegend verändern werden.

3. Hausaufgabe-UX mit Figma Make

Als weitere Hausaufgabe erhielten wir die Aufgabe, mithilfe von Figma Make ein Interface zu entwickeln. Anschließend sollte das entworfene Design über MCP (Model Context Protocol) in Visual Studio Code eingebunden und mithilfe des Plugins GitHub Copilot in Code überführt werden.

Hierbei handelt es sich um ein UX Design von Figma Make

Darauf folgt, die Umwandlung von Github Copilot

Wie auf den Abbildungen deutlich zu erkennen ist, wurde das ursprüngliche Design von GitHub Copilot neu interpretiert und nicht vollständig originalgetreu übernommen. Zwar war die technische Implementierung vergleichsweise einfach und schnell umsetzbar, dennoch zeigen sich bereits in der ersten generierten Version deutliche Schwächen im Bereich UX/UI. Abstände zwischen Elementen sind teilweise inkonsistent, wodurch das Layout unruhig wirkt. Gleichzeitig erscheint das erste Design in seiner visuellen Hierarchie recht eintönig und wenig differenziert.

Auch der generierte Code ist kritisch zu betrachten. Er enthält keine Kommentare oder weiterführende Strukturierung, was die Nachbearbeitung, Wartung und Erweiterung des Projekts erschwert. Möchte man zusätzliche Funktionen integrieren oder grundlegende Layoutanpassungen vornehmen, stößt man schnell an Grenzen, da die Codebasis häufig wenig transparent und nur bedingt modular aufgebaut ist.

Hinzu kommt, dass die generierte Anwendung ausschließlich das Frontend abbildet. Aspekte wie Backend-Strukturen, Datenbankanbindungen, Validierung von Nutzereingaben oder Sicherheitsmechanismen werden nicht berücksichtigt. Gerade in Hinblick auf Datenschutz, Eingabesicherheit und Skalierbarkeit entstehen dadurch potenzielle Schwachstellen.

Zusammenfassend zeigt sich, dass KI gestützte Tools wie GitHub Copilot großes Potenzial für schnelles Prototyping und die Entwicklung einfacher Anwendungen besitzen. Für komplexe, bedürfnisorientierte und technisch robuste Webanwendungen reichen solche automatisierten Lösungen allein jedoch nicht aus, da sie sowohl in gestalterischer als auch in technischer Hinsicht schnell an ihre Grenzen stoßen.

30.04.2026

Im Rahmen der heutigen Sitzung beschäftigten wir uns mit dem Thema Prompt Engineering. Unsere Aufgabe bestand darin, mithilfe einer JSON-Datei einen Prototypen in Figma Make zu erstellen. Ziel war es, die prägnantesten und relevantesten Informationen aus der JSON-Struktur herauszuarbeiten und diese in ein verständliches sowie visuell ansprechendes User Interface zu überführen.

Die erste Phase, die Extrahierung und Identifikation relevanter Datenpunkte, erfolgte in Gruppenarbeit. Die anschließende Umsetzung des UI-Prototyps in Figma Make wurde in Einzelarbeit ausgearbeitet.

Als Hausaufgabe erhielten wir die Aufgabe, unseren Prompting Prozess inklusive Designentscheidung und finalem Entwurf in Form einer Präsentation aufzubereiten und zu reflektieren.

4. Hausaufgabe Figma Make

07. 05.2026

Online Kurs - Auswertung der Hausaufgabe via Zoom

Im Online Kurs erhielten wir eine Einführung in die Verwendung von APIs. Dabei beschäftigten wir uns damit, wie APIs in Figma Make Projekte integriert und anschließend für die Weiterverarbeitung an GitHub Copilot übergeben werden können. Außerdem wurden mögliche Probleme in diesem Workflow thematisiert sowie die Grenzen dieser Arbeitsweise kritisch betrachtet. Zudem gingen wir noch auf das Thema Datenvisualisierung ein. 

Ein weiterer Schwerpunkt lag auf dem Thema Prompting. Wir gingen ausführlich durch, wie der Aufbau eines Prompts gestaltet sein sollte, um möglichst präzise und zielführende Ergebnisse zu erhalten. Dabei wurde deutlich, wie stark die Qualität der Ausgabe von einer klaren Struktur, präzisen Formulierungen und einem gut definierten Ziel abhängt.

Diese Stunde gab uns einen detaillierteren Einblick in die Arbeit mit Figma Make und GitHub Copilot sowie in das Zusammenspiel von Design, APIs und KI-gestützter Entwicklung.

5. Physical Computing

21.05.2026

An diesem Kurstag wurden wir in den Umgang mit dem Raspberry Pi eingeführt. Zu den behandelten Inhalten gehörten unter anderem das Flashen der MicroSD-Karte sowie der grundlegende Aufbau elektronischer Schaltungen mit Breadboard und Jumper Kabeln.

Im praktischen Teil schlossen wir einen Ultraschallsensor an und kombinierten diesen mit LEDs, um ein einfaches interaktives Nutzerverhalten zu programmieren. Anschließend nutzten wir Python Skripte, um die Sensorik mithilfe des Raspberry Pis auszulesen und anzusteuern.

Die Sitzung vermittelte erste Grundlagen im Bereich Physical Computing sowie im Zusammenspiel von Hardware und Python-basierter Programmierung.

6. Projektkonzept

Hausaufgabe

28.05.26

Wir bekamen die Aufgabe ein Projektkonzept zu unserem Projekt zu schreiben. Hierbei sollten wir Fragen beantworten und die Datei Fristgerecht abgeben. Zusätzlich sollte eine dazugehörige Präsentation von 7-8 min erstellt werden.

7. Abschlussarbeit

Für dieses Semesterprojekt habe ich mich entschieden, einen sozialen und interaktiven Roboter zu entwickeln. Ausschlaggebend für diese Wahl war mein Wunsch, meine Kenntnisse im Bereich Physical Computing zu festigen und praktisch zu erweitern. Das Projekt verbindet den mechanischen Aufbau eines Roboters mit Elektronik, Programmierung und der Gestaltung von Interaktion. Gleichzeitig bietet es mir die Möglichkeit, diese praktische Arbeit in den Forschungskontext der sozialen Robotik und der Mensch-Roboter-Interaktion einzuordnen.

Im Mittelpunkt steht die Frage, wie ein Roboter als soziales Gegenüber wahrgenommen werden kann. Lumi soll langfristig nicht nur vorgegebene Befehle ausführen, sondern eine intuitive Interaktion ermöglichen. Ergänzend sollen Bewegungen, Blickrichtung, Licht und weitere Ausdrucksformen dazu beitragen, seine Reaktionen verständlich und lebendig zu vermitteln. Dafür müssen unterschiedliche technische Bereiche miteinander verbunden werden: der mechanische Aufbau, die Stromversorgung, Sensoren und Aktoren, die Verarbeitung von Sprache sowie die Programmierung des Interaktionsverhaltens.

Mein Ziel in diesem Kurs war es, eine technische und gestalterische Grundlage für dieses Vorhaben zu schaffen. Dazu gehörten der Aufbau des Roboters, die Einrichtung seiner Hard- und Software, die Kalibrierung der Motoren und die Entwicklung erster Ansätze für eine eigene Persönlichkeit und Sprachinteraktion. Dabei interessiert mich nicht nur, ob die einzelnen Komponenten funktionieren, sondern auch, wie ihr Zusammenspiel die Wahrnehmung des Roboters beeinflusst.

Lumi ist als längerfristiges Projekt angelegt und wird nicht mit dem Ende dieses Kurses abgeschlossen sein. Die vorliegende Dokumentation beschreibt deshalb sowohl die bisher umgesetzten und getesteten Bestandteile als auch technische Schwierigkeiten, offene Fragen und geplante Erweiterungen. Sie soll den Entwicklungsprozess auch für Personen nachvollziehbar machen, die zuvor nicht an dem Projekt beteiligt waren.

Fortführung der Inhalte nach der Abschlusspräsentation: 

Lumi befand sich bereits zum Zeitpunkt der Abschlusspräsentation in einer ersten funktionsfähigen Entwicklungsphase. Es existierte bereits ein eigener Prototyp für die Sprachinteraktion. Dieser lief zunächst auf meinem MacBook und verwendete dessen eingebautes Mikrofon zur Spracheingabe. Die gesprochene Eingabe wurde verarbeitet und über eine API an ein Sprachmodell weitergegeben. (Chat GPT 4o-mini)

Für den Dialog hatte ich außerdem einen eigenen System-Prompt entwickelt, der die gewünschte Persönlichkeit und das Antwortverhalten des Roboters definierte. Ergänzend verwendete ich eine JSON-Datei, in der Gedächtnisdaten und Informationen für spätere Gespräche gespeichert werden konnten. Während eines dieser Dialogtests wählte der Roboter selbst den Namen „Lumi“. Der Name entstand somit aus der Interaktion mit dem Sprachmodell.

Der Sprachdialog und die dafür geschriebenen Dateien unterschieden sich von der ursprünglichen Open-Duck-Mini-Runtime und bildeten bereits zu diesem Zeitpunkt einen eigenen Teil des Projekts. Die von mir entwickelten und angepassten Programme werden deshalb in einem eigenen GitHub-Repository dokumentiert. Dort wird zwischen meinem Quellcode und den verwendeten Open-Source-Grundlagen unterschieden. Bestandteile wie die vorhandene Laufsteuerung und die Machine-Learning-Policy werden nicht als eigene Entwicklung dargestellt, sondern mit einem Verweis auf das ursprüngliche Open-Duck-Mini-Projekt gekennzeichnet.

Die Sprachinteraktion war zur Abschlusspräsentation allerdings noch nicht vollständig in die Hardware des Roboters integriert. Die Verbindung mit dem Raspberry Pi, dem Lautsprecher, den Motoren, den LEDs und den weiteren Ausdrucksfunktionen des Roboters blieb ein nachfolgender Entwicklungsschritt.

Nach der Abschlusspräsentation begann die nächste praktische Entwicklungsphase des Projekts. Die weitere Arbeit umfasste den erneuten 3D-Druck fehlerhafter Bauteile, die Vorbereitung und Montage der Servomotoren, den Einbau der Elektronik sowie die schrittweise Inbetriebnahme des Systems.

7.1 3D Druck und Gewinde

Nachdruck und Materialauswahl

Zunächst musste ich mehrere fehlerhaft gedruckte Bauteile erneut herstellen. Bei einigen Drucken ließen sich die Supportstrukturen nur schwer entfernen. Dadurch wurden Oberflächen oder für die Montage relevante Bereiche beschädigt. Je nach Funktion des jeweiligen Bauteils verwendete ich für den Nachdruck PLA oder PETG.

Die Fußsohlen wurden separat aus TPU gedruckt. Im Gegensatz zu den starren Kunststoffen PLA und PETG ist TPU flexibel und besitzt eine griffigere Oberfläche. Dadurch sollen die Füße weniger leicht wegrutschen und dem Roboter beim späteren Stehen und Laufen einen besseren Halt geben. Die Materialwahl war somit nicht nur eine gestalterische, sondern auch eine funktionale Entscheidung.

Einsetzen der Gewinde

Die gedruckten Bauteile konnten nicht unmittelbar miteinander verschraubt werden. In größere Komponenten mussten zunächst Gewindeeinsätze für M3-Schrauben eingebracht werden. Diese Metalleinsätze werden erhitzt und in den Kunststoff gedrückt, sodass nach dem Abkühlen ein belastbares Gewinde entsteht.

Dieser Arbeitsschritt erforderte deutlich mehr Genauigkeit als zunächst erwartet. Die Gewindeeinsätze mussten gerade und in der richtigen Tiefe positioniert werden. Bei einzelnen Bauteilen gelang dies nicht vollständig. Besonders im Kopfbereich sind einige Gewinde nicht genau ausgerichtet, weshalb sich dort momentan nicht alle vorgesehenen Schrauben einsetzen lassen. 

Die Bildbeispiele beinhalten nicht alle Komponenten mit Gewindeeinsatz.

7.2 Servo Motoren

Nachdem die benötigten Druckteile fertiggestellt und die Gewindeeinsätze eingebracht waren, bereitete ich die Servomotoren für die Montage vor. Ich ordnete sie ihrer späteren Position im Roboter zu und kennzeichnete sie mit den vorgesehenen Servo-IDs.

Für die Einrichtung verband ich die Servos nacheinander über einen USB-Serial-Bus-Servo-Controller mit dem Raspberry Pi. Dieser übermittelte die Steuerbefehle, während die Motoren über eine separate Stromversorgung versorgt wurden.

Vor dem Einbau brachte ich jeden Servo in seine definierte Ausgangsposition. Dabei müssen die mechanische Stellung des Gelenks und die digitale Position des Motors übereinstimmen. Eine fehlerhafte Ausrichtung kann dazu führen, dass sich ein Gelenk in die falsche Richtung bewegt oder gegen einen mechanischen Anschlag fährt. Dadurch können sowohl der Motor als auch die gedruckten Bauteile beschädigt werden.

Danach setzte ich die Motoren in die vorgesehenen Halterungen ein und verband sie schrittweise miteinander. Die Verkabelung verläuft durch die Füße, Beine und den Körper. Deshalb mussten mechanische Montage und elektrische Verbindung parallel erfolgen. Viele Kabel konnten nach dem Zusammenschrauben einzelner Bauteile nicht mehr problemlos erreicht werden. Die Reihenfolge des Zusammenbaus hatte somit einen erheblichen Einfluss darauf, ob sich die folgenden Arbeitsschritte noch ausführen ließen.

7.3 Elektronik

Integration der elektronischen Komponenten

Nach dem mechanischen Grundaufbau begann die Integration der Elektronik. Ein großer Teil der Komponenten befindet sich im Kopf des Roboters. Dazu gehören der Raspberry Pi  2 W Zero, ein Lautsprecher, ein Mikrofonmodul, LEDs für die Augen sowie eine Kamera als visueller Sensor. 

Im Körper befinden sich unter anderem die Steuerung für die Servomotoren, die Akkus, ein USB-C-Ladeanschluss und ein Battery-Management-System. Das BMS überwacht und schützt den aus zwei Zellen bestehenden Akku, ersetzt jedoch keine geeignete Verkabelung oder stabile Spannungsregelung. Zusätzlich mussten USB-C-Verbindungen, Jumper-Kabel und stärkere Leitungen für die Stromversorgung im begrenzten Innenraum untergebracht werden.

Im seitlichen Kopfbereich sind außerdem zwei zusätzliche Servomotoren für spätere bewegliche Ausdruckselemente beziehungsweise Antennen vorgesehen. Sie sind noch nicht in die Steuerung integriert. Auch für ein außen angebrachtes Licht- oder Projektorelement fehlten im verwendeten 3D-Modell die benötigten Öffnungen. Da mir nur eine ältere Version des Modells vorlag, musste ich die Aussparungen nachträglich von Hand bohren.

Um den Überblick zu behalten, beschreib ich die Kabel und versuchte ein Farbsystem Konsequent durchzuführen. Ground bekam bei mir die Farbe Schwarz, Volt rot und die einzelnen Module wurden auch zugewiesen. Aufgrund der Menge der Verkabelung, konnte das nicht vollständig aufrecht erhalten werden. Zudem mussten einige Kabel mit längeren ersetzt werden. Da Ground und Strom mehrfach verwendet wurden, lötete ich sie auf eine Platte, die ich auch erst zuschneiden musste, damit sie den Anforderungen entsprach.

Platzmanagement und iterative Montage

Eine der größten Herausforderungen war das Platzmanagement. Der Kopf und der Körper bieten nur wenig Raum. Gleichzeitig müssen die Leitungen so geführt werden, dass sie nicht zwischen Bauteilen eingeklemmt werden oder die Bewegung der Gelenke behindern.

Die Montage verlief deshalb nicht linear. Mehrfach musste ich bereits zusammengesetzte Bereiche wieder öffnen, weil Kabel nicht mehr erreichbar waren, Komponenten in einer anderen Reihenfolge eingebaut werden mussten oder eine Verbindung nachträglich verändert werden musste. Auch zum aktuellen Stand wird der Roboter wiederholt geöffnet, da die Hardware noch angepasst und verbessert wird.

Die vorhandene Open-Source-Dokumentation war eine wichtige Grundlage, ließ sich jedoch nicht in allen Punkten unmittelbar auf meinen Aufbau übertragen. Informationen zu Montage, Verkabelung und Software waren teilweise auf unterschiedliche Stellen verteilt oder setzten bestimmte Bauteile voraus. Einige der im Ausgangsprojekt eingesetzten Komponenten sind in Deutschland nicht oder nur schwer erhältlich. Deshalb musste ich nach Alternativen suchen. Diese unterscheiden sich teilweise in ihren Abmessungen, Anschlüssen oder elektrischen Eigenschaften, wodurch die ursprüngliche Anordnung der Komponenten nicht immer übernommen werden konnte.

Der Aufbau bestand dadurch zu einem erheblichen Teil aus Reverse Engineering und iterativer Problemlösung: ausprobieren, messen, Fehler erkennen, Bauteile erneut öffnen und eine angepasste Lösung entwickeln. Bis zu einem weitgehend zusammengesetzten Roboter waren mehrere vollständige Montage- und Korrekturschritte notwendig.

7.4 Software

Software und erneute Servoprüfung

Die Softwareentwicklung begann bereits vor der Abschlusspräsentation. Zu diesem Zeitpunkt existierte ein erster Prototyp für die Sprachinteraktion, der auf meinem MacBook ausgeführt wurde. Nach der Präsentation bestand die nächste Aufgabe darin, diese Funktionen schrittweise auf den Raspberry Pi zu übertragen und mit der physischen Hardware des Roboters zu verbinden.

Langfristig sollen Sprachausgabe, Kopfbewegungen, LEDs, Lautsprecher, Kamera und weitere Ausdruckselemente zu einem gemeinsamen Interaktionsverhalten verbunden werden. Mehrere der benötigten Komponenten sind bereits eingebaut, aber noch nicht vollständig programmiert oder miteinander verknüpft. Die Sprachinteraktion ist daher als getesteter Softwareprototyp zu verstehen, während ihre vollständige Integration in den Roboter noch aussteht.

Parallel dazu musste ich die Motorsteuerung an meinen konkreten Aufbau anpassen. Die Machine-Learning-Policy für die reguläre Laufbewegung stammt aus dem Open-Duck-Mini-Projekt und wurde nicht von mir selbst trainiert. Auf meinem Roboter konnte sie noch nicht sicher ausgeführt werden, da die gleichzeitige Aktivierung mehrerer Motoren zu Spannungseinbrüchen und Hard-Resets des Raspberry Pi führte.

Obwohl die Servos vor der Montage eingerichtet und in eine definierte Ausgangsposition gebracht worden waren, mussten sie nach dem Einbau erneut einzeln geprüft werden. Mechanische Einbaulage, individuelle Nullposition und Bewegungsrichtung können sich von Gelenk zu Gelenk unterscheiden. Deshalb entstand das Hilfsskript `find_one_offset.py`. Es ermöglicht, ein ausgewähltes Gelenk zu untersuchen, während die übrigen Motoren ausgeschaltet bleiben. Das Gelenk wird von Hand in seine mechanische Nullstellung gebracht, anschließend wird die Position ausgelesen und vorsichtig mit geringer Haltekraft überprüft.

Für die Abschlussdemo verwendete ich zusätzlich eine eigene reduzierte Bewegungssteuerung. Sie berücksichtigt die Grenzen der aktuellen Stromversorgung und belastet die Motoren kontrollierter. Die Steuerung ersetzt nicht die vorhandene Machine-Learning-Policy, ermöglichte aber die Demonstration ausgewählter Bewegungen. Nach einer Überarbeitung der Stromversorgung sollen auch komplexere Bewegungsabläufe und die ursprüngliche Laufpolicy getestet werden.

Meine Programme und Anpassungen dokumentiere ich in einem eigenen GitHub-Repository. Dazu gehören der Sprachdialog, der System-Prompt, projektspezifische Konfigurationen sowie die Skripte zur Diagnose und Einzelkalibrierung der Servomotoren. Das Repository enthält ausschließlich Dateien, die für mein Projekt neu erstellt oder von mir angepasst wurden. Quellcode aus dem ursprünglichen Open-Duck-Mini-Projekt wurde nicht dupliziert. Stattdessen verweise ich auf das Originalprojekt.

Videos

7.5 KI Integration

Künstliche Intelligenz spielt in diesem Projekt sowohl als Bestandteil des geplanten Roboters als auch als Werkzeug im Entwicklungsprozess eine wichtige Rolle. Ich habe KI nicht nur für die Sprachinteraktion von Lumi verwendet, sondern auch zur Unterstützung beim Schreiben, Programmieren, Dokumentieren und Verstehen technischer Zusammenhänge.

Bei der sprachlichen Ausarbeitung nutzte ich KI, um eigene Texte zu korrigieren, verständlicher zu formulieren und zu strukturieren. Die Inhalte und Erfahrungen gab ich selbst vor. Die KI half mir dabei, unklare technische Abläufe so zu beschreiben, dass sie auch für Außenstehende nachvollziehbar sind.

Auch bei der Programmierung setzte ich KI unterstützend ein. Für Lumis Persönlichkeit, den System-Prompt und die Gedächtnisdaten legte ich zunächst selbst fest, welche Inhalte, Regeln und Eigenschaften benötigt werden. Die KI unterstützte mich anschließend dabei, diese Vorgaben in eine JSON-Struktur zu übertragen. Dadurch musste ich beispielsweise längere Listen von String nicht vollständig von Hand eingeben.

Den Code für die Speicherung und Verarbeitung von Gedächtnisdaten entwickelte ich teilweise selbst und teilweise mit punktueller KI-Unterstützung. Ich nutzte die KI unter anderem, wenn ich bei einer Funktion unsicher war, eine Fehlermeldung besser verstehen wollte oder nach einer geeigneten Struktur für einen Programmteil suchte.

Das Hilfsskript zur einzelnen Überprüfung und Kalibrierung der Servomotoren entstand ebenfalls mit KI-Unterstützung. Ich beschrieb dafür das konkrete technische Problem, die verwendete Hardware und die notwendigen Sicherheitsbedingungen. Auf dieser Grundlage wurde ein erster Codeentwurf erstellt. Diesen musste ich anschließend an meinem realen Aufbau prüfen, anpassen und hinsichtlich seines Verhaltens bewerten. Da der Code physische Motoren steuert, konnte ich mich nicht allein darauf verlassen, dass er syntaktisch korrekt war. Entscheidend war, ob immer nur der ausgewählte Servo aktiviert wurde, unplausible Messwerte erkannt wurden und am Ende des Tests alle Motoren wieder abgeschaltet waren.

Bei der Erstellung des GitHub-Repositorys nutzte ich KI zur Formulierung der README-Datei, zur Entwicklung einer verständlichen Dateistruktur und zur transparenten Trennung zwischen eigenen Anpassungen und übernommenen Open-Source-Bestandteilen. Auch technische Fragen zur Bauanleitung, zu Komponenten und zu möglichen Fehlerursachen ließ ich mir erklären, wenn die vorhandene Dokumentation für meinen konkreten Aufbau nicht eindeutig war.

Der umfangreiche Einsatz von KI hatte auch mit dem zeitlichen Aufwand des Projekts zu tun. Mechanischer Aufbau, Elektronik, Fehlersuche und Programmierung mussten parallel bearbeitet werden. KI half mir dabei, einzelne Arbeitsschritte zu beschleunigen und schneller einen Ausgangspunkt für weitere Tests zu erhalten. Sie ersetzte jedoch nicht die praktische Überprüfung. Vorschläge konnten technisch falsch, unvollständig oder für meine Hardware ungeeignet sein.

Die Verantwortung blieb bei mir. Besonders bei sicherheitskritischen Bereichen wie Stromversorgung und Motorsteuerung arbeitete ich schrittweise und testete Funktionen zunächst einzeln. In der öffentlichen Dokumentation und im GitHub-Repository kennzeichne ich deshalb transparent, welche Inhalte mit KI-Unterstützung entstanden sind.

Damit wurde in diesem Projekt ein automatisiertes System eingesetzt, um ein weiteres automatisiertes System zu entwerfen. Diese doppelte Rolle von KI ist zugleich Teil meiner Reflexion: KI war sowohl Gegenstand der Gestaltung als auch Werkzeug innerhalb des Gestaltungsprozesses.

Grenzen und kritische Erfahrungen mit KI

Neben den hilfreichen Ergebnissen machte ich auch negative und potenziell gefährliche Erfahrungen mit KI-generierten Empfehlungen. Bei Fragen zur Stromversorgung wurde mir zeitweise vorgeschlagen, den Raspberry Pi direkt an den Akku des Roboters anzuschließen. Diese Empfehlung wäre für meinen Aufbau ungeeignet gewesen.

Das Problem liegt dabei an der Spannung. Mein aus zwei in Reihe geschalteten Zellen bestehender 2S-Akku besitzt eine Nennspannung von ungefähr 7,4 Volt und erreicht im vollständig geladenen Zustand bis zu 8,4 Volt. Der Raspberry Pi benötigt dagegen eine stabile und geregelte Versorgung mit 5 Volt. Eine direkte Verbindung mit dem Akku könnte den Raspberry Pi beschädigen. Deshalb ist ein geeigneter Spannungsregler notwendig.

In diesem Fall konnte ich die fehlerhafte Empfehlung aufgrund meiner Vorkenntnisse im Bereich Elektronik erkennen. Ohne dieses Wissen hätte eine sprachlich überzeugend formulierte Antwort zu beschädigter Hardware oder im ungünstigsten Fall zu einer sicherheitskritischen Situation führen können. Auffällig war außerdem, dass die KI den Fehler nach einem entsprechenden Hinweis zwar bestätigte, ihn zuvor aber nicht selbst erkannt hatte.

KI kann technische Fragen verständlich erklären und bei der Suche nach Lösungsansätzen helfen. Ihre Antworten dürfen jedoch nicht automatisch als fachlich geprüfte Anleitung verstanden werden. Besonders bei Hardware müssen Angaben immer abgeglichen werden.

Für die sinnvolle Arbeit mit KI ist deshalb ein eigenes fachliches Grundverständnis notwendig. Nur mit ausreichendem Vorwissen lässt sich beurteilen, ob eine Antwort qualitativ ist.

7.6 Eigenleistung

Lumi basiert auf dem Open-Source-Projekt Open Duck Mini. Meine Eigenleistung liegt daher nicht in der vollständigen Neukonstruktion des Roboters, sondern in der Anpassung und Erweiterung des Ausgangssystems für meinen konkreten Aufbau und meine gestalterische Fragestellung.

Ein Teil der technischen Anpassungen entstand durch die Auswahl der Komponenten. Einige im Open-Duck-Mini-Projekt vorgesehene Bauteile waren in Deutschland nicht erhältlich oder nur schwer zu beschaffen. Gleichzeitig verfügte ich bereits über geeignete Komponenten, bei denen eine Neuanschaffung allein wegen abweichender Maße nicht sinnvoll gewesen wäre. Deshalb verwendete ich unter anderem vorhandene Audio- und Elektronikmodule, auch wenn diese nicht exakt für das ursprüngliche Modell vorgesehen waren. Abweichende Abmessungen und Anschlüsse erforderten eigene Lösungen: Halterungen und Öffnungen mussten angepasst, Befestigungsmöglichkeiten ergänzt und Steckverbindungen teilweise anders eingesetzt werden.

Auch die elektrische Integration musste ich teilweise selbst herleiten. Die vorhandene Dokumentation bot zwar Orientierung, enthielt jedoch keinen vollständig auf meinen Aufbau übertragbaren Verkabelungsplan. Deshalb plante und realisierte ich die Leitungswege, die Stromversorgung und die Verbindungen passend zu meinen Komponenten. Wiederkehrende Spannungseinbrüche und Neustarts untersuchte ich schrittweise und identifizierte die derzeitige Stromversorgung als wesentliche Schwachstelle.

Zum mechanischen Eigenanteil gehören der Nachdruck fehlerhafter oder instabiler Bauteile, die Auswahl geeigneter Druckmaterialien, nachträgliche Bohrungen sowie wiederholte Anpassungen und Reparaturen des Aufbaus. Aufgrund abweichender Komponenten und teilweise unklarer Montageschritte musste ich den Roboter mehrfach auseinanderbauen und in veränderter Reihenfolge erneut zusammensetzen.

Auf Softwareebene entwickelte ich einen Prototyp für die deutsche Sprachinteraktion mit eigenem System-Prompt und JSON-basierten Gedächtnisinhalten. Für die Hardwarediagnose entstand außerdem das Skript find_one_offset.py, mit dem sich die Servos einzeln prüfen und kalibrieren lassen.

Zusätzlich programmierte ich eigene, reduzierte Bewegungsabläufe für die Demonstration. Die vorhandene Laufpolicy des Open-Duck-Mini-Projekts konnte mit meiner derzeitigen Stromversorgung nicht zuverlässig ausgeführt werden, da die gleichzeitige Belastung vieler Servomotoren zu Spannungseinbrüchen führte. Meine Bewegungsskripte steuern deshalb nur ausgewählte Gelenke und begrenzen die Belastung der Motoren. Dadurch wurde trotz der technischen Einschränkungen eine kontrollierte körperliche Interaktion mit Lumi möglich. Diese Skripte ersetzen die ursprüngliche Laufsteuerung nicht, sondern dienen als sichere Zwischenlösung für den aktuellen Entwicklungsstand.

Meine Programme, Konfigurationen und Anpassungen dokumentiere ich in einem eigenen GitHub-Repository. So entstand aus der Open-Source-Grundlage ein individueller Roboteraufbau mit eigener Persönlichkeit, Sprachinteraktion sowie angepassten Diagnose- und Bewegungsprogrammen.

7.7 Reflexion und Ausblick

Lumi ist als längerfristiges Entwicklungsprojekt angelegt und endet nicht mit dem Abschluss dieses Kurses. Der bisherige Aufbau bildet eine technische und gestalterische Grundlage, auf der in den kommenden Monaten weitergearbeitet werden soll.

Eine wichtige Aufgabe ist die Stabilisierung der Stromversorgung. Das aktuell verwendete Batteriemodul ist für die gleichzeitige Belastung durch die Servomotoren nicht optimal geeignet. Die im ursprünglichen Open-Duck-Mini-Projekt vorgesehene Komponente war in Deutschland nicht verfügbar, weshalb ich auf eine alternative Lösung ausweichen musste. Diese funktioniert vorübergehend, soll zukünftig jedoch durch eine leistungsfähigere und zuverlässigere Lösung ersetzt werden.

Auch einzelne mechanische Bauteile müssen überarbeitet werden. Einige der gedruckten Komponenten erwiesen sich im praktischen Einsatz als bruchanfällig. Besonders das Halsgelenk ist während der bisherigen Tests bereits mehrfach gebrochen und musste neu gedruckt werden. Für eine dauerhafte Nutzung müssen deshalb einzelne Teile verbessert werden.

Darüber hinaus müssen Kabel, Lötverbindungen und das Kabelmanagement überarbeitet werden. Die Servomotoren benötigen unter Last vergleichsweise hohe Ströme. Im Kopf ist der verfügbare Platz sehr begrenzt, weshalb sich die bisherige Kabelführung nur als vorläufige Lösung versteht. Langfristig sollen Kabelwege übersichtlicher, belastbarer und leichter wartbar werden.

Nach der Stabilisierung der technischen Grundlage sollen alle bereits vorgesehenen Module vollständig integriert werden. Dazu gehören eine zuverlässig laufende Kamera, die Audioausgabe über den Lautsprecher, die Verarbeitung von Tönen, die LEDs, das Licht- beziehungsweise Projektorelement und die beiden zusätzlichen Servomotoren im Antennenbereich. Die Antennen sollen nicht nur eine technische Funktion erfüllen, sondern als spielerische Ausdruckselemente eingesetzt werden. Kleine Bewegungen könnten beispielsweise Aufmerksamkeit, Neugier oder Unsicherheit vermitteln und damit zur Persönlichkeit des Roboters beitragen.

Ein wesentlicher nächster Entwicklungsschritt ist ein zusätzliches Interaktionsmodell, das ohne natürliche Sprache auskommt. Lumi soll perspektivisch auch durch Töne, Körperhaltung, Blickrichtung und Bewegungen mit mir kommunizieren können. Dafür möchte ich wiederkehrende Interaktionsmuster entwickeln, durch die der Roboter angemessen auf bestimmte Situationen und Handlungen reagiert. Diese Muster sollen nachvollziehbar und konsistent sein, damit die Reaktionen nicht zufällig wirken und sich mit der Zeit eine verständliche Form der Kommunikation entwickeln kann.

Die bereits entwickelte Sprachinteraktion wird dadurch nicht zwangsläufig ersetzt.  Besonders interessiert mich jedoch die Frage, ob sich auch ohne gesprochene Sprache ein Gefühl von Aufmerksamkeit, Vertrautheit und gegenseitigem Verständnis entwickeln kann. Dabei orientiere ich mich sowohl an menschlicher Körpersprache als auch an der Kommunikation zwischen Menschen und Tieren.

Im Forschungskontext ergeben sich daraus mehrere Fragen: Wie lernen Menschen die nichtsprachlichen Signale eines Roboters zu verstehen? Wie konsistent müssen Töne und Bewegungen eingesetzt werden, damit ihnen eine Bedeutung zugeschrieben wird? Und wie kann eine wertschätzende Beziehung zu einem technischen System entstehen, das keine natürliche Sprache verwendet, aber auf die anwesende Person reagiert?

Auch Lumis Gedächtnis soll weiterentwickelt werden. Der aktuelle Prototyp arbeitet mit statischen Informationen, die zuvor in einer JSON-Datei festgelegt wurden. Neue Informationen können bisher nicht selbstständig und gezielt ergänzt werden, ohne dass ich den Code oder die gespeicherten Daten manuell bearbeite. Langfristig soll ein dynamischeres Gedächtnismodell entstehen, das relevante Informationen aus Interaktionen auswählen, speichern und in späteren Situationen wieder aufgreifen kann. 

Aufbauend auf den im Projekt bereits entstandenen technischen Anpassungen und eigenen Softwarelösungen möchte ich Lumi langfristig zunehmend über die ursprüngliche Open-Source-Grundlage hinaus weiterentwickeln. Neben der individuellen Gestaltung und Interaktionsprogrammierung sollen dabei auch technisch wiederverwendbare Lösungen entstehen. Wenn meine Anpassungen ausreichend getestet und dokumentiert sind, möchte ich sie der Open-Duck-Mini-Community zur Verfügung stellen. Auf diese Weise möchte ich nicht nur von einem Open-Source-Projekt profitieren, sondern die im Rahmen der Entwicklung gewonnenen Erfahrungen und eigenen Lösungen zukünftig selbst in die Community zurückgeben.

Money, Money, Money

Kosten und Komponenten

Auch wenn sich der Lerngewinn eines solchen Projekts nur schwer in Zahlen ausdrücken lässt, werde ich es trotzdem versuchen. Nach einer vorläufigen Schätzung belaufen sich die bisherigen Kosten auf rund 500 Euro. 

Den größten Anteil daran hatten die 14 Feetech-Servomotoren der vorgesehenen 19-Kilogramm-Klasse. Zusammen kosteten sie rund 340 Euro. Günstigere Motoren hätten zwar das Budget geschont, aber nicht ohne eine umfangreiche Anpassung des 3D-Modells in die vorhandenen Halterungen gepasst. Für den zeitlichen Rahmen des Projekts war dieser zusätzliche Umbau nicht realistisch.

Die restlichen Kosten verteilen sich auf Raspberry Pi, Elektronik, Akkus, Stromversorgung, Kabel, Befestigungsmaterial und 3D-Druck. Arbeitszeit, vorhandene Werkzeuge und einige Fehlkäufe sind dabei noch nicht vollständig eingerechnet. Da Lumi weiterentwickelt wird, dürfte es außerdem nicht bei diesen 500 Euro bleiben... :)