Welchen Controller??

@nestler
alle 3 Varianten sind ungeeignet.

Bei dem begrenzten Speicher den man zur Verfügung hat sollte man unbedingt mit Vektoren arbeiten.

hm....

natürlich hast du recht, dass sich mit vektoren die bilder noch kompakter
speichern lassen. jedoch sieht der roboter die umgebung leider nicht in
"vektorform", sondern in noch in "bitmap form".

vereinfacht schaut der roboter auf einen punkt a0 mit den koordinaten x0,
y0. dieser punkt ist entweder befahrbar oder unbefahrbar. dann schaut
der roboter auf den nächsten punkt a1, usw...

das problem: wie kann der roboter diese information sinnvoll in vektoren
speichern? er müsste ja nach geraden o.ä. die der neue punkt mit be-
kannten punkten bildet, suchen. das ist einerseits zeitaufwändig, ander-
erseits bei einem gewissen grundrauschen (das sich wohl nicht vermei-
den lässt) ziemlich ineffektiv.

folgendes muster:

Code:

---

111111111111111111111
011010101010101010110
000000000000000000000
00000000000x000000000

---

(roboter x schaut auf eine wand in "nord"richtung)
dieses muster lässt sich nur mit viel aufwand vektorbasiert kompakter
speichern. die wand hat zwar einen "inhalt" die oberfläche ist aber "ver-
schwommen". das heisst, es gibt viele einzelne punkte und linien der
länge 2 (brauchen beide genauso viel platz, wie im bitmap!)

gruß,
simon

Natürlich ist eine Vektorkarte schwerer zu handhaben, aber es hat eben alles seine Vor- und Nachteile.

Grundsätzlich ist es ja eigentlich immer so, daß man zwischen Rechenleistung, Geschwindigkeit und Größe abwägen muss. (nicht nur bei Karten)
Soll ein Algorithmus schneller werden braucht man entweder mehr Rechenleistung oder mehr Speicher,
dreht man an einem Parameter so muss man zwangsläufig auch die anderen anpassen.


Ich würde übrigens nicht unbedingt sagen, daß der Roboter die Umwelt in Bitmap-Form sieht...

Wenn von Anfang an klar ist, dass Vektorkarten genutzt werden sollen, kann man ja die Verarbeitung der Sensordaten gleich darauf ausrichten.
Umfährt der Roboter z.B. ein Hindernis, kann er ja gleich versuchen den Abstand konstant zu halten.
Überschreitet dann die Richtungsänderung einen bestimmten Wert wird das als Ecke erkannt und ein entsprechender Vektor in die Karte eingetragen.


So kann man von Anfang an die Probleme vermeiden die sich ergeben wenn der Roboter eine Bitmap-Karte erstmal in eine Vektorkarte umrechnen muss.
(er müsste erstmal das Bild durch ein paar Filter jagen und dann die Ecken suchen, was viel zu viel Rechenleistung und Speicher benötigen würde)

Nochmal zurück zum Thema:

Natürlich kann man den Speicher des AVR auch leicht erweitern. 64KB sind kein Thema.
Für die genannte Aufgabe der Kartenerstellung allerdings sind beide Varianten nicht geeignet. Ich sehe da zwei Möglichkeiten:
1. Atmel Controller mit Funkanbindung, der überträgt die Wegdaten, Sensordaten, etc. per Funk an einen PC, der die Arbeit macht.
2. Embedded Linux System, z.B. http://www.gumstix.com . Die arbeiten mit nem richtig schnellen ARM-Kern und darauf lassen sich dann auch ordentliche Algorithmen programmieren.

Hm, wie werden die Embedded Linux Systeme den Programmiert??
die Preise bei gumstix sind ja noch ok...
kann mir jemand mehr über diese Linux Systeme Erzählen??

naja, da gibt es eigentlich die gleichen compiler wie auch für linux.
d.h. du kannst z.b. in c programmieren...

was du natürlich beachten solltest: embedded pc geht schon mehr
in richtung pc. - das bedeutet, es ist ist ein eigenständiges system.
du schliesst deinen monitor und deine tastatur an das system an
und kannst direkt auf dem roboter programmieren...

eine funkanbindung ist natürlich immer sinnvoll. damit lassen sich dann
auch mehrere karten laden / speichern.


gruss,
simon

So jetzt muss ich mich wohl bei Thread Ersteller entschuldigen
das der Thread so abgedriftet ist.

Aber ich bin nach wie vor davon überzeugt das "PC" und Controller sich die
Aufgaben teilen sollten. Egal wie man es nun realisiert.

PC mit XYZ und robi mit Funk
Oder den PC mit schleppen egal ob als Epia oder anderes Embedded System.

Der Controller für schnelles I/O was sich leicht bauen lässt und für
das Rechnen und die Massen Daten was wo ich teile aus dem Regal
nehmen kann.

Noch eine Kleinigkeit wenn ein "PC" auf dem robi hat kann auch WLAN
als Funk verwenden um ins "Gehirn" zu gucken. Ich finde auch die Idee richtig interessant das Roboter mit einander reden können auf treffen oder so. Oh gleite schon wieder ab deshalb mache ich jetzt Schluss

Ja, ich glabe ich werde ein Gumstix Conex 400g (mit 400mHz) nehmen in kombination mit irgent einem (nicht so teurem) Controller. Die haben da bei Gumstix.com auch schon nen vorschlag für nen Board mit nem ATMega Controller (Robostix). Das gibt es aber leider noch nicht zu kaufen und ich bin noch nicht so erfahren mit Hadware...
Wie verbinde ich den Controller überhaut mit dem "PC"??
Über die RS232??

ja die meinsten hier machen es per RS232 das mache ich auch so wenn
man da ein bischen kobelt reicht das lange.

bei http://www.robotikhardware.de

gibt es fast alles was du brauchst nur die haben urlaub zur zeit. habe ich gerade gesehen. es gibt da die meinsten sachen auch aufgebaut und getestet.

Gibt es da noch andere Möglichkeiten (I2C??, CAN??), wie funktionieren die und was ist für welche Anwendungen am besten/schnellsten?