Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- projektewise24:projekt6:doku [2025/03/31 02:14]
uszer [Code und Software]
+++ projektewise24:projekt6:doku [2025/03/31 03:22] (aktuell)
uszer [Reference]
@@ Zeile 2: / Zeile 2: @@
 Projektlabor Robotik Wintersemester 2024/25
-Disclaimer: Dieses Projekt ist nicht fertig gestellt. Es werden CAD-Modelle in Tinkercad zur Anschauung benutzt. Diese sind zu meist in Fusion360 modelliert worden.\\
+Disclaimer: Dieses Projekt ist nicht fertig gestellt. Es werden CAD-Modelle in Tinkercad zur Anschauung benutzt. Diese sind zu meist in Fusion360 modelliert worden. Zusätzlich werden Mechaniken anhand eines Prototyps erläutert.
-Leider ist, bevor ich Videos von unserem Prototypen aufnehmen konnte, mein Laptop gecrasht und hat dabei meinen Adapter gefried.\\
 [[https://www.tinkercad.com/things/cDiCKqvupxW-nerfbot-model-v23-wise2425?sharecode=aleDFEdCd0t51QOP0Ii2RrIt-svdVommRIZTkE3n1xE|CAD-Model des Roboters, enthält druckfertige Teile. Bitte Beschreibung beachten.]]
 -----
@@ 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 Kegelradgetriebe (Bevel-Gear) an der Unterseite der Grundscheibe diese an. Durch genaues Drucken des Getriebes ist eine präzise Steuerung und eine hohe Kraftübertragung möglich.\\
+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 105: / Zeile 116: @@
 Um die Darts aus dem Magazin in die Flywheels zu bewegen, wird ein positional-micro-Servo genutzt, der leicht und klein genug ist um sehr einfach installiert zu werden. Dafür nutze ich einen [[orga:starterset|SG92R-MicroServo aus dem Starterset]].
-==="=magazine-Servo" Servo Motor==
+==="magazine-Servo" Servo Motor==
 Der Servo zum weiterbewegen des Magazins ist der einzige continuous-servo der im Roboter verbaut ist, das bedeutet, ein Servo-Motor der keine Winkel-Begrenzung hat sondern sich frei bewegen kann. Dafür nutze ich ebenfalls einen Micro-Servo um Platz zu sparen, und zwar einen [[https://www.amazon.de/AMZLORD-Servomotor-Starrflügel-Servomotor-steuert-RC-Hubschrauber-Flugzeuge/dp/B0CQ8WKHH6/ref=asc_df_B0CQ8WKHH6?mcid=7bce899fb49a3aee9aca1742a757c576&th=1&tag=googshopde-21&linkCode=df0&hvadid=728048089413&hvpos=&hvnetw=g&hvrand=14084311143564815560&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9043206&hvtargid=pla-2400262577010&gad_source=1&psc=1|MicroServo-9g-SG90]].
@@ 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 121: / Zeile 135: @@
 Der Arduino wird von der Computer-Schnittstelle konstant mit 5 Volt versorgt. Durch den 5V-Pin des Arduinos ist es möglich, alle Bestandteile des Roboters ausreichend mit Strom zu versorgen.
+-----
+====Das Magazin====
-====Gedruckte Teile:====
-Hier soll es vor allem um Dinge wie Gear-Ratios, Größen und ähnliches gehen.
-===Magazin, Magazin-Servos und -Schienen===
 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 147: / 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 161: / 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 170: / 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 179: / 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 190: / 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 217: / Zeile 235: @@
 </hidden>
+===Instabilität und Crashes===
 Die größten Probleme mit der Software und dem Code stammen von der Kommunikation zwischen Arduino und dem Programm.
@@ Zeile 238: / Zeile 257: @@
 Gibt es nämlich einen Fehler beim Senden dieser Daten, und die Kommunikation wird corrupted, hängt das Programm in dieser Schleife fest und stürzt ab wenn der input buffer überfließt.\\
-Man kann das beheben, indem man in beiden Programmen, dem Arduino und der Python-Software, besseres error-handling einbaut, zum Beispiel indem man einen timer setzt, den Buffer jeden durchlauf überprüft und cleart, oder ähnliches. Leider fehlt uns dazu die Zeit.
+Man kann das beheben, indem man in beiden Programmen, dem Arduino und der Python-Software, besseres error-handling einbaut, zum Beispiel indem man einen timer setzt, den Buffer jeden durchlauf überprüft und cleart, oder ähnliches. Leider fehlt uns dazu die Zeit.\\
 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 262: / 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.//
 ----
+====Ergebniss====
+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 [[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