## c't-Projekte - Mailinglisten

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

### RE: [ct-bot] behaviour_map_go_destination

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

- Referenzen:
  - [ct-bot] behaviour_map_go_destination
    - From: Menzel, Frank IT-OO4
  - Re: [ct-bot] behaviour_map_go_destination
    - From: Benjamin Benz
  - RE: [ct-bot] behaviour_map_go_destination
    - From: Menzel, Frank IT-OO4
  - Re: [ct-bot] behaviour_map_go_destination
    - From: Benjamin Benz
  - Re: [ct-bot] behaviour_map_go_destination
    - From: Timo Sandmann

- Voriger (Datum): Re: [ct-bot] behaviour_map_go_destination, Timo Sandmann
- Nächster (Datum): Re: [ct-bot] behaviour_map_go_destination, Timo Sandmann
- Voriger (Thread): Re: [ct-bot] behaviour_map_go_destination, Timo Sandmann
- Nächster (Thread): Re: [ct-bot] behaviour_map_go_destination, Timo Sandmann
- Indizes:
  - Datum
  - Thread