|
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: Mi, 17.09.2008 13:32:28
In-reply-to:
<EDE147DE-F11D-48F1-AA7B-30CC1C5BA2B0@xxxxxxxxxxxxxxx>
References:
<000001c91830$68e450e0$0400a8c0@mexpnew> <EDE147DE-F11D-48F1-AA7B-30CC1C5BA2B0@xxxxxxxxxxxxxxx>
Hallo Timo,
ok, mein Algorithmus soll die Pfadplanung sein. Wenn der Bot auf der Karte ganz unten steht und seinen Weg nach ganz oben planen will, sind das im ungünstigsten Fall 10 Meter, die ja auch die Karte enthält.
Nun müssen aus der hochauflösenden Karte im 1. Step die Hindernisinfos rausextrahiert werden und in eine andere Datenstruktur importiert werden. Jedes Objekt dieser Datenstruktur stellt ebenfalls eine Koordinate dar. Ist ein Objekt als Hindernis markiert, kann der Bot genau diese Position nicht anfahren und fällt bei der Pfadplanung raus. Jedes Objekt muss wiederum Bezug zu seinen Nachbarpositionen haben. Und bei dieser Datenstruktur habe ich mir eine 2. niedrigauflösende Karte vorgestellt. Aber selbst bei geringer Auflösung ist die Datenstruktur zu groß für den Ram bei Planung über 10 Meter. Vielleicht bin ich hier zu einseitig orientiert aber wie kann denn sonst die Datenstruktur (Objekt muss einen Zählerwert besitzen und Beziehungen zu 4 Nachbarpositionen) realisiert werden ?
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: Wednesday, September 17, 2008 12:31 PM
To: Entwicklung rund um den c't-bot
Subject: Re: [ct-bot] bot_drive_area() -> überarbeitet
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
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler
|
|