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: Frank Menzel
Datum: Mi, 03.10.2007 19:39:12
In-reply-to:
<6CE00C6D-6E21-4CEF-BCB0-8C768C05F6C5@xxxxxxxxxxxxxxx>
Hallo Timo,
funktioniert denn das Verhalten auch besser als das alte ? Denn das war
ja Sinn und Zweck...
Alles andere muß ich mir erst mal auf der Zunge zergehen lassen.
Gruß, Frank Menzel
-----Ursprüngliche Nachricht-----
Von: ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx
[mailto:ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von Timo
Sandmann
Gesendet: Mittwoch, 3. Oktober 2007 18:30
An: Entwicklung rund um den c't-bot
Betreff: Re: [ct-bot] neues catch_pillar
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
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler