PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ASURO - Problem mit den Tastern



DarkFire
06.01.2006, 19:54
Hallo, ich habe ein Problem mit meinen Tastern beim ASURO bzw. mit der PollSwitch Funktion.
Diese liefert mir für die ersten 3 Taster 1, 2 und 4 zurück, woran ich ja auch nichts auszusetzen habe, aber für die Taster K4 - K6 liefert sie mir 7, 15 und 31 statt 8, 16 und 32.
Was kann ich da machen, ich bräuchte nämlich doch eher 8, 16 und 32 zwecks besserer Implementierbarkeit, bzw. ist es eher ein Software oder Hardwarefehler?
Ich habe es bereits mit der Standardlibrary für den ASURO, aber auch mit der erweiterten aus dem Forum probiert.

Chris

MSSputnik
06.01.2006, 21:37
Hallo,

das ist ganz einfach. (ist hier im Forum auch schon mehrere Male erklärt worden)

Schau dir die Funktion PollSwitch mal genau an. Da wird der Wert der Taster berechnet.

return ((unsigned char) ((( 1024.0/(float)i - 1.0)) * 63.0 + 0.5));

Ersetze die 63.0 mal durch 62.0 bzw. mußt du diesen wert an deinen Asuro anpassen bis alle Schalterkombinationen korrekt funktionieren.

Martin

IRQ
08.01.2006, 21:09
Und ich hab mich schon gefragt, warum die Taster auf der linken Seite bei meinen Programmen nicht funktionieren 8-[

Wie gibst du denn die Werte zurück? Wenn ich


char zahl;
zahl = PollSwitch();
SerWrite(zahl, 1);

schreibe, dann macht jeder Taster zwar seine eigene Zeichenfolge im Terminal, aber das sind nur wirre Zeichen, die keinen Sinn für mich geben.

Den Trick von MSSputnik werd ich mal probieren, aber erst mal muss ich wissen, was die Taster im Moment überhaupt liefern.

*Edit: Hab noch ein wenig im Forum gestöbert und bin auf Folgendes gestoßen:

https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=131852#131852

Das sollte wohl erklären, wie man's macht. Aber was macht sprintf() eigentlich genau?

DarkFire
08.01.2006, 21:39
Hallo!

Ich habe mein Tasterproblem jetzt gelöst.
Ich habe den Wert einfach auf 64 gestellt und jetzt funktioniert es einwandfrei. Das mit der Ausgabe der Tasterwerte habe ich wie folgt gelöst:


char buffer[3];
int Schalterstatus;

while(1) {

Schalterstatus = PollSwitch();
itoa (Schalterstatus, buffer, 10);
SerWrite(buffer, 3);
_delay_ms(50);
}

IRQ
09.01.2006, 17:22
Kann mir jemand erklären, warum das bei jedem Asuro anders ist? Ich habe meinen jetzt auf 61.5 eingestellt und damit funktioniert es in allen erdenklichen Tastenkombinationen perfekt.

MSSputnik
09.01.2006, 21:51
Hallo,

das liegt an den tollernanzen der verwendeten Wiederstände.

Im Prinzip ist die Schaltererkennung ja als Spannungsteiler aufgebaut. Je nachdem welche Schalter du drückst, werden andere Wiederstände parallel geschaltet. Durch die geschickte Wahl der Wiederstände, ergben sich dann die Wertigkeiten der Schalter.
Aber leider spielt dabei die Natur nicht so richtig mit. Jeder Wiederstand ist ein bisschen anders.
Und so muß auch jeder Asuro an seine Wiederstände angepasst werden.

Martin

sealord
09.01.2006, 23:22
Weil's gerade passt (Problem mit Tastern), möchte ich dazu auch noch einen Beitrag liefern: Auch wenn die Pollswitches die richtigen Werte liefern, geht leider gar nichts mehr, sobald die Motoren laufen. Und genau dann werden die Taster ja gebraucht. Aber aufgrund des Spannungsabfalls und der unsauberen Spannung durch die Motoren erhält der ATMega falsche Werte. Jemand (Name nicht mehr bekannt) hat hier im Forum sehr schöne Oszilloskopbilder des Spannungsverlaufs vom Asuro bei laufenden Motoren gepostet und auch den Spannungsabfall angesprochen. Andere haben sich Gedanken gemacht über eine stabilere Energieversorgung mit AA-Akku's. (Aber auch da gibt es einen Spannungsabfall und die Motoren liefern immer noch dieselben Störimpulse.) Aber eine echte Lösung habe ich noch nicht gesehen.

Ich habe alle möglichen Varianten bei der Software ausprobiert (zuerst die Motoren laufen lassen, erst dann mehrfach (!) Pollswitches abfragen), aber nichts hat bei laufenden Motoren geklappt. Ich könnte mir vorstellen, dass bei gesonderten Spannungen je eine für Elektronik und eine für die Motoren das Problem behebbar ist. Softwaremäßig sehe ich da aber keine Lösung. Oder??

Mike

m.a.r.v.i.n
10.01.2006, 09:42
Hallo Mike,
schließ mich deiner Meinung an. Eine Trennung der Stromversorgung wäre wohl die günstigste Lösung. Allerdings wird man wohl kaum noch einen Akkusatz auf den Asuro schnallen, wegen Gewicht und so.

Möglich wäre vielleicht ein 9V Block mit LowDrop Regler für die Steuerung und den Batteriepack für die Motorbrücken lassen.

Muß mir mal das Layout der Leiterplatte ansehen, wo man am besten die Stromversorgung auftrennen kann. Oder man legt die Motorbrücken tot und packt einen L293D auf eine separate Platine.

Gruß Peter

sealord
10.01.2006, 21:09
Hallo Peter,

oder man verzichtet ganz auf die 6 Taster. Sie sind m.E. sowieso zu kurz. Der Asuro muss immer erst gegen ein Objekt knalllen, um dann zu reagieren. Man sollte die Taster durch einen Sharp-IR-Sensor ersetzen. Dann kann man Abstände bis zu 80 cm erkennen und so Kollisionen vermeiden. Der Sharp käme mit demselben Eingang wie die Taster aus. Dürfte also nicht kompliziert sein.

Gruß
Mike

m.a.r.v.i.n
10.01.2006, 21:33
Hallo Mike,
man könnte auch einfach die IR Schnittstelle zum Kollionssensor umbauen, wie hier (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11114) beschrieben und die Taster so lassen wie sie sind. So könnte man die Taster für Benutzereingaben weiterverwenden.

Gruß Peter

FrankyD80
12.04.2006, 15:02
Hi,

Ich hatte auch sonderbare Verschiebungen in den WErten, die aus der Funktion PollSwitch() zurückgegeben wurden, was mich veranlasste, sämtliche Kombinationen zu probieren und eine Funktion dem Muster entsprechend zu schreiben, die mir die Werte in Tasterzustände umrechnet. 8-[

Habe jetzt in der asuro.c die Funktion Pollswitch von

return ((unsigned char) ((( 1024.0/(float)i - 1.0)) * 63.0 + 0.5));

auf

return ((unsigned char) ((( 1024.0/(float)i - 1.0)) * 61.0 + 0.5));

abgeändert und es funktioniert nun, wie es sollte.

Jedoch ergibt sich noch immer das Problem mit der Pollswitchabfrage, wenn der Motro / die Motoren laufen. Es werden verzerrte Werte geliefert, die wohl auf Spannungseinbrüche zurückzuführen sind [-(