|
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: Timo Sandmann
Datum: Do, 10.05.2007 20:39:56
In-reply-to:
<200705101311.25367.tevers@xxxxxxxxxxxxx>
References:
<000001c7919e$441ba070$fe78a8c0@mexpnew> <464181E6.2080803@xxxxxxxx> <FF6AE7CD-4269-4A94-B8B1-8A60FF60B7A9@xxxxxxxxxxxxxxx> <200705101311.25367.tevers@xxxxxxxxxxxxx>
Hi Torsten,
Am 10.05.2007 um 13:11 schrieb Torsten Evers:
Thorsten committet den Ringpuffer demnächst in den devel-Zweig, dann
oder Torsten... 8-)
:P
SCNR ;-)
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.
Es ist eben die Frage, was man alles speichert, bei drei floats für
Position und Richtung + Timestamp + Verhaltenspriorität wären es z.B.
17 Bytes pro Eintrag (hattest du ja schon angemerkt, dass es
Speicherintensiv ist, deshalb kam ich auf die MMC). 170 Byte fände
ich etwas zu viel dafür (wenn man denn das genannte alles speichern
möchte). Bezieht man nur Notfallverhalten mit ein, müsste man
vielleicht auch vorm Beenden des Notfallverhaltens noch Position und
Zeit speichern.
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
Ja, aber andersrum ist es auch blöd Potential zu verschenken (wenn es
denn sinnvoll eingesetzt werden könnte). Die MMC-Erweiterung allein
ist ja nicht so aufwendig und teuer, wer kein WLAN möchte, kann
genauso per USB mit dem Bot kommunizieren, weil das vom Bot aus
völlig transparent ist. Wenn keine MMC vorhanden ist, kann ein
Verhalten eben nicht so schlau agieren, weil es weniger Informationen
hat. Deshalb würde ich das in erster Linie danach entscheiden, ob es
sinnvoll ist und etwas bringt und nicht danach, ob die MMC nun
zufällig eine Erweiterung ist, die der Bot nicht von Anfang an hatte.
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
Nicht zwingend, Verhalten A kann ja berücksichtigen, was B gemacht
hat, WENN es das möchte und eben nicht wieder versuchen zum alten
Ziel zu fahren, WEIL es auf diese Weise gemerkt hat, dass das nicht
funktioniert (und deshalb B aktiv wurde). Ich denke auch, dass das
Problem mit dem alten Ziel jetzt nichts mit einem Verhaltens-Trace-
Stack zu tun hat. Die Idee war nur, allen Verhalten (und zusätzlich
dem User, aber das ginge auch einfacher) mehr Informationen zur
Verfügung zu stellen. Ob und wie diese benutzt werden, ist ja den
Verhalten selbst überlassen und unabhängig von ihrer Semantik.
Ich sehe zumindest ad hoc nicht, welchen anderen Vorteil diese
Informationen
einem Verhalten bringen soll (ausser bei Notfällen, die ja
unerwartet "dazwischen" kommen).
Meine Idee dazu kam auch eher deshalb auf, weil du auf den
Speicherbedarf hingewiesen hattest, über alle möglichen
Anwendungsfälle habe ich noch nicht weiter nachgedacht. Ich finde
nur, man sollte, wenn man das Thema angeht, vielleicht auch ein
bisschen voraus schauen und überlegen, was noch sinnvoll und machbar
sein könnte. Und da aus Diskussionen per ML schon einige gute
Features entstanden sind, habe ich's mal hier aufgeschrieben. ;-)
Denkbar wäre ja z.B. auch eine Art Undo-Funktion, also
Verhaltensausführungen seit (Zeit-) Punkt X rückgängig machen, wenn
der Bot feststellen sollte, dass es unsinnig war, was er da gefahren
hat (nur mal so als eine Idee, das wollte ich z.B. beim Wettbewerb
einbauen, aber dazu kam es ja dann nicht mehr).
...wir reden doch noch von einem ATMega32 µC, oder? :P
Ja, der zurzeit (im average-case) um den Faktor 10 schneller ist als
ein Bot im Sim...
Als Logging-Variante wäre es aber cool.
Für reines Logging lohnt es IMHO nicht, das auf die MMC zu schreiben.
Viele Grüße,
Timo
|
|