Überlegungen zum Mapbuilding

RLE habe ich eben nachgeschlagen:
http://de.wikipedia.org/wiki/Laufl%C3%A4ngenkodierung
Das wäre eine Sache die wir generell im Auge behalten sollten.

Netter Gruß

Also ich habe mich kennesfalls auf 1/0 abspeichern eingeschossen ;)
Ich bin an sich auf für eine Vektorbasierende Speicherung.

Ich denke den Grund dafür habe ich bereits in meinem letzen Post erläutert (ich denke an meine 3D Oberfläche...)

Bei wirklichem 3D könnt' man fast auch über "Meshes" nachdenken.

daran habe ich schon gedacht, zumindest für die 3D Berechnungen mit hilfe meiner beiden Webcams (du wirst dich sicher an den Thread erinnern ;)

bis lang verwende ich als Grundlage 2D Vektoren, daraus werden dann die restlichen Punkte automatisch berechnet, die für eine 3D Darstellung benötigt werden.

Denn ich halte es durchaus für machbar den µC mit Vektoren rumschubsen zu lassen. Das schwierige (was mir demnächst bevor steht) ist einem µC bezubringen, wie er aus den ganzen Einzelmessungen meiner Sharps (drehbar) vereinfachen kann, um die nötigsten Vektoren als Ergebnis zu bekommen.

Zitat:

---

..ganzen Einzelmessungen meiner Sharps (drehbar..

---

Weil du es grad sagst: Ich kämpfe mit sehr schwankenden Meßwerten vom GP2D12. Wie sieht es da bei dir aus, und, wenn besser, wie hast du das beschaltet ?

direkt daran diverse Kondis (100n helfen schon sehr).
Über die Versorgung kommt gerne noch was rein (bzw stört der Sharp sich u.U. selbst. Einfach mal Oszi darauf ansetzen dann sieht man doch gut, woran es hapert.
Desweiteren sind bei mir die Sharps wie auf http://mrnd.dyndns.org/elektronik/botbilda/bot3.jpg zu sehen befestigt, das verhindert die fehlerhaften Messwerte an senkrechten Kanten.

Ansonsten werde ich mich mal daran versuchen die Messungen auf die Ausgabe eines neuen Sensorwertes zu syncnen (hab mein Oszi schonmal am Sharp gehabt, gibt da eingies an evl. verwendbaren Signalen), damit will ich bei max. Messrate die Fehlmessungen stark verkleinern (z.b. kann es sonst passieren das ich den Messwert der letzten Messung für den der aktuellen verwende.)

Hallo Marvin42x,

ja, es scheint daß es da noch ein Mißverständnis gibt.

a) Bei meinem "Bitmap"-Vorschlag gehe ich davon aus, entsprechenden Speicherplatz komplett zu allozieren. In diesem Array von 4Bit x X-Coord x Y-Coord kann man entsprechende Werte Eintragen/Auslesen. Die X/Y-Koordinaten ergeben sich aus der Position im Array. Das ist simpel, braucht aber für genauere Karten viel Speicherplatz.

b) Mal schaun, ob ich den anderen Vorschlag richtig verstanden habe:
- erstmal gehen wir davon aus, das alles befahrbar ist
- wir speichern nur die Hindernisse bzw. den "Zaun" drumherum
- dafür brauchen wir im Datensatz die Angabe von X/Y-Koordinate + evtl. noch ein paar Bit für Zusätzliche Informationen

Letzteres ist wiederum gar nicht weit weg von einer 2D-Vektor-Lösung. Lediglich die Länge der Vektoren wäre einheitlich "1 Rastereinheit".

@MrNiemand: Hast Du schon mal mit 2D oder gar 3D-Vektoren auf einem Mikrocontroller gearbeitet? Da sehe ich im Moment das größte Problem:
Bei einer Bitmap kann ich ausgehend von meiner eigenen Position relativ schnell ermitteln , ob ich in das gewünschte angrenzende Feld fahren kann/darf, bzw. in welche Position ich fahren kann. Bei einer Vektorbasierten Lösung muss ich immer gegen alle Vektoren in der Karte Prüfen, die könnten ja schließlich auch länger sein und ich muss errechenen, ob sie sich mit meinem Bewegungsvektor schneiden.

Grüße,
Reinald

PS: Ich favorisiere keine spezielle Lösung und bin offen für alle Vorschläge, mein Interesse gilt einer praktikablen Lösung, die auf einem Mikrocontroller lauffähig ist und einige Grundlegende Anforderungen löst.
3D-Laserscan, Video-Bildanalyse, Bau eines 3D-Gitternetzes und Kollisionsberechnung darin scheiden daher leider aus.

Ist die Frage, wieweit sich eine Karten-Bitmap von einer Video-Bitmap eigentlich unterscheidet (jetzt mal prinzipiell).

Dass 3D immer eins drauf, is natürlich logo.

@PicNick: Was verstehst Du unter "Video-Bitmap"?

Gruß
Reinald

Naj, Karte ist x, y und ein Wert
Video(ein Frame) ist x, y und auch ein Wert (Farbe, Helligkeit)