|
 |
 |
 |
|
|
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: Menzel, Frank IT-OO4
Datum: Di, 20.05.2008 14:40:07
In-reply-to:
<B54038E9-6E4E-4710-AFC3-45D499E76914@xxxxxxxxxxxxxxx>
References:
<48C139945BA47F4DB4DE05DF62CD57AA03B4D1CCC0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <483299C9.9030900@xxxxxxxx> <48C139945BA47F4DB4DE05DF62CD57AA03B4D1CD8B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4832B116.2030500@xxxxxxxx> <B54038E9-6E4E-4710-AFC3-45D499E76914@xxxxxxxxxxxxxxx>
Hallo,
erst mal besten Dank für die Sichtweisen.
Ich hatte immer Mapkoordinaten ausserhalb der map.c benutzt und nicht die Worldkooordinaten, weil diese auch bisher in float waren und ich wollte nicht mit float rechnen.
Wenn aber die Sichtweise nun auch rechnerisch eben die ist, außerhalb in World zu rechnen und dann in Map umzusetzen, sollte es mit den bisher außen zugänglichen Routinen möglich sein.
Da aber das vorhandene Verhalten behaviour_map_go_destination weder momentan übersetzungsfähig ist noch in diese realisierte Denkweise passt, schlage ich vor dieses rauszunehmen.
Mit freundlichen Grüßen / best regards
Frank Menzel
-----Original Message-----
From: ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx [mailto:ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Timo Sandmann
Sent: Tuesday, May 20, 2008 1:44 PM
To: Entwicklung rund um den c't-bot
Subject: Re: [ct-bot] behaviour_map_go_destination
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
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler
|
|
|