Drei-Achsen-Roboterarm: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
 
(134 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:


=== Einleitung ===
== 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. 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.  
 
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.
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.
Das Projekt wurde initiiert und umgesetzt von den Mechatronikstudenten des Studienschwerpunktes SDE, im Wintersemester 2022/2023, [[Benjamin Dilly]] und David Weigt.
 
== Anforderungen ==


=== Anforderungen ===
_____________________________________________________________________
<br>
<br>
{| class="wikitable"
{| class="wikitable"
|+ Text der Überschrift
|+ Roboterarm
|-
|-
! ID !! Anforderung !! Umgesetzt !! Datum  
! ID !! Anforderung !! Umgesetzt !! Datum  
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 1 || Gelenke für die Bewegung || Beispiel || Beispiel  
|-
| 2 || Greifer zum Transportieren von Objekten || Beispiel || Beispiel  
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 3 || Aktuatoren für Gelenke || Beispiel || Beispiel  
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 4 || Schnittstelle für Aktuatoren und Positionsübermittlung || Beispiel || Beispiel  
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 5 || Greifermotor || Beispiel || Beispiel
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 6 || Einfaches Ansteuern || Beispiel || Beispiel  
|-
|-
| Beispiel || Beispiel || Beispiel || Beispiel  
| 7 || Flüssige Bewegung und mechanische Robustheit || Beispiel || Beispiel  
|}
|}


=== Funktionaler Systementwurf/Technischer Systementwurf ===
<br>
_____________________________________________________________________
{| class="wikitable"
|+ Steuereinheit (Arduino)
|-
! 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
|}
 
 
<br>
{| class="wikitable"
|+ Joystick
|-
! 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
|}
 
<br>
{| class="wikitable"
|+ Taster
|-
! ID !! Anforderung !! Umgesetzt !! Datum
|-
| 1 || Allgemeines Erfassen der Systembefehle || Beispiel || Beispiel
|}
 
== Funktionaler Systementwurf/Technischer Systementwurf ==
 
[[Datei:Schematischer Systemaufbau.jpeg|600px|mini|zentriert|Gezeigt ist schematischer Systemaufbau]]
[[Datei:Schematischer Systemaufbau.jpeg|600px|mini|zentriert|Gezeigt ist schematischer Systemaufbau]]


=== Komponentenspezifikation ===
[[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 ==
 
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...<br>
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.<br>
 
Programmiertaster: Startet/stoppt die Programmierung.<br>
 
Rücksetzungstaster: Wenn nichts anderes aktiv ist, setzt er das Bewegungsmuster zurück. Während Programmierung, löscht er den zuletzt gespeicherten Zwischenschritt.<br>
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.<br><br>
 
Wenn eine Aktion nicht ausgeführt werden kann, wird ein Signal gegeben. Dieses wird solange aufrechterhalten, wie der verursachende Zustand aktiv ist.<br>
Um dies zu vermeiden, sollte das Bewegungsmuster vor Aktivierung des Programmiermodus zurückgesetzt werden (wenn bereits vorhanden).<br>
Zudem sollte vermieden das Bewegungsmuster auszuführen, solange nicht mehr oder genau vier Zwischenschritte eingespeichert wurden.<br>
Das Deaktivierung des Signals kann einfach durch erneutes betätigen des verursachenden Tasters geschehen.
 
== Hardware ==
 
{| class="wikitable"
|+ Systembefehle
|-
! 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
 
 
{| class="wikitable"
|+ Schnittstellenkonfiguration
|-
! Schnittstelle !! Breite (Pins)  !! Typ
|-
| Taster || 4 || Digital
|-
| Joystick || 5 || Analog
|-
| Roboterarm || 5 || Digital
|}
 
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 ===
[[Datei: Programmablaufplan der Roboterarmsteuerung.png|150px|mini|zentriert|Programmablaufplan]]
 
== Umsetzung (HW/SW) ==
 
'''
=== Software===
 
[[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 ==
 
'''Software'''
 
[[Datei:Statusgenerierungstest.mp4|600px|mini|zentriert|Datei:Statusgenerierungstest]]


[[Datei: Testen der gesamten Steuerung.mp4|600px|mini|zentriert|Datei:Testen der gesamten Steuerung]]


=== Umsetzung (HW/SW) ===
[[Datei: Vereinfachter Hardwaretest.mp4|600px|mini|zentriert|Datei:Vereinfachter Hardwaretest]]
_____________________________________________________________________




=== Komponententest ===
== 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


=== Ergebnis ===
== 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]]


=== Zusammenfassung ===
Die Benutzung der Dateien geschieht auf eigene Gefahr!
_____________________________________________________________________


== Projektplan ==


=== Projektunterlagen ===
[[Datei:ProjektPlanRoboterarm.png|mini|800px|center]]
_____________________________________________________________________


== Projektdurchführung ==


=== Projektplan ===
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 ==


=== Projektdurchführung ===
_____________________________________________________________________




=== YouTube Video ===
== Weblinks ==
_____________________________________________________________________




=== Weblinks ===
_____________________________________________________________________


________________________________________________________


_____________________________________________________________________
◀▶ Zurück zur Vorgängerseite [[https://wiki.hshl.de/wiki/index.php/Kategorie:ProjekteET_MTR_BSE_WS2022]]


◀▶ Hauptseite: ProjekteET MTR BSE WS2022 [[https://wiki.hshl.de/wiki/index.php/Kategorie:ProjekteET_MTR_BSE_WS2022]]
◀▶ Zurück zur Projekthauptseite: [[Fachpraktikum Elektrotechnik & Angewandte Elektrotechnik]]

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


Roboterarm
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


Steuereinheit (Arduino)
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



Joystick
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


Taster
ID Anforderung Umgesetzt Datum
1 Allgemeines Erfassen der Systembefehle Beispiel Beispiel

Funktionaler Systementwurf/Technischer Systementwurf

Gezeigt ist schematischer Systemaufbau
Gezeigt ist der skizzenhafte Armaufbau
Schaltplan der Servomotoren und der Potentiometer

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

Systembefehle
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


Schnittstellenkonfiguration
Schnittstelle Breite (Pins) Typ
Taster 4 Digital
Joystick 5 Analog
Roboterarm 5 Digital

Pins insgesamt: 14


Steckbrett

Als Platine wurde ein einfaches Steckbrett benutzt, wie das oben gezeigte.

10K Poti

Als Sensoren wurden die 10K Potis benutzt.

Servos

Verwendet wurden Servos vom Typ SG90 (Erhältlich von verschiedenen Anbietern wie: WAVESHARE, AZDelivery etc.).

Mikrokontroller

Als Mikrokontroller wurde ein Arduino Uno verwendet (Kein Original Uno von Arduino selbst (s.o.) sondern einer eines Drittanbieters mit identischem Aufbau).

Software

Programmablaufplan

Umsetzung (HW/SW)

Software

Softwareaufbau mit Matlab/Simulink

Das Hauptmodell übernimmt die eigentliche Ansteuerung und das Abfragen der Hardwarebausteine. Wie Servos, Analog- & Digitalpins sowie der seriellen Schnittstelle.

Systemstatusmodell

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.
Der Systemstatus wird durch den Stateflow generiert.

Virtuelle Tasten Modell

Modell zum virtuellen Simulieren der Tasten auf dem Arduino Uno

Ermöglicht das Testen auch ohne Hardwaretasten, bzw. die Handhabung/Steuerung.

Sensoren Modell

Modell zum Umwandeln der Sensordaten

Rechnet die digitalen Werte der Analogpins des Arduino Unos in Gradmaße um, um die Servos anzusteuern.

Executer Modell

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

Clock

Generiert das Clock-Signal zur zeitlichen Messung in Executer und der Tastenauswertung.

Komponententest

Software

Datei:Statusgenerierungstest
Datei:Testen der gesamten Steuerung
Datei:Vereinfachter Hardwaretest


Ergebnis

Fertiges Roboterarm Modell

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