Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- projektewise24:projekt6:doku [2025/03/31 02:27]
uszer [Code und Software]
+++ projektewise24:projekt6:doku [2025/03/31 03:22] (aktuell)
uszer [Reference]
@@ Zeile 28: / Zeile 28: @@
 Einer Grundplatte, auf der sich der Rest des Roboters befindet, die für das horizontale schwenken verantwortlich ist.
 Der Halterung des Roboters, die auf der Grundplatte installiert ist und den Roboter vertikal kippen kann:\\
-{{ :projektewise24:projekt6:tilt_mechanism.png?200 |Hier nicht-transparent }}
+{{ :projektewise24:projekt6:tilt_mechanism.png?200 |Hier nicht transparent}}
+<sup>Abb.1: CAD-Skizze des Frames und der Riemenverbindung zum Neigen der Gun</sup>
-Der Trigger und die Magazine-Schiene, die das Schießen und Nachladen übernehmen:{{ :projektewise24:projekt6:cad_mag-slide-trigger.png?200 |Das Magazin auf der Magazin-Schiene und der Trigger}}
+Der Trigger und die Magazine-Schiene, die das Schießen und Nachladen übernehmen:
+{{ :projektewise24:projekt6:cad_mag-slide-trigger.png?200 |Das Magazin auf der Magazin-Schiene und der Trigger}}
+<sup>Abb.2: CAD-Model der Magazin-Mechanik</sup>
 Und der Abschuss-Mechanismus, bestehen aus den Flywheels und der Kamera Halterung. //Mehr zu den Flywheels [[projektewise24:projekt6:doku#Einzelne Systembestandteile: Schießen und Nachladen|hier]]//
 {{:projektewise24:projekt6:flywheel_nocage.jpg?100|Flywheels}}
+<sup>Abb.3: Foto, geöffnete Flywheels eines N-Strike Elite Stockade Blasters</sup>
 Der Roboter muss in der Lage sein, sich frei auf seinen Rotationsachsen bewegen zu können, weshalb das Entwerfen der Mechanik sowie der physischen Teile sehr viel Zeit in Anspruch nahm.
@@ Zeile 41: / Zeile 45: @@
 Der Arduino sorgt für einen konstanten Stromfluss im Breadboard, über das alle anderen Komponenten verkabelt sind. Der Microswitch wird hier durch einen normal Pushbutton dargestellt, wird aber auf die gleiche Art und Weise angeschlossen. Nur wenn der Knopf gedrückt wird, kann der Arduino einen Stromfluss am Pin 12 ablesen.\\
 Die Flywheels, die im Grunde aus zwei zusammengelöteten DC-Motoren bestehen, sind mit ihrem Power-Kabel an die vom Arduino ausgegebenen 5V angeschlossen, und mit ihrem GND-Kabel an den nMOS. Dieser funktioniert als ein simples Logic-Gate: nur wenn der "Gate"-Pin des nMOS vom Arduino angesteuert wird, kann Strom zwischen dem "Source" und "Drain"-Pin fließen und dadurch die Motoren an- und ausschalten.
+<sup>Abb.4: Schaltplan zum Anschließen aller elektronischen Bestandteile an den Arduino</sup>
 -----
@@ Zeile 49: / Zeile 55: @@
 {{ :projektewise24:projekt6:tracking_roaming_failedendmarker.mp4 |Software+Terminal während des Trackens, Roamens und Crashens}}
+<sup>Vid.1: Screenrecording, Program state check</sup>
 Die Bewegungen der Servos sowie der Zustand des Roboters (searching, aiming, locked) werden dann berechnet, und als Datensatz an den Arduino gesandt. Da der Computer als einziges die Daten der Kamera erhält und verarbeitet, ist die fehlerlose Weiterleitung der interpretierten Daten an den Arduino der wichtigste Vorgang im gesamten Prozess. Dadurch ist die [[projektewise24:projekt6:doku#Einzelne Systembestandteile: Kommunikation zwischen Arduino und Computer| Kommunikation zwischen Arduino und Computer]] am anfälligsten für Errors, war eine der größten Herausforderungen im gesamten Bearbeitungsprozess, und läuft immer noch nicht völlig zuverlässig.
@@ Zeile 61: / Zeile 68: @@
 ===Einzelne Systembestandteile: Die Bewegung des Roboters===
 Der Roboter hat zwei unabhängig voneinander ansteuerbare Rotationsachsen, auf denen er sich in einem Bereich von etwa 10° bis 170° bewegen kann, abhängig von den Winkelgrenzen der eingesetzten Servo-Motoren.\\
 {{:projektewise24:projekt6:tilt_mechanism_belt_front.png?200 |}}
 Der für die horizontale Rotation verantwortliche pan-Motor ist der größten Belastung ausgesetzt, und befindet sich unterhalb des Roboters innerhalb der Grundplatte. Von dort aus treibt der Motor über ein simples Getriebe die Grundscheibe an. Durch genaues Drucken des Getriebes ist eine präzise Steuerung und eine hohe Kraftübertragung möglich.\\
 Der tilt-Servo sitzt direkt auf der Grundplatte und steuert über einen Riemen die Neigung der Gun, und ist durch diesen Riemen verbunden mit einem Rahmen um den Hauptteil des Roboters. Dadurch kann der gesamt "Kopf", bestehend aus dem Trigger, dem Magazin, den Flywheels und der Kamera ohne Probleme noch unten und oben gekippt werden. Um Kollision mit der Grundplatte zu vermeiden, sitzt der Kopf etwa 10cm über der Grundplatte, und erlaubt dadurch theoretisch eine volle Umdrehung.
+<sup>Abb.5: Skizze, Frontansicht des Neigungsmechanismus mit Riemen</sup>
 ===Einzelne Systembestandteile: Schießen und Nachladen===
 {{ :projektewise24:projekt6:flywheel_test_5darts.mp4|Manueller Test der Flywheels}}
 Der Roboter nutzt sogenannte "Flywheels" um die Darts abzuschießen. Flywheels sind im Grunde zwei einander gegenüberliegende, gegensätzlich rotierende Scheiben. Die Darts werden von einem Trigger zwischen diese Scheiben geschoben, die durch ihre Geschwindigkeit und Reibung den Dart stark beschleunigen.\\
 Die Darts werden in ein beliebig erweiterbares gedrucktes Magazin geladen. Dieses Magazin wird auf der Magazin-Schiene vor dem Trigger platziert, um dann vom Magazin-Servo Motor am Trigger entlang bewegt zu werden. Das Magazin verfügt über Erhöhungen auf der Oberseite, die einen Micro Switch, der direkt über dem Zentrum des Triggers angebracht ist, drücken. Sollte dieser Knopf gedrückt werden, so weiß der Arduino, dass das Magazin mit einer Kammer nun direkt zwischen dem Trigger und den Flywheels liegt, und sich nichts verkantet.
-Der Trigger verfügt über Zähne auf einer Seite, wodurch die Rotationsbewegung des Trigger-Servos und des daran befestigten Zahnrads in eine lineare Bewegung umgesetzt werden. Der Trigger wird in das geladene Magazin geschoben, und drückt dadurch den Pfeil zwischen die Flywheels. Das Magazin wird dann weiterbewegt, bis die nächste Kammer ausgerichtet ist. Sollten alle Pfeile verschossen worden sein, so wird das Magazin automatisch ausgeworfen.
+Der Trigger verfügt über Zähne auf einer Seite, wodurch die Rotationsbewegung des Trigger-Servos und des daran befestigten Zahnrads in eine lineare Bewegung umgesetzt werden. Der Trigger wird in das geladene Magazin geschoben, und drückt dadurch den Pfeil zwischen die Flywheels. Das Magazin wird dann weiterbewegt, bis die nächste Kammer ausgerichtet ist. Sollten alle Pfeile verschossen worden sein, so wird das Magazin automatisch ausgeworfen.
+<sup>Vid.2: Video, Flywheel Demonstration</sup>
 //Note: Der Arduino weiß tatsächlich nicht, ob überhaupt ein Magazin geladen ist, er reagiert einzig und allein auf die Aktivierung des Mikro Schalters. Ist das Ende des Magazins erreicht, so wird der Schalter nicht mehr gedrückt, und der Magazin-Servo schaltet sich nicht aus.//
@@ Zeile 81: / Zeile 91: @@
 {{:projektewise24:projekt6:prototype_frontal.jpg?300|Frontalansicht: 2 Servos und LEDs}}
 {{:projektewise24:projekt6:prototype_top.jpg?300|Aufsicht: 2 Servos und LEDs}}
-{{:projektewise24:projekt6:prototype_tilt.jpg?300|Nahaufnahme Neigung}}
+{{:projektewise24:projekt6:prototype_tilt.jpg?300|Nahaufnahme Neigung}}\\
+<sup>Abb.6: Foto: Frontalansicht des Prototypens, Abb.7: Foto, Draufsicht des Prototypen, Abb.8: Foto, Nahaufnahme des Neigungsmechanimsus im Prototypen</sup>
 Alles Videomaterial in dieser Dokumentation wurde mithilfe des Prototypen erfasst.
@@ Zeile 114: / Zeile 125: @@
 {{:projektewise24:projekt6:nstrikeelite_stockade.png?300 | Original Blaster}}
+<sup>Abb.9: Foto, Geöffneter Flywheel-Cage</sup>
+<sup>Abb.10: Screenshot, N-Strike Elite Stockade Blaster, Quelle der verbauten Flywheels</sup>
 ===Limit Switch===
@@ Zeile 126: / Zeile 140: @@
 Das Magazin besteht aus einer 17mm hohen und 70mm dicken Platte, in die beliebig viele Kammern eingefügt werden können. Jede Kammer hat einen Durchmesser von 13mm, und eine Wanddicke in alle Richtungen von 2mm. Dadurch ergibt sich folgende Formel für die Länge des Magazins:\\
 {{:projektewise24:projekt6:equation_maglength.png?200 |Formel zum berechnen der Länge des Magazins in mm}}
-//Hier bei gibt "n" die Anzahl der Kammern an, also die Kapazität des Magazins. Bei unserem fertig modelliertem Magazin handelt es sich um ein Magazin mit einer Kapazität von 11 Darts, also einer Länge von 167mm//
+//Hier bei gibt "n" die Anzahl der Kammern an, also die Kapazität des Magazins. Bei unserem fertig modelliertem Magazin handelt es sich um ein Magazin mit einer Kapazität von 11 Darts, also einer Länge von 167mm//\\
+<sup>Abb.11: Screenshot, Formel zum Berechnen der Länge des Magazins in Abhängigkeit von der Kapazität</sup>
 Mittig über jeder Kammer befindet sich eine Erhöhung, die den MicroSwitch oberhalb des Triggers auslöst und so sicher geht, dass das Magazin zentral ausgerichtet ist.\\
-{{:projektewise24:projekt6:mag_gear_simensions.png?300 |Skizze und Berechnungen zur Größe der Zahnräder/Gear Racks. Und ja, ich habe mich vertippt.}}
+{{:projektewise24:projekt6:mag_gear_simensions.png?300 |Skizze und Berechnungen zur Größe der Zahnräder/Gear Racks.}}
 Das Magazin verfügt über zwei mittige Einschnitte an der Unterseite, die auf gleiche negative Schienen auf einer Magazin-Grundplatte angepasst sind. In dieser Grundplatte befinden sich zwei Zahnräder, die über eine eingebettete Achse mit dem Magazin-Servo-Motor verbunden sind, und über Zahnstangen (Gear Racks) an der Unterseite des Magazins dieses entlang des Triggers bewegen. Diese Zahnräder sind mit dem Abstand der Achse und der Gear Racks auf den Millimeter angepassst.\\
 Das Entwickeln von Zahnrädern passend zu bereits gegebenen Umständen (wie z.B. Abstand der Achsen, also Durchmesser des Zahnrades) ist komplizierter als am Anfang angenommen, weshalb auch hier viel Zeit verloren ging. Am Beispiel des Magazinantriebs wird dieser Vorgang nun dargelegt.
+<sup>Abb.12: Skizze, Zahnrad Schematik für Magazin</sup>
 -----
 Ein paar wichtige Größen müssen vorher definiert werden. Damit zwei Zahnräder miteinander "meshen" können, das Bedeutet, Problemlos ineinander greifen, müssen der Pitch Diameter, der Pressure Angle und das Module gleich sein, und sie müssen im Richtigen Abstand voneinander angebracht sein.
 [[https://static.wixstatic.com/media/2f92ea_b0c8f903a106445095ff83c87057b39e~mv2.jpg/v1/fill/w_568,h_532,al_c,q_80,usm_0.66_1.00_0.01,enc_avif,quality_auto/2f92ea_b0c8f903a106445095ff83c87057b39e~mv2.jpg|{{ :projektewise24:projekt6:gear_dimensions_exmpl.png?400|Link to image}}]]
-Der **"Pitch Diameter"** ('PD'; Pitch Diamteter') ist der Durchmesser des Zahnrades, berechnet von der Mitte der Zähne, der sogenannte "Pitch Circle". In diesem Fall liegt die Achse 13mm von dem Pitch Circle des Gear Racks entfernt. Dadurch lässt sich ein Pitch Diamete r von 26mm berechnen.
+Der **"Pitch Diameter"** ('PD'; Pitch Diamteter') ist der Durchmesser des Zahnrades, berechnet von der Mitte der Zähne, der sogenannte "Pitch Circle". In diesem Fall liegt die Achse 13mm von dem Pitch Circle des Gear Racks entfernt. Dadurch lässt sich ein Pitch Diameter von 26mm berechnen.
 >>PD = 26mm
 Der **"Pressure Angle"** (α; 'Alpha') bestimmt den Winkel der Zähne zueinander, ein geringer Pressure Angle sorgt für eine geringere Kraftübertragung im Austausch für mehr Präzision. Da es um nicht besonders viel Gewicht geht, wurde sich für einen Mittelwert von 20° Entschieden.
@@ Zeile 145: / Zeile 162: @@
 >>m = 2
-Da wir mit zwei verschiedenen Arten von Zahnrädern arbeiten, hier mit einem sogenannten "Spur Gear" und einem "Spur Rack" brauchen wir mehrere verschiedene Formeln. Die Länge des Gearracks ist bereits bekannt: Die Länge des Magazins, also 167mm.\\
+Da wir mit zwei verschiedenen Arten von Zahnrädern arbeiten, hier mit einem sogenannten "Spur Gear" und einem "Spur Rack" brauchen wir mehrere verschiedene Formeln. Die Länge des Gearracks ist bereits bekannt: <sup>Abb.13: Webbild, Visualisierung der Zahnrad-Größen</sup>\\
+Die Länge des Magazins, also 167mm.
 Die **Anzahl an Zähnen im GearRack** Z<sub>rack</sub> lässt sich nun aus der Formel //l=m*pi*Z<sub>rack</sub>// berechnen (m=Module, l=Länge des Magazins), nach Umstellen der Formel erhalten wir Z<sub>rack</sub>~26.
 >>Z<sub>rack</sub> = 26
@@ Zeile 159: / Zeile 178: @@
 ====Pin Belegung====
 ^ Pin     ^ Name          ^ Zweck                                                                ^
 |  d2     | redLED        | aktiviert und deaktiviert die rote LED (LED 1 -> kein Face detected) |
 |  d3     | yellowLED     | aktiviert und deaktiviert die gelbe LED (LED 2 -> face detected)     |
 |  d4     | greenLED      | aktiviert und deaktiviert die grüne LED (LED 3 -> face locked)       |
@@ Zeile 168: / Zeile 187: @@
 |  d10    | flywheelServo | startet oder stoppt die Flywheels über einen nMOS                    |
 |  d12    | contactPin    | verbunden mit dem MicroSwitch um Magazinausrichtung zu überprüfen    |
+<sup>Tab.1: Tabelle zur Belegung der Digital Pins am Arduino UNO </sup>
 -----
 ====Code und Software====
@@ Zeile 177: / Zeile 196: @@
 ===LFK_face_tracking===
-Die einzige nennenswerte Änderung des Codes, abgesehen von größtenteils gescheiterten Stabilisierungen, ist eine veränderung der Roam-Logic, also wie der Roboter sich bewegt, wenn es gearde kein face zu tracken gibt.
+Die einzige nennenswerte Änderung des Codes, abgesehen von größtenteils gescheiterten Stabilisierungen, ist eine veränderung der Roaming-Logic, also wie der Roboter sich bewegt, wenn es gerade kein face zu tracken gibt.
-Im originalen Code nutzt der Roboter random numbers, um sich auf beiden Achsen zufällig im definierten Bereich zu bewegen. Diese Logik wurde durch eine simplere Version ersetzt. Da der Roboter insgesamt deutlich schwerer ist als das Beispiel auf welches das Programm eigentlich zugeschnitten ist, waren Modifikationen von Nöten, so wurde der zufällige Neigungswinkel komplett entfernt und durch konstante 90° ersetzt, das bedeutet beim Roamen bleibt die Kamera bei einer neutralen, mittleren Neigung.
+Im originalen Code nutzt der Roboter random numbers, um sich auf beiden Achsen zufällig im definierten Bereich zu bewegen. Diese Logik wurde durch eine simplere Version ersetzt. Da der Roboter insgesamt deutlich schwerer ist als das Beispiel auf welches das Programm eigentlich zugeschnitten ist, waren Modifikationen von Nöten, so wurde der zufällige Neigungswinkel komplett entfernt und durch konstante 90° ersetzt, das bedeutet beim Roaming     <sub>Vid.3: Video, Prototyp beim 'Roaming'</sub>\\ bleibt die Kamera bei einer neutralen, mittleren Neigung.
 {{ :projektewise24:projekt6:roaming_test.mp4|Roaming Test}}
@@ Zeile 188: / Zeile 207: @@
 Der Arduino beginnt seine Funktion mit einer kurzen LED-Sequenz, und bewegt alle Servos in ihre Ausgangsposition.\\
 Die loop, die danach ausgeführt wird, ist relativ simple:\\
-{{ :projektewise24:projekt6:rduibo_aktivierungsskizze.png?1080 |Loop function des Arduino}}
+{{ :projektewise24:projekt6:rduibo_aktivierungsskizze.png?1080 |Loop function des Arduino}}\\
+<sup>Abb.14: Skizze, Aktivierungsdiagramm der Arduino loop()-funktion</sup>
 Dieser Code Abschnitt ist einer der Herausfordernsten, nicht weil die Funktion an sich etwas komplexes tut, sondern weil sie auf einem schon existierenden Framework gebaut werden musste. Da das Programm auf Schleifendurchläufen basiert, musste eine etwas komplexere Lösung gefunden werden, weshalb mit states und der millis()-funktion gearbeitet werden muss.
@@ Zeile 240: / Zeile 260: @@
 Korrupte Datensätze liegen vermutlich an überlasteten Anschlüssen und schlechter Verbindung meinerseits, da ich einen USB-Hub mit einem USBA-USBC-Adapter nutzen muss um sowohl Kamera als auch Arduino gleichzeitig anschließen zu können.
 {{ :projektewise24:projekt6:application_crash_bufferoverflow.mp4 |Dieses Video zeigt representativ, was bei einem Buffer-Overflow passiert. (Ardiuino start message not received, stuck in waiting loop)}}
+<sup>Vid.4: Screenrecording, Crash-Ursache: Buffer Overflow aufgrund einer infinite Loop</sup>
 -----
 Ein weiteres Beispiel für das crashen des Programmes aufgrund von korrupter Kommunikation lässt sich in der gleichen Funktion, nur ein paar Zeilen weiter finden:
@@ Zeile 261: / Zeile 282: @@
 Wie das aussieht, sieht man in diesem Video:
 {{ :projektewise24:projekt6:application_crash_corruptendmarker.mp4 | Achtet besonders auf die Konsole im Hintergrund.}}
+<sup>Vid.5: Screenrecording, Crash-Ursache: Korrupte Endmarker</sup>
 //Side note: Diese Characters werden vom Arduino automatisch am Ende jeder Nachricht hinzugefügt: Ein "carriage return" \r der denCurser zurück zum Anfang der aktuellen line bewegt, und der "new line character" \n, der eine neue Linie beginnt. Diese sind Teil der Serialen Kommunikation, sollten allerdings durch den End Marker '>', der davor versandt wird, nicht gelesen werden.//
@@ Zeile 268: / Zeile 290: @@
 Auch wenn der Roboter nicht fertig gestellt werden konnte, sind viele Teile bereits weit fortgeschritten. Es gibt ein fertiges Design mit vielen Druckfertigen Teilen, auch wenn hier noch viel Arbeit ansteht, vor allem was die Grundplatte angeht.
-Der Code ist voll mit bugs und das Programm stürzt andauernd ab, doch die Ursachen für diese Instabilität sind bekannt und behebbar. Fast alle Teile sind bereits fertig programmiert, nur hier und da gibt es Teile die nur durch ausgiebiges Testen mit einem fertigen Modell verbesserbar sind, wie Bspw. die [[Verzögerung im Trigger w
+Der Code ist voll mit bugs und das Programm stürzt andauernd ab, doch die Ursachen für diese Instabilität sind bekannt und behebbar. Fast alle Teile sind bereits fertig programmiert, nur hier und da gibt es Teile die nur durch ausgiebiges Testen mit einem fertigen Modell verbesserbar sind, wie Bspw. die [[projektewise24:projekt6:doku#Arduino Code|Verzögerung im Trigger]].
+Der Prototyp ist bereits in der Lage, viele Funktionen des Roboters zu simulieren, wie die Bewegung, die LEDs oder sogar die Bewegung der anderen Servo Motoren.
+Offensichtlich bestehen viele Ausbaumöglichkeiten, besonders in Fragen der Stabilität, aber mit der Menge an bereits fertig gestellten Teilaufgaben kann man nicht nur den Roboter beenden, sondern sogar erweitern, ihn Bspw. Mobil machen, Farben erkennen lassen, und vieles mehr. Das Framework das hier erarbeitet wurde muss zwar zunächst fertig gestellt werden, kann dann jedoch auf fast alles angepasst werden. Die Nerf kann durch Paintball, T-Shirts, Wasser ersetzt werden, das Face-Tracking durch Color-Tracking, die Möglichkeiten sind endlos.
+-----

Projektlabor Robotik MINTgrün

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge