|
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: Mi, 17.09.2008 12:30:51
In-reply-to:
<000001c91830$68e450e0$0400a8c0@mexpnew>
References:
<000001c91830$68e450e0$0400a8c0@mexpnew>
Hi,
Am 16.09.2008 um 21:14 schrieb Frank Menzel:
Hallo,
mir kam die folgende Idee: Wir haben ja schon die wunderschönen
Routinen, um auf eine Map auf einer MMC-Karte zuzugreifen. Wenn ich
nun
für eine Pfadplanung eine 2. Map haben möchte, die eine etwas gröbere
Auflösung hat, kann man dann nicht eine 2. Map auf der Karte speichern
und mit denselben Routinen drauf zugreifen?
du meinst, dass zwei Karten parallel aktualisiert werden? Ist
sicherlich machbar, kostet aber wieder einiges an Performance.
Die Routinen müssten nur so
parametrisiert werden, dass diese einfach mit dem Namen aufgerufen
werden der zu benutzenden Map.
Und sie müssen wissen, welche Map welche Auflösung hat, um die
Koordinaten richtig umrechnen zu können usw.
Hauptsächlich würde ich eine Mapkoordinate mit übergebener
Weltkoordinate mit bestimmten Wert beschreiben wollen bzw. auslesen
wollen...
Sorry, aber ich sehe den Sinn darin immer noch nicht. Gibt es ein
konkretes Beispiel, das sich anders nicht oder nur sehr schwer
realisieren lässt und die Angelegenheit verdeutlicht?
Stell dir das ganze Map-System mal für einen Augenblick als Blackbox
vor, was darin passiert und wie, ist nicht bekannt, du weißt nur, dass
der Bot darin Informationen über seine bekannte Umgebung bereithält.
Möchtest du über irgendeinen Bereich Informationen haben, lassen sich
diese abfragen (get_average(), get_ratio(); unabhängig davon, wie das
System intern arbeitet.
Der Vorteil solch einer gekapselten Architektur (ob man es nun Schicht
oder Modul oder Objekt oder sonst wie nennt, ist hier nicht so
wichtig) ist, dass sie sehr übersichtlich ist, interne Änderungen
ermöglicht, ohne dass alle verzahnten Module auch angepasst werden
müssen usw. Der einzige Grund, so etwas (leider) aufzubrechen, ist
überlicherweise Performance.
Nur zwei Beispiele, warum solch ein orthogonales Design große Vorteile
bietet:
Im anderen Mail-Thread zum Thema Lokalisierung kam die Idee auf, dass
es vielleicht für bestimmte Anwendungen auch sinnvoll sein könnte, die
Map nicht lokal auf dem Bot, sondern remote auf einem PC zu führen.
Möchte man so etwas später mal alternativ anbieten, braucht man bei
einer klar abgegrenzten Architektur nur intern etwas ändern und kann
vielleicht sogar zwischen den Varianten umschalten, ohne dass man alle
Verhalten anpassen muss.
Außerdem möchte man den Pfadplanungsalgorithmus vielleicht
auswechseln / umschalten können, je nach Bedarf. Je mehr dieser jetzt
mit dem Map-System verwurstelt ist, desto komplizierter oder
unmöglicher wird das.
Darum: Wenn dein Algorithmus lieber eine grobe Karte hätte, wäre es
dann nicht machbar, dass er mit map_get_average() jeweils Teile
(Zellen) aus der Map liest und diese als einen Wert (das kann jetzt
Durchschnitt sein, alternativ lässt sich auch noch Minimum oder
Maximum realisieren) verschmilzt? Damit kann er die Auflösung selbst
je nach Bedarf bestimmen (z.B. erstmal gröber und wenn sich danach
kein Weg findet, feiner).
Wenn Mapfelder markiert werden müssen, reichen vermutlich ein oder
zwei Bits aus, angenommen du willst über einen 1m x 1m großen Bereich
planen und deine Auflösung soll 5 cm betragen, dann sind das 400
Felder, also z.B. 400 Bits = 50 Byte. So eine Bitmap lässt sich bequem
im RAM halten.
Grüße,
Timo
|
|