Archiv verlassen und diese Seite im Standarddesign anzeigen : Erstes Proggi: Quadratisch abhängiger Linienfolger
Hi!
Also, den Asuro hab ich jetzt seit ca. 4 Tagen. MANMANMAN macht das Teil Böcke! \:D/
Ich hab jetzt Verschiedenes ausprobiert und bin ein wenig an der Linienverfolgung hängen geblieben. Was mir nicht gefallen hat: Bisherige Lösungen sind entweder linear abhänging (und neigen damit zum "Wackeln" auf geraden Strecken) oder "schalten" praktisch gesehen einfach nur die Geschwindigkeit einer Seite auf Null (wie das Beispielproggi im Lieferumfang). Was ich gesucht habe ist eine kontinuierliche Regelung, die bei leichten Abweichungen auch nur leicht reagiert, bei stärkeren entsprechend auch stärker (auch mit negativen Geschwindigkeiten!).
Nach einigem probieren, hier jetzt eine meiner Meinung nach sehr passable Lösung: Quadratisch abhängige Regelung. Sprich: Die Differenz des Liniensensors wird zunächst quadriert und anschließend als Korrektur für beide Motoren verwendet. Dies verträgt sich ganz gut mit den Motoren, deren Anlaufverhalten ist ja auch alles andere als linear. Das Ergebniss: Auf geraden Strecken wackelt der Asuro deutlich weniger, gleichzeitig werden aber sehr viel engere Kurven genommen!
Hier der Code:
#include "asuro.h"
#include <stdlib.h>
#define maxspeed 130 /* gibt sowohl die maximal positive als auch die maximal negative
Geschwindigkeit an, guter Mittelwert etwa 140 */
#define medspeed 120 /* gibt die den Durchschnitt der Geschwindigkeit beider Seiten an,
guter Mittelwert etwa maxspeed-20 */
#define quadteiler 30 /* Quotient des Liniensensors. Umso niedriger desto mehr neigt der
Asuro zum "Wackeln" auf geraden Strecken, aber er nimmt auch engere Kurven. Umgekehrt umso
höher dieser Wert, desto schneller fährt der Asuro die Strecke ab (ohne Wackeln), aber es
werden zu enge Kurven "überfahren" Gute Werte zwischen etwa 10-100, guter Mittelwert 30 */
int speedLeft,speedRight, sR, sL, i;
unsigned int lineData[2];
void Line (void)
{
speedRight = medspeed - ((i*abs(i))/quadteiler);
speedLeft = medspeed + ((i*abs(i))/quadteiler);
if (speedRight > maxspeed) speedRight = maxspeed;
if (speedLeft > maxspeed) speedLeft = maxspeed;
if (speedRight < -maxspeed) speedRight = -maxspeed;
if (speedLeft < -maxspeed) speedLeft = -maxspeed;
if (speedRight < 0) {MotorDir (FWD,RWD); sR=-speedRight;sL=speedLeft;}
else if (speedLeft < 0) {MotorDir (RWD,FWD); sL=-speedLeft;sR=speedRight;}
else {MotorDir(FWD,FWD);sL=speedLeft;sR=speedRight;}
}
int main(void)
{
Init();
FrontLED(ON);
for (i = 0; i < 0xFF; i++) LineData(lineData);
speedLeft = speedRight = 120;
for(;;) {
LineData(lineData);
i = lineData[0] - lineData[1];
if (i > 0) {
StatusLED(GREEN);
Line();
}
else if (i < 0) {
StatusLED(RED);
Line();
}
else {
StatusLED(OFF);
speedLeft = speedRight = medspeed;
MotorDir(FWD,FWD);
sL=speedLeft;sR=speedRight;
}
MotorSpeed(sL,sR);
}
}
Würde mich natürlich freuen, wenn hier mal ein paar Leute bei Interesse eine Art "Review" geben würden, da das ja mein erstes "richtiges" Proggi ist. Es kann sein das die ersten drei definierten Werte deutlich angepasst werden, da ich meinen Liniensensor etwas aufgemotzt hab (siehe Bilder hier: https://www.roboternetz.de/phpBB2/viewtopic.php?t=11178&sid=d87ffe9b3f0144dbe85bbb8386cc6d7d)
Für "normale" Asuros empfehl ich aus dem Bauch bspw. einen quadteiler von ca. 10-30, bin mir aber nicht sicher.
Nojo, wie auch immer, hoffe euch gefällts. Gruß payce.
Hei! Das sieht doch mal nett aus. Ich werde es gleich mal ausprobieren. Bei mir hat es nämlich doch deutlich gewackelt. Ich mach es mal mit meiner billigen "Beta-Version" von der Verbesserung der Sensoren und mal normal.
Dann meld ich mich wieder.
Andun
Nachtrag:
Also ich hab es getestet und es läuft gut. Allerdings ist mir jetzt kein sooo heftiger Unterschied aufgefallen, da ich fand, dass er auch vorher nicht so gewackelt hat. Was mir allerdings aufgefallen ist, dass er sich komischerweise 2 mal am Anfang aufgehängt hat. Also in dem Moment wo er von komplett weiß nach schwarz fährt. Da hängt er sich an der Kante fest und wackelt nur nohc da. Sehr komisch.
Versteh ich nicht ganz.
Ich schau mal ob ich da ncoh was finden kann, aber ansonst ist das Programm gut. Also wenn er einmal auf der Linie läuft, dann tut er das gut, nur für meinen Geschmack zu langsam. :D (Ich werd einfach mal die Konstanten ändern)
So long
Andun
2. Nachtrag:
Es passiert sogar jedesmal dass er sich aufhängt, wenn cih ihn auf die Kante halte. Liegt wohl daran, dass dieser Unterschied dann ja auch noch quadriert wird. Das Problem ist wohl, dass er dann Richtung 0 kommt und dann nicht mehr los fährt. Da muss man noch irgendeine Kontrollstruktur einbauen.
Andun
3. Nachtrag:
Ich nochmal. :D
Also ihc hab mal nachgedacht. Wie man auf meiner HP unter Asuro --> Liniendetektor nachschauen kann im Diagramm "Ohne Mantel - hell" können bei mir Unterschiede von bis zu 600 auftreten. 600² ist 360.000. Und diese Zahl liegt ja wohl leider außerhalb des Bereiches eine "int" der ja signed (hier ja nicht als unsigned angegeben) nur bis etwa 32k geht. Da sollte der Hund begraben liegen.
Freut euch auf meinen 4. Nachtrag.
Andun
4. So das wird wohl für heute das letzte hier von mir sein. Aber komischer macht der Asuro bei mir nur Mist, wenn ich statt int einfach long hin schreibe. Ich versteh das nicht. Eigentlich dürfte sich doch nichts ändern. komisch ??? Falls mir das einer erklären kann. Bitte gern
Andun :-s
Hei, danke Andun für das ausführliche Review! Heeeftig!
Also den Unterschied zwischen int und long versteh ich auch überhaupt nicht. Gaaanz komisch. Ich probiers auch gleich mal aus (Nachtrag kommt ;) ) Wegen den Helligkeitsunterschieden kann ich mal folgende Formel angeben, mit der ich etwa den Faktor quadteiler geschätzt habe:
quadteiler = (maximaler Helligkeitsunterschied)²/(medspeed+maxspeed)
Warum medspeed+maxspeed? Weil, falls du diesen Wert von der durchschnittlichen Motordrehzahl abziehst, du an der untersten negativen Kante des Motors landest.
Bei mir ist der maximale Helligkeitsunterschied etwa nur 100 und medspeed+maxspeed = 250. Also quadteiler=10000/250=40. Bei dir wäre es dann eine ganz andere Liga an Teiler: 360000/250=1440 (!!!). Auch wenn du 100 als quadteiler verwendest, dürfte der Asuro sich noch den Allerwertesten abwackeln! Evtl sollte ich die Formel mal mit ins Proggi reinschreiben, wird verständlicher. Probiers mal aus! :)
Noch zwei andere Ideen hatte ich (um die Linie evtl noch schneller abzufahren): 1. mal ne kubische Abhängigkeit probieren (ich glaub allerdings, das dürfte zu heftig werden und ähnlich wie ein/abschalten des Motors wirken) und 2. adaptive MedSpeed im Sinne von: Wenn du (der Asuro) merkst, das du gerade aus fährst (sprich i relativ klein) schraub die Drehzahl hoch, bis der Unterschied wieder größer wird.
Dürfte beides nicht allzu schwer zu implementieren sein. Nur mach ich mir bei beiden Ideen Sorgen um die Stabilität (nicht, das er dann nach der 5. Fahrt doch noch ausbricht...).
So, schreib ich gleich nochmal.
1. Nachtrag:
Also was sofort bei Umstieg aller ints auf long auffällt: Die .hex wird deutlich größer!! Ist ja irgendwie auch klar. Nur: Reagiert der Asuro dann einfach zu langsam, weil er zuviel zu rechnen hat? Hab mal als "Taktanzeiger" eine der BackLeds mit drangehängt (direkt in der for(;;) Schleife). Ist aber kein Prob, die BackLED leuchtet noch durchgehend (also sicher noch (f Takt) > 100 Hz.
Mal hier eben ne blöde Frage nebenbei: Wieviel passt in den Asuro rein? Sprich: Wieviele Pages kann man über das Flashtool übertragen bzw. wie groß darf die .hex maximal sein?
Wegen den Probs mit long: Denke, es gibt Probs bei i = lineData[0] - lineData[1]; Hier werden zwei unsigned Ints (müssen Ints sein!) voneinander abgezogen und dann als eine signed long übergeben. Da muss es Schwierigkeiten geben, weil das Vorzeichenbit einfach als Zahl mit rüber kommt. Abhilfe: Statt unsigned int lineData[2]; als Definition einfach nur int lineData[2]; angeben. Der negative Bereich ist zwar nicht benötigt, aber so umgeht man die sonst notwendige Konvertierungsroutine.
So, Prob gelöst, Asuro läuft jetzt komplett auf long-Variablen völlig problemlos (zumindest hier bei mir). Um RAM zu sparen kann man später mal noch die Variablen auf long und int wieder aufteilen.
Aktualisierter Code für dich, Andun, und andere Interessierte:
2. Nachtrag:
War ja wohl sooooowas von klar, das ein zweiter Nachtrag kommt! So, hier jetzt dann erstmal der letzte Code für heut. Erstens hab ich mal nur i und die beiden Speeds auf long gelassen, um RAM zu sparen. Dürfte ausreichen, wenn nicht, müsste das wieder geändert werden.
Wichtiger: Nach dem Einsehen, das der quadteiler eigentlich *die* wichtige Variable in dem Proggi ist, hab ich sie über die Switches einstellbar gemacht. Es gibt jetzt einen quadinit, die entsprechend dem beschriebenen Schätzwert eingestellt wird und eine Variable quadteiler, die je nach quadinit über die Switches eingestellt werden kann (Sw1: quadteiler=quadinit/8 ... Sw6: quadteiler=quadinit*4). Das hat einige Vorteile: Erstens kann der Schätzwert eher mal untermauert/wiederlegt werden, ohne 50ig mal zu programmieren, zweitens kann der Asuro auf die jeweilige Bahn getrimmt werden (nur scharfe Kurven: Sw1 -> durch die Gegend wackel, eher Geraden und lange Kurven: Sw6 -> düüüüs).
Der Code dazu:
#include "asuro.h"
#include <stdlib.h>
#define maxspeed 130 /* gibt sowohl die maximal positive als auch die maximal negative
Geschwindigkeit an, guter Mittelwert etwa 140 */
#define medspeed 120 /* gibt die den Durchschnitt der Geschwindigkeit beider Seiten an,
guter Mittelwert etwa maxspeed-20 */
//zur Variable quadinit (fast schon wichtigste Variable!!):
/* Quotient des Liniensensors. Umso niedriger desto mehr neigt der
Asuro zum "Wackeln" auf geraden Strecken, aber er nimmt auch engere Kurven. Umgekehrt umso
höher dieser Wert, desto schneller fährt der Asuro die Strecke ab (ohne Wackeln), aber es
werden zu enge Kurven "überfahren". Einen Schätzwert erhält man über die Formel
quadinit = (maximaler Helligkeitsunterschied)²/(medspeed+maxspeed) , wobei der maximale
Helligkeitsunterschied von Asuro zu gemodetten Asuros sehr groß werden kann und bekannt sein
sollte! Bei mir: ca. 100 (damit quadinit=40), bei bspw. Anduns Asuro: 600 (und damit
quadinit=1440 (!))
Über die Kollisionstaster können verschiedene quadteiler ausgewählt werden (je nach abzufahrender Bahn)*/
/*ToDo: Kubische Abhängigkeit ausprobieren, adaptive medspeed abhängig von i*/
long i, speedLeft, speedRight;
char flag, sw;
int lineData[2], quadinit = 30, quadteiler, sR, sL;
void Line (void)
{
speedRight = medspeed - ((i*abs(i))/quadteiler);
speedLeft = medspeed + ((i*abs(i))/quadteiler);
if (speedRight > maxspeed) speedRight = maxspeed;
if (speedLeft > maxspeed) speedLeft = maxspeed;
if (speedRight < -maxspeed) speedRight = -maxspeed;
if (speedLeft < -maxspeed) speedLeft = -maxspeed;
if (speedRight < 0) {MotorDir (FWD,RWD); sR=-speedRight;sL=speedLeft;}
else if (speedLeft < 0) {MotorDir (RWD,FWD); sL=-speedLeft;sR=speedRight;}
else {MotorDir(FWD,FWD);sL=speedLeft;sR=speedRight;}
}
int main(void)
{
Init();
quadteiler=quadinit;
flag=0;
FrontLED(ON);
for (i = 0; i < 0xFF; i++) LineData(lineData);
speedLeft = speedRight = 120;
for(;;) {
if (flag=1) {flag=0; BackLED(ON,OFF);}
else {flag=1;BackLED(OFF,OFF);}
sw = PollSwitch();
sw = PollSwitch();
sw = PollSwitch(); //wird nur zum korrekten Auslesen 3x aufgerufen
if (sw > 0)
quadteiler=quadinit/8;
if (sw > 1)
quadteiler=quadinit/4;
if (sw > 2)
quadteiler=quadinit/2;
if (sw > 4)
quadteiler=quadinit;
if (sw > 8)
quadteiler=quadinit*2;
if (sw > 16)
quadteiler=quadinit*4;
LineData(lineData);
i = lineData[0] - lineData[1];
if (i > 0) {
StatusLED(GREEN);
Line();
}
else if (i < 0) {
StatusLED(RED);
Line();
}
else {
StatusLED(OFF);
speedLeft = speedRight = medspeed;
MotorDir(FWD,FWD);
sL=speedLeft;sR=speedRight;
}
MotorSpeed(sL,sR);
}
}
Mir ist gerade aufgefallen, das der PollSwitch() Probs macht und ab und an sw=1 übergibt, obwohl nix gedrückt wurde. Muss vielleicht noch öfters aufgerufen werden, um sicher zu gehen (steht zumindest in der Asuro-Anleitung). Haaaab aber jetzt echt keinen Bock mehr, weils 01:30 ist. :) *aufToDoListeschreib*
Gute Nacht und viel Spaß mit dem Proggi! :)
So. Moin erstmal. (Ihc musste grade eben schon in die Schule um meinen Stundenplan zusammen zustellen, damit es dann morgen shcon losgehen kann ;( Naja, B2T)
Also ich hab dein Programm von oben jetzt einfach mal direkt kompiliert und ausprobiert. Also wenn ich den Asuro ohne Abschirmung (also im normal Zustand) im Licht (von vorne) fahren lasse, dann geht dies nur zuverlässig mit K1, also "sw > 16" , also "quadteiler=quadinit*4;" Es funktioniert bei mir also mit einem quadteiler von 120 gut. Wenn ihc ihn in dem Zustand (120) auf die Kante(weiß, schwarz) setzte kommt er von dieser auch weg, ohne sich zu verhaken. Bei jedem anderen (also kleineren) Wert hängt er sich an der Kante auf.
Ich denke, dann hätten wir das geklärt. :D Achja, wie viele Pages in den Asuro passen wüsste ich auch gern. (Ich bin zu faul ins Datenblatt zu gucken, da ich dann ja immer noch nicht weiß, wie viel Platz durch den Bootloader belegt ist) Weiß das jemand?
So, jetzt noch als kleine Anekdote:
Ich bin mir durchaus bewusst, dass ich hier das maximum simuliert habe. Denn ich habe keine Abschirmung verwendet und die Sensoren haben von Vorne Licht bekommen. Sie wurden also ziemlich geblendet. Mit meiner schlechten Strohhalm-Abdeck Variante hab ich es noch nicht versucht, aber damit sollte es gleich ein wenig besser sein. Dass werde ich noch ausprobieren.
Also kann man eigentlich sagen, dass man bei direktem ungeschütztem Frontlich einen sehr hohen Quadteiler braucht und bei geschützen Sensoren (wie bei dir) und wohl kein direktes Front Licht (oder?) eher einen kleinen.
So, jetzt probier ich noch die Abschirmung aus.
Andun
Nachtrag: Wenn ich es mit der Abschirmung benutze, dann geht es schon fast gut im normalen Zustand. Gut läuft es bei K2 und perfekt läuft es dann auch bei K1. Ich weiß aber auch nicht so genau, wie viel Licht die nun eigentlich absorbieren. Ich hab nochmal 2 Photos angehängt wo man sieht wie es bei mir aussieht.
Jau, also das mit dem quadteiler stimmt, siehe die im Code angegebene Formel.
Aaaaber: Merkst du jetzt auch nen Unterschied? Fährt er deiner Meinung nach die Strecken besser ab als mit den "herkömmlichen" Reglern bzw. Linienfolgern? Schon, oder?
Mh . . . gute Frage. Also ich bin mir eigentlich nicht so sicher. Er wackelt ein bischen weniger, aber man hat dafür ein bisschen mehr Code.
Also ich werde es wahrscheinlich schon das ein oder andere mal verwenden. Wenns halt auf Codegröße ankommt, dann mach ihc es halt weg. :D
Ihc muss aber eigentlich auch noch ein paar Versuche unter normale Bedingungen machen. Also kein frontales Licht.
So long
Andun
Jupp, stimmt. Über 50 Pages ist schon bös, hätt ich auch nicht erwartet. Vielleicht kann man an der einen oder anderen Ecke noch was sparen, mal gucken.
Das Verhalten bei kubischer Abhängigkeit hab ich mal ausprobiert. Besteht eigentlich kein gravierender Unterschied. Nur das der Asuro (erwartungsgemäß) eher mal zum Ausbrechen neigt (nach der 5. bis 10. Kreisbahn). Ist halt dann doch fast schon kein kontinuierlicher Regler mehr, sondern geht fast schon wieder in die "Schalter"-Richtung.
Also vielleicht bis hier erstmal der vorerst endgültige Code, denk ich. Außer es hat noch wer watt vorzuschlagen! :D
Dann dickes DANKE soweit, Andun! Wirklich schönes Review von dir! :)
So, hier mal die vorerst finale Version des Linienfolgers (der jetzt meiner Meinung nach sehr schön funktioniert!). Das hier hat sich noch geändert:
- Die BackLEDs leuchten alle 100 Prozesszyklen kurz auf und zeigen so die Zyklengeschwindigkeit an. Der hat nämlich echt Probleme gemacht und das "Wackeln" auf Geraden verursacht. Nachdem der Code deutlich abgespeckt wurde (z.B. werden die Taster jetzt auch nur noch alle 100 Zyklen abgefragt) läuft der Asuro deutlich besser und stabiler seine Bahnen ab!
- Kubische Abhängigkeit und verschiedene Fuzzyregler ausprobiert. Hat alles nix gebracht, quadratisch scheint hier echt die beste Lösung (BISHER) zu sein. Beim kubischen kann man auch gleich einen "Schalter" einbauen und für eine *gescheite* Fuzzyregelung ist der Prozessor nicht ausreichend schnell - und damit kommts wieder zum Wackeln.
- Die Formel wurde über den Jordan geschickt und ersetzt. Die einzige Benutzerangabe ist jetzt noch der maximale Helligkeitsunterschied. Funzt viel besser und ist leichter verständlich. Der Rest wird intern erledigt.
Ich hab das Proggi auch mal auf einer nachgebauten Bahn von der letzten Roboliga laufen lassen und da hat er nach ein zwei Probeläufen (mit verschiedenen Tastern) mit Bravur bestanden.
Ziehts euch rein (oder auch nicht) und gebt mir eure Meinung. Ich denk mal, *jetzt* ist das Thema wirklich abgehandelt!
/* Quadratisch abhängiger Linienfolger vorerst finale Version
vmax = maximal negative und maximal positive Motorgeschwindigkeit;
imaxinit sollte etwa dem maximalen Helligkeitsunterschied der Liniendioden entsprechen
(z.B. Wert hell = 130, Wert dunkel = 30 -> imaxinit = 100)
Im Programmablauf kann dieser Wert (der das korrekte Folgen der Strecke am meisten
beeinflusst) noch über die Kollisionstaster angepasst werden:
Sw0 -> imaxinit -20 (mehr enge Kurven)
sw1 -> imaxinit -10
Sw2 -> imaxinit (Standard)
Sw3 -> imaxinit +10
Sw4 -> imaxinit +20
Sw5 -> imaxinit +40 (langgezogene Kurven, viele Geraden)
Die Schalter werden ausgelesen, wenn die BackLEDs aufleuchten!
Die StatusLED zeigt an, ob sich die Linie links oder rechts der Mittelstellung befindet.
Die BackLEDs leuchten alle 100 Zyklen kurz auf und zeigen so die Prozessorlast an.
pay.c 12.08.2005
*/
#include "asuro.h"
#include <stdlib.h>
#define vmax 120
#define imaxinit 100
long i;
char flag = 0, sw, sR, sL;
int lineData[2], imax = imaxinit, speedLeft, speedRight;
void Line (void)
{
speedRight = ((((-i*abs(i))/50)+100) * vmax)/100;
speedLeft = ((((i*abs(i))/50)+100) * vmax)/100;
if (speedLeft > vmax) speedLeft=vmax;
if (speedRight > vmax) speedRight=vmax;
if (speedRight < 0) {MotorDir (FWD,RWD); sR=-speedRight;sL=speedLeft;}
else if (speedLeft < 0) {MotorDir (RWD,FWD); sL=-speedLeft;sR=speedRight;}
else {MotorDir(FWD,FWD);sL=speedLeft;sR=speedRight;}
MotorSpeed(sL,sR);
}
int main(void)
{
Init();
FrontLED(ON);
for (i = 0; i < 0xFF; i++) LineData(lineData);
for(;;) {
if (flag>=99) {flag=0; BackLED(ON,ON);
sw = PollSwitch();
sw = (sw+PollSwitch())/2;
sw = (sw+PollSwitch())/2; //sicheres Auslesen der Schalter!!
if (sw > 0)
imax=imaxinit-20;
if (sw > 1)
imax=imaxinit-10;
if (sw > 2)
imax=imaxinit;
if (sw > 4)
imax=imaxinit+10;
if (sw > 8)
imax=imaxinit+20;
if (sw > 16)
imax=imaxinit+40;
}
else {flag++;BackLED(OFF,OFF);}
LineData(lineData);
i = ((lineData[0] - lineData[1])*100)/imax;
if (i>100) i=100;
if (i<-100) i=-100;
if (i > 0) StatusLED(GREEN);
else StatusLED(RED);
Line();
//if (lineData[0] < 40 && lineData[1] < 40) {Encoder_Init();Go(50,150);Turn(180);}
}
}
Ja. Sieht doch gut aus. Jetzt ist es wirklich ziemlich gut abgehandelt. :D
Ich werde es mir heute nachmittag mal auch aufspielen.
Andun
Hallo payce,
ich hab mal dein Programm getestet. Mein Asuro fährt sehr ruhig mit den Grundeinstellungen. Wenn ich aber die Geschwindigkeit erhöhe, dann habe ich auch das Schütteln. Es ist auch stark vom Umgebungslicht abhängig. Ich werde es nochmal mit meiner Software zur Unterdrückung des Umgebungslichts ausprobieren.
Aber grundsätzlich ist eine Schwingneigung nicht durch eine quadratische Funktion zu beseitigen. Das ist so wie mit einer linearen und einer progressiven Feder. Beide Federn schwingen, nur ist vielleicht die Frequenz verschieden. Um eine Schwingneigung zu unterdrücken braucht es eine stabile Regelschleife mit ausreichender Dämpfung. Das bedeutet auch, die Verstärkung im Regelkreis sollte möglichst konstant bleiben. Da ist meiner Ansicht nach eine nichtlineare Funktion sogar schädlich, ausser sie kompensiert eine andere nichtlineare Kennlinie.
Probier es mal mit einem PD-Regler. Nach einer Simulation von mir sollte das eigentlich am günstigsten sein.
Gruss Waste
Nachtrag:
Mit meiner Kompensationsroutine läuft es jetzt besser, aber enge Kurven fährt der Asuro eckig, fast als wollte er wieder mit dem Schütteln anfangen.
Hmm, jupp, geb ich dir recht. Allerdings habe ich eine quadratische Kennlinie genommen, da die Motoren ja auch nicht gerade in die lineare Generation gehören. ;)
Und der weitere Sinn ist, das leichte Abweichungen auch nur leicht abgefedert werden sollen, stärkere hingegen sinngemäß auch stark. Das Problem mit dem Umgebungslicht hab ich türlich weniger, wegen dem hier: https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11178&sid=d87ffe9b3f0144dbe85bbb8386cc6d7d) (die beiden Bilder von mir).
Von PD oder ähnlichen Reglern (PI oder watt auch immer) lass ich aus zwei guten Gründen bisher die Finger: Erstens immo noch zu kompliziert für mich und zweitens gibt es Berichte von verschiedensten Seiten, daß sich Mikrocontroller und klassische Regelsysteme oft nicht vertragen. Das liegt meistens daran, daß klassische Regelkreise keine Totzeit haben (analoge Schaltungen). Im Mikrocontroller kommst du natürlich ohne nicht aus. Will man verschiedenen Berichten glauben, sind Fuzzy-Regler da immer noch die bessere Alternative.
High-End ist dann natürlich (auch von verschiedensten Berichten untermauert) eine Hybrid-Regelung aus Fuzzy- und Analogregler (bspw. PD, PI, PT). Die Dinger sollen sehr gut funzen, vorrausgesetzt, die Prozessorleistung ist vorhanden (einen ATMEGA8 zwingst du damit türlich in die Knie).
Aber danke für die Gedanken! Vielleicht trau ich mich ja irgendwann tatsächlich an einen Linienfolger mit PD-Regler! :)
Hallo payce!
Scheinbar kennst du dich ein bisschen mit der Materie aus. Wie wär es, wenn wir es gemeinsam mit einem PD-Regler versuchen, oder auch einem anderen Regler, falls sich im Laufe der Entwicklung was anderes als besser herausstellt. Möglicherweise wird es sogar in einem Fuzzy-Regler enden. Ich hab zwar schon komplizierte Regelschleifen in der Elektronik realisiert, aber in der Robotik blieb es bisher immer bei einem normalen P-Regler. Deshalb würde mich die Sache schon reizen.
Die Totzeit ist in diesem Fall kein Problem, die ist beherrschbar, das habe ich mir schon angeschaut. Anders ist es bei der Odometrie, da ist die Totzeit wirklich ein Problem.
Also wie wär's, packen wir's an?
Gruss Waste
Puh, also ganz ehrlich, da trau ich mich *noch* nicht ran. Mit analoger Regelungstechnik hab ich schon so meine Erfahrungen, aber: 1. Der Asuro ist mein erster Bot und 2. das ist das erste Mal, daß ich in C programmiere (wollte ich mir schon seit Längeren mal aneignen). Ich hab mich bisher halt eher theoretisch damit beschäftigt um möglichst Sackgassen zu vermeiden (und damit derbe Motivationsdämpfer).
Sobald ich ein wenig mehr Erfahrung hab, gerne, dürfte echt interessant sein! Aber immo hab ich die Befürchtung, daß ich da nicht wirklich durchsteige...
Aber danke für die Nachfrage! *geehrt fühl* :D Komm ich auf jeden Fall drauf zurück, wenns soweit ist!
Apropos, hier mal zwei gute Quellen:
Einführung zur Fuzzy-Regelung:
http://esr.e-technik.uni-dortmund.de/Downloads/FuzzyControl/Folien/FuzzyRegler.pdf
und eine Einführung in die Regelungstechnik mit einem kleinem Ausflug in die digitale Regtechnik:
http://www.meilhaus.com/regeltechnik/bilder/rt.pdf
oder:
http://www.meilhaus.com/regeltechnik/
Hallo payce,
ich habe den Eindruck, dass du ein gutes Grundwissen in der Sache hast und bin deshalb auf die Idee gekommen. Das muss jetzt nicht direkt eine Mitarbeit im Sinne von Aufgabenteilung sein, sondern mehr als Beobachter, Kritiker, Fragensteller und Verbesserer.
Ich habe bisher noch in keinem Roboterboard eine Beschreibung gefunden, wie eine solche Regelung von Grund auf berechnet und realisiert wird. Bin aber sicher, dass dies sehr viele gerne wissen würden. Nachdem ich mich jetzt schon ein wenig damit befasst habe, will ich es jetzt auch selbst wissen, ob es geht und wie gut es geht. Möglicherweise geht es aber gar nicht und ich werde scheitern. Das macht auch nichts, dann bin ich eben um eine Erfahrung reicher geworden. Eine erste Simulation zeigt allerdings Vielversprechendes, was mich natürlich zusätzlich motiviert.
Ich werde dazu einen neuen Thread eröffnen. Wenn es soweit ist, werde ich hier nochmal darauf hinweisen.
Gruss Waste
Ahsoooooo! Dodal missverstanden! Ja also das ist ja wohl sowas von selbstverständlich! :D
Jo, klar, wär ich jetzt nie darauf gekommen, daß du das so meinst, sowas halt ich jetzt echt für selbstverständlich. Wenn mich ein Thema interessiert (und das tut der Linienfolger ja offensichtlich) bin ich grundsätzlich bei einer Diskussion nicht weit weg! ;)
Fazit: Logen, daboi!
Also der 1.Teil steht.
siehe https://www.roboternetz.de/phpBB2/viewtopic.php?p=106560#106560
Es wird etwas umfangreich, muss es auf mehrere Beiträge aufteilen.
Gruss Waste
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.