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]

Re: [ct-bot] Neues wall_explorer-Verhalten...

Absender: Timo Sandmann
Datum: Mo, 27.08.2007 21:01:51
In-reply-to: <812F86EC9E1A96489D5E83C2AB7D688601309E55@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <812F86EC9E1A96489D5E83C2AB7D688601309E55@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


Hi,

Am 27.08.2007 um 08:29 schrieb Menzel, Frank IT-OO4:
Ich habe aber noch ein paar Anmerkungen:
Die aus dem Olympic-Verhalten ausgelagerte Funktion "int16
is_obstacle_ahead(int16 distance)" sollte dann am besten auch aus der olympic.c-Datei raus und in sensor.c, denn der Distanzsensor- Vergleich wird ja nicht mehr nur von olympic benutzt. -> verstehe ich nicht, da die Routine in Olympic ja benutzt wird, also auch der Sensorvergleich benutzt wird... Kann die Routine trotzdem auslagern.

ich meine folgendes: Die einzelnen Verhalten sind in unterschiedlichen Dateien aufgeteilt und werden mit unterschiedlichen #defines aktiviert. Ich fände es am Übersichtlichsten, wenn alles, was in der Datei behaviour_xyz.c steht auch mit BEHAVIOUR_XYZ_AVAILABLE komplett an- oder abgeschaltet wird. Sonst weiß man nie so genau, was jetzt alles mit compiliert wird, welche Funktion, die auch von anderen Codeteilen benutzt wird, wo überhaupt definiert ist usw. Wenn jede zweite bahviour-Datei auch Code enthält, der immer compiliert wird, unabhängig vom #define-Schalter für dieses Verhalten, für das die Datei eigentlich gedacht war, verliert man schnell den Überblick. Außerdem ist eine Funktion, die prüft ob ein Hindernis in Entfernung X existiert, so allgemein, dass sie immer im Code vorhanden sein kann / sollte. Zudem geht sie in einer "Verhaltensdatei" auch unter und wird kaum benutzt, obwohl es sich an vielen anderen Stellen anbieten würde. Daher der Vorschlag diese Funktion auszulagern.

Anstatt der Funktion "int8 time_reached(uint16 ms)" würde ich lieber "bot_delay_behaviour" benutzen, so wie das u.a. auch bot_turn () macht, dann haben wir den Code dafür nur einmal. -> Problem ist nur, daß das delay-Verhalten selbst das aufrufende Verhalten deaktiviert und erst nach Ablauf der Zeit wieder aktiviert. Der Unterscheid zu den bisher benutzten Aufrufen ist aber der, dass mein Verhalten weiterhin aktiv sein muß und solange die Drehgeschwindigkeiten setzen muß. Kann das Delay-Verhalten also so nicht verwenden.

Oh stimmt, das hatte ich übersehen. In diesem Fall ist man mit timer_ms_passed() am besten bedient.

"int8 wall_is_vertical(void)" rechnet die Differenz in floating- point Werte um, ich denke mal das ist eher ein Tippfehler und nicht beabsichtigt, oder? Außerdem ist der Name der Funktion etwas merkwürdig...
-> ist klar

Die Geschwindigkeitsunterscheidungen für Sim-Bot und Real-Bot finde ich auch nicht so gut, weil der Sim ja eigentlich den echten Bot möglichst genau simulieren sollte, auch wenn es im Sim (bisher) keinen Nachlauf des Bots gibt.
-> auch klar...

Viele Grüße,
Timo





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