Der Jumper ist draussen aber an den Batterien kann es vll liegen es sind "nur" welche von so einer No-Name Firma gestern abend hatte kein Geschäft mehr auf um vernünftige Batterien/akkus zu holen.....
Druckbare Version
Der Jumper ist draussen aber an den Batterien kann es vll liegen es sind "nur" welche von so einer No-Name Firma gestern abend hatte kein Geschäft mehr auf um vernünftige Batterien/akkus zu holen.....
ja allerdings. wenn du ein multimeter mit "batterietest" funktion hast, kannst du checken wieviel strom die batterie unter last abgibt (einfach die voltzahl messen wäre ohne last). die billig batterien fallen schon nach wenigen minuten unter 0,8V.
ich nutze akkus (jumper gesetzt) und bin ganz zufrieden.
Guten Morgen in die Runde und ein gutes Roboterjahr,
ich besitze (noch) keinen Roboter, konnte jedoch am Sylvesterabend das frustrierende Verhalten des Asuro von papa_moll beobachten. Er fährt im leichten Kreisbogen vorwärts, nach ca. 60 cm Weg im Bogen ca. 60 cm rückwärts und in stetiger Folge hin und her, wobei die Krümmung der Bögen wechselt. Lt. Programm sollte er geradeaus fahren.
1. Im Forum wird im Zusammenhang mit Geradeausfahrt überwiegend über die Ansteuerung der Motoren diskutiert. Vom Motor zum Rad ist ein weiter Weg mit vielfältigen Toleranzen und Fehlern. Wichtig ist aber doch das Weg/Zeit-Verhalten der Räder. Warum wird nicht das Weg/Zeit-Verhalten der Räder über das Encoder-Zahnrad geregelt. Man weiß, daß je Radumdrehung 40 hell/dunkel-Wechsel erfolgen und je hell/dunkel-Wechsel ein Weg von 3,025 mm zurückgelegt wird. Wenn nun der gewollte Weg, z.B. beim Haus des Nikolaus, über die erf. hell/dunkel-Wechsel über eine Schleife gesteuret werden, müßte das doch funktionieren und die Motoren könnten machen was sie wollen.
2. Die abrupten, gleichförmig getakteten Richtungswechsel lassen doch auf einen nicht zufälligen Fehler schließen. Mir fehlen jetzt die Voraussetzungen um diesen Fehler zu ergründen. Vielleicht ist einer der vielen Experten (Respekt) in der Lage hier eine Lösung zu finden.
Einige Anregungen in der Hoffnung, daß die Profis den Problemen auf die Spur kommen.
ponzelar
Hallo
Unsinn. Das ist eine tri-state-LED, sie hat also 3 Zustände(+OFF):Zitat:
Zitat von Asuro-n00b
Also ergibt ROT und GREEN zusammen YELLOWZitat:
Zitat von asuro.c
Gruß
Radbruch
Trotzdem kann rot und grün im schnelle wechsel gelb aussehen. so unsinnig ist das nicht, gerade wenn es um ein programm geht, welches die led nur rot ODER grün leuchten lassen sollte. an sich sind es nur zwei leds mit einem gemeinsamen pin und einem gemeinsamen gehäuse.Zitat:
Zitat von radbruch
du meinst eine möglichkeit, mithilfe der odometrie geradeaus zu fahren? ich glaube da gibt es tausende ansätze hier im forum, einige gehen, andere nicht, und einer ist sogar in der funktion "Go()" in die erweiterte lib gekommen...Zitat:
Zitat von ponzelar
und so einfach ist das alles leider nicht: die sensoren sind extrem ungenau, gelegentlich gehen ticks verloren oder durch störlich kommen welche hinzu. du kannst ja mit papa_moll mal das haus vom nikolaus probieren... oder fangt beim ersten wettbewerb an: der asuro soll zweimal ein rechteck abfahren, wobei die strecke IDENTISCH sein soll (also nicht zwei rechtecke, sondern 2x das GLEICHE). das ist schwer genug.
auch die tatsache, dass ein tick etwa 3 mm sind, ist nicht so einfach zu sagen: das kommt auf die aufgeklebte scheibe an (es gibt verscheidene mit verscheidenen felderzahlen), auf das spiel der motoren usw.
davon ganz abgesehen: wenn du mit der odometrie einfluss auf das weg-zeit-verhältnis (also auf gutdeutsch die geschwindigkeit) der zahnräder bzw der reifen einfluss nehmen willst, musst du zwangsläufig die motoren ansteuern... wie solltest du die räder sonst zum drehen bewegen?
Mir ist eben noch ein Einfall gekommen!Zitat:
Zitat von papa_moll
Wenn du statt mit der StatusLED die Richtung mit den BackLEDs anzeigst, weißt du, ob das gelbe Flackern der StatusLED von der IF-Abfrage herkam.
Bei mir leuchtet die StatusLED bei folgendem Programm während der gesamten Zeit grün:
Code:#include "asuro.h"
int main(void)
{
int i;
Init();
while(1)
{
if (PollSwitch()>0) // wenn einer der Taster betätigt
{ // dann...
BackLED(OFF,ON);
MotorDir(RWD,RWD);
MotorSpeed(100,150); //rückwärts wenden(mit großem Wendekreis)
for(i=0;i<1500;i++) // 3s
{Sleep(144);}
}
else //ansonsten...
{
MotorSpeed(0,0);
MotorDir(BREAK,BREAK); //Das englische wort für bremse heisst zwar brake... aber egal =)
Sleep(216); //3ms
MotorDir(FWD,FWD);
MotorSpeed(120,120); //geradeaus fahren
BackLED(ON,OFF);
}
for(i=0;i<10;i++) // 30ms warten, damit er nicht durcheinander kommt
Sleep(216);
}
return(0);
}
hmm... ist es nicht egal, ob nun "rot-grün-gelb" oder "links-rechts-beide" angezeigt wird?
die richtige batteriespannungsmessung geschieht nur im bootloader. aus irgend einem grund springt das programm in der abfrage, so dass die gelbe led (oder eben beide backleds) leuchtet/n.
morgen hab ich meinen asuro wieder, dann kann ich mal schaun was bei mir ist.
Habe mir gerade Akkus gekauft O:) jetzt müssen die nur wieder laden #-o .....
Melde mich dann ob es nun endlich klappt.
Ich denke nicht, dass das egal ist, weil du ja gesehen hast, dass es eine Diskussion gab, ob die StatusLED wegen dem Programm oder wegen eines Fehlers wie z.B. in der Versorgungsspannung, gelb geleuchtet hat.Zitat:
Zitat von damaltor
Wenn es nun wirklich an dem Programm liegen sollte (was ich mir wirklich nur schwer vorstellen kann, da ja noch die Sleepfunktion von 3 Sekunden drin ist, sobald die Lampe rot leuchtet),
dann findet man das doch heraus, wenn man es über die BackLEDs anzeigen lässt.
Dann müssten bei papa_moll die beiden BackLEDs gleichzeitig leuchten.
Bin gespannt, mit den neuen Akkus wird's bestimmt laufen. ;)
naja die spann ungsmessung ist es mal mit sicherheit nicht, da das programm ja schon läuft wenn der fehler auftritt. die messung der spannung findet jedoch nur im bootloader, vor dem programmablauf statt.