Wheelie - ein DIY-Segway - Versionsgeschichte

Marius Koehler: /* Test und Optimierung */

2019-09-21T14:05:04Z

Test und Optimierung

← Nächstältere Version		Version vom 21. September 2019, 14:05 Uhr
Zeile 227:		Zeile 227:

	== Test und Optimierung ==		== Test und Optimierung ==
	Zunächst wird das Simulink-Modell im External-Mode auf dem Arduino ausgeführt, welcher per USB mit dem PC verbunden ist. Erste unbemannte Tests werden durchgeführt, in dem der Segway auf eine Getränkekiste gestellt wird. Diese dienen in erster Linie um zu überprüfen, ob Lenkung und Regler in korrekter Richtung arbeiten und ob die Sicherheitseinrichtungen funktionieren. Wie im Abschnitt zum Aufbau angedeutet zeichnen sich bei diesen Tests Probleme mit der Sensorik ab, die Schrittweise eingedämmt werden. Nach der Verlegung des Sensors auf den Deckel des Segway werden im Wechsel bemannte Testfahrten und Anpassungen an den Regelparametern durchgeführt. Da zu diesem Zeitpunkt eine Beobachtung der Regelgröße während der Fahrt nicht möglich war, wurden die Regleranpassungen anhand der Eindrücke Fahrverhaltens getätigt. Diese schrittweise Annäherung an ein möglichst vertrauenswürdiges Verhalten des Segway, führt zu den Regelparametern <math>K_{P}=3,6</math> und <math>K_{D}=0,35</math>. Das Ergebnis kann in ~~einem Video~~ (derzeit im Projekt Repository) begutachtet werden.		Zunächst wird das Simulink-Modell im External-Mode auf dem Arduino ausgeführt, welcher per USB mit dem PC verbunden ist. Erste unbemannte Tests werden durchgeführt, in dem der Segway auf eine Getränkekiste gestellt wird. Diese dienen in erster Linie um zu überprüfen, ob Lenkung und Regler in korrekter Richtung arbeiten und ob die Sicherheitseinrichtungen funktionieren. Wie im Abschnitt zum Aufbau angedeutet zeichnen sich bei diesen Tests Probleme mit der Sensorik ab, die Schrittweise eingedämmt werden. Nach der Verlegung des Sensors auf den Deckel des Segway werden im Wechsel bemannte Testfahrten und Anpassungen an den Regelparametern durchgeführt. Da zu diesem Zeitpunkt eine Beobachtung der Regelgröße während der Fahrt nicht möglich war, wurden die Regleranpassungen anhand der Eindrücke Fahrverhaltens getätigt. Diese schrittweise Annäherung an ein möglichst vertrauenswürdiges Verhalten des Segway, führt zu den Regelparametern <math>K_{P}=3,6</math> und <math>K_{D}=0,35</math>. Das Ergebnis kann in Videos (derzeit im Projekt Repository) begutachtet werden.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Test und Optimierung */

2019-09-21T14:03:26Z

Test und Optimierung

← Nächstältere Version		Version vom 21. September 2019, 14:03 Uhr
Zeile 227:		Zeile 227:

	== Test und Optimierung ==		== Test und Optimierung ==
	Zunächst wird das Simulink-Modell im External-Mode auf dem Arduino ausgeführt, welcher per USB mit dem PC verbunden ist. Erste unbemannte Tests werden durchgeführt, in dem der Segway auf eine Getränkekiste gestellt wird. Diese dienen in erster Linie um zu überprüfen, ob Lenkung und Regler in korrekter Richtung arbeiten und ob die Sicherheitseinrichtungen funktionieren. Wie im Abschnitt zum Aufbau angedeutet zeichnen sich bei diesen Tests Probleme mit der Sensorik ab, die Schrittweise eingedämmt werden. Nach der Verlegung des Sensors auf den Deckel des Segway werden im Wechsel bemannte Testfahrten und Anpassungen an den Regelparametern durchgeführt. Da zu diesem Zeitpunkt eine Beobachtung der Regelgröße während der Fahrt nicht möglich war, wurden die Regleranpassungen anhand der Eindrücke Fahrverhaltens getätigt. Diese schrittweise Annäherung an ein möglichst vertrauenswürdiges Verhalten des Segway, führt zu den Regelparametern <math>K_{P}=3,6</math> und <math>K_{D}=0,35</math>. Das Ergebnis kann in einem Video begutachtet werden.		Zunächst wird das Simulink-Modell im External-Mode auf dem Arduino ausgeführt, welcher per USB mit dem PC verbunden ist. Erste unbemannte Tests werden durchgeführt, in dem der Segway auf eine Getränkekiste gestellt wird. Diese dienen in erster Linie um zu überprüfen, ob Lenkung und Regler in korrekter Richtung arbeiten und ob die Sicherheitseinrichtungen funktionieren. Wie im Abschnitt zum Aufbau angedeutet zeichnen sich bei diesen Tests Probleme mit der Sensorik ab, die Schrittweise eingedämmt werden. Nach der Verlegung des Sensors auf den Deckel des Segway werden im Wechsel bemannte Testfahrten und Anpassungen an den Regelparametern durchgeführt. Da zu diesem Zeitpunkt eine Beobachtung der Regelgröße während der Fahrt nicht möglich war, wurden die Regleranpassungen anhand der Eindrücke Fahrverhaltens getätigt. Diese schrittweise Annäherung an ein möglichst vertrauenswürdiges Verhalten des Segway, führt zu den Regelparametern <math>K_{P}=3,6</math> und <math>K_{D}=0,35</math>. Das Ergebnis kann in einem Video (derzeit im Projekt Repository) begutachtet werden.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Test und Optimierung */

2019-09-21T14:02:39Z

Test und Optimierung

← Nächstältere Version		Version vom 21. September 2019, 14:02 Uhr
Zeile 227:		Zeile 227:

	== Test und Optimierung ==		== Test und Optimierung ==
			Zunächst wird das Simulink-Modell im External-Mode auf dem Arduino ausgeführt, welcher per USB mit dem PC verbunden ist. Erste unbemannte Tests werden durchgeführt, in dem der Segway auf eine Getränkekiste gestellt wird. Diese dienen in erster Linie um zu überprüfen, ob Lenkung und Regler in korrekter Richtung arbeiten und ob die Sicherheitseinrichtungen funktionieren. Wie im Abschnitt zum Aufbau angedeutet zeichnen sich bei diesen Tests Probleme mit der Sensorik ab, die Schrittweise eingedämmt werden. Nach der Verlegung des Sensors auf den Deckel des Segway werden im Wechsel bemannte Testfahrten und Anpassungen an den Regelparametern durchgeführt. Da zu diesem Zeitpunkt eine Beobachtung der Regelgröße während der Fahrt nicht möglich war, wurden die Regleranpassungen anhand der Eindrücke Fahrverhaltens getätigt. Diese schrittweise Annäherung an ein möglichst vertrauenswürdiges Verhalten des Segway, führt zu den Regelparametern <math>K_{P}=3,6</math> und <math>K_{D}=0,35</math>. Das Ergebnis kann in einem Video begutachtet werden.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Der Eigenbau */

2019-09-21T13:48:10Z

Der Eigenbau

← Nächstältere Version		Version vom 21. September 2019, 13:48 Uhr
Zeile 225:		Zeile 225:

	Der Fußtaster wird als Sicherheitseinrichtung eingebunden. Mit Hilfe von Switch-Blöcken führt ein nicht-gedrückter Fußtaster dazu, dass Lenkung und Regler jeweils den Input 0 erhalten, sodass es nicht mehr zur Drehung der Motoren kommt. Der jetzige Stand des Simulink-Modells kann im Projekt-Repository eingesehen werden.		Der Fußtaster wird als Sicherheitseinrichtung eingebunden. Mit Hilfe von Switch-Blöcken führt ein nicht-gedrückter Fußtaster dazu, dass Lenkung und Regler jeweils den Input 0 erhalten, sodass es nicht mehr zur Drehung der Motoren kommt. Der jetzige Stand des Simulink-Modells kann im Projekt-Repository eingesehen werden.

			== Test und Optimierung ==

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-21T13:45:36Z

Die Programmierumg

← Nächstältere Version		Version vom 21. September 2019, 13:45 Uhr
Zeile 223:		Zeile 223:

	Dazu wird zunächst der PID-Controller-Block eingebunden. Anhand des Modells mit der PID-Tuner-App voreingestellt, werden im ersten Schritt die Regelparameter dahin gehend angepasst, dass der Neigungswinkel in Grad angegeben wird, wohingegen im Modell mit Radiant gearbeitet wird. Die so erhaltenen Parameter sind <math>K_{P}=4</math> und <math>K_{D}=0.6</math> (Die Parameter wurden nach der Anpassung gerundet). Zusätzlich wird der Ausgang des Reglers mit dem Faktor -2,4 multipliziert. Diese Multiplikation dient einerseits der Abbildung des Wertebereichs der Regelgröße auf den des PWM-Output-Blocks ([-25,25]->[-60,60]) und andererseits der Bestimmung der Drehrichtung. (Es wäre ebenso Möglich die Polung der Motoren umzukehren, um die Drehrichtung zu beeinflussen.) Nachdem so die Regelung eingebunden ist, wird die Lenkung implementiert. Wie zuvor erwähnt, besitzt das Lenksignal einen Wertebereich von [-1,1] (negative Werte entsprechen einem Lenkeinschlags nach Links). Dieses Signal wird zu 1 addiert (für den linken Motor) beziehungsweise von 1 subtrahiert (für den rechten Motor). Multipliziert mit dem Regler-Output soll so das geforderte Drehmoment auf die Motoren verteilt werden, sodass einem Lenkeingriff entsprechend die Räder unterschiedlich schnell drehen und trotzdem ein Umfallen verhindert wird. Da der "Nullpunkt" bei einem Input von 190 in den Arduino-PWM-Block liegt, wird der aus Regler und Lenkung erhaltene Wert zu 190 addiert. Zur Sicherheit wird Erhaltenes mit Saturation-Blöcken auf das festgelegte Input-Intervall begrenzt, auf ganzzahlige Werte gerundet und schließlich in die PWM-Blöcke geführt.		Dazu wird zunächst der PID-Controller-Block eingebunden. Anhand des Modells mit der PID-Tuner-App voreingestellt, werden im ersten Schritt die Regelparameter dahin gehend angepasst, dass der Neigungswinkel in Grad angegeben wird, wohingegen im Modell mit Radiant gearbeitet wird. Die so erhaltenen Parameter sind <math>K_{P}=4</math> und <math>K_{D}=0.6</math> (Die Parameter wurden nach der Anpassung gerundet). Zusätzlich wird der Ausgang des Reglers mit dem Faktor -2,4 multipliziert. Diese Multiplikation dient einerseits der Abbildung des Wertebereichs der Regelgröße auf den des PWM-Output-Blocks ([-25,25]->[-60,60]) und andererseits der Bestimmung der Drehrichtung. (Es wäre ebenso Möglich die Polung der Motoren umzukehren, um die Drehrichtung zu beeinflussen.) Nachdem so die Regelung eingebunden ist, wird die Lenkung implementiert. Wie zuvor erwähnt, besitzt das Lenksignal einen Wertebereich von [-1,1] (negative Werte entsprechen einem Lenkeinschlags nach Links). Dieses Signal wird zu 1 addiert (für den linken Motor) beziehungsweise von 1 subtrahiert (für den rechten Motor). Multipliziert mit dem Regler-Output soll so das geforderte Drehmoment auf die Motoren verteilt werden, sodass einem Lenkeingriff entsprechend die Räder unterschiedlich schnell drehen und trotzdem ein Umfallen verhindert wird. Da der "Nullpunkt" bei einem Input von 190 in den Arduino-PWM-Block liegt, wird der aus Regler und Lenkung erhaltene Wert zu 190 addiert. Zur Sicherheit wird Erhaltenes mit Saturation-Blöcken auf das festgelegte Input-Intervall begrenzt, auf ganzzahlige Werte gerundet und schließlich in die PWM-Blöcke geführt.

			Der Fußtaster wird als Sicherheitseinrichtung eingebunden. Mit Hilfe von Switch-Blöcken führt ein nicht-gedrückter Fußtaster dazu, dass Lenkung und Regler jeweils den Input 0 erhalten, sodass es nicht mehr zur Drehung der Motoren kommt. Der jetzige Stand des Simulink-Modells kann im Projekt-Repository eingesehen werden.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-21T13:37:14Z

Die Programmierumg

← Nächstältere Version		Version vom 21. September 2019, 13:37 Uhr
Zeile 216:		Zeile 216:
	So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.		So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.

	Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen. Die PWM-Outputs des benutzten Arduino Mega2560 arbeiten mit einer Frequenz von 490Hz. Der Input des Analog-Ouput-Blocks für einen Output mit einer Pulsweite von 1500us ergibt sich daher wie folgt:		Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>s, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen. Die PWM-Outputs des benutzten Arduino Mega2560 arbeiten mit einer Frequenz von 490Hz. Der Input des Analog-Ouput-Blocks für einen Output mit einer Pulsweite von 1500us ergibt sich daher wie folgt:

	<math>PWM_{in, 1500us} = 490\frac{1}{s}\cdot1500\mu s\cdot255</math>		<math>PWM_{in, 1500us} = 490\frac{1}{s}\cdot1500\mu s\cdot255 = 187,425</math>

	Mit diesem Zusammenhang lässt sich das Input-Intervall [125,250] berechnen. (Tests haben gezeigt, dass das Intervall [130, 250] besser geeignet ist. Der Nullpunkt liegt dann bei 190).		Mit diesem Zusammenhang lässt sich das Input-Intervall [125,250] berechnen. (Tests haben gezeigt, dass das Intervall [130, 250] besser geeignet ist. Der "Nullpunkt" liegt dann bei 190). Somit ist bestimmt, welcher Gestalt die Signale sein müssen, die zur Ansteuerung der Motoren dienen. Um diese bereitzustellen folgt der Entwurf der Transformation der Systemeingänge in die Ausgänge.

			Dazu wird zunächst der PID-Controller-Block eingebunden. Anhand des Modells mit der PID-Tuner-App voreingestellt, werden im ersten Schritt die Regelparameter dahin gehend angepasst, dass der Neigungswinkel in Grad angegeben wird, wohingegen im Modell mit Radiant gearbeitet wird. Die so erhaltenen Parameter sind <math>K_{P}=4</math> und <math>K_{D}=0.6</math> (Die Parameter wurden nach der Anpassung gerundet). Zusätzlich wird der Ausgang des Reglers mit dem Faktor -2,4 multipliziert. Diese Multiplikation dient einerseits der Abbildung des Wertebereichs der Regelgröße auf den des PWM-Output-Blocks ([-25,25]->[-60,60]) und andererseits der Bestimmung der Drehrichtung. (Es wäre ebenso Möglich die Polung der Motoren umzukehren, um die Drehrichtung zu beeinflussen.) Nachdem so die Regelung eingebunden ist, wird die Lenkung implementiert. Wie zuvor erwähnt, besitzt das Lenksignal einen Wertebereich von [-1,1] (negative Werte entsprechen einem Lenkeinschlags nach Links). Dieses Signal wird zu 1 addiert (für den linken Motor) beziehungsweise von 1 subtrahiert (für den rechten Motor). Multipliziert mit dem Regler-Output soll so das geforderte Drehmoment auf die Motoren verteilt werden, sodass einem Lenkeingriff entsprechend die Räder unterschiedlich schnell drehen und trotzdem ein Umfallen verhindert wird. Da der "Nullpunkt" bei einem Input von 190 in den Arduino-PWM-Block liegt, wird der aus Regler und Lenkung erhaltene Wert zu 190 addiert. Zur Sicherheit wird Erhaltenes mit Saturation-Blöcken auf das festgelegte Input-Intervall begrenzt, auf ganzzahlige Werte gerundet und schließlich in die PWM-Blöcke geführt.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-21T12:24:22Z

Die Programmierumg

← Nächstältere Version		Version vom 21. September 2019, 12:24 Uhr
Zeile 216:		Zeile 216:
	So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.		So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.

	Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen.		Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen. Die PWM-Outputs des benutzten Arduino Mega2560 arbeiten mit einer Frequenz von 490Hz. Der Input des Analog-Ouput-Blocks für einen Output mit einer Pulsweite von 1500us ergibt sich daher wie folgt:

			<math>PWM_{in, 1500us} = 490\frac{1}{s}\cdot1500\mu s\cdot255</math>

			Mit diesem Zusammenhang lässt sich das Input-Intervall [125,250] berechnen. (Tests haben gezeigt, dass das Intervall [130, 250] besser geeignet ist. Der Nullpunkt liegt dann bei 190).

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-20T13:30:00Z

Die Programmierumg

← Nächstältere Version		Version vom 20. September 2019, 13:30 Uhr
Zeile 216:		Zeile 216:
	So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.		So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.

	Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es ~~Nötig~~ die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen.		Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-20T13:27:26Z

Die Programmierumg

← Nächstältere Version		Version vom 20. September 2019, 13:27 Uhr
Zeile 212:		Zeile 212:
	== Die Programmierumg ==		== Die Programmierumg ==
	Wie schon zuvor Bemerkt wird der Segway mit Matlab und Simulink programmiert, wobei der größte Teil dessen mit letzterem vollzogen wird.		Wie schon zuvor Bemerkt wird der Segway mit Matlab und Simulink programmiert, wobei der größte Teil dessen mit letzterem vollzogen wird.
	Zum Entwurf der Software wird das System, welches Programmiert werden soll, zunächst abstrahiert und als Black Box betrachtet. So werden die Eingangssignale und deren Umwandlung in die gewünschten Ausgangssignale genauer Definiert. Von dieser groben Dreiteilung ausgehend wird, beginnend mit den Eingängen, das Programm aufgebaut. So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung ~~von~~ Winkelmessung und Lenk-Signal. Das ~~Lenksignal wird weiterhin~~		Zum Entwurf der Software wird das System, welches Programmiert werden soll, zunächst abstrahiert und als Black Box betrachtet. So werden die Eingangssignale und deren Umwandlung in die gewünschten Ausgangssignale genauer Definiert. Von dieser groben Dreiteilung ausgehend wird, beginnend mit den Eingängen, das Programm aufgebaut.

			So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung der Winkelmessung und eine Sicherheitsfunktion, die die Motoren abschalten soll, falls der Sensor einfriert. Das Lenk-Signal wird mittels Multiplikation mit einem empirisch ermittelten Faktor und einem Saturation-Block auf einen Wertebereich von [-1,1] abgebildet, der Grund dafür wird bei Erklärung der Transformation der Eingänge zu Ausgängen ersichtlich.

			Bevor die Erzeugung der Ausgänge, also die Signale zur Steuerung der Motoren, Umgesetzt wird, muss geklärt sein, welcher Gestalt diese sein müssen. Der Motortreiber kann mit PWM-Signalen gesteuert werden. Dazu steht der Analog-Output-Block zur Verfügung. Dieser verarbeitet Eingänge in Form von ganzzahligen Werten zwischen 0 und 255 die einer Ausgangsspannung zwische 0 und 5V entsprechen. Der Motortreiber interpretiert die PWM-Signale jedoch als Signale einer Fernsteuerung. Das heißt ist diesem Fall, dass Signale mit Pulsweiten zwischen 1000 und 2000<math>\mu</math> zur Steuerung der Motoren genutzt werden. Hier bedeutet eine Pulsweite von 1500<math>\mu</math>, dass die Motoren stehen, über diesem Wert drehen sie Vorwärts und unterhalb Rückwärts. Daher ist es Nötig die Pulsweiten für die Werte zwischen 0 und 255 zu berechnen.

	= Anforderung =		= Anforderung =

Marius Koehler: /* Die Programmierumg */

2019-09-20T12:44:32Z

Die Programmierumg

← Nächstältere Version		Version vom 20. September 2019, 12:44 Uhr
Zeile 212:		Zeile 212:
	== Die Programmierumg ==		== Die Programmierumg ==
	Wie schon zuvor Bemerkt wird der Segway mit Matlab und Simulink programmiert, wobei der größte Teil dessen mit letzterem vollzogen wird.		Wie schon zuvor Bemerkt wird der Segway mit Matlab und Simulink programmiert, wobei der größte Teil dessen mit letzterem vollzogen wird.
	Zum Entwurf der Software wird das System, welches Programmiert werden soll, zunächst abstrahiert und als Black Box betrachtet. So werden die Eingangssignale und deren Umwandlung in die gewünschten Ausgangssignale genauer Definiert. Von dieser groben Dreiteilung ausgehend wird, beginnend mit den Eingängen, das Programm aufgebaut. So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann.		Zum Entwurf der Software wird das System, welches Programmiert werden soll, zunächst abstrahiert und als Black Box betrachtet. So werden die Eingangssignale und deren Umwandlung in die gewünschten Ausgangssignale genauer Definiert. Von dieser groben Dreiteilung ausgehend wird, beginnend mit den Eingängen, das Programm aufgebaut. So stellen sich zwei Fragen: Welche Eingänge besitzt das System? Und wie werden diese mit Simulink benutzt, beziehungsweise nutzbar? Die Eingänge des Systems sind der ''Neigungswinkel'', der ''Lenkeinschlag'' und der ''Fußtaster''. Lenkeinschlag und Fußtaster lassen sich mit Blöcken des Simulink Support Package for Arduino Hardware erfassen. Dazu wird ein Analog-Input-Block zur Messung der Spannung am Lenk-Potentiometer und ein Digital-Input-Block zur Erfassung des Fußtaster-Zustands genutzt. Das GY-521-Sensorboard kommuniziert über den I2C-Bus des Arduino. Auch für diesen existiert ein fertiger Block, der jedoch nicht zur effizienten Nutzung der Funktionen des Sensors geeignet ist. Daher wird mit Hilfe des so genannten S-Function-Builder ein eigener Treiber-Block erstellt, der den Zugriff auf den Sensor im gewünschten Maß erlaubt. Der Code des Treiber-Blocks basiert auf der MPU6050-Bibliothek aus der [https://github.com/jrowberg/i2cdevlib i2cdevlib] von Jeff Rowberg. Diese erlaubt unter Anderem den Zugriff auf den DMP ('''D'''igital '''M'''otion '''P'''rocessor) des Sensors, der aus den Sensordaten die Lagewinkel bestimmen kann. Der DMP wird genutzt, da so der Arduino entlastet wird und die selbst-implementierte Sensordatenfusion als Fehlerquelle ausgeschlossen werden kann. Somit stehen die drei Eingangssignale des Systems, die in Simulink zu einem Subsystem zusammengefasst werden. In diesem Subsystem befinden sich weiterhin vor-verarbeitende Funktionen und Blöcke, sodass aus dem Subsystem Daten weitergegeben werden, die im folgenden direkt weitergenutzt werden können. Diese Vorverarbeitung umfasst die Bestimmung des Offsets der Winkelmessung, die Korrektur der Winkelbestimmung beim Nulldurchgang, Tiefpass-Filterung von Winkelmessung und Lenk-Signal. Das Lenksignal wird weiterhin

	= Anforderung =		= Anforderung =