- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: Erstes Proggi: Quadratisch abhängiger Linienfolger

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54

    Erstes Proggi: Quadratisch abhängiger Linienfolger

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hi!

    Also, den Asuro hab ich jetzt seit ca. 4 Tagen. MANMANMAN macht das Teil Böcke! \/

    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:

    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/vi...5bbb8386cc6d7d)
    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.

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    04.04.2005
    Ort
    Hamburg
    Alter
    36
    Beiträge
    826
    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. (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.

    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
    www.subms.de
    Aktuell: Flaschcraft Funkboard - Informationssammlung

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54
    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:

    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 */
    
    //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);
    	} 
    }

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54
    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!

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    04.04.2005
    Ort
    Hamburg
    Alter
    36
    Beiträge
    826
    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. 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.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken gesamt_474.jpg   front.jpg  
    www.subms.de
    Aktuell: Flaschcraft Funkboard - Informationssammlung

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54
    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?

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    04.04.2005
    Ort
    Hamburg
    Alter
    36
    Beiträge
    826
    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.

    Ihc muss aber eigentlich auch noch ein paar Versuche unter normale Bedingungen machen. Also kein frontales Licht.

    So long

    Andun
    www.subms.de
    Aktuell: Flaschcraft Funkboard - Informationssammlung

  8. #8
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54
    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!

    Dann dickes DANKE soweit, Andun! Wirklich schönes Review von dir!

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    19.07.2005
    Ort
    Nürnberg
    Alter
    44
    Beiträge
    54
    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!

    Code:
    /* 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);}
    		
    	} 
    }

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    04.04.2005
    Ort
    Hamburg
    Alter
    36
    Beiträge
    826
    Ja. Sieht doch gut aus. Jetzt ist es wirklich ziemlich gut abgehandelt.

    Ich werde es mir heute nachmittag mal auch aufspielen.

    Andun
    www.subms.de
    Aktuell: Flaschcraft Funkboard - Informationssammlung

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test