Drei-Achsen-Roboterarm: Unterschied zwischen den Versionen
(29 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 111: | Zeile 111: | ||
[[Datei:Schematik Roboterarm-001 .jpg|600px|mini|zentriert|Gezeigt ist der skizzenhafte Armaufbau]] | [[Datei:Schematik Roboterarm-001 .jpg|600px|mini|zentriert|Gezeigt ist der skizzenhafte Armaufbau]] | ||
[[Datei:Schaltplan.PNG.png|600px|mini|zentriert|Schaltplan der Servomotoren und der Potentiometer]] | |||
== Komponentenspezifikation == | == Komponentenspezifikation == | ||
Zeile 187: | Zeile 189: | ||
Pins insgesamt: 14 | Pins insgesamt: 14 | ||
[[Datei: Dre-Achs-Roboterarm-Steckbrett.png|60px|mini|zentriert|Steckbrett]] | |||
Als Platine wurde ein einfaches Steckbrett benutzt, wie das oben gezeigte. | |||
[[Datei: Drei-Achs-Roboterarm-Poti.jpg|60px|mini|zentriert|10K Poti]] | |||
Als Sensoren wurden die 10K Potis benutzt. | |||
[[Datei: Drei-Achs-Roboterarm-Sg90-servo-1 1.jpg|60px|mini|zentriert|Servos]] | |||
Verwendet wurden Servos vom Typ SG90 (Erhältlich von verschiedenen Anbietern wie: WAVESHARE, AZDelivery etc.). | |||
[[Datei: Drei-Achs-Roboterarm-Arduino image.jpg|60px|mini|zentriert|Mikrokontroller]] | |||
Als Mikrokontroller wurde ein Arduino Uno verwendet (Kein Original Uno von Arduino selbst (s.o.) sondern einer eines Drittanbieters mit identischem Aufbau). | |||
=== Software === | === Software === | ||
Zeile 197: | Zeile 211: | ||
[[Datei:Software Drei-Achsen-Roboterarm.png|600px|mini|zentriert|Softwareaufbau mit Matlab/Simulink]] | [[Datei:Software Drei-Achsen-Roboterarm.png|600px|mini|zentriert|Softwareaufbau mit Matlab/Simulink]] | ||
Das Hauptmodell übernimmt die eigentliche Ansteuerung und das Abfragen der Hardwarebausteine. | |||
Wie Servos, Analog- & Digitalpins sowie der seriellen Schnittstelle. | |||
'''Systemstatusmodell''' | |||
[[Datei: Status Generierer-001.png|600px|mini|zentriert|Modell zum generieren des allgemeinen Systemstatus]] | |||
Filtert die Hardwaretasten und triggert auf die steigende Flanke der Tasten. Des Weiteren filtert es prioritär die Tasten bei multipler Tastenbetätigung.<br> | |||
Der Systemstatus wird durch den Stateflow generiert. | |||
'''Virtuelle Tasten Modell''' | |||
[[Datei: Virtuelle Tasten-001.png|600px|mini|zentriert|Modell zum virtuellen Simulieren der Tasten auf dem Arduino Uno]] | |||
Ermöglicht das Testen auch ohne Hardwaretasten, bzw. die Handhabung/Steuerung. | |||
'''Sensoren Modell''' | |||
[[Datei: Sensoren-001.png|600px|mini|zentriert|Modell zum Umwandeln der Sensordaten]] | |||
Rechnet die digitalen Werte der Analogpins des Arduino Unos in Gradmaße um, um die Servos anzusteuern. | |||
'''Executer Modell''' | |||
[[Datei: Executer-001.png|600px|mini|zentriert|Modell zum Ausführen von Systemaktionen und der Servosteuerung]] | |||
Mit zu sehen ist noch eine alte Stateflow-Version des Executer Modells. Er übernimmt die Systemverwaltung und alle auszuführenden Aktionen, wie Ausführen des Bewegungsmusters, der Programmierung, dem Speichern etc. | |||
'''Clock Modell''' | |||
[[Datei: Clock-001.png|600px|mini|zentriert|Clock]] | |||
Generiert das Clock-Signal zur zeitlichen Messung in Executer und der Tastenauswertung. | |||
== Komponententest == | == Komponententest == | ||
Zeile 206: | Zeile 247: | ||
[[Datei: Testen der gesamten Steuerung.mp4|600px|mini|zentriert|Datei:Testen der gesamten Steuerung]] | [[Datei: Testen der gesamten Steuerung.mp4|600px|mini|zentriert|Datei:Testen der gesamten Steuerung]] | ||
[[Datei: Vereinfachter Hardwaretest.mp4|600px|mini|zentriert|Datei:Vereinfachter Hardwaretest]] | [[Datei: Vereinfachter Hardwaretest.mp4|600px|mini|zentriert|Datei:Vereinfachter Hardwaretest]] | ||
== Ergebnis == | == Ergebnis == | ||
[[Datei:20230110 084312.jpg|600px|mini|zentriert|Fertiges Roboterarm Modell]] | |||
== | == Lessons Learned == | ||
bestehen aus... | |||
* Projektplanung | |||
* Kommunikation | |||
* Simulation vereinfacht die Umsetzung & Validierung | |||
* Aufgezählter Listeneintrag | |||
== Projektunterlagen == | == Projektunterlagen == | ||
Alle Unterlagen können in den folgenden Zip-Ordnern heruntergeladen werden: | |||
Code[[https://wiki.hshl.de/wiki/index.php/Datei:Drei-Achs-Roboterarm-Code.zip]], CAD-Modelle [[https://wiki.hshl.de/wiki/index.php/Datei:CAD-Drei-Achs-Roboterarm.zip]] | |||
Die Benutzung der Dateien geschieht auf eigene Gefahr! | |||
== Projektplan == | == Projektplan == | ||
Zeile 220: | Zeile 272: | ||
== Projektdurchführung == | == Projektdurchführung == | ||
Bei der Umsetzung der Software stellte uns die Umstellung von schriftbasiertem Programmieren auf blockbasiertes Programmieren vor die Herausforderung sich in die Neue Art der Programmierung einzudenken. | |||
Insbesondere das notwendige, permanente Casten von Datentypen war hier ungewohnt und verursachte häufige Fehler beim Kompilieren. Nachdem man sich aber daran gewöhnt hatte konnten wir schnell und einfach das Programm umsetzen. Ein Nachteil hierbei ist, das Simulink sehr viel Programmierspeicher beansprucht und wir deshalb besonderen Wert darauf legen mussten besonders effizient zu programmieren. Durch das einfügen des Funktionsblocks in Executer.slx konnten wir den Programmspeicherbedarf senken. Der Vorteil lag jedoch ganz klar in der Möglichkeit die Software in einer Simulation zu testen, wodurch nur noch das Testen der Hardware über bleibt. | |||
Beim Finalen Test mit dem fertigen Armmodell war das System zunächst nicht funktionstüchtig was an den Verbindungsleitungen lag. Für das Projekt sind wir nach dem V-Modell vorgegangen. | |||
== YouTube Video == | == YouTube Video == |
Aktuelle Version vom 10. Januar 2023, 09:56 Uhr
Einleitung
In Rahmen des GET-Fachpraktikums soll ein mechatronisches System entwickelt und getestet werden. Dies soll unter Zuhilfenahme der theoretisch erworbenen Kenntnisse der Mess- und Regelungstechnik, Elektrotechnik und der Aufbau und Verbindungstechnik geschehen. Im Zuge des Fachpraktikums wird ein Drei-Achsen-Roboterarm mit einer manuell-mechanischen Bewegungsprogrammierung gebaut. Diesbezüglich wird ein dem Arm nachempfundener "Joystick" gefertigt über den das Bewegungsmuster des Armes manuell eingegeben werden kann. Hierfür werden an alle drei Drehachsen Sensoren befestigt um den Drehwinkel und Richtung zu erfassen. Mittels zwei Knöpfe kann das Muster gelernt oder gelöscht werden. Der Arm fährt live mit.
Die Aufgabe ist es den Arm dazu zu bringen Objekte aufzuheben und an eine andere Stelle zu legen.
Das Projekt wurde initiiert und umgesetzt von den Mechatronikstudenten des Studienschwerpunktes SDE, im Wintersemester 2022/2023, Benjamin Dilly und David Weigt.
Anforderungen
ID | Anforderung | Umgesetzt | Datum |
---|---|---|---|
1 | Gelenke für die Bewegung | Beispiel | Beispiel |
2 | Greifer zum Transportieren von Objekten | Beispiel | Beispiel |
3 | Aktuatoren für Gelenke | Beispiel | Beispiel |
4 | Schnittstelle für Aktuatoren und Positionsübermittlung | Beispiel | Beispiel |
5 | Greifermotor | Beispiel | Beispiel |
6 | Einfaches Ansteuern | Beispiel | Beispiel |
7 | Flüssige Bewegung und mechanische Robustheit | Beispiel | Beispiel |
ID | Anforderung | Umgesetzt | Datum |
---|---|---|---|
1 | Schnittstelle für Winkelsensoren des Joysticks | Beispiel | Beispiel |
2 | Schnittstelle für Aktoren des Roboterarms | Beispiel | Beispiel |
3 | Schnittstelle Operationstaster | Beispiel | Beispiel |
4 | Erfassen und Verarbeiten des Bewegungsmusters | Beispiel | Beispiel |
5 | Bewegungsmusternachverfolgung bei Programmierung mit Roboterarm | Beispiel | Beispiel |
6 | Umsetzen des Bewegungsmusters (Dauerschleife) | Beispiel | Beispiel |
7 | Asynchrones Erfassen der Joystickausrichtung | Beispiel | Beispiel |
8 | Nach Programmierstart, Arm nach Joystick ausrichten | Beispiel | Beispiel |
9 | Speichern der letzten Roboterarmausrichtung /Position bei Programmierstart | Beispiel | Beispiel |
10 | Nach Programmierabbruch, zur gespeicherten Armausrichtung zurückkehren, warten auf Befehle | Beispiel | Beispiel |
11 | Nach Programmierabbruch, auf Befehle warten | Beispiel | Beispiel |
12 | Nach Programmierung: Bewegungsmuster Dauerhaft speichern | Beispiel | Beispiel |
13 | Nach Programmierung: In Ausgangsposition zurückkehren | Beispiel | Beispiel |
14 | Bei Rücksetzung zurück in die Grundstellung fahren, Flags und letzte Armposition löschen | Beispiel | Beispiel |
15 | Bei Abschaltung in Grundstellung fahren, Flag setzen | Beispiel | Beispiel |
16 | Nach Programmstart / Neustart Flags prüfen, auf Befehle warten | Beispiel | Beispiel |
17 | Bei Bewegungsstopp: Bewegung stoppen, auf Befehle warten | Beispiel | Beispiel |
18 | Anzeigen des allgemeinen Systemstatus | Beispiel | Beispiel |
ID | Anforderung | Umgesetzt | Datum |
---|---|---|---|
1 | Möglichst genaues Nachempfinden des Roboterarms | Beispiel | Beispiel |
2 | Sensoren zum Erfassen des Bewegungsmusters (Winkelsensoren) | Beispiel | Beispiel |
3 | Sensoren ermöglichen das Erfassen der Drehrichtung | Beispiel | Beispiel |
4 | Schnittstelle zum Abfragen der Winkelsensoren | Beispiel | Beispiel |
5 | Robuster Aufbau | Beispiel | Beispiel |
6 | Einfache und flüssige Handhabung/Flüssiges bewegen lassen | Beispiel | Beispiel |
7 | Beibehalten der Position | Beispiel | Beispiel |
ID | Anforderung | Umgesetzt | Datum |
---|---|---|---|
1 | Allgemeines Erfassen der Systembefehle | Beispiel | Beispiel |
Funktionaler Systementwurf/Technischer Systementwurf
Komponentenspezifikation
Die zu verwundene Hardware erstreckt sich über die im nächsten Abschnitt gelisteten Bauteile. Dazu gehören die Taster, Servomotoren, Potenziometer und einen Arduino (Uno, Nano, Mini).
Servomotor
Die Servomotoren sollten mindestens einen Winkel von 180° verfahren und möglichst direkt an den Arduino angeschlossen werden können.
Sensoren
Für die Sensoren werden einfache Potenziometer verwendet. Diese besitzen einen Widerstand von 10k Ohm, was eine hohe Auflösung ermöglichen würde.
Arduino Uno
Da für das Projekt ein Arduino Uno im Vorfeld zur Verfügung stand, wurde dieser für die spätere Auslegung des eingebetteten Systems verwendet. Kleine Varianten wie der Arduino Nano eignet sich genauso gut, da diese mehr als fünf analoge und digitale Pins besitzen. Zu beachten ist, dass jeder Arduino über eine verbaute Sicherung verfügt, welche im USB Betrieb die USB Schnittstelle vor Überlast schützen soll. Dabei dürfen keine Ströme über 500mA an der Schnittstelle anliegen. Somit sollte der Uno über ein zusätzliches Netzteil (6-20 Volt) versorgt werden und beim Nano über Pin 30 (6-20 Volt) oder Pin 27 (5 Volt) anliegen. Achtung ! Es ist zu beachten, dass nur die Arduino originalen Boards eine geleichzeitige Spannungsversorgung über USB und einem Netzteil ermöglichen.
Bedienung
Tasten...
Start/Stopp: startet und stoppt die Bewegung. Speichert im Programmiermodus die Zwischenschritte des Bewegungsmusters ab. Es können max. 10 Schritte und mindestens 4 zwischengespeichert werden.
Programmiertaster: Startet/stoppt die Programmierung.
Rücksetzungstaster: Wenn nichts anderes aktiv ist, setzt er das Bewegungsmuster zurück. Während Programmierung, löscht er den zuletzt gespeicherten Zwischenschritt.
Abschalttaster: Einmaliges Betätigen hält den Arm an und sperrt alle weiteren Aktionen für 3 Sekunden. Erneutes Betätigen während dieser Zeit, fährt Arm in Nullposition zum Ausschalten zurück.
Wenn eine Aktion nicht ausgeführt werden kann, wird ein Signal gegeben. Dieses wird solange aufrechterhalten, wie der verursachende Zustand aktiv ist.
Um dies zu vermeiden, sollte das Bewegungsmuster vor Aktivierung des Programmiermodus zurückgesetzt werden (wenn bereits vorhanden).
Zudem sollte vermieden das Bewegungsmuster auszuführen, solange nicht mehr oder genau vier Zwischenschritte eingespeichert wurden.
Das Deaktivierung des Signals kann einfach durch erneutes betätigen des verursachenden Tasters geschehen.
Hardware
Befehl | Taster |
---|---|
Bewegung starten / speichern | |
Bewegung stoppen | 1 |
Programmierung starten | |
Programmierung beenden | 1 |
Zurücksetzen | 1 |
Abschaltung | 1 |
Taster insgesamt: | 4 |
Info: Beim Beenden der Programmierung ohne voriges speichern, gilt die Programmierung als verworfen/abgebrochen und der Arm kehrt zum alten Bewegungsmuster zurück
Schnittstelle | Breite (Pins) | Typ |
---|---|---|
Taster | 4 | Digital |
Joystick | 5 | Analog |
Roboterarm | 5 | Digital |
Pins insgesamt: 14
Als Platine wurde ein einfaches Steckbrett benutzt, wie das oben gezeigte.
Als Sensoren wurden die 10K Potis benutzt.
Verwendet wurden Servos vom Typ SG90 (Erhältlich von verschiedenen Anbietern wie: WAVESHARE, AZDelivery etc.).
Als Mikrokontroller wurde ein Arduino Uno verwendet (Kein Original Uno von Arduino selbst (s.o.) sondern einer eines Drittanbieters mit identischem Aufbau).
Software
Umsetzung (HW/SW)
Software
Das Hauptmodell übernimmt die eigentliche Ansteuerung und das Abfragen der Hardwarebausteine. Wie Servos, Analog- & Digitalpins sowie der seriellen Schnittstelle.
Systemstatusmodell
Filtert die Hardwaretasten und triggert auf die steigende Flanke der Tasten. Des Weiteren filtert es prioritär die Tasten bei multipler Tastenbetätigung.
Der Systemstatus wird durch den Stateflow generiert.
Virtuelle Tasten Modell
Ermöglicht das Testen auch ohne Hardwaretasten, bzw. die Handhabung/Steuerung.
Sensoren Modell
Rechnet die digitalen Werte der Analogpins des Arduino Unos in Gradmaße um, um die Servos anzusteuern.
Executer Modell
Mit zu sehen ist noch eine alte Stateflow-Version des Executer Modells. Er übernimmt die Systemverwaltung und alle auszuführenden Aktionen, wie Ausführen des Bewegungsmusters, der Programmierung, dem Speichern etc.
Clock Modell
Generiert das Clock-Signal zur zeitlichen Messung in Executer und der Tastenauswertung.
Komponententest
Software
Ergebnis
Lessons Learned
bestehen aus...
- Projektplanung
- Kommunikation
- Simulation vereinfacht die Umsetzung & Validierung
- Aufgezählter Listeneintrag
Projektunterlagen
Alle Unterlagen können in den folgenden Zip-Ordnern heruntergeladen werden: Code[[1]], CAD-Modelle [[2]]
Die Benutzung der Dateien geschieht auf eigene Gefahr!
Projektplan
Projektdurchführung
Bei der Umsetzung der Software stellte uns die Umstellung von schriftbasiertem Programmieren auf blockbasiertes Programmieren vor die Herausforderung sich in die Neue Art der Programmierung einzudenken. Insbesondere das notwendige, permanente Casten von Datentypen war hier ungewohnt und verursachte häufige Fehler beim Kompilieren. Nachdem man sich aber daran gewöhnt hatte konnten wir schnell und einfach das Programm umsetzen. Ein Nachteil hierbei ist, das Simulink sehr viel Programmierspeicher beansprucht und wir deshalb besonderen Wert darauf legen mussten besonders effizient zu programmieren. Durch das einfügen des Funktionsblocks in Executer.slx konnten wir den Programmspeicherbedarf senken. Der Vorteil lag jedoch ganz klar in der Möglichkeit die Software in einer Simulation zu testen, wodurch nur noch das Testen der Hardware über bleibt. Beim Finalen Test mit dem fertigen Armmodell war das System zunächst nicht funktionstüchtig was an den Verbindungsleitungen lag. Für das Projekt sind wir nach dem V-Modell vorgegangen.
YouTube Video
Weblinks
________________________________________________________
◀▶ Zurück zur Vorgängerseite [[3]]
◀▶ Zurück zur Projekthauptseite: Fachpraktikum Elektrotechnik & Angewandte Elektrotechnik