## c't-Projekte - Mailinglisten

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

### AW: [ct-bot] neues catch_pillar

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

- Antworten:
  - Re: AW: [ct-bot] neues catch_pillar
    - From: Timo Sandmann

- Referenzen:
  - Re: [ct-bot] neues catch_pillar
    - From: Timo Sandmann

- Voriger (Datum): Re: [ct-bot] neues catch_pillar, Timo Sandmann
- Nächster (Datum): Re: AW: [ct-bot] neues catch_pillar, Timo Sandmann
- Voriger (Thread): Re: [ct-bot] neues catch_pillar, Timo Sandmann
- Nächster (Thread): Re: AW: [ct-bot] neues catch_pillar, Timo Sandmann
- Indizes:
  - Datum
  - Thread