Das Pilotprojekt des ersten Mastersemesters an der HAWK Gestaltung fiel im Sommersemester 2019 unter dem Thema Social Design. Das Projekt sah vor zunächst eine eigene Vorstellung von dem Thema zu bekommen und sich anschließend ein Problem zu suchen, welches einer Lösung bedarf. Die Lösung konnte dabei ein Konzept oder auch ein Artefakt sein, welches einen Ansatz zur Problemlösung bietet. Social Design ist für uns eine Form der Gestaltung, die eine Verbesserung der Gesellschaft und deren Lebensbedingungen für die Menschen als Ziel hat. Unser Interesse gilt einem leichten Einstieg in technische und zukunftsorientierte Themen für Kinder und Schüler.

Fachkräftemangel in MINT Berufsfeldern angehen

In unserer Projektgruppe haben wir uns mit dem Problem des Fachkräftemangels in den MINT Berufsfeldern befasst. Im Allgemeinen besteht das Problem darin, dass neue Generationen nur schwer an technische Berufe herangeführt oder vorbereitet werden können. So sagt eine Studie der Wirtschafts- und Beratungsgesellschaft PwC mit 2000 befragten Schülern und Studierenden:

“Die Mehrheit der jungen Menschen, also je 61 % der Schüler und Studierenden, wünscht sich mehr Beratung und Information zu MINT- Berufen. Allerdings gaben auch 76 % der Studierenden und 75 % der Schüler als Hauptgrund gegen eine MINT-Karriere einen Mangel an persönlichem Interesse an. Die Schwierigkeit der Ausbildung ist für 37 % der Studierenden und knapp ein Viertel der Schüler ausschlaggebend für eine Entscheidung gegen einen entsprechenden Beruf. 22 % der Studierenden und 21 % der Schüler gaben an, dass ihnen die Kreativität in diesen Fächern fehlen würde.” [QUELLE 01]

Dieselbe Studie weist auf einen Fachkräftemangel und ein Fehlen von 470.000 Arbeitskräften in MINT-Berufen hin. Es wird klar, dass junge Menschen zu spät an Technologien und deren zumeist komplizierte, Fremdsprachen ähnliche Aufbauweise herangeführt werden. Es fehlt ihnen an Perspektive, Weitsicht und an Vorbildern. Dies gilt besonders für Frauen, so die Studie, denn besonders dort fehle es an Vorbildern in der Technologie-Branche. Daher wird eine frühzeitige Aufklärung und ein frühzeitiges Entdecken von Talenten für die MINT-Branche gefordert.

In der Gruppe sind wir zu der Überlegung gekommen, dass wir dieses Problem bereits im Grundschulalter angehen wollen. Die Schule hat die Aufgabe jungen Schülern wichtige Grundkenntnisse für die spätere Schul- und Ausbildungszeit zu vermitteln. Im Grundschulalter wird der Grundstein für das Interesse der Schüler gelegt. Sie kommen in Kontakt mit verschiedenen Sprachen und Wissenschaften.

Wir sind der Meinung, dass das Aneignen technischer Fähigkeiten auch eine Grundkenntnis für die nächsten Generationen sein muss, um die bisherigen Hürden der MINT Berufe zu überwinden. Je früher und professioneller der Kontakt zu technischen Möglichkeiten hergestellt wird, umso höher ist die Erfolgschance bei Kindern Interesse zu entfachen und ihnen den richtigen Umgang beizubringen.

Um dies zu erreichen haben wir nach einer Möglichkeit gesucht den Kindern einen solchen Einstieg zu gewährleisten. Ziel sollte es sein für sie bereits bekannte Abläufe, die sie vom Umgang mit Spielsachen kennen, miteinzubeziehen, um für ein besseres Verständnis zu sorgen. In der Kombination mit Technik, die sie bisher nicht aus ihrem Alltag kennen, soll ihre Faszination für Neues geweckt werden. Der Ablauf der Interaktionen soll unbewusst und spielerisch bei den Schülern einen Lerneffekt erzielen, durch den sie die Grundlagen des Programmierens verstehen können, ohne mit der Herausforderung explizit konfrontiert zu sein.

Das Konzept

Die Idee ist es Kindern den Umgang mit zukünftiger Technik, spielerisch mit Hilfe eines Roboterarms zugänglich zu machen.

Dafür sollen Kinder den Roboterarm selber “programmieren” dürfen, indem sie Weg und Actions beschreibende Karten auf einem Tisch auslegen. Eine Kamera, die über dem Tisch positioniert sind, erfasst die ausgelegten Karten und eine Weiterverarbeitung mit einem Raspberry Pi generiert aus den Kameradaten Befehle für die Bewegungen des Roboterarms. Die Kinder sind dann in der Lage dem Roboterarm Anweisungen zu geben, um zum Beispiel einen Ball aufzunehmen und in einer Schale fallen zu lassen.

Ziel ist es, dass die Karten in diesem Fall eine Art Programmiersprache darstellen, die von den Kindern verstanden und verwendet werden kann. Dadurch soll ihnen ein Bewusstsein vom menschlichen Einfluss in automatisierter Technik vermittelt werden.

Der Input stellt den ersten Schritt des Ablaufs dar. Dieser soll dadurch funktionieren, dass die Nutzer mit Karten einen Ablauf von Roboteraktionen legen, um eine Lösung für den aufgebauten Parcours des Roboterarms zu schaffen. Die erste Problemstellung ist demnach, wie der Input die Informationen der Kartenaktionen generiert.

Ein erster Ansatz stellte die Lösung über NFC-Chips in Kombination mit Arduino dar. Aufgrund des wahrscheinlichen Umfangs an Kabeln und der benötigten Masse an Sensoren, haben wir uns gegen diese Möglichkeit entschieden. Letztendlich entschieden wir uns für die Umsetzung mit einer Kamera am Steuertisch, welche die Funktionen der Karten über die Farbgebung erkennt.

Bei unserem Prototypen waren sechs Funktionen nötig, die jeweils einen Farbcode als Erkennung benötigten. Dabei wurde der HSB-Farbraum genutzt, der die Reduzierung auf den Farbton möglich machte. “Start” bekam den Farbwert H 120 (grün), “Ende” den Farbwert H 0 oder 360 (rot), “Geradeaus” den Farbwert H 240 (dunkelblau), “Kurve” den Farbwert H 60 (gelb), “Greifen” den Farbwert H 300 (lila) und “Loslasen” den Farbwert H 180 (hellblau). Allen anderen Farbtöne, die außerhalb der Werte und ihrer Toleranzbereiche liegen, wurden keine Funktionen zugeschrieben. Diese Farbtöne befinden sich jeweils in der linken oberen Ecke der Befehlskarten.

Im Programm wurde ein Raster angelegt, welches den Bereich des Tischs in die Bereiche der Karten einteilt. Dort untersucht das Script jede der vier Ecken einer Karte den Farbwert nach einem Farbton mit Funktion. Wegen der möglichen wechselnden Lichtverhältnisse haben die Farbwerte einen Toleranzbereich von plus minus 20.

Nicht nur die Farberkennung ist dabei wichtig, sondern auch die Ausrichtungserkennung der Karten. Da diese auf dem Feld gewendet werden können, muss auch dies das Programm erkennen können, damit der Roboterarm den richtigen Weg einschlägt. Dafür wird in dem Raster nicht nur erkannt, ob der geprüfte Farbwert eine Funktion hat, sondern auch in welcher Ecke der Farbwert mit Funktion erkannt wurde. Dadurch lässt sich vom Programm erkennen, wie die Karte ausgerichtet ist.

Zum Testen dieser Funktionen, ohne von dem Aufbau des Prototypen abhängig zu sein, wurde ein beispielhaftes Raster erstellt, welches zur Prüfung der Erkennung von Farbe und Ausrichtung dient.

Diese Informationen wurden in einem Array abgespeichert damit das Script für die nächsten Schritte vorbereitet ist.

Die Verarbeitung der Kameradaten ist der zweite Schritt, für den wir eigens ein Script entwickelt haben, welches die ausgelegten Karten auf einen logischen und für den Roboterarm ausführbaren Aufbau prüft.

1.  Dafür muss dass Kartenmuster gewisse Kriterien erfüllen:
2. Es muss ein Startfeld existieren.
3. Es darf kein weiteres Startfeld existieren.
4. Der beschriebene Pfad darf nicht unterbrochen sein.
5. Der Pfad muss ein Ende haben.
6. Auf jede Greif-Action muss eine Ablege-Action folgen bevor das Ende erreicht wird oder erneut eine Greif-Action folgt.
7. Jeder Ablege-Action muss eine Greif-Action vorangegangen sein.

Erkennt das Script all diese Bedingungen als erfüllt, generiert es aus den nacheinander geprüften Karten eine Befehlskette welche wie folgt aussehen kann.

An den ersten beiden Stellen einer Befehlskette befindet sich die X,Y Koordinate für den Startpunkt, darauf folgen die Einzelschritte und zum Schluss das Endsignal.

Mit einer generierten Befehlskette ist das Script bereit für den nächsten Schritt der Roboterarm-Steuerung und lässt dafür einen Button neben dem Kartenfeld aufleuchten, dessen Bestätigung den nächsten Schritt auslöst.

Wenn eine Befehlskette erstellt und bestätigt wurde, wird diese von einer weiteren Funktion des Scripts nach und nach in Einzelbefehle an den Roboterarm gesendet. Dabei unterscheiden wir zwischen drei Arten von Befehlen.

Die erste ist die Ansteuerung der einzelnen Robotergelenke und ermöglicht es so den Roboter in einer gewünschte Haltung(Pose) zu versetzen indem wir festlegen, welche Gelenke, wie weit rotiert sein sollen. Hier besteht jedoch auch die Gefahr den Roboter in sich selbst hineinzusteuern und dabei Schäden zu riskiert. Deshalb sollte diese Befehlsart nur sehr vorsichtig getestet werden.

„movej([0, -1.4, -1.2, -2.0, 1.6, -1.2291], a=0.5, v=0.5) \ .

Die zweite Befehlsart ist die der Angabe einer Zielposition (x,y,z) im Raum mit Angabe der Ausrichtung. Der Roboter fährt dabei seine Gelenke automatisch von der Ursprungshaltung in die Zielhaltung, um mit dem Werkzeug in der gewünschten Ausrichtung zu sein. Dabei bewegt der Roboter seine Gelenke so, dass er zum Erreichen der Zielposition nur die geringstmögliche Rotation ausüben muss. Das kann unter Umständen auch dazu führen, dass die angenommene Pose, nach mehreren vom Roboter automatisch entschiedenen Posen, irgendwann unpraktisch wird und andere Posen gar nicht mehr erlaubt. Das Problem wird in unserer Anwendung durch eine vorgegebene Ausgangshaltung mit festgelegten Gelenkrotationen vorgebeugt.

“ 0, -3.14159, 0], \n“ .

Die dritte Befehlsart ist die der Werkzeugsteuerung. Hier wird mit einer Befehlszeile eine Angabe darüber gemacht ob die Zange des Roboterarms geschlossen oder geöffnet werden soll.

„set_tool_digital_out(0, B) \n“ .

Der Roboterarm führt je Befehl eine Aktion aus, die aus einer Bewegung oder der Werkzeugnutzung bestehen kann. Nach ca. zwei Sekunden erhält der Roboterarm den nächsten Befehl in der Befehlskette. Ein Ziel ist es die Zeitverzögerung zu entfernen und stattdessen auf ein Signal vom Roboter zu warten, wann dieser den letzten Befehl beendet hat und einen neuen Befehl abwartet.

Das Kamera- und RPi-Gehäuse

Der Prozess des Inputs, der Verarbeitung und des Outputs stellt das Herzstück des Projektes dar. All diese Schritte an einem Punkt zu bündeln hat uns dazu gebracht einen weiteren Prototypen für ein geschlossenes Kamera-zu-Roboter-System zu bauen, welches als Standalone System auch außerhalb unserer Montur, an anderen Positionen und mit anderen Robotern funktionieren kann.

Für das geschlossene Kamera-zu-Roboter-System mussten alle notwendigen Komponenten Platz in einem kleinen Gehäuse finden. Um den Platzbedarf und die Anordnung zu prüfen wurde ein 3D-Modell des Aufbaus angefertigt.

Im Anschluss wurde das Gehäuse gedruckt und alle Komponenten in ihr verbaut.

Die Karten für den Tisch stellen eine Programmiersprache dar, die jedoch auch von Kindern verstanden und nutzbar gemacht werden muss. An diesem Punkt wurden in der Gruppe mehrere Designvorschläge besprochen und verbessert. Unter anderem bestand kurzzeitig die Idee, Richtungshinweise durch Kinder zeichnen zu lassen. Diese Idee wurde jedoch schnell verworfen, da eine Zeichnung durch ein Kind nicht gleich bedeutet, dass andere Kinder diese Zeichnung auch verstehen. Daher wurde sich im Designprozess der Karten stark an Symbole und Farben orientiert, die Kinder bereits aus dem Alltag gewohnt sind oder bereits gesehen haben können. Da die Karten für den Auslesevorgang durch die Kamera und das dahinter arbeitende Programm jedoch größtenteils dunkel, bzw. möglichst einfarbig gehalten werden sollten, musste sich hier auf wenig Möglichkeiten in der Farbgebung eingestellt werden. Als Grundbausteine für die Anwendung sollten eine Karte für den Anfang, für eine Gerade, für eine Kurve, zum Aufheben eines Gegenstandes, zum Ablegen eines Gegenstandes und für das Ende gestaltet werden. Dabei kam früh die Idee auf, sich an Stadt bzw. Fahrplänen zu orientieren.

Das erste Design arbeitet mit den Farben Rot, Grün und Blau um leitgebende Elemente zu definieren. Grüne Pfeile stellen hierbei den Start und das Aufnehmen eines Objektes dar, Rote Pfeile den Endpunkt und das Ablegen eines Objektes durch den Roboter. Im Team wurde jedoch festgestellt, dass der Entwurf nicht sofort intuitiv verstehbar ist, da ein Kind die Symbole auch durchaus anders deuten kann.

Ein darauffolgender Entwurf, mit zwei Farbvarianten, versuchte ganz ohne Farben auszukommen. Der Start- und Endpunkt wurden hier durch Schriftzüge ersetzt, was allerdings die Nutzbarkeit der Anwendung auf Kinder, im Grundschulalter und mit ausreichend Leseverständnis, reduziert. Das Aufheben und Ablegen eines Objektes wurde in diesen beiden Varianten durch einen Roboter-Greifer dargestellt. Da der später für die Anwendung verwendete UR5E eine solche Greifvorrichtung besitzen würde, schien diese Symbolik für die Kinder besser verknüpfbar zu sein, als das vorhergehende Pfeil-Design.

Eine weitere Idee bestand darin, mit Händen als Informationsträger zu arbeiten. Dies hat den Vorteil, dass man hier mit etwas arbeitet, dass den Kindern mit absoluter Sicherheit bekannt ist und von Menschen im generellen zur Informationsübertragung genutzt wird. Dennoch sollen die Kinder mit der Anwendung des Roboters vertraut gemacht werden , was wiederum gegen Hände als Symbole sprach.

Auch ein Smiley-Design stand kurz zur Debatte, um den vollendeten Weg zu markieren, zeigte sich aber ähnlich wie die Hände als nicht zielführend.

Da bereits die Wegführung durch Stadt- und Straßenpläne inspiriert war, entstand auch ein Design für den Anfangs- und Endpunkt mit ähnlicher Anlehnung. Dieser Start- und Stop-Schild-Entwurf sollte den Kindern durch bereits bekannte Straßenbeschilderung die Aufgabe der jeweiligen Karte vermitteln.

Zu Anfang stellte sich die Frage, was die Aufgabe des Prototyps sein würden und was dafür gebraucht wird. Die Robosandbox teilt sich in zwei Teile auf: den Kartentisch und den Robotertisch. Auf dem Kartentisch sollen die Kinder mit den Karten ihren Weg für den Roboter legen. Dabei dürfen die Karten nicht verrutschen, was eine Befestigung oder einen Rahmen für die Karten sinnvoll macht. Zugleich müssen die Karten durch eine Kamera ausgelesen werden, welche in einem ausreichenden zentrierten Abstand über den Karten platziert sein muss. Zusätzlich zu der Kamera kommt noch weitere Hardware, wie z.B ein Raspberry Pi oder LEDs zur Beleuchtung des Kartentischs, welche verstaut werden müssen. Für beide Teile wurde sich in der Gruppe als Grundbasis für einen einfachen 55x55cm Tisch von Ikea entschieden [QUELLE 02]. Für den Kartentisch wurde auf dem Tisch eine Holzplatte mit Ausfräsungen für die Karten platziert. Diese wurde mit einer CNC Fräse an der HAWK vorgenommen.

Für die Aufhängung der Kamera über den Karten gab es mehrere Entwürfe, schließlich wurde sich für einen Entwurf mit zwei Trägern entschieden. Dieser besteht aus zwei Aluminiumstangen, welche jeweils gegenüber voneinander an den Außenseiten des Kartentisches befestigt sind. Auf diesen sind in einer Höhe von etwa 80+-cm ein Mittelteil aufgesetzt, welches die Box mit der Kamera und Hardware trägt. Durch eine Kombination von Gewinden und Federn, lässt sich die Box im Inneren des Mittelteiles sehr genau justieren.

Der Mittelteil, die Hardware-Box, die Halterungen für die Träger, sowie die Auflagen für die Karten und die Halterung für den LED-Knopf wurden mittels 3D Druck erstellt. Hierbei wurde PLA und PLA++ in einer Ebenenstärke von 0,1-0,2 mm mit einem Creality 3D-Drucker verarbeitet. Die optimale Drucktemperatur dieser Materialien lag je nach Hersteller zwischen 210 und 225 Grad Celsius mit einer Bett-Temperatur von 60 Grad Celsius. Beim 3D Druck wird ein Objekt aus tausenden einzelnen Ebenen zusammengesetzt. Um Überhänge zu stützen wird ein sogenannter Support eingefügt, der später wieder entfernt wird. Der Druck selber ist fast nie ein gefüllter Druck. Das sogenannte Infill entscheidet zu wie viel Prozent und mit welchem Muster ein Druck gefüllt wird. Ein Druck kann mit 15% Prozent gefüllt sein oder mit 50%. Die Stärke des Infill, kombiniert mit der Stärke der Außenwände, beeinflussen die Dauer des Druckes, sowie das Gewicht und die Belastbarkeit des späteren fertigen Druckes.

Das Drucken von solch großen Teilen zeigte sich als sehr zeitaufwendig und durchaus fehleranfällig. Daher wurde vor dem Prototypen wurde bereits eine vereinfachte Version, zum Erproben der Hard- und Software erstellt.

Der Druck bestand aus fünf Teilen für die Halterung der Träger und dem Mittelteil ohne Hardwarebox. Diese wurden nach dem Druck ausgearbeitet und lackiert.

Die Animation soll einen möglichen Ablauf der Anwendung simulieren. Die Figur, die dabei die Anwendung betätigt, ist mit Absicht möglichst undefinierbar dargestellt. Heißt: Man kann ihr durch ihre Form und Darstellung weder Alter, noch Geschlecht oder eine ethnische oder religiöse Herkunft zuordnen.

Der Raum, in dem sich die Szene befindet, ist einem Kursraum in der HAWK nachempfunden. Er ist einfach gehalten und soll mit seiner Gestaltung und seiner Einrichtung ein Gefühl dafür geben, in welchem Umfeld das Produkt eingesetzt oder vorgestellt werden könnte. Gleichzeitig kann man den Raum flexibel umgestalten oder gar ganz ersetzen um z.B. eine Expo Szenerie darzustellen.

Der Kartentisch befindet sich auf einem gewöhnlichen Tisch wie man ihn aus der HAWK kennt. Diese Art der Platzierung entspricht auch der späteren realen Platzierung des Prototyps. Zuerst war geplant, dass der Ikea Tisch samt Beine verwendet wird. Dies stellte sich aber als eine zu geringe Höhe heraus und wurde daher durch die neue Platzierung auf einem gewöhnlichen Tisch ersetzt, bei der die Beine des Ikea Tischs wegfallen. Der Roboter selbst mit seinem Sandkasten steht hinter einer Glasscheibe zwischen zwei Tischen. Diese enge Platzierung soll vermeiden, dass Kinder sich zwischen Tisch und Glas hindurch quetschen und so an den Roboter gelangen. Der Glaskasten selbst verhindert, dass die Kinder von vorne auf den Sandkasten greifen und damit in die Reichweite des Roboterarms gelangen. Später wird zusätzlich zu dem, was in der Animation zu sehen ist, auch stets eine Person hinter dem Roboter stehen und es wird gegebenenfalls einen geschlossenen Glaskasten geben, in welchem sich Roboter und Sandkasten befinden.

Zu sehen ist die Figur, die an den Tisch mit den Karten herantritt und beginnt diese aufzunehmen und zu legen.

Das Kartenlegen selbst wird nun aus einer erhöhten Einstellung gezeigt, ähnlich der, der Kamera in der Hardware Box. Nachdem alle Karten gelegt sind leuchtet der grüne Knopf auf. Der Vorgang kann beginnen.

Nun bewegt sich der Roboterarm entlang der ihm zugewiesenen Strecke und führt die ihm zugewiesenen Funktionen aus.

Von oben wird der vom Roboter-Arm zurückgelegte Weg noch einmal sichtbar.

Die Animation dient als Vorstellungs- und Erklärungsvideo für den Prototypen. Sie soll Nutzern den Vorgang erklären und bildlich und ohne Text verständlich machen. Dies ist besonders wichtig, da bereits im Kartendesign entschieden wurde, auf Text jeglicher Art zu verzichten. Da die Simulation sich selbst erklärt, wird auch kein Sprecher benötigt und somit in lauten Umgebungen wie einer Expo, auch keine Untertitel.