Druckbare Version
Hallo
Vorlagen für Encoderscheiben gibt's u.a im Startbeitrag dieses Threads:
https://www.roboternetz.de/phpBB2/ze...ag.php?t=27081
Oder du färbst meine Scheiben schwarz/weis ein:
https://www.roboternetz.de/phpBB2/ze...ag.php?t=32143
Eigene Vorlagen kann man elegant als Tortendiagramm mit einem Office-Programm erstellen.
Gruß
mic
Moin,
ich hab so ein ähnliches Problem mit dem flashen.
Beim Übertragen des Programmes werden ständig checksum error
ausgegeben. Das Übertragen der Programme ist daher so gut
wie nicht möglich. Um es doch hinzubekommen muss ich den IR-Sender
immer in eine ganz bestimmte Position zum ASURO bringen.
(Extrem schwierig und meist ohne Erfolg :-s )
Das Flashprogramm sendet die Daten ja als einzelne "Pages".
Sollte es mal die ersten 3, 4 geschafft haben, dann läuft der flash ohne Probleme weiter. Da jedoch hinzukommen, ist wie gesagt fast nicht möglich.
Hatte schonmal jemand das Problem?
Kann mir jemand helfen?
Ich muss dazu sagen, dass ich den ASURO erst gestern zusammengebaut habe :-)
und nocht nicht viel Erfahren(oder so gut wie gar keine) in Sachen Robotik habe.
Danke aber schonmal für Antworten!!!
du solltest verschiedene konstellationen testen:
wenn du leuchtstoffröhren oder energiesparlampen in deinem zimmer hast - ausmachen. einige bildschirme scheinen zu stören. mal alles abdunkeln, mal viel sonnenlicht reinlassen (wir hatten schon einen transceiver, der nur auf der sonnenterase ging...), mal nur eine kleine schreibtischlampe anlassen... manchmal wirkt eine klorolle als lichtschirm auch ganz gut,
danke!!!
mitlerweile hab ich es mehr oder weniger anders hinbekommen.
#MaxTry for flashing hab ich auf 100 gesetzt, und dann den sender neben ASURO gelegt. die dateiübertragung geht dann immer, aber mal nach dem 69. und mal nach dem 1. versuch. 8-[
normal kann das doch nicht sein, oder?
naja... glückssache... =)
Hallo
@Meur
Ich wuerde mir nicht so viele Gendanken ueber diesen einen Code machen. Wie auch radbruch schon festgestellt hat, wurde der eigentlich simple Code mit Funktionsdefinitionen und komeischen Bedingungen unoetig verkompliziert.
Einiges ist meiner Meinung nach nicht richtig programmiert worden:
Bei den if-Abfragen im Kollisionsfall werden naemlich zum Ueberpruefen folgende Ausdruecke verwendet:
if (t1 & 0x07)
if (t1 & 0x38)
Dabei ist das & kein Vergleich sondern eine logische UND-Verknuepfung. Das Ergebniss wird dabei eins, wenn alle Bedingung eins sind. Verknuepft man Zahlen wie z.B. 17 und 13 oder beliebige andere mit Ausnahme von Null, dann erhaelt man immer eine eins. Also ist die Bedingung immer wahr (t1 hat ja im Kollisionsfall immer einen Wert).
Das erklaert auch, warum der Asuro deines Freundes immer nach rechts faehrt. Die erste Bedingung wird ganz kurz ausgefuehrt, dann kommt schon die zweite. Die ist ebenfalls wahr und wird dadurch auch ausgefuehrt. Danach fuehrt er noch den letzten Befehl fuer die Motoren (rueckaerts rechts fahren) aus, bis Msleep vollendet ist.
Warum deiner dabei jedoch anders reagiert weis ich jetzt nicht zu erklaeren.
Verwendet ihr beide die gleiche lib-Version?? Msleep ist naemlich in der beim Kauf mitgelieferten Library noch gar nicht vorhanden. Das koennte dann naemlich erklaeren, warum er bei dir stehen bleibt. Ohne die Msleep Wartezeit sind, wie radbruch schon gesagt hat, die Intervalle, in denen die Motoren ihre Befehle kriegen, zu kurz.
Ich wuerde dir raten eine anderes Kollisionsprogramm auszuprobieren.
Spiel dich mit dem Trimmer am IR Sender. Mit dem kann man die IR Übertragung enorm verbessern!Zitat:
Zitat von jzd
Der Selbsttest ist etwas mit Vorsicht zu genießen, am besten du schreibst dir deinen eigenen Selbsttest(und lernst damit gleich was über die Asuro Programmierung).
Hallo
Hallo NATHAN, ich muss ein bisschen korrigieren.Zitat:
Zitat von NATHAN
Das & ist zwar tatsächlich kein Vergleich, aber es verknüpft in C jedes einzelne Bit einer Variablen. Nur das && ist ein logisches UND mit den jeweiligen logischen Gesamtwerten der zu vergleichenden Variablen.
Hier mal als duales Bitmuster:
0x07 ensprechen [00]000111
0x38 ensprechen [00]111000
Die in Klammern gesetzten 0-en existieren nicht als Taster. Die anderen 0-en und 1-en stellen somit die 6 Taster vom Asuro dar, und die 0x-er Werte wurde so gewählt, dass entweder die 3 linken oder eben die 3 rechten Taster 'maskiert' werden können.
Drückt man auf der linken Seite einen Taster, kommt z.B. folgendes raus
[00]010000
&
[00]000111
--------------
[00]000000 <-- Dieses Ergebniss ist in der Abfrage aber FALSE. Egal welche der 3 linken Tasten gedrückt wurde.
Die gleiche Taste nun mit 0x37 verglichen ergibt:
[00]010000
&
[00]111000
-------------
[00]010000 <-- Dies ist TRUE als Ergebniss.
Somit liegt es (zum Glück) doch am Taster, welcher Programmteil durchlaufen wird.
Wenn Msleep nicht vom Linker gefunden würde, würde keine hex-Datei zum Schluß rauskommen.Zitat:
Zitat von NATHAN
@Meur
Im Übrigen:
Das Programm vom 14.07.2007, 10:42 funktioniert hervorragend. (Auf meinem Asuro)
Jetzt bleiben doch wirklich nur noch die Tasten bzw. die Umrechnung in PollSwitch() übrig, wie radbruch schon vermutete.
Ich habe in diesem Thread ein Programm gepostest, mit dem, unter anderem, der beste Wert für den Umrechenfaktor in der PollSwitch()-Funktion ermitteln werden kann. (Test 1 liefert den Wert.)