Hallo, ich schreibe derzeit an meiner Bachelorarbeit. Thema ist die Entwicklung eines Lenkwickelgebers und einer Lenkwinkelregelung für ein autonomes Modellfahrzeug. Auf dem Fahrzeug ist ein PC, welcher die Fahrbahnerkennung und Fahrspurberechnung erledigt, verbaut. Dieser bekommt die Fahrzeugistwerte bzw sendet die Sollwerte an einen Mikrocontrollerverbund. Dieser Verbund besteht aus 2 ARM Controllern. Der Erste ist für die Kommunikation zum PC und die Abfrage der Sensoren (I2C) zuständig. Der zweite Controller ist für die Erzeugung der PWM-Werte für Lenkservo und Motor zuständig. Auf diesem soll auch die Regelung implementiert werden. Auf den Controllern kommt ein Scheduler zum Einsatz. Das heißt es werden alle Tasks in vorgebener Reihenfolge abgearbeitet. So gibt es zB eine Task, die die Sensorwerte abfragt und eine Weitere die die Kommunikation zu ARM2 tätigt. Für den Lenkwinkelgeber habe ich einen Sensor auf Basis eines belasteten Spannungsteilers entwickelt, der mit dem Lenkservo verbunden ist. Über die gemessene Spannung lässt sich der Winkel ermitteln. Der ADC ist über den I2C-Bus an ARM1 angeschlossen. ARM1 überträgt den gemessenen Wert an ARM2, welcher diesen für die Regelung benötigt. Nun habe ich mehrere Messungen für die Sprungantwort gemacht. Im ersten Schritt habe ich die Zeit gemessen, die benötigt wird zwischen setzen des PWM-Wertes (Triggersignal auf ARM2) und dem Ereichen des sationären Endwertes (gemessen am Poti). Im zweiten Schritt habe ich die übertragung zwischen Abfrage des Sensors und "Eintreffen" des Istwertes in der Reglertask gemessen. Diese Zeit muss ich nach meinem Verständnis zur Totzeit zuaddiern. Zur Sicherheit habe ich jeweils mehrere Messungen getätigt. Dabei ist mir aufgefallen, dass die Zeit zwischen ARM2 und Poti immer gleich ist (39ms Totzeit und 340ms von Linksausschlag nach Rechtsausschlag). Jedoch schwankt die Zeit von ARM1 zu ARM2. Mit jedem Neustart des Systems erhalte ich andere Zeiten. Zwischen 4ms und 20ms. Verändere ich die Reihenfolge der Tasks oder kommen weitere Tasks hinzu, kann sich die Totzeit auf bis zu 120ms ausweiten. Zur Berechnung der Regelung kommt das Verfahren von Takahashi zum Einsatz. Leider wurde das Thema Regelung im Studium nur sehr oberflächlich behandelt. Frei nach dem Motto: Regelung gibt es auch. Somit bin ich etwas aufgeschmissen, da ich nicht weiß wie ich dieses Problem angehen soll. Soll ich zur Berechung einfach die längste gemessene Totzeit nehmen (In der Hoffnung, dass ich die längste gemessen habe)? Das System darf ich nicht ändern. Es ist also nicht möglich die Aufteilung der Aufgaben der ARM's (würde auch mechanische Änderungen erfordern) zu ändern, noch darf ich das Taskkonzept aushebeln. Wo finde ich, für einen technischen Informatiker, leicht verständliche Literatur, welche einfache Wege zur Problemlösung aufzeigt bzw mit der ich belegen kann, dass eine Reglerimplementation den Rahmen der BA sprengen würde. Bei den millionen von Büchern zum Thema Regelungstechnik sehe ich das richtige Kapitel vor lauter Seiten nicht. ;) Vielen Dank für die Hilfe im Voraus Christian
>Soll ich zur Berechung einfach die längste >gemessene Totzeit nehmen (In der Hoffnung, dass ich die längste gemessen >habe)? Bei Regelungen ist so, dass Systeme mit langen Totzeiten schlechter zu regeln sind. Vereinfacht ausgedrückt (zum Verständniss): Wenn die Regelung schneller als die Regelstrecke ist kommt es zum Schwingen. Totzeiten machen die Regelstrecke langsamer. Also wenn die Totzeit größer wird muss die Regelung langsamer gestaltet werden. Das heißt beim Auslegen der Regelung musst du den worst case ansetzten also die längste mögliche Totzeit. Dadurch wird dein Gesammtsystem natürlich langsamer aber es wird vermieden, dass es zu Resonanzen kommt.
Die Regelung muss ja nicht im Nebel stochern sondern kann von einem definierten Verhalten ausgehen.
Das war der Hinweis den ich brauchte. Wenn ich eine Fahrzeuggeschwindigkeit von 7m/s zu Grunde lege, wird im worst case (160ms) ja schon eine Strecke von mehr als einem Meter während der Totzeit zurückgelegt. Da ist eine Reglung irgendwie nutzlos. Vielen Dank.
Christian Möller schrieb: > Der ADC ist über den I2C-Bus an ARM1 angeschlossen. > ARM1 überträgt den gemessenen Wert an ARM2, welcher diesen für die > Regelung benötigt. Hat sich das dein Prof oder irgendeiner seiner Assi's ausgedacht? Also - so wie ich das verstanden habe: Der Ist-Lenkwinkel wird per Poti und ADC von uC1 gemessen und dann irgendwann nach einer erheblichen und unvorhersagbaren Pause an uC2 gesendet, der seinerseits den Soll-Lenkwinkel kennt und anhand des gesendeten Ist-Wertes die Nachstellung des Lenkwinkels veranlassen soll. Schönen Gruß an deinen Prof: Wenn er mein Mitarbeiter wäre, dann würde ich ihm seine Idee um die Ohren schlagen bis er begreift, was für einen Stuss er sich da ausgedacht hat. Sowas einem Studenten zuzumuten ist nach meiner Meinung eine Abart vom Mobbing - er weiß vermutlich sehr genau, daß man mit derartigen Vorgaben schlichtweg vor die Wand rennt und scheitern MUSS. Also: 1. der Ist-Winkel sollte direkt mit einem internen ADC vom uC2 gemessen werden. 2. Der Wert sollte per Interrupt-Routine abgefragt und sofort zu einer entsprechenden Nachstellung des Lenkantriebes führen, also ohne den Umweg über langsame und zeitlich unvorhersagbare RTOS-Mechanismen. 3. Sowas muss erlaubt sein, denn der Sinn eines jeden Echtzeit-Betriebssystems besteht ja gerade darin, daß es in Echtzeit, also zur rechten Zeit reagieren kann. Wenn dieses für Dinge hoher Priorität (und die Lenkung eines Fahrzeuges hat wohl die allerhöchste Priorität) von der Systemstruktur (also der Aufgabenaufteilung, der Priorisierung etc.) nicht garantiert werden kann, dann ist der gesamte Systemansatz ein Fall für die Mülltonne. Selbst Shannon läßt hier grüßen. Wahrscheinlich mußt du bei anzunehmenden Totzeiten von 200 ms und mehr die Forderung erheben, daß die Fahrgeschwindigkeit des Vehikels nicht mehr als 2..3 cm pro Sekunde betragen darf, weil sonst nicht mehr für die Lenkung garantiert werden kann - eben wegen des Abtast-Therorems. W.S.
Mir scheinen die Zeiten fuer die trivialen Operationen viel zu hoch zu sein. Mir erscheint 0.5 .. 1ms grad noch tragbar zu sein. Zwei ARM Controller haben ja eine derart hohe Rechenleistung, das sollte moeglich sein. Wo geht die Zeit drauf ? Ist das System preemptiv ? Dann mit 10kHz clocken.
@ W.S. Ja das hat sich einer meiner Professoren ausgedacht. Ist aber kein Informatiker. Die Vermutung, dass das Konzept Mist ist wurde schon früher geäußert (nicht nur von mir). Aber welcher Student widerspricht schon gerne seinem betreuenden Prof. Leider kann kein interner ADC verwendet werden, da diese mit der Überwachung der Akkus betraut sind. Dies ließe sich codetechnisch wohl leicht ändern, aber die elektronische Komponente nicht. Zumindest nicht, wenn man die Überwachung nicht weglassen will. Das Konzept alles in Tasks zu machen wurde meines Wissens gewählt, weil dadurch alle Funktionen klar abgetrennt sind und wohl leichter zu verstehen. Das Fahrzeug wird in studentischen Projekten eingesetzt, in denen die Studierenden ein Semester mitarbeiten. Deshalb kann ich da auch nicht einfach das Konzept ändern und über Interrupts Daten senden oder abfragen. Zum Glück kann die Erkenntnis das etwas nicht realisierbar ist (auch wenn man es vorher wusste) das Resultat einer BA sein. Somit ist die Annahme zumindest belegt. Nicht schön für mich, aber zumindest habe ich ein Sensorsystem entwickelt. Das wohl bei den vorherschenden Laufzeiten nur als informell bezeichnet werden kann. Sieht doch in einer Telemetrieoberfläche schick aus. @ Mega Oschi Soweit ich das Scheduling durchblicken konnte (ich hab mich nicht so tiefgreifend damit beschäftigt), bekommt eine Task x ms Laufzeit zur Verfügung gestellt. Ob sie diese nun braucht oder nicht ist egal. Der Timer läuft ab und der Taskwechsel erfolgt. Des Weiteren wird in jedem Zyklus jede Task durchlaufen. Egal ob sie etwas zu tun hat oder nicht. Zum Beispiel Licht steuern: Wenn das Licht schon leuchtet schalte es nochmal ein. Bei mehreren Tasks, welche zw 10ms und 25ms Zeit bekommen, summiert sich dies halt entsprechend auf. Durch umsortieren habe ich die Zeit für meinen Fall ja schon drücken können. Aber sollte jemand auf die Idee kommen eine andere zeitkritische Anwendung zu implementieren ... Leider ist der Scheduler nicht preemtiv. Ich denke das Konzept ist in dem Fall richtig, wenn man nur ein paar Fahrwerte setzen will und keine Rückmeldung benötigt. Auch das Hinzufügen neuer Funktionen ist somit ja leicht. Definiere die Variablen im Datencontainer die du brauchst, schreib deine Task, trage diese in der main-Funktion ein und füge einen case zur Abfrage bzw zum Senden in die entsprechende Task ein. Fertig. Nur wie gesagt bei zeitkritschen Sachen wie Regelung versagt der Ansatz. Ich danke nochmals allen für die Hilfe. Viele Grüße Christian
Wofuer geht denn die Rechenzeit drauf ? Floatingpoint matritzen ? Man kann solche Tasks auch abkuerzen, indem man nur die halbe Matrix pro Zeitscheibe rechnen laesst. Das Wesen eines Echzeitsystems ist, dem wichtigen Prozess die noetige Rechenzeit zur Verfugung zu stellen. Und das Steuern des Fahrzeuges ist wichtig. Falls die Rechenzeit nicht reicht, muss man eben langsamer fahren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.