c't

c't-Projekte - Mailinglisten


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

Re: AW: AW: [ct-bot] neues Pfadplanungs-Verhalten nach der Map

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