Chris266
14.10.2006, 06:57
Hallo zusammen,
mir schwebt seit kurzem ein Gedanke durch den Kopf der mich immer wieder einholt. Es gibt für so viele Dinge eine fertige Lösung: Motortreiber/Board, Servo-Chips, Controller-Boards, Kompassmodul, etc.
Doch eines, was vielen Roboterbastlern am Herzen liegt (zumindest mir), fehlt als "ready-to-run" Applikation: ein "MAP-Board".
Ich verstehe darunter ein kompaktes Board mit dessen Hilfe der Robi Punkte anfahren kann um den Weg von A nach B (von B nach F etc.) zu finden.
Mal angenommen es würde tatsächlich funktionieren: gefüttert wird das Board mit Odometriedaten, berechnet daraus seine ungefähre Position (X,Y Koordinaten). Mit einem Tastendruck kann diese Position "gespeichert" werden. Anschließend fährt der Robi weiter, bleibt stehen (X und Y Position werden weiterhin aktualisiert) und soll auf einen erneuten Knopfdruck wieder zur vorherigen Position zurück finden - auf dem kürzesten Weg.
Sollten Hindernisse detektiert werden, müsste es möglich sein dem "Map-Board" dies mitzuteilen. Dieses Hinderniss wird in der "Map" des Board gespeichert und wird in Zukunft umfahren.
Ich habe (noch) keine Erfahrung mit Odometriedaten, zumindest nicht um eine zuvor gespeicherte Position wieder zu finden. Bisher habe ich die Odometriedaten lediglich für eine bessere Geradeausfahrt verwendet.
Als Alternative zu den Odometriedaten könnten ggf. auch Beschleunigungssensoren und ein Gyro dienen. Doch auch hierzu habe ich keine pratischen Erfahrungen.
Es geht mir nicht darum eine zuvor gespeicherte Position auf den mm wieder anfahren zu können, ein paar cm Abweichung sind sicherlich akzeptabel: beispielsweise für das autonome Staubsaugen in einer Wohnung.
Mal angenommen es würde funktionieren, wäre es nicht schön wenn ein Roboter, beispielsweise über I2C oder SPI Interface ein externes "MAP-Board" fragen könnte: "Ich muss nach X=329, Y=100. In welche Richtung soll ich fahren und wie weit?". Diese "Frage" müsste selbstverständlich wiederholt werden damit "Abbiegungen" möglich sind. Sobald die zu fahrende Strecke = 0 ist, wäre der Robi am "Ziel", mit etwas Abweichung.
Mit einem kleinen ATMega Chip könnte sowas ggf. möglich sein. Kommt eben auf die Auflösung der internen MAP an und die gewählte Speichermethode. Soll die Wohnung bzw. die Umgebung in ein 8x8cm Raster unterteilt werden so könnte man mit 512 Bytes Speicher eine Fläche von 5,12m x 5,12m abspeichern sofern für jedes Feld ein Bit verwendet wird:
512 Bytes = 4096 Bits = 64 x 64 Felder mit 1 Bit pro Feld (0=frei, 1=Hinderniss).
Pro Feld eine Fläche von 0,08m x 0,08m = 64 * 0,08 * 64 * 0,08 = 26qm.
Die zurück gelegte Strecke als auch die aktuelle Ausrichtung des Robis (bei Zweiradantrieb) lässt sich mittels der Odometriedaten theoretisch errechnen.
Wenn ich mich jetzt nicht verschätzt habe (nicht ausgerechnet) müsste mit 4096 Bytes Speicher etwa eine Fläche von 100qm möglich sein (bei 8cm Auflösung)?
Die X und Y Position des Robis könnte in einer "höheren" Auflösung stattfinden (Bsp. mm). Es geht also nur darum "Kästchen" abzufahren.
Leider steigt der Speicherbedarf für den A*Pathfinding Algo (um gezielt den kürzesten Weg zwischen zwei bekannten Punkten ermitteln zu können) mit größerer MAP erheblich! Da für jedes Feld im Schlimmsten Fall ein X,Y,I(Index zum Vorgänger), H und G gespeichert sein muss (F wird beispielsweise permanent neu berechnet um Speicher zu sparen).
Wird eine MAP mit 512 Bytes verwendet (64x64 Felder) so ergibt sich, sofern für X,Y,I, H und G NUR ein Byte verwendet wird ein maximaler Speicherbedarf von 4096Felder*5Bytes=20480Bytes.
Diese Zahl ist zum Glück nur im Extremfall notwendig. Genau genommen muss X und Y kein ganzes Byte breit sein: schließlich sind in diesem Beispiel nur 64 Positionen in X und Y Richtung zu addressieren.
Ich möchte hier, zumindest zu diesem Zeitpunkt, nicht weiter auf die technischen Details eingehen.
Was mich interessiert:
Hat jemand Lust an der Entwicklung mit zu wirken? 8-[
Grüße und Danke!
mir schwebt seit kurzem ein Gedanke durch den Kopf der mich immer wieder einholt. Es gibt für so viele Dinge eine fertige Lösung: Motortreiber/Board, Servo-Chips, Controller-Boards, Kompassmodul, etc.
Doch eines, was vielen Roboterbastlern am Herzen liegt (zumindest mir), fehlt als "ready-to-run" Applikation: ein "MAP-Board".
Ich verstehe darunter ein kompaktes Board mit dessen Hilfe der Robi Punkte anfahren kann um den Weg von A nach B (von B nach F etc.) zu finden.
Mal angenommen es würde tatsächlich funktionieren: gefüttert wird das Board mit Odometriedaten, berechnet daraus seine ungefähre Position (X,Y Koordinaten). Mit einem Tastendruck kann diese Position "gespeichert" werden. Anschließend fährt der Robi weiter, bleibt stehen (X und Y Position werden weiterhin aktualisiert) und soll auf einen erneuten Knopfdruck wieder zur vorherigen Position zurück finden - auf dem kürzesten Weg.
Sollten Hindernisse detektiert werden, müsste es möglich sein dem "Map-Board" dies mitzuteilen. Dieses Hinderniss wird in der "Map" des Board gespeichert und wird in Zukunft umfahren.
Ich habe (noch) keine Erfahrung mit Odometriedaten, zumindest nicht um eine zuvor gespeicherte Position wieder zu finden. Bisher habe ich die Odometriedaten lediglich für eine bessere Geradeausfahrt verwendet.
Als Alternative zu den Odometriedaten könnten ggf. auch Beschleunigungssensoren und ein Gyro dienen. Doch auch hierzu habe ich keine pratischen Erfahrungen.
Es geht mir nicht darum eine zuvor gespeicherte Position auf den mm wieder anfahren zu können, ein paar cm Abweichung sind sicherlich akzeptabel: beispielsweise für das autonome Staubsaugen in einer Wohnung.
Mal angenommen es würde funktionieren, wäre es nicht schön wenn ein Roboter, beispielsweise über I2C oder SPI Interface ein externes "MAP-Board" fragen könnte: "Ich muss nach X=329, Y=100. In welche Richtung soll ich fahren und wie weit?". Diese "Frage" müsste selbstverständlich wiederholt werden damit "Abbiegungen" möglich sind. Sobald die zu fahrende Strecke = 0 ist, wäre der Robi am "Ziel", mit etwas Abweichung.
Mit einem kleinen ATMega Chip könnte sowas ggf. möglich sein. Kommt eben auf die Auflösung der internen MAP an und die gewählte Speichermethode. Soll die Wohnung bzw. die Umgebung in ein 8x8cm Raster unterteilt werden so könnte man mit 512 Bytes Speicher eine Fläche von 5,12m x 5,12m abspeichern sofern für jedes Feld ein Bit verwendet wird:
512 Bytes = 4096 Bits = 64 x 64 Felder mit 1 Bit pro Feld (0=frei, 1=Hinderniss).
Pro Feld eine Fläche von 0,08m x 0,08m = 64 * 0,08 * 64 * 0,08 = 26qm.
Die zurück gelegte Strecke als auch die aktuelle Ausrichtung des Robis (bei Zweiradantrieb) lässt sich mittels der Odometriedaten theoretisch errechnen.
Wenn ich mich jetzt nicht verschätzt habe (nicht ausgerechnet) müsste mit 4096 Bytes Speicher etwa eine Fläche von 100qm möglich sein (bei 8cm Auflösung)?
Die X und Y Position des Robis könnte in einer "höheren" Auflösung stattfinden (Bsp. mm). Es geht also nur darum "Kästchen" abzufahren.
Leider steigt der Speicherbedarf für den A*Pathfinding Algo (um gezielt den kürzesten Weg zwischen zwei bekannten Punkten ermitteln zu können) mit größerer MAP erheblich! Da für jedes Feld im Schlimmsten Fall ein X,Y,I(Index zum Vorgänger), H und G gespeichert sein muss (F wird beispielsweise permanent neu berechnet um Speicher zu sparen).
Wird eine MAP mit 512 Bytes verwendet (64x64 Felder) so ergibt sich, sofern für X,Y,I, H und G NUR ein Byte verwendet wird ein maximaler Speicherbedarf von 4096Felder*5Bytes=20480Bytes.
Diese Zahl ist zum Glück nur im Extremfall notwendig. Genau genommen muss X und Y kein ganzes Byte breit sein: schließlich sind in diesem Beispiel nur 64 Positionen in X und Y Richtung zu addressieren.
Ich möchte hier, zumindest zu diesem Zeitpunkt, nicht weiter auf die technischen Details eingehen.
Was mich interessiert:
Hat jemand Lust an der Entwicklung mit zu wirken? 8-[
Grüße und Danke!