-
        

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 30

Thema: Problem mit der Odometrie Hardwarefehler? [gelöst]

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    12.09.2007
    Alter
    23
    Beiträge
    98

    Problem mit der Odometrie Hardwarefehler? [gelöst]

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Hallo Leute ich hab ein Problem mit der Odometrie. Wenn ich follgendes Programm flash, aus Mehr Spaß mit ASURO Band II etwas modofieziert:

    Code:
    #include "asuro.h"
    
    /*Schwellwert für die Hell-/Dunkel-Unterscheidung. Eventuell muss damit etwas variiert werden.*/
    #define TRIGGERLEVEL 600
    #define HYSTERSIS 10
    #define LOW 0
    #define HIGH 1
    #define SPEED 255
    
    int main(void) 
    { 
    	unsigned int data[2];
    	signed int status[2] = {0, 0};
    	signed int difference = 0;
    	Init();
    	MotorDir(FWD, FWD);
    	MotorSpeed(SPEED, SPEED);
    	while(1) 
    	{
    	                OdometrieData(data); 										
    		if ((status[0]==LOW) && (data[0]>TRIGGERLEVEL+HYSTERSIS))		/*Wenn linker Sensor von niedrig auf hoch wechselt*/
    		{
    			status[0]=HIGH;
    			difference++;
    		}
    		if ((status[0]==HIGH) && (data[0]<TRIGGERLEVEL-HYSTERSIS))	/*Wenn linker Sensor von hoch auf niedrig wechselt*/
    		{
    			status[0]=LOW;
    			difference++;
    		}
    		if ((status[1]==LOW) && (data[1]>TRIGGERLEVEL+HYSTERSIS))		/*Wenn rechter Sensor von niedrig auf hoch wechselt*/
    		{
    			status[1]=HIGH;
    			difference--;
    		}
    		if ((status[1]==HIGH) && (data[1]<TRIGGERLEVEL-HYSTERSIS))	/*Wenn rechter Sensor von hoch auf neidrig wechselt*/
    		{
    			status[1]=LOW;
    			difference--;
    		}
    		PrintInt (difference);
    		if (difference<-SPEED)											/*Sicherheitsabfragen*/
    		{
    			difference=-SPEED;
    		}						
    		if (difference>SPEED)
    		{
    			difference=SPEED;
    		}						
    		if (difference>0)
    		{
    			MotorSpeed(SPEED-difference, SPEED);							/*Motoren einstellen*/
    		}		
    		else if (difference<0)
    		{
    			MotorSpeed(SPEED, SPEED+difference);
    		}
    		if (SPEED-difference<=100)
    		{
    			difference=0;
    		}
     	}
    }
    Wenn ich dann die Daten abfrage kommt folgendes:

    Code:
    00000011111.....206206206206.......
    und wenn 206 kommt bleibt das rechte Rad stehen. Könnte es ein Hardwaredefekt sein oder ist im Programm ein Fehler?

    Vielen Dank im vorraus.

  2. #2
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Jena
    Alter
    31
    Beiträge
    3.912
    du musst die triggerlevel werte anpassen. variiere sie etwas, dann sollte es gehen.
    kleinschreibung ist cool!

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    03.07.2007
    Beiträge
    349
    Lass dir zuerst mal deine Werte für die Odometrie ausgeben.
    Im Anhang als Beispiel meine Werte.

    Du brauchst dir nur in Excel von beiden Odometriereihen den Mittelwert bilden lassen und fertig.

    Die Hysterese kannst du dir sparen da es sich ja eh nur um ungefähre Mittelwerte handelt. Außerdem sind die Amplituden der Sinuswellen so groß dass die +-10 der Hysterese nicht ins Gewicht fällt.

    Hier ein Beispiel wie du den links und rechts zurückgelegten Weg bekommst. Die von dir gewünschte Differenz ist halt dann einfach counter_l-counter_r
    Übrigens entspricht 1 Tick 3mm Fahrstrecke bei der 8er Odometriescheibe.
    Code:
            
    //alle folgenden Variablen sind vom typ int
    
            OdometrieData(odata);
    
            if(odata[0]<ODOMETRIE_L && flag_l==0)
            {
                counter_l++;
                flag_l=1;
            }
            else if(odata[0]>ODOMETRIE_L && flag_l==1)
            {
                counter_l++;
                flag_l=0;
            }
    
    
            if(odata[1]<ODOMETRIE_R && flag_r==0)
            {
                counter_r++;
                flag_r=1;
            }
            else if(odata[1]>ODOMETRIE_R && flag_r==1)
            {
                counter_r++;
                flag_r=0;
            }
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken odo.gif  
    Grüße,
    Harri

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo liggi,
    auch dir erst mal ein willkommen im Forum.

    Folgendes hilft zwar nicht für dein Problem, aber du solltes Bedenken:
    Wenn du in der main()-Schleife die PrintInt()-Funktion benutzt, verlierst du auf alle Fälle einige Wechsel an der Odometrie.
    Zum übertragen eines einzelnen Zeichens benötigst du ca. 5ms. Um den INT-Wert zu senden scheinst du 3 Zeichen zu benötigen. Das sind dann 15ms.
    Wenn du an der Odometrie die Scheiben mit den den 8 Farbwechseln hast (harry3 spricht dann sinnvollerweise von den 8er-Scheiben), hast du bei ca. 50cm/Sekunde (Volldampf mit 255) nur ca. 6ms Zeit zwischen den einzelnen Farbwechseln.
    Gerechnet: 1 / (50cm/Sekunde / 12cm/Radumdrehung * 5(Getriebestufe1) * 8(Farbwechsel))
    Bei den 16-er-Scheiben sieht es dann natürlich noch schlechter aus, da hier die Zeit auf ca. 3ms zwischen den Farbwechseln schumpft.

    Du bekommst hier also nur ungefähr jeden 3(6)-ten Farbwechsel mit. Wenn nun das senden und die Geschwindigkeit eventuell 'synchron' laufen, dann wird du sogar gar keine Wechsel 'sehen'. (Das ist aber sehr unwahrscheinlich).
    Lieber Asuro programieren als arbeiten gehen.

  5. #5
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Jena
    Alter
    31
    Beiträge
    3.912
    das ist wahr. besser sammeln, und dann nach der messung kurz stehen bleiben und ein array senden.
    kleinschreibung ist cool!

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    03.07.2007
    Beiträge
    349
    Ich hab mir ein int Array mit (soweit ich mich erinnern kann) 200 Elementen gemacht und dann alle 0,5ms gemessen.

    Zuerst auf Vollgas beschleunigen, dann kurz warten, dann das Array mit Werten füllen, und letztendlich Motor stoppen und mittels IR Übertragung das Array übermitteln.

    Man sieht in der Regel anhand der Sinuskurven eh sehr schön ob man oft genug gemessen hat. Nur wenn die Sinuswelle schön "rund" ist und keine Ecken hat passt die Abtastrate.
    Grüße,
    Harri

  7. #7
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Jena
    Alter
    31
    Beiträge
    3.912
    alternativ könnte man auch 512 bytes im eeprom speichern. schreibzeit sind etwa 8-10 milliesekunden, was aber dafür immer noch schnell genug ist. leider müsste man dann den wert durch 4 teilen, um ihn in byteform zu bringen, was etwas auf kosten der genauigkeit geht. alternativ würde man den wert um 2 bits nach rechts shiften, das spart rechenzeit. dafür könnte man 512 werte fest speichern, und dann auch später abrufen.
    kleinschreibung ist cool!

  8. #8
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    03.07.2007
    Beiträge
    349
    alternativ könnte man auch 512 bytes im eeprom speichern. schreibzeit sind etwa 8-10 milliesekunden, was aber dafür immer noch schnell genug ist.
    8-10ms sind meiner Meinung nach etwas zu langsam um bei Vollgas schön aufgelöste Kurven zu sehen.

    Der 10bit Messwert steckt in einem int von 2 byte Größe, also 16bit.
    Man könnte den int also in 2 einzelne bytes zerlegen. Und diese kann man ja dann in eeprom schreiben.

    Beim Senden an den PC kann man die jeweils zusammengehörenden bytes wieder zu int's zusammenbauen.
    Grüße,
    Harri

  9. #9
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Jena
    Alter
    31
    Beiträge
    3.912
    das ist wahr, jedoch kann man dann nur noch die hälfte speichern.

    ich würde es mal probieren, ohne zeitverzögerung, also schreiben-messen-schreiben-messen usw, das wäre dann ja die bestmögliche frequenz. durch 4 teilen, bzw. nach rechts shiften geht schneller als 2x in den eeprom zu schreiben, deshalb würde ich die bits opfern, zumindest für die ersten tests.
    mein asuro ist allerdings grad baustelle.
    kleinschreibung ist cool!

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Zitat Zitat von harry3
    8-10ms sind meiner Meinung nach etwas zu langsam um bei Vollgas schön aufgelöste Kurven zu sehen.
    Wenn ich nicht total vergesslich wäre, könnte ich glauben, dass ich schon vorgerechnet hatte, das dies nicht nur etwas zu langsam ist, sondern mit Sicherheit ist das zu lahm.
    Lieber Asuro programieren als arbeiten gehen.

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

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