- heise online
- c't Magazin
- iX Magazin
- Technology Review
- Telepolis

- heise mobil
- heise Security
- heise Netze
- Open Source

- heise Resale
- heise Foto
- heise Autos
- c't-TV

- Software/Download
- Stellenangebote
- Preisvergleich
- IT-Markt

- heisetreff
- heise Veranstaltungen
- heise Whitepapers
- Abo&Heft
- Archiv

Aktuelles Heft #### Support Hotline & FAQ Tipps & Tricks Treiber & BIOS Firmenkontakte #### Download Software zu c't Software-Verzeichnis c't-Projekte Testbilder & Vorlagen #### Service Tipp-Datenbank c't-CD-Register Virenschutz #### Magazin Heftarchiv c't specials English Pages Benchmarks Red. Stuff Leserforum c't-Bildmotive URLs aus c't Schlagseite #### Aktionen Browsercheck Krypto-Kampagne Schulen ans Netz Netz gegen Kinderporno TV/Radio-Termine #### Info Abo & Heft Veranstaltungen Mediadaten Kontakt Impressum Kleinanzeigen und Veranstaltungen
| c't Projekte - c't-Bot und c't-Sim - Mailinglisten ## c't-Bot und c't-Sim [Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)] [Nach Datum][Nach Thread] ### RE: [ct-bot] bot_drive_area() -> überarbeitet->Pfadplanung 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
Antworten: Re: [ct-bot] bot_drive_area() -> überarbeitet -> Pfadplanung From: Timo Sandmann Referenzen: AW: [ct-bot] bot_drive_area() -> überarbeitet From: Frank Menzel Re: [ct-bot] bot_drive_area() -> überarbeitet From: Timo Sandmann Voriger (Datum): Re: [ct-bot] bot_drive_area() -> überarbeitet, Timo Sandmann Nächster (Datum): Re: [ct-bot] bot_drive_area() -> überarbeitet -> Pfadplanung, Timo Sandmann Voriger (Thread): Re: [ct-bot] bot_drive_area() -> überarbeitet, Timo Sandmann Nächster (Thread): Re: [ct-bot] bot_drive_area() -> überarbeitet -> Pfadplanung, Timo Sandmann Indizes: Datum Thread |

Copyright © 2008 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis Impressum International: heise online UK, heise Security UK, heise open source UK, heise networks UK, heise online Polska, heise Security Polska, heise Open Source Polska, heise Networks Polska