Problem mit der Odometrie Hardwarefehler? [gelöst]

[liggi]

Hallo Leute ich hab ein Problem mit der Odometrie. Wenn ich follgendes Programm flash, aus Mehr Spaß mit ASURO Band II etwas modofieziert:

#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:

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.

[damaltor]

du musst die triggerlevel werte anpassen. variiere sie etwas, dann sollte es gehen.

[harry3]

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.

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

[Sternthaler]

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).

[damaltor]

das ist wahr. besser sammeln, und dann nach der messung kurz stehen bleiben und ein array senden.

[harry3]

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.

[damaltor]

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.

[harry3]

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.

[damaltor]

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.

[Sternthaler]

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.