heise online · c't · iX · Technology Review · Telepolis · mobil · Security · Netze · heise open · heise resale · Autos · c't-TV · Jobs · Kiosk
Zum Inhalt
c't

c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


[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





Copyright © 2007 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis   Impressum