Nichtlineare Regelung mit einem Raspberry PI

Ein Ball mit einer Masse \(m_{B}\) und einem Radius \(r_{B}\) liegt auf einem Rad. Dieses Rad mit Radius \(r_{W}\) und dem Trägheitsmoment \(J_{W}\) wird von einem Gleichstrommotor angetrieben. Ziel des Aufbaus ist es, den Ball durch die Drehung des Rades auf dem Rad zu balancieren. Der Winkel des Rades wird mit \(\varphi_{W}\) und der des Balles mit \(\varphi_{B}\) (siehe Skizze Abb. 1) bezeichnet. Zunächst sollen beide Winkel einbezogen werden. Allerdings wird vom Rad lediglich die Winkelgeschwindigkeit \(\dot{\varphi}_{W}\) gemessen, so dass der Winkel \(\varphi_{W}\) später weggelassen wird. Mit dem Trägheitsmoment \(J_{W}\) des Rades sowie dem Trägheitsmoment \(J_{B}\) und der Masse \(m_{B}\) des Balles erhält man die kinetische Energie des Gesamtsystems Weiters erhält man mit der Schwerkraft \(g\) die potentielle Energie Aus dem Lagrange Formalismus erhält man die Bewegungsgleichungen mit den verallgemeinerten Kräften \(\boldsymbol {Q} = \begin{bmatrix} Q_{1} & Q_{2} \end{bmatrix}^{T}\). Die Kräfte setzen sich zusammen aus einem Teil vom Motor und einem Teil aus der Reibung im System. Der wirkt über ein Getriebe mit der Übersetzung \(i_{G}\) auf das Rad. Da es sich um einen Gleichstrommotor handelt, ist sein Moment \(M_{M}\) gegeben durch: mit der Motorkonstanten \(k_{M}\), dem Ankerwiderstand \(R_{A}\) und der Ankerspannung \(u_{A}\) als Stellgröße. Die Induktivität des Motors ist gegenüber dem mechanischen Aufbau vernachlässigbar klein. Die wesentlichen Reibbeiträge entstehen durch das Drehen des Rades im Lager und durch das Rollen des Balles auf dem Rad jeweils mit einem Coulombschen und einem viskosen Anteil. Zusammengenommen sind die Kräfte dann Die Zahlenwerte der Parameter sind in Tab. 1 zu finden.

Sowohl für den Reglerentwurf als auch für die Trajektorienplanung wird eine kompakte Darstellung als eingangsaffines System, im Englischen Affine Input System, verwendet. In den Modellgleichungen taucht der Winkel \(\varphi_{W}\) nicht auf. Da er auch nicht gemessen wird, kann man ihn weglassen und führt \(\omega_{W} = \dot{\varphi}_{W}\) ein. Setzt man in die Gl. (1), (2) und (3a), (3b) die Parameterwerte aus Tab. 1 ein, so erhält man mit dem Zustand das eingangsaffine System Die Werte sind rechts in Tab. 1 zu finden. Die Konstanten \(C_{W}\) und \(C_{B}\) entstehen durch die Coulombsche Reibung und hängen nur von den Vorzeichen \(\operatorname{sign}\omega_{W}\) und \(\operatorname{sign}(\dot{\varphi}_{B} - \omega_{W})\) ab, die sich während des Betriebes zumeist nicht ändern. Das rechtfertigt die Berücksichtigung als Konstante. Im Einzelnen sind es

Da verschiedene Zustandsregler zum Einsatz kommen sollen, muss der gesamte Zustand messbar sein. Die Größen \(\omega_{W}\) und \(\varphi_{B}\) werden messtechnisch erfasst. Die dritte \(\dot{\varphi}_{B}\) muss beobachtet werden. Sieht man von den Konstanten ab, so fällt bei der Betrachtung von Gl. (4) auf, dass die nichtlinearen Terme einzig aus gemessenen Größen bestehen und die zu beobachtende Größe linear auftritt. Das System hat die Struktur Der Zustand \(\hat{z}\) des reduzierten Beobachters und die Beobachterverstärkung werden analog zum linearen Fall eingeführt Die Beobachtergleichungen lauten dann und für den ,,wahren” Wert Zieht man beide voneinander ab, erhält man die lineare Fehlerdynamik

Zwei unterschiedliche Zustandsregler sollen realisiert werden, zum ersten ein einfacher linearer Zustandsregler, zum zweiten eine Steuerung und Regelung, die die Eigenschaft der Flachheit nutzt.

BIOE wurde ursprünglich für eine Verwendung mit einem echtzeitfähigen Standard-PC entwickelt. Daher verwendet es dessen parallele Schnittstelle (LPT) zur Übertragung. So musste der Raspberry PI mit einer LPT-Schnittstelle versehen werden. Dies wurde mit einem speziellen LPT-Treiber, der auf dem Beispiel [8] basiert, erreicht. Mit diesem Treiber ist neben der geforderten minimalen IO-Zeit und der Zuverlässigkeit beim Setzen einzelner GPIOs auch das zeitlich parallele Setzen und Lesen mehrerer GPIOs möglich. Mit dem damit entwickelten Treiber ergibt sich sogar eine etwas bessere IO-Zeit als am PC in der Regel mit einer echten LPT-Schnittstelle zu erwarten wäre. Die IO-Zeit am Raspberry PI beträgt etwa 30 μs. Noch kürzere Zeiten sind vom Raspberry PI her möglich. Jedoch sind die Mikroprozessoren der BIOE-Module dafür nicht geeignet.

Zur Adaption der Hardware wurde der LPT-Adapter geplant und gefertigt, welcher dazu dient, den Logik-Pegel für High von 5 V des BIOE auf die 3.3 V des Raspberry PI wandeln zu können. Eine Trägerplatine nimmt drei kleine Logik-Konverter-Platinen auf, welche ihrerseits je vier bidirektionale IO-Leitungen umsetzen können. Diese werden unter anderem für Entwicklerarbeiten am Raspberry PI angeboten.

Das bisher veröffentlichte BIOE [10] bietet die Möglichkeit pro Modul bis zu vier Spannungen zwischen 0 und 5 V, einzulesen. Zur Ausgabe analoger Signale existiert lediglich eine Puls-Weiten-Modulation (PWM). Wegen des offenen Charakters ist das BIOE jedoch gut erweiterbar. Es wurde eine Platine gefertigt, die mit verschiedenen Pin-kompatiblen 12-bit ADC-Chips bestückt werden kann. Hier kamen ein HI-674A der Firma Intersil und ein ADS774 von Texas Instruments zum Einsatz. Weiters wurde eine Platine gefertigt, die einen 12-bit DAC, den DAC811 von Texas Instruments, an das BIOE anschließt. Dadurch können mehrere bipolare Spannungen mit wählbaren Bereichen eingelesen und ausgegeben werden. Die jeweils nötigen Versorgungsspannungen werden mit einem integrierten DC/DC-Wandler aus der \(+5\) V Versorgung gewonnen.

Die BIOE-Firmware wurde modifiziert, um eine neue DTN (Device-Type-Number) für den Betrieb mit der ADC-Platine und der DAC-Platine bereit zu stellen.

Zusammen mit BIOE [10] wird das Internet-basierte Bedien- und Beobachtungspaket RTXML angeboten. Dieses ist als Erweiterung für Scilab [9] und Scicoslab verfügbar. Über die in Scilab und Scicoslab enthaltene graphische Programmierumgebung Scicos, kann damit C-Code und dessen direkt ausführbares Programm generiert werden. Sobald es gestartet wird, bietet es ein über HTTP bereitgestelltes Web-Interface an, welches dem Benutzer erlaubt, Parameter des im Programm enthaltenen Echtzeittasks zu ändern und Messdaten von jenem im Web-Browser graphisch darzustellen.

Im Zuge der in diesem Artikel vorgestellten Adaptierung und Erweiterung von BIOE wurde auch eine Modifikation von RTXML realisiert, welche die Verwendung von RTXML in der Programmierung mit C oder C++ möglich macht. Die spezielle Schnittstelle, die bei der Code-Generierung in Scilab verwendet wird, wurde dabei durch eine für den Programmierer lesbare ersetzt.

Als Betriebssystem wird Xenomai [1] für den Raspberry PI verwendet. Eine Verwendung von RT PREEMPT und Standard-Linux funktioniert mit wenigen Anpassungen ebenso.

Um die Echtzeitfähigkeit zu testen, wurde ein Ablauf ähnlich zu dem im Abschn. 4.3 vier Stunden lang durchgeführt. Dabei wurden während der Ausführung über Xenomai-POSIX Zeitpunkte der CLOCK_MONOTONIC² gemessen. Das Ergebnis findet man in Tab. 2. Die Verteilung des Jitters, also die Zeit um die sich der Start des Programmes gegenüber dem geplanten Start verzögert, ist in Abb. 2 als Histogramm dargestellt. Hervorzuheben ist, dass der Jitter im Mittelwert lediglich 19.84 μs mit geringen Schwankungen beträgt, so dass auch wesentlich kürzere Abtastzeiten, als die hier verwendeten 10 ms möglich sind. Die echtzeitkritische Rechenzeit ist jene Zeit, die von der Bereitstellung der Messwerte bis zur Bereitstellung der Stellgröße für den jeweiligen Abtastschritt verstreicht. Die echtzeitkritische Gesamtzeit ist die Zeit, die vom Start des Programmes bis zur Ausgabe der neuen Stellgröße verstreicht, also die Summe aus Eingabe-, Ausgabe- und Rechenzeit. Der recht hohe Maximalwert zeigt an, dass es durch betriebssysteminterne Abläufe sehr vereinzelt auch zu deutlich längeren Rechenzeiten kommen kann, die jedoch die Stabilität der Regelung nicht merklich beeinflussen. In Abb. 3 sieht man das Histogramm der echtzeitkritischen Gesamtzeit.

Um eine gute Modularisierung und Wiederverwendbarkeit zu erreichen, wird der Regler objektorientiert in C++ realisiert. Dadurch können in der gegebenen Struktur (Abb. 4) unterschiedliche Regler leicht ausgetauscht werden. Dabei müssen selbstverständlich nicht immer sämtliche Klassen vorhanden sein und bei den Klassen müssen nicht sämtliche Eigenschaften ausgeprägt werden. Beispielsweise hat der Trajektorienfolgeregler (8a), (8b) keine internen Zustände und der lineare Regler mit I-Anteil benötigt keinen \(x^{d}(t)\)-Generator. Man beachte, dass der \(y^{d}(t)\)-Generator keinerlei Information über die spezifische Regelstrecke hat, bzw. benötigt. Er lässt sich daher für andere Aufgaben wiederverwenden. In der vorliegenden Arbeit wird die Solltrajektorie durch abschnittsweise definierte Polynome dargestellt, bei denen an den Übergangsstellen die erforderliche Glattheit garantiert wird. Weil die Darstellung der Trajektorien eine private Eigenschaft ist, können ohne Schwierigkeit auch andere Darstellungen implementiert werden. Ein Algorithmus zur Planung von Übergängen zwischen Ruhelagen \(y^{d}_{\mathrm{start}}\) und \(y^{d}_{\mathrm{end}}\) gehört zur Grundausstattung.

Auch die Simulationsumgebung wurde ausschließlich mit offener Software eingerichtet, nämlich mit GNU-Octave [3] und dessen C++ Schnittstelle. Zunächst wurden die Bewegungsgleichungen (1) um einige bewusst nicht modellierte Eigenschaften erweitert, um realitätsnahe Störungen in der Simulation zu erhalten. Speziell wurden die Exzentrizität des Balles, denn der Ball ist nicht ausgewuchtet, und ein feineres Reibmodell hinzugenommen. Dieses Modell wurde für den Befehl lsode von GNU-Octave als zeitkontinuierliches Modell implementiert. In einer Schleife über die Abtastzeitpunkte wurden die simulierten Messwerte über das External Code Interface (Oct-Files) an die in Abschn. 3.4 skizzierten Regler übergeben und die berechnete Stellgröße für den neuen Abtastschritt entgegengenommen. Zu bedenken ist dabei nur, dass die Objekte nach jedem Aufruf zerstört werden. Daher müssen deren Eigenschaften während der Simulation static deklariert werden, was zur Folge hat, dass jeweils nur eine Reglerkonfiguration gleichzeitig getestet werden kann. Von Abtastzeitpunkt zu Abtastzeitpunkt wird dann wieder zeitkontinuierlich simuliert, weshalb man von einer hybriden Simulation sprechen kann.

Die validierten Regler werden in der Folge an der realen Strecke mit einer Abtastzeit von 10 ms getestet.

Zwei Anschläge an dem Aufbau verhindern, dass der Ball im Falle des Versagens der Regelung herunter fällt. Zu Beginn des Tests liegt der Ball an einem dieser Anschläge. Das Testergebnis findet man in Abb. 5. Mit Einschalten des Reglers wird der Ball in die Mitte geholt und bei einer festen Winkelgeschwindigkeit \(\omega_{M}^{\mathrm{soll}}\) balanciert. Ein Sollwertsprung demonstriert die Robustheit. Dabei versucht der Regler das System in der Ruhelage zu halten, was natürlich bei Beschleunigung speziell für den Winkel \(\varphi_{B}\) nicht gelten kann. Die genaue Gestalt der Abweichungen bleibt bei diesem Regler dem Zufall überlassen. Man beachte, dass auch der Vorzeichenwechsel in \(\omega_{W}\), bei dem auch die trockene Reibung das Vorzeichen wechselt, kein Problem ist. Der I-Anteil kompensiert die geänderte Reibung wieder.

Falls keine höheren Ansprüche an das Verhalten bei Sollwertänderungen gestellt werden, ist dieser Regler gut genug, denn die Ruhelage wird robust stabilisiert.

Die Trajektorienplanung soll in etwa die gleiche Aufgabe lösen, wie zuvor der lineare Regler. Der Ball soll von einem Anschlag in die Mitte geholt und dort bei einer festen Geschwindigkeit \(\omega_{W}^{\mathrm{soll}}\) balanciert werden. Danach soll er auf eine andere feste Sollgeschwindigkeit wechseln. Die Wechsel sollen möglichst schnell geschehen. Dabei sind der Schnelligkeit jedoch Grenzen gesetzt, denn der Ball soll sich nicht zu weit aus der Mitte bewegen. Schaut man sich Gl. (6b) näher an, so fällt auf, dass \(\dot{y}\) überwiegend von \(\sin\varphi_{B}\) abhängt. Wenn man also \(z_{2} = \dot{y}\) beschränkt, wird sich der Ball nicht zu weit heraus bewegen. Die Solltrajektorie \(y^{d}\) wird daher eine Rampe mit der Steilheit \(-17.17\:\sin(10^{\circ})\), die an den beiden Enden durch Übergangspolynome so in eine Konstante \(\bar{y}^{d}\) überführt wird, dass die Trajektorie zweimal differenzierbar bleibt und die Spannung \(u_{A}\) nicht über \(\pm 24\) V geht. Durch die genauere Vorausplanung kann der Regler schwächer mit eingestellt werden. Das Ergebnis sieht man in Abb. 6. Den geplanten Trajektorien wird gut gefolgt. Durch die Planung ist man in der Lage, die Grenzen des Systems auszunutzen und gleichzeitig einzuhalten.