c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] neues catch_pillar

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