[Asuro] Problem bei Tasterabfrage mittels PollSwitch

[jenser212]

Tja, vielleicht waren auch nur die Batterien etwas schwach.

Gut möglich. Ich habe nicht gerade die besten gekauft.

Ich würde ihn erst Hinter dem Schalter anlöten, denn ich meine zu galuben, dass immer ein geringer Strom fließt. Das wäre ja Mist, wenn sich das Ding über Nacht entlädt.

Oh, das wäre wirklich schlecht. Ok, da muss ich mir wohl einen anderen Platz raussuchen. Wäre ja auch zu einfach gewesen...

Herzlichen Dank für die Hilfe!

Grüße Jens

[Peda]

Hallo,

ich hatte bei meinem Asuro genau dasselbe Problem(hab das gleiche Programm geschrieben), das er sich immer gedreht hat obwohl nirgendwo angestoßen ist. Ich habs dann Softwaretechnisch gelöst indem ich die PollSwitch-Funktion zweimal aufrufe und dann jeweils vergleiche ob das Ergebnis identisch ist somit werden solche Spannungsschwankungen oder ähnliches rausgefiltert.

Ich hab allerdings bei anderen Versuchen noch andere Probleme die auch den oben genannten ähnlich sind. Bei der Auswertung der Odometrie-Daten differenzieren die Werte anscheinend sehr stark je nachdem wie hell die umgebung beleuchtet ist oder wie weit das Zahnrädchen vom Transistor entfernt ist. Somit ist ein errechnen der momentanen Geschwindigkeit schwierig und eigentlich recht unbrauchbar. Hat da vielleicht jemand eine Idee wie man das in den Griff bekommt?

[jenser212]

Hi Peda,

bei der Odometrie habe ich folgendes gemacht:

Zuerst wird Min und Max des linken und rechten Sensors ermittelt (in dem ich den Asuro einfach für ein paar Umdrehungen fahren lasse und die Odometrie auswerte).
Anhand dieser Werte kannst ich dann prüfen, ob der Sensor nun hell oder dunkel ist. Anbei ein kleines Beispiel-Programm.

Viele Grüße
Jens

#include "asuro.h"
#define DUNKEL 0
#define HELL 1

unsigned int lowLeft = 512;
unsigned int highLeft = 512;
unsigned int lowRight = 512;
unsigned int highRight = 512;

unsigned char getLeftStatus(unsigned int data) {
	unsigned int diffLow = data - lowLeft;
	unsigned int diffHigh = highLeft - data;

	if (diffLow < diffHigh) {
		return OFF;
	} else {
		return ON;
	}
}

unsigned char getRightStatus(unsigned int data) {
	unsigned int diffLow = data - lowRight;
	unsigned int diffHigh = highRight - data;

	if (diffLow < diffHigh) {
		return OFF;
	} else {
		return ON;
	}
}

int main(void) {
	Init();

	unsigned int speed = 100;
	MotorSpeed(speed, speed);

	unsigned int data[2];

	unsigned int i;
	for (i = 0; i < 1000; i++) {
		OdometrieData(data);

		//LEFT
		if (data[0] < lowLeft) {
			lowLeft = data[0];
		} else if (data[0] > highLeft) {
			highLeft = data[0];
		}

		//RIGHT
		if (data[1] < lowRight) {
			lowRight = data[1];
		} else if (data[1] > highRight) {
			highRight = data[1];
		}

	}

	while (TRUE) {
		OdometrieData(data);
		BackLED(getLeftStatus(data[0]), getRightStatus(data[1]));
	}

	return 0;
}

[Peda]

Hi Jens,

danke für deinen Lösungsvorschlag, probier ich gleich mal aus. Das könnte gut funktionieren.
Ich hab da allerdings im moment noch ein anderes problem. wenn ich mit dem flash-Tool etwas auf den Prozessor draufspielen will dann. bekomme ich fast nie eine verbindung mit Asuro. das erste mal klappt es meistens doch dann geht meistens denn ganzen abend nix mehr. Was ist da los, sind die batterien leer, ist das licht schlecht?? der transceiver-test funktioniert einwandfrei und wenn programme laufen dann sendet der asuro auch fehlerfrei an den Transceiver.

mfg
Peda

[Grave80]

Hi, Peda,
das gleiche Problem hatte ich zum anfagn auch mit der Übertragung, bei mir lag es einfahc nur an den batterien die waren zu schwach, jetzt klappt alles prima.

JETZT AN DIE ANDEREN!!!

habe da nen problem mit den Pollswitch also der taster 1 wird nur durch die Dezimalzahl 33 anstatt 32 angesprochen und der taster 6 löst teilweise fehler aus, habe den dann ausm programm komplett entfernt , jetzt geht alles und komischerweise bewirkt der taster auch das was er ursprünglich sollte obwohl er auskommentiert ist, wie kann das sein???

bei dem taster6 steht in der fehlerbehebung das es durch bauteiltoleranzen dazu kommen kann das der uC den falsch erkennt und das das später softwaremässig behoben werdne kann, doch wie steht leider nicht in der beschreibung, weiss da jemand von euch was???

[Weja]

Hallo Grave80,
Im Handbuch steht genau:
"In seltenen Fällen kann es vorkommen, dass durch Bauteiletoleranzen ein falsches Muster erkannt wird. Das kann aber später softwareseitig behoben werden.”
Das betrifft bei Dir Taste 1 mit dem Wert 33. Die Softwarekorrektur kann dann so aussehen.:
x=PollSwitch(); if (x>31) x--;
Was passiert denn bei Taster 6 ? Welche Fehler ?
Ich hab mir vorgenommen eine verbesserte Asuro Bibliothek zu schreiben, dasollten PollSwitch Probleme mit behoben werden.
Siehe Thema: erweiterte ASURO Bibliothek
Gruß Weja

[Grave80]

hoi weja

also bei taster 6 is das seltsam also wenn ich ne for schleife schreibe das der bei pollswitch==1 irgendwas macht oder halt was anderes dann macht der imme rdas was im else bereich steht und das ganz komische ist wenn ich die For schleife dann auskommentiere funktioniert alles prima und der Taster1 macht auch genau das was er machen soll
ich pack mal meenen quellcode mit rein wenn es klappt

Sone verbesserte Bibliothek wäre nicht schlecht aber ich will mich jetzt in embedded C programmierung versuchen , aber wenn de sone bibliothek fertig hast würde mich die mal interessieren

mfg Grave80

[Arexx-Henk]

Hallo Grave80,

in die pollswitch function im datei asuro.c bevindet sich ein verzogerung Sleep(10) vielleicht hilfts wenn du diesen wert etwas grosser macht.

in pollwitch function wird zuerst die microcontroller pin PD3 hoch gemacht (SWITCH_ON), dan einige zeit gewartet (Sleep(10)), und dann wird die gedruckten Tasten spannungswert ausgelesen. Die Sleep(10) ist notwendig weil ein Kondensator an dieser Stelle angeschlossen ist und dann daurts etwas bis bei einem tastendruck die Spannung sich ausgewertet hat.

gruss

Henk

[KlausR]

Ich bin am Überlegen, ob es überhaupt clever war, immer wieder run aufzurufen.
Bei einer Rekursion muss sich das Programm ja irgendwie seinen Rückweg merken.

Naja, wie du selbst schon festgestellt hast, lag es nicht am rekuriv aufgerufenen run(). Allerdings ist das rekursiv Aufrufen ne schlechte Idee, denn in der Tat will der kleine Atmega8 bei jedem Aufruf die Rücksprungadresse sichern. Nur hat er nur 512 Bytes Ram, und jeder Aufruf benötigt zwei Bytes. Dem AVR geht also ruck zuck der Speicher aus. Allerdings gibt es zunächst keine Fehlermeldung, der AVR wird nur munter Speicherinhalte, u.U. den Inhalt von Variablen, überschreiben.

-Klaus

[Christian 25]

Hallo, also ich habe auch das selbe Problem wie Jenser (auch bei einem ganz einfachen Programm) und dieses Problem läßt sich auch durch eine sleep Funktion lösen. (siehe auch https://www.roboternetz.de/phpBB2/vi...?p=85276#85276). Mich würde mal interessieren wieso dieses Anhalten des Prozessors die Lösung bringt??? Wäre es davor würde ich es ja noch verstehen da man sagen könnte der wartet erstmal bis die Spannung wieder konstant ist und schaut dann. Aber danach???

MFG
Christian