Absender: Torsten Evers
Datum: Do, 10.05.2007 13:10:44
In-reply-to:
<FF6AE7CD-4269-4A94-B8B1-8A60FF60B7A9@xxxxxxxxxxxxxxx>
References:
<000001c7919e$441ba070$fe78a8c0@mexpnew> <464181E6.2080803@xxxxxxxx> <FF6AE7CD-4269-4A94-B8B1-8A60FF60B7A9@xxxxxxxxxxxxxxx>
Hi, Am Donnerstag, 10. Mai 2007 10:50:04 schrieb Timo Sandmann: > > Thorsten committet den Ringpuffer demnächst in den devel-Zweig, dann > > oder Torsten... 8-) :P [Beschreibung] > Das Ganze würde leicht nachvollziehbar machen, welches Verhalten wann > lief und was bewirkt hat (im Wesentlichen die Änderung der Bot- > Position). Das ginge auch per LOG-Ausgabe, aber so könnte auch der > Bot selbst die Daten wieder einlesen und auswerten. > > Lohnenswert darüber weiter nachzudenken oder Overkill? Im Prinzip macht der Ringpuffer für die Notfallverhalten ja (wenn auch nur für 10 Aufrufe und nur bei Notfallverhalten) genau das schon. Man könnte den diesbezüglich erweitern. Ich sehe es allerdings als kritisch an, Verhalten von der Existenz solcher Informationen abhängig zu machen (zumindest von MMC), denn 1. hat die nicht jeder und 2. kann ein Verhalten schlecht einordnen, wie diese letzten Änderungen zustande gekommen sind. Man müsste dann ja einbauen, dass Verhalten A vorhersieht, dass Verhalten B, weil es beim letzten Durchgang Aktion X durchgeführt hat, nun Aktion Y ausführt, um sein eigenes Verhalten danach auszurichten. Sonst berechnet Verfahren A mit der von Verhalten B geänderten Position seine Fahrstrecke so neu, dass wieder das "alte" Ziel von vor der Änderung durch B erreicht wird. Verhalten B seinerseits tut dann dasselbe mit seinem Ziel usw...ein Teufelskreis :P Ich sehe zumindest ad hoc nicht, welchen anderen Vorteil diese Informationen einem Verhalten bringen soll (ausser bei Notfällen, die ja unerwartet "dazwischen" kommen). ...wir reden doch noch von einem ATMega32 µC, oder? :P Als Logging-Variante wäre es aber cool. Schöne Grüße, Torsten