|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Timo Sandmann
Datum: Mi, 03.10.2007 18:30:30
In-reply-to:
<000001c804cb$bdb46ed0$fe78a8c0@mexpnew>
References:
<000001c804cb$bdb46ed0$fe78a8c0@mexpnew>
Hallo,
das Verhalten funktioniert bei mir meistens ganz gut, manchmal fährt
der Bot aber auch gegen die Dose, was IMHO daran liegt, dass nach dem
Stopp der Nachlauf der Motoren nicht abgewartet wird.
Außerdem noch ein paar andere Anmerkungen:
catch_pillar arbeitet jetzt teilweise genau wie drive_distance, warum
dann nicht gleich drive_distance aufrufen? So haben wir den Code
dafür doppelt.
Hinzu kommt, dass es genau wie drive_distance mit den aktuellen
Encoder-Ständen rechnet und danach die zu fahrende Wegstrecke
bestimmt. Das ist eigentlich nicht besonders gut (bei drive_distance
auch nicht - es gibt aber ja auch schon den "Nachfolger" gotoxy()).
Ich wäre sehr dafür, dass die Verhalten nicht direkt die
Encoderstände (oder z.B. die Daten der Mausregister) verwenden,
sondern die von sensor_update() berechneten Positionsdaten - dafür
gibt es ja extra den Odometrie-Code in sensor_update().
Hier ist generell eine (logische) Trennung zwischen Sensorrohdaten-
Auswertung und Verhalten sinnvoll (auch wenn das derzeit noch nicht
überall so eingehalten wird, aber zumindest neue Verhalten sollten
das tun).
Gerade die Encoder-Werte könnten sich während der
Verhaltensausführung ändern, selbst wenn man den Zeiger auf die
Variable als volatile deklarieren würde. Ein Beispiel (nur zur Info):
sensEncL == 255 und ein Verhalten möchte nun den Inhalt von sensEncL
verwenden und holt dazu die Variable aus dem RAM. Dabei werden jetzt
zunächst die unteren 8 Bit gelesen (== 255). Nun trifft ein Timer-
Interrupt ein und beim Encoder-Update wird sensEncL um eins erhöht,
ist jetzt also 256. Die ISR kehrt zurück und das Verhalten lädt die
oberen 8 Bit von sensEncL (dort steht nun 1 drin, denn 256 = 2^8) und
schließt auf einen Encoderstand von 1*256 + 255*1 = 511, der
Encoderstand beträgt aber zu diesem Zeitpunkt erst 256 => Fehlerhafte
Daten.
Zugegeben, die Wahrscheinlichkeit, dass dieser Fall eintritt, ist
recht gering, passieren kann es aber trotzdem. Also besser auf die
von sensor_update() bestimmten Positionsdaten zurückgreifen, was
außerdem eine saubere Trennung zwischen Rohdaten und für Verhalten
aufbereitete Daten bewirkt.
Das hat jetzt nicht nur etwas mit catch_pillar() zu tun,
drive_distance() benötigt hier ebenfalls eine Überarbeitung (ich
hatte schon mal angefangen ein Verhalten zu basteln, das einen Punkt
anfährt und dabei auch Fehler korrigiert, worauf u.a. drive_distance
() dann sehr einfach zurückgreifen könnte, ich bin bisher aber noch
nicht dazu gekommen, es fertig zu machen), aber wenn man es
überarbeitet, wäre es vielleicht gut, solche Dinge gleich mit zu
berücksichtigen.
Ich denke, wenn man mit der x/y-Position des Objekts rechnet und
diese anfährt, umgeht man auch das Problem mit dem Nachlauf oder
andere Störungen, die unterwegs auftreten könnten.
Das Avoid-Border-Verhalten darf nur dann versucht werden
abzuschalten, wenn es auch vorhanden ist.
Der neue Unload-Aufruf fehlt in den Remote-Calls.
Der Code sollte überall MAX_PILLAR_DISTANCE verwenden und nicht
teilweise hard-gecodete Entfernungen.
Gruß Timo
Am 02.10.2007 um 10:10 schrieb Frank Menzel:
Hallo,
da das catch_pillar-Verhalten doch noch einige Fehler und Macken
hatte,
habe ich diese mal umgekrempelt und angehangen. Nicht als Patch
sondern
die Datei selbst, da die Änderungen so grundlegend waren.
So ist jetzt die Drehung nach 360 Grad Drehung vorbei, wenn nichts
gefunden wurde. Auch wird bei Objekterkennung nicht mehr endlos
vorwaerts gelaufen und bei Fehlerkennung damit nach einer bestimmten
Strecke voraus weiter im Umkreis gesucht. Eine Wand wird ebenfalls
nicht
mehr als einzufangendes Objekt erkannt und andere Fehlerkennungen
vermieden.
Einfach gegen die bisherige Datei ersetzen und schon geht's...
Ach so, beim Entladen gibt's noch ein abgewandeltes Entladen mit den
Params curve und cm, so wie bei bot_drive_distance beschrieben. Ein
Objekt wird damit xx cm voraus entladen, wobei der Bot diese mit der
curve zurücklegt. Macht dann Klappe auf und fährt den Bogen wieder
zurück, das Entladen ist dann vorbei.
Gruß, Frank Menzel
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler
|
|
|