3D Map erstellen

Hey Leute

Ich bin nun endlich fertig mit meinem ,,Erkundungsroboter" (Fotos siehe Anhang), zur Steuerung ein Arduino UNO mit Motorshield, zwei Getriebemotoren und zum Kontrollieren über Funk ein Sparkfun Bluetooth Mate Gold. Ich habe eine Gehäuse aus Plexiglas gefertigt und außen zwei Ketten angebracht um auch einfache Stufen etc. hoch bzw. herunter zu fahren.
Nun möchte ich das wenn der Roboter in einen fremden Raum fährt, dass er dann automatisch eine 3D Map erstellt und diese vllt. auf einer Micro-SD Karte speichert. Wenn möglich soll der Roboter wenn der unbekannte Raum durch eine offene Tür mit einem anderen Raum verbunden ist auch in diesen fährt und auch von diesem ein 3D Bild erstellt. Das Endergebnis soll sein das wenn der Roboter in ein fremdes Haus gelassen wird, er autonom durch das Haus fährt und einen Grundriss von dem Haus erstellt und durch selbständiges herausfinden aus dem Haus die auf der SD-Karte gespeicherten Daten automatisch aus dem Haus herausfährt. Ich habe schon überlegt ob ich einen 360 Grad Laser Scanner nehmen sollte aber da dieser sehr teuer ist ( http://www.robotshop.com/eu/en/rplid...r-scanner.html (400€)) habe ich als Alternative überlegt ob man einfach einen ultraschall abstandssensor auf einen Servo setzen sollte, würde das ausreichen um ein 3D Modell zu erstellen?
Dann gibt es noch diese Sachen wie z.B. ,,Optical Flow Sensoren" ( http://www.amazon.de/Optical-APM2-52...al+Flow+Sensor ) oder diese Pixy CMUcam5 ( http://www.amazon.com/Pixy-CMUcam5-S.../dp/B00IUYUA80 ) können diese irgendwie hilfreich sein?

Danke schon mal im Voraus
ToastCrafterHD

Meinst Du wirklich eine 3D-Karte oder eine 2D-Karte?
Mit einem US Sensor auf einem Servo bekommt man "nur" eine 2D-Karte.
Bei Anordnung des Sensors rechtwinkelig zur Rotationsachse eine Schnitteben einer Kugel (Polarkoordinatensystem).
Bei nicht rechtwinkeliger Anordnung einen Kegel.
Mit einer Gimbal Anordnung von 2 Servos kann man eine komplette Kugel scannen.
Je nach Sensor muß man aber das Verhalten bei Überschreiten der maximalen Meßdistanz berücksichtigen.
Beim HC-SR04 zum Beispiel dauert eine Messung 20ms.
Bei Überschreitung der maximalen Meßdistanz steht das Echosignal allerdings 200ms an.
Wenn man also fest mit einem Zeitrahmen von 20ms pro Messung misst, hat man bei den nächsten 9 Messungen einen fehlerhaften Messwert.
Optical Flow liefert Bewegungsvektoren, also Geschwindigkeitsdaten.
Damit kann man die Eigenbewegung bzw. die Relativbewegung zu anderen bewegten Objekten und der nicht bewegten Landschaft ermitteln.
Also ein Odometriesensor.
https://de.wikipedia.org/wiki/Optischer_Fluss

Es muss eigendlich keine 3D Karte sein es soll nur so sein das der Roboter einen ungefähren Grundriss des Hauses hat und kein kompettes 3D Modell. Theoretisch würde es dann reichen den Us-Sensor mit einem Servo nur um 360 Grad zu drehen.

Mein aktuelles Konzept sind zwei HC-SR04 auf normalen Servos mit je 180° Stellbereich, in Fahrtrichtung links und rechts.
Bei normaler Gradeausfahrt schauen die beide nach vorne, 10° nach außen (für die Hindernisserkennung).
Bei Rundumblick fährt der eine auf 180° (nach hinten) und der andere auf 0° (nach vorne) und messen dann in 10° Schritten je einen Halbkreis.
Somit gibt es zwei Messungen die jeweils von beiden Sensoren durchgeführt werden und die man somit gegeneinander abgleichen kann (sofern der Roboter nicht so breit ist, das es einen spürbaren offset zwichen den Sensoren gibt).

Zitat:

---

Zitat von i_make_it

Mein aktuelles Konzept sind zwei HC-SR04 auf normalen Servos mit je 180° Stellbereich, in Fahrtrichtung links und rechts....

---

Mal interessehalber: Bekommst Du damit ein sauberes Mapping eines Grundrisses hin? (Wenn ja, mit welcher Auflösung?)

Momentan habe ich nur das Konzept und einen Arduino Nano an dem zwei HC-SR04 hängen und die ihre Daten an den seriellen Monitor senden.
Die Entfernungsauflösung ist in ein Zentimeter Schritten und die Reichweite ist knapp über 4 Meter.
Bei 10° seitlicher Auflösung und 4 Metern Entfernung kommt man auf eine seitliche Auflösung von fast 70 cm.
Allerdings hat man ja auch den Öffnungswinkel des Sensors der eine feinere Auflösung wie 10° unsinnig macht.

Wenn man eine gute Odometrie realisiert, ist aber auch damit SLAM möglich. Man kann dann ja für höhere Auflösung näher an Objekte heranfahren.

So um mal bei dem Beispiel HC-SR04 zu bleiben, hier mal 2 Links zu Unterlagen.
https://docs.google.com/document/d/1...t?pref=2&pli=1
Hier findet man auf Seite 3 die Angabe zum Öffnungswinkel von 30° und auf Seite 5 eine Grafik.
http://www.mikrocontroller.net/attac...hreibung_3.pdf
Hier sind noch ein paar Infos in Deutsch.
Bei einem Selbstbau eines US-Sensors kann man die Auflösung etwas verbessern, indem man den Öffnungswinkel des Empfängers verkleinert und ggf. durch mehrere Empfänger mit leicht unterschiedlichen Blickrichtungen eine vergleichende Messung durchführt.
Anhang 31295


Bei Sharp IR Sensoren erreicht man eine bessere seitliche Auflösung, aber dafür braucht man da dann 2 bis 3 Sensoren um vom Nahfeld bis zum Fernfeld alles abzudecken.
Anhang 31294
Achtung die Bezeichnungen der Modelle haben sich mittlerweile geändert.

Man kann einen optischen Sensor nach dem Triangulationssystem auch selbst bauen, das ist dann aber schon etwas Arbeit (grade beim genauen ausrichten) Und bei meinem Versuch war die Detektion ließ die Erkennung noch zu wünschen übrig.
Man braucht einen Laser mit Koliminatoroptik, einen Polarisationsfilter (Folie einer billig 3D-Brille) eine Zeilenlupe (gibt es immer wieder mal günstik aus Acryl in Billigmärkten) ggf. einen gewölbten Spiegel (selbst machen) und eine Sensorzeile von einem Flachbettscanner.

#

Zitat:

---

Zitat von i_make_it

Mein aktuelles Konzept sind zwei HC-SR04 auf normalen Servos mit je 180° Stellbereich, in Fahrtrichtung links und rechts.
Bei normaler Gradeausfahrt schauen die beide nach vorne, 10° nach außen (für die Hindernisserkennung).
Bei Rundumblick fährt der eine auf 180° (nach hinten) und der andere auf 0° (nach vorne) und messen dann in 10° Schritten je einen Halbkreis.
Somit gibt es zwei Messungen die jeweils von beiden Sensoren durchgeführt werden und die man somit gegeneinander abgleichen kann (sofern der Roboter nicht so breit ist, das es einen spürbaren offset zwichen den Sensoren gibt).

---

Ok gehe wir davon aus ich bau diese Apparatur auf meinen Roboter, dann braucht es ja noch eine Programm das wenn der Roboter in einen Raum fährt, sieht das er geradeaus weiterfahren kann. Er stellt sich hin scannt einmal den Raum aus seiner jetzigen Sicht, fährt dann weiter sieht das er jetzt auch meinetwegen um eine Ecke gucken kann und stellt sich dort hin und scannt erneut womit er auch den alten schon vorher gescannten Teil aus seiner jetzigen Sicht aktualisiert bzw. verfeinert. Jetzt dreht er sich einmal im Kreis und sieht z.B. das dort eine offene Tür ist, er fährt durch diese Tür und fängt auch an diesen Raum zu scannen. Währe das so als Programm realisierbar ?

ToastCrafterHD

Das ist realisierbar, ist sogar bei schnellen Sensoren bei der Fahrt realisierbar.
Mann muß sich aber mit den Fehlern auseinadersetzen, die die erstellte Karte verzerren können.
Das ganze Thema nennt man SLAM.
https://de.wikipedia.org/wiki/Simult...on_and_Mapping

So, ich habe mal etwas auf der Festplatte gewühlt.
Eine Liste von Sensoren die ich mir im Laufe der Zeit mal für SLAM zusammengestellt habe.

Sensoren
============
Odometrie
-Quadratur/CPC Shaft encoder
-optischer Fluß (optical flow sensor)

Kollision
-Mikroschalter
-Kapazitive Kontaktfolie (Leitsilikon: Elastosil)

Nahbereich 0mm - 30mm
-Induktiver Näherungssensor
-Kapazitiver Näherungssensor
-Reflexlichtschranke mit/ohne Signallaufzeitauswertung

Mittelbereich 20mm - 800mm
-Reflexlichtschranke mit Signallaufzeitauswertung (TOF)
-Reflexlichtschranke mit Triangulation (SHARP)
-Puls Ultraschall Echolot
-FMCW Ultraschall echolot
-Puls RADAR
-FMCW RADAR
-Lichtschnitt mit Linienlaser und Kamera
-Stereo Kamera (Triangulation)
--optischer Fluß (Odometrie)

Fehrnbereich 400mm - 10000mm
-Reflexlichtschranke mit Signallaufzeitauswertung (TOF)
-Puls Ultraschall Echolot
-FMCW Ultraschall echolot
-Puls RADAR
-FMCW RADAR
-Lichtschnitt mit Linienlaser und Kamera
-Stereo Kamera (Triangulation)
-PDM/TOF Kamera

Beim SLAM geht der Roboter beim Einschalten erst mal davon aus das sein momentaner Standort der Koordinatennullpunkt auf einer unbekannten Karte ist.
Sinnvollerweise ist das Koordinatensystem der Karte karthesisch.
Die Sensor Daten kommen allerdings als Polarkoordinaten (mit dem Roboter als Ursprung des polaren Koordinatensystems) rein.

Das Karthesische Koordinatensystem kann man entweder beliebig ausrichten oder auch nach Wänden oder z.B. Kompass ausrichten.
Der Roboter erstellt am Startpunkt erst mal eine Karte und tastet sich dann vor.
Sind schon Karten im Speicher, kann er anhand von Landmarken versuchen ob sich seine Position auf einer der schon vorhandenen Karten befindet und ab da dann immer abgleichen ob das zutrifft oder nur eine lokale Übereinstimmung vorhanden war.

Ein Lösungsansatz:
LidarLite als 360° Rundumsensor, ca. 13ms/ Messung, 128 Messungen/Umdrehung.

Anhang 31296
Links mit/rechts ohne Slam, Auflösung 10cm/Kästchen, gefahrene Strecke ca. 85m auf einem Terrain von etwa 10x10m Grundfläche (der typische Kellerflur).
Links in schwarz von Odometrie gemessene Position/Weg, in blau durch Slam korrigiert.

Der Slam läuft übrigens nicht auf dem Controller, sondern auf einem mitgeführten Tablet.

Aber ich habe keine Ahnung, ob ich da mit Kanonen auf Spatzen schieße. Kommt hier jemand mit "weniger" Sensorik auf gleichwertige Ergebnisse?

Was meinst Du mit "weniger" Sensorik?
Das ist ja ein einziger Sensor. Mit null Sensoren geht es nicht.
Oder meinst Du preislich günstiger, da der ja um die 115US$ kostet?
Natürlich kann ein Roboter mit Radencodern und Bumpern das ebenfalls. (Wenn kein Schlupf auftritt)
Allerdings dauert das dann entsprechend lange.

Es Kommt halt drauf an was an Präzision und an Geschwindigkeit gefordert ist.
Das nächst teurere wäre dann ein RADAR wie das "MIT IAP 2011 Laptop Based Radar" das dann auch mehr als 40 Meter Reichweite hat.
Da kosten die Teile aber auch einiges mehr.

http://ocw.mit.edu/resources/res-ll-...11_proj_in.pdf

Auf Seite 16 liegen die bei 360US$.
Und die Auswertung ist "etwas" anspruchsvoller.

Zitat:

---

Zitat von i_make_it

Was meinst Du mit "weniger" Sensorik?
Das ist ja ein einziger Sensor. Mit null Sensoren geht es nicht.
Oder meinst Du preislich günstiger, da der ja um die 115US$ kostet?

---

Hmmm,

mit der Sensorik und der korrekten Odometrie ist's so 'ne Sache. Meine bisherigen Erfahrungen mit dem SLAM-Gedöns: Es verbessert die Lokalisierung und damit die Maperstellung, es heilt sie allerdings nicht. Auch bei mir zerfasert die Map schlagartig, wenn eine Bewegung des Roboters außerhalb der vorgegebenen Toleranzen landet und irgendwo ist Schluss, wenn der Sensor mal spinnt. Ganz ohne Annahmen geht's nun mal nicht.

Daher die Frage: wo ist nach unten hin Schluss? Wo geht's auch mit vieeeel Rechenaufwand nicht weiter?

Kannst Du z.B. mit Deinem preislich durchaus attraktiven Sensorsetup die Aufgabenstellung des TE bewältigen? Ich definier das mal als Otto-Normal-Wohnung 100...150qm u.a. mit großem Wohnzimmer, ggf. einem Kreisdurchbruch (ClosedLoop) und ja, es liegt natürlich Teppich und auch der tödliche Langhaar-Flokati darf den Boden irgendwo mal zieren. Die Aufgabe wäre dann: Reinfahren, rauskommen, Map haben!

Ganz ehrlich? Ich kann's nicht! So schön das Bild oben aussieht, in der Simulation zickt mein Slam immer noch beim ClosedLoop-Problem, meine Nahfeldsensorik ist immer noch Bockmist, der Pathfinder bricht teilweise an Engpässen ab und nach zwei Jahren Kellerbastelei bin ich noch nicht mal auf dem Niveau der Funktion eines Miele-Robotersaugers, hab aber den Preis desselbigen im Budget (inbegriffen aller Fehlschläge) um ein mehrfaches überschritten.

Was soll's

Der Weg ist das Ziel.:cool:

Ich selbst bin in der Praxis noch nicht so weit. Auch wenn ich jetzt in einer Wohnung lebe wo ich mal loslegen könnte.
Bei einem Durchgang mit begrenzter Sicht zum messen, halte ich es wie Vermessungsingenieure. Genau im Durchgang zwei Messpunkte mit denen man sich möglichst gut an den schon vermessenen Landmarken ausrichten kann und neue Landmarken in Relation dazu einmessen kann.
Da man dabei dann Anhält ist das eigentlich kein SLAM, da man ja nicht simultan kartiert und sich lokalisiert, sondern sich erst lokalisiert und dann kartiert.

So einmal zusammengefasst, ich nehmen zwei Us-Module, diese setze ich auf zwei 180 Grad Servos welche beide jeweils nach rechts und nach links gerichtet sind. Dann installiere ich noch einen ,,Optischen-Fluss-Sensor", damit ich weis wo im Raum ich bin. Der Roboter wird dann so programmiert das er selber sieht wo er noch nicht wahr und wo er hin muss. Später lege ich den gefahrenen Weg und die Karte aus Ultraschallmesspunkten übereinander und habe eine ungefähre Karte von meinem Objekt. Sollte das funktionieren kann man anhand der Karte später den Roboter verhältnismäßig genau steuern.

ToastCrafterHD

Nicht ganz.
Anhang 31301
Beim Gradeausfahren schauen beide US-Sensoren zur Kollisionsvermeidung nach vorne oder je 10°-20° nach außen damit sie sich nicht gegenseitig stören.
Beim Kartieren wird dann z.B. der rechte um 180° nach hinten gedreht und dann fahren beide parallel in 10° Schritten gegen den Uhrzeigersinn die 180° ab.
So dauert das Kartieren nur halb so lange und beide Sensoren schauen nicht gleichzeitig in die selbe Richtung, was Störungen vermeidet.

Ein optical flow Sensor verrät dir nicht wo Du bist sondern wie Du dich bewegst. Das Bild enthällt nur Bewegungsvektoren.
Du kannst also feststellen wie schnell du bist und ob alle Vektoren gleich schnell sind (Gradeausfahrt) oder eine Seite langsamer ist (Kurvenfahrt/Drehung).
Oder ob es Vektoren gibt die nicht zur Eigenbewegung passen (bewegtes Fremdobjekt).

Erst beides zusammen sagt Dir wo du (relativ zu den kartierten Landmarken) bist.

Würden die Us-Sensoren es auch bei der Fahrt schaffen die Map aufzuzeichnen wenn ich für die Kollisionsvermeidung 4 weitere Us bzw. Infrarot Sensoren an allen vier Seiten anbringen würde, oder sind die Ultraschallsensoren zu langsam mit 50 Messungen die Sekunde? Oder könnte man wenn man 4 Sensoren nur für die Kollisionsvermeidung hat auch die zwei Us-Sensoren oben auf einen Servo setzten (Anhang) ?

ich glaube die US-sensoren sind schon schnell genug, sie haben aber einen relativ großen abstrahlwinkel, es könnte evtl. echos geben, die die sensoren untereinander stören. Stört Dich der fehler durch die fahrt nicht?

Es soll wirklich nur ein ungefährer Grundriss des Raumes sein also nicht das ich exakt sehen kann das die eine Kante 210cm oder 211,5 cm lang ist.

Die fertigen US-Module wie der HC-SR04 arbeiten beim selben Modell verständlicherweise mit der selben Frequenz und selben Modulierung.
Folglich gibt es da kein, viele Sensoren helfen viel.
Stell dir vor du nimmst eine Aufname bei der Du Hallo" rufst und hast 10 Player mit denen Du die Aufnahme fast zeitgleich abspielst und auf das Echo lauscht.
Du wirst mit ziemlicher Sicherheit nicht in der Lage sein festzustellen welches Echo von welchem Player stammt.
Das selbe Problem werden die US-Module bekommen.
Wenn man mehrere Sender paralle ansteuert und somit ein Signal zeitgleich, rundum ausstrahlt und dann noch mehrere Empfänger rundum anordnet, die durch Maskierung eine Richtcharakteristik haben, kann man das hinbekommen.
Um mehrfach Echos auseinander halten zu können, braucht man US-Kapseln, die durchstimmbar sind (die normalen haben eine feste Resonanzfrequenz).
Damit kann man dann ein FMCW (frequency modulated continuous wafe) System aufbauen.

Zu dem Bild mit einem Servo und 2 Sensoren.
Das geht, aber ich will halt bewusst auch mit beiden Sensoren gleichzeitig nach vorne oder hinten schauen können.
Damit kann ich bei der Kollisionsvermeidung unterscheiden ob ein Hinderniss links oder rechts ist. und so direkt entscheiden ob ich nach links oder rechts ausweiche.

Ok, ich bau mal die Sachen in den nächsten Tagen an meinen Roboter und gucke mal was herauskommt.

ToastCrafterHD

Darf man fragen woher du dein Fahrgestell hast?

Gruß
Torsten

Zitat:

---

Zitat von inka

wessen fahrgestell meinst du?

---

Ich meinte die Bilder im ersten Post also vom Thema Ersteller. Aber dein Fahrgestell sieht auch nicht übel aus... ;-)

Ich bin halt auf der Suche nach einen Ketten-Fahrgestell. Die meisten sind entweder zu klein oder viel zu teuer.

Gruß
Torsten

Zitat:

---

Zitat von toto1975

Darf man fragen woher du dein Fahrgestell hast?

Gruß
Torsten

---

Das Fahrgestell ist komplett selber gebaut, es besteht aus mit der Stichsäge gesägtem Plexiglas. Das Plexiglas ist mit Spezialkleber geklebt und die Achsen für die Ketten sind mit Lagerblöcken gelagert. Die Lagerblöcken, Ketten und die Kettenräder kommen von dem Anbieter Robotshop ( http://www.robotshop.com/eu/en/ )
Ketten: http://www.robotshop.com/eu/en/lynxm...ck-trk-02.html
Kettenräder: http://www.robotshop.com/eu/en/lynxm...t-9-tooth.html
Lagerblöcke: http://www.robotshop.com/eu/en/lynxm...ock-pb-02.html
Hubs zur Befestigung der Kettenräder auf der Welle: http://www.robotshop.com/eu/en/lynxm...ersal-hub.html
Das Plexiglas habe ich von einem der das Material verarbeitet und der bei uns in der Nähe sitzt, dass schöne ist das die Reste von ca. 1,5 m x 80 cm kostenlos verschenken, da sonst ein Quadratmeter von industriellen Plexiglas ca. 60€ kostet.

Im Anhang einmal die Lagerung der Wellen und ein Bild der Ketten.


ToastCrafterHD

super gut gemacht! Gratulation!

Vielen Dank @HaWe ,es hat jede Menge Zeit zur Planung und zum Bau gebraucht.

ToastCrafterHD

Sieht echt super aus... ;-) Ich möchte nicht wissen wie viele Stunden du da rein investiert hast.

Hast du eventuell auch noch einen Link zu deinen Motoren?

Viele Grüße
Torsten

Die Motoren kommen von Conrad ( www.conrad.de ) und sie gibt es einmal in der 12V Ausführung:Hochleistungsgetriebemotor 12 V Modelcraft RB350050-22723R 50:1 ( Bestellnummer:233132 - 62 ) und einmal in der 6V Ausführung: Hochleistungsgetriebemotor 6 V Modelcraft RB350050-22H22R 50:1 ( Bestellnummer: 233130 - 62 ).
Es sind die stärksten Motor die es in dieser Preisklasse zu finden gibt, bei ,,Voll-Power" kann man sie nicht mit der Hand anhalten.
Die Kegelräder für die Übersetztung auf die Welle kommen auch noch von Robotshop mit einer 1:1 Übersetztung.

ToastCrafterHD

irgendwie stimmen die links nicht

Tolles Modell, herzllichen Glückwunsch!!

Danke für die Bezugsquellen

vG

fredyxx

So, ich wollte noch mal schreiben was ich nach einer längeren Pause gemacht habe. Vor ca.2 Wochen habe ich mir eine Microsoft Kinect 360 Kamera gekauft, habe auf Ubuntu ROS Kinetic, Rtabmap und den freenect Treiber installiert. Angefangen habe ich in Rtabmap mit einer 3D Map und dann einer 2D Map ( Abb. 1) wobei ich ein bisschen mit den Occupancy gridmap Einstellungen rumprobiert habe. Was ich aber noch nicht hinbekommen und auch noch nicht weiß wo ich anfangen soll ist, wie ich mit diese 2D Karte meinen auf Arduino basierenden Roboter ansteuern soll. Mein Ziel ist es, dass ich die Kinect mit meinem Raspberry Pi auf den Roboter montiere und das dieser selbstständig in der Gegend herumfährt und gleichzeitig eine 2D Karte erstellt.

TCHD

benutzt du eigentlich Encodermotoren?

Zitat:

---

Zitat von HaWe

benutzt du eigentlich Encodermotoren?

---

Nein, ich habe nur normale Getriebemotoren. Ich habe schon überlegt beide Motoren mit Encodern auszustatten. Als Shield würde ich das hier benutzen: http://www.robogaia.com/3-axis-encod...no-shield.html
und als Encoder würde ich diese benutzen: http://usdigital.com/products/encode...al/modules/EM1
Oder würde es auch funktionieren mit dieser Gabellichtschranke: http://www.eibtron.com/epages/eibtro...FUeeGwodbW8PjQ ?

nun, mit Grid-Karten etc kenne ich mich nicht aus, aber was du ja wohl machen willst, ist ein map-and-explore-robot, oder SLAM-robot (Simultaneous Localization And Mapping ), oder täusche ich mich?
Dann musst du ja die augenblicke Position im Raum mit Sensoren irgendwie messen, bezogen auf was auch immer - entweder IR- oder Funk-Baken, Transponder, Referenz-Linien auf dem Boden, Farbmarkierungen an Wänden, oder Magnetkompass, GPS, oder eben auch interne Referenzen, wie. z.B. Odometriedaten. Letztere sind zwar manchmal, ohne Slip und ohne Drift, sehr aussagekräftig, manchmal, gerade bei Kettenfahrzeugen, aber auch sehr ungenau - immerhin, es sind verwertbare Daten (gleiches gilt in anderen Bereichen auch für Kompass und GPS).
Was genau ist dein Sensormodell aus verschiedenen Sensoren, die (nach Fusion) deine Position berechnen sollen?

Ich dachte bisher, dass diese Aufgabe von der Kinect Kamera übernommen wird, da diese sich aus dem Aktuellen Bild Referenspunkte heraussucht und wenn diese sich bewegen die Bewegung registriert. Wenn er sich also einmal um die eigene Achse dreht, müsste er schon eine ziemlich exakte Position haben. Außerdem hat die Kinect eine Genauigkeit bei 2m Abstand von 3mm.

ok, da muss ich passen
- ich habe bisher nur mit Odometrie (per Encodermotoren), Kompass, Gyroskop und Accelerometer gearbeitet. In diesen Fällen war Odometrie (mit Encodermotoren) sehr hilfreich, und andere Sensoren wurden mit Kalman- und anderen statistischen und stochastischen Filtern fusioniert, das machte Sinn.
http://www.mindstormsforum.de/viewtopic.php?f=70&t=6746

Wäre es möglich statt Encodern auch einen Optical Flow Sensor(z.B. https://www.amazon.de/gp/product/B014BJLCU2 ) zu benutzen, da dieser etwas günstiger ist ? Ist es mit dem Leichter oder Schwerer zu realisieren als mit Encodern ?

Sind das Maussensoren mit Optik?
Die müssten dann ja nach unten gerichtet werden.

Zitat:

---

Zitat von Holomino

Sind das Maussensoren mit Optik?

---

Ja, dass sind eigendlich nur hochauflösende Maussensoren mit einer höheren Reichweite.

Gefunden hier:

Known issues
•The sensor only works in well lit environments
•A fixed-focus lens is used meaning it cannot focus on objects closer than 30cm (1 foot).
•Rotating the sensor will confuse the sensor


Ist das das, was Du suchst?

Zitat:

---

Zitat von Holomino

Known issues
•The sensor only works in well lit environments
•A fixed-focus lens is used meaning it cannot focus on objects closer than 30cm (1 foot).
•Rotating the sensor will confuse the sensor

---

Das habe ich nicht gesehen, dann wird es wohl bei den Encodern bleiben müssen.