|
 |
 |
 |
|
|
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: Di, 20.05.2008 13:43:59
In-reply-to:
<4832B116.2030500@xxxxxxxx>
References:
<48C139945BA47F4DB4DE05DF62CD57AA03B4D1CCC0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <483299C9.9030900@xxxxxxxx> <48C139945BA47F4DB4DE05DF62CD57AA03B4D1CD8B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4832B116.2030500@xxxxxxxx>
Hi,
ich antworte mal auf die Antwort, ist hoffentlich übersichtlicher:
Am 20.05.2008 um 13:08 schrieb Benjamin Benz:
so ganz verstehe ich nicht, wieso die Routinen nicht zugänglich
sein sollen. Oder gibt es andere Cache-Äquivalente, die benutzt
werden sollten von aussen ?
Hierfür gibt es verschiedene Gründe:
1. brauchen Schreibzugriffe die MMC exklusiv ==> Der Cache kümmert
sich um das Locking
2. Haben Schreibzugriffe bisher den Bot so ausgebtremst, dass wir
sie nun Cachen
3. Wollten wir der übersichtlickkeithalber das Interface auf das
absolute Minimum beschränken -- was nicht heißt, dass man es nun
einzeln wieder erweitern kann.
Noch eine kleine Ergänzung, vielleicht wird dann klarer, wie der
Zugriff gedacht ist: Verhalten sprechen mit dem Map-Cache, um die Map
zu verändern. Zwischen Map-Cache und der eigentlichen Map gibt es eine
Verbindung, die aber nicht weiter spezifiziert ist - wann hier was wo
geschrieben wird, ist nicht eindeutig vorbestimmt. Um die Karte
auszulesen, können Verhalten auf die Lese-Funktionen in map.h
zugreifen. Der Map-Zugriff soll also auf zwei verschiedenen Wegen
passieren und beide sind Einbahnstraßen (nur lesen oder nur schreiben).
In einem Verhalten habe ich ja nur die Bot x/y-Weltkoordinaten.
Wenn ich auf Mapebene arbeiten will, muss ich diese umrechnen
können in Mapkoordinaten, um z.B. den Abstand zum nächsten
Hindernis laut Map berechnen zu können.
Unserer Idee nach sollte all sowas außerhalb der Map in Real-
Koordinaten eerfolgen, weil das die übersichtlichkeit/
Verständlichkeit erhöht.
Warum sollte der Abstand zum Hindernis auch in Map-Koordinaten
berechnet werden?
Will ich einfach nur einen Wert innerhalb der Map auf einen
bestimmten Wert setzen, brauche ich auch set_field...
Hier stellt sich die Frage was für Werte denn in die Karte
einzutragen sind und ob die Map der geeignete Ort für solche Daten
ist. Wenn es solche gibt wäre der eleganteste Weg die aktualisierung
über die Cache-Strukturen vorzunehmen.
Die Karte an sich ist kein Speicherplatz, sondern beinhaltet nur
Wahrscheinlichkeiten. Ist an anderer Stelle auch schon was zu gesagt.
Mein Verständnis der Map war bisher nicht die Umgebungskarte als
Schönheit in der hohen Auflösung zu haben, sondern diese eigentlich
zu nutzen für intelligente Aufgaben.
Völlig klar.
Ob aber ein Verhalten die Karte "anschaut" oder der Bot-Besitzer, ist
eigentlich egal. Sie sollte so sein, dass die Informationen gut
erkannt werden können, das gilt ja auch für Verhalten.
Und dazu brauche ich nach außen nutzbare Mapfunktionen...
Nun einige (lesende) sind ja nach außen verfügbar:
map_get_average()
map_get_point()
map_way_free()
wir hatten noch über eine weitere Funktion nachgedacht:
map_get_lowest() -- damit ließe sich prüfen, ob im umkreis
mindestens ein Loch vorhanden ist.
Ja, die fehlt noch.
Mit diesen vier Routinen sollte sich eigentlich fast alles machen
lassen. Wobei zu bedenken ist, dass es sich ja ohnehin um eine
stochastische Karte handelt, also eigentlich primär die average-
Routine wichtig ist.
Oder was habe ich jetzt nicht verstanden ?
Wenn ich den alten Code und diese Diskussion hier richtig
interpteire geht es darum, ob und wie Zusatzinfornationen zur
wegplanung etc. in die Karte eingetragen und wieder ausglesen werden
können.
Die derzeitige Organisation der Karte eignet sich (leider) kaum, um
"Notizen" mit in die Karte zu schreiben.
Gründe dafür:
a) Jedes Feld in der karte hat nur 8 Bit, die derzeit wie folgt
interpretiert werden:
<0: das Feld ist wahrscheinlich nicht frei (Der Betrag istv ein Maß
für die Wahrscheinlichkeit)
>0: das Feld ist wahrscheinlich frei (Der Betrag istv ein Maß für
die Wahrscheinlichkeit)
0: keine Information über das Feld vorhanden
-128: Feld ist ein Abgrund
Bis auf den letzten Fall sind alles wahrscheinlichkeiten, auch die 0
kann als solche interpretiert werden. Bei den Löchern/Abgründen
haben wir eine Ausnahme gemacht.
Würde man weitere Sonderfälle über feste Werte abbilden, klappt das
Updaten der Karte nicht mehr sinnvoll oder führt zu Flickwerk.
Wenn Metainformationen gewünscht sind, sehe ich folgende Optionen:
a) wir erweitern die Karte um ein (oder mehr) zusätzliche Bytes für
jedes Feld. Das hätte ein paar unschöne Nebeneffekte auf unser
Performance-tuning und würde die Karte erheblich vergrößern/
verlangsamen. Dafür könnte man dann sauber Kartendaten und Marker
trennen
b) Wir reduzieren die Bittiefe der Map, um ein paar Bit für
Informationen freizubekommen. Das kostet Information (aber keine
Performance) und ermöglicht dennoch probalistische Karten UND eine
Trennung von Karte und Metainfo.
zu a) und b): Außerdem hat man immer das Problem, das man für die Meta-
Infos die ganze Karte ablaufen müsste, weil man ja nicht weiß, in
welchem Feld Infos stecken. Das ist doch viel zu langsam und
umständlich.
c) Metainformationen, Marker etc, kommen in eine eigene "Karte", die
dann vielleicht auch mit viel niedrigerer Auflösung auskommt
Oder eine entsprechende Datenstruktur, die besser passt, als eine
Rasterkarte. Erscheint mir irgendwie viel einfacher und passender.
Oder ich sehe den entscheidenden Vorteil von "Metadaten in Karte" nicht.
Grüße,
Timo
|
|
|