So! jetzt hab ich erstmal ein paar Demo-Scans gemacht.
In der Grafik oben sieht man die grafische Auswertung davon.
Blau sind die Punkte der ersten Messung
Rot sind die Punkte der zweiten Messung (um ca. 90° gedreht und ca. 5 cm verschoben)
Grün sind die roten Punkte, gedreht um die 268,2° also die "drehkompensierten" Punkte
Die Balkengrafiken stellen die Messwerte, "so wie sie im Speicher liegen" dar, also langer Balken = große Entfernung, der Reihe nach, bei "0°" beginnend.
Ganz unten sieht man das "Korrelationsergebnis" Der Algorithmus meint, das das Bild um 268,2° = 360-(90° + 1 Schritt) gedreht wurde, also ist das Ergebnis "verkehrt herum" gemessen...
Egal. Was mich aber sehr freut ist, dass die Verschiebung um 5cm praktisch keine Auswirkungen auf die Messung hat, die 1,8° Abweichung kann ich auch beim Verschieben verzittert haben...
Die Auswertung dauert auf dem ATmega8 etwa eine Sekunde, ohne jede Optimierung. Wenn man die zulässige Drehung auf +-45° beschränken würde und die Rechnung optimieren würde (Assembler statt C ...)
müsste das locker in 200 ms erledigt sein.
Da dauert ja das Scannen doch wesentlich länger
Hallo
Das sieht ja gut aus! Und läuft angenehm schnell. 1s ist im Vergleich zum Scannen vernachlässigbar.
Sind das echte Sensordaten oder simulierte?
Ich schätze, dass das Ergebnis für grössere Translationen/Rotationen/Kombinationen von beidem etwas mieser ausfallen könnte. Kannst Du das ev. mal testen?
Ich schätze, das nächste Zeil dürfte sein, auch die Translation zu berechnen (?)
Darf man mal einen Blick auf den Code werfen?
mfg
Fritzli
Das sind echte Sensordaten (JUCHUUU) weil ich es nicht hinbekommen habe gute Sensordaten zu simulieren
letztendlich war es halt einfacher gleich zu messen
Ja vermutlich wird das Ergebnis für größere Abweichungen deutlich schlechter.
Welchen Code möchtest du denn haben? (Ist mir noch etwas peinlich alles zu posten, das ist so wirr zusammenprogrammiert und ohne jede Struktur...)
Wenn das ganze volkommen ist, veröffentliche ich den Code, mit Fotos, Bauanleitung etc...
Der Code für die Korrelation ist folgender:Code:lcd_clear(); lcd_print_string("Korrelation läuft"); uint8_t w=0; uint32_t max=0; for (uint8_t i=0; i<200;i++) { uint32_t sum=0; for(uint8_t j=0;j<200;j++) { uint16_t dj = j+i; if (dj>=200)dj -=200; sum+=messungenA[j]*messungenB[dj]; } if (max < sum) { max=sum; w=i; } } lcd_clear(); lcd_print_string("Drehung um "); lcd_print_uint8(w); lcd_print_string(" Schritte");
Merci, mehr wollte ich auch nicht haben.
Ein paar Fragen zum uC:
- wie schnell wird der getaktet?
- hat das Ding nen Hardware-Multiplizierer?
mfg
Fritzli
Unter vernünftigen Bedingungen(*) beeinflusst die Verschiebung die Ergebnise sehr wenig.
Eine Verschiebung um ca. 12 cm bringt eine Ungenauigkeit von 2-3 Schritten = 3,6° bis 4,2° mit sich, ich finde das ist tolerabel. Schließlich ist die Auflösung des Sensors eh nur 1 Schritt = 1,8° ...
Die Genauigkeit könnte man nun weiter steigern, wenn man nachher beim X-Y-Korrelieren auch noch 5 Winkelschritte einbeziehen würde.
____
(*) Vernünftige Bedingungen sind: Die Hindernisse sind weiter als 12 cm entfernt und werden durch die Verschiebung nicht (oder nur geringfügig) verdeckt.
Ich meine, er läuft im Moment auf 1MHz, interner Oszillator.
irgendwann bohre ich ihn mal auf 8MHz auf... bislang hab ich mich nicht getraut. Eigentlich wollte ich ihn ja auf externer Quarz 4MHz proggen, komischerweise ist stattdessen interner Oszillator 1MHz draus geworden, so wie es aussieht muss man gerade das invertierte eingeben...
Hardware-Multiplizierer? Du meinst ob er in einem Takt-Schritt multiplizieren kann? Ich glaube Ja, denn es gibt den Assemblerbefehl MUL etc. und nirgendwo steht, dass der länger braucht als andere Befehle.
So: Neuester Stand.
Nachdem mir gerade aufgefallen ist, dass ich Trottel in meinem Auswertungsprogramm ein "(1/2)" vergessen hab, und deswegen die ganze Korrelation nicht viel bringen konnte (alle Winkel falsch...)
... hab ich das ausgebügelt und nun ein paar Messungen gemacht.
Wie genau das ganze wirklich ist, ist ein bisschen schlecht abzuschätzen, aber so wie es aussieht scheint sich die Messungenauigkeit doch wieder im cm-Bereich abzuspielen.
Blöd ist noch, dass schon mein Notebook ein, zwei Minuten an der Korrelation rechnet. Aber noch ist auch nichts optimiert. Jetzt wo das Prinzip funktioniert werde ich mich an die Optimierungen wagen.
Jedenfalls ein nettes Bild:
Blau sind wieder die Punkte der 1. Messung
Rot die der 2. Messung
Schwarz die Roten Punkte um die ermittelte Verschiebung verschoben, also die "korrigierten" Punkte
1 Kasten entspricht etwa 1 cm,
das Programm behauptet die Verschiebung wären -4 Kästen in Y-Richtung
Könnte etwa hinkommen, ich hab das ganze um ca. 5 cm (Augemaß) in diese Richtung verschoben.
Die türkisen Linien sind die Objekte, deren Punkte ich zuordnen konnte...
Hi,
ich hab auch sowas programmiert. Ich habe einen Sharp GP2D12 auf einem Servo sitzen und messe nach jedem schritt (insgesamt 180 grad, da sind bei mir 230 schritte). Dabei brauche ich insgesamt ca. 16 Sekunden, viel schneller dürfte es laut Datenblatt des Sensors auch nicht gehen, habe aber noch Optimierungsideen, die es etwa auf 14 Sek. drücken könnten.
In der ersten Version die jetzt läuft speichere ich die Punkte als Vektoren ab und es können immer mehr werden, da der Scanner dauernd läuft (s. Ansicht links). Im der rechten Ansicht habe ich ein Raster aufgesetzt und jedem feld eine Wertigkeit anhand der enthaltenen Punkte gegeben (schwarz=viele punkt im feld). So kann ich jetzt schon sehr gut Wände etc. erkennen, die Einstellung der Wertigkeit ist dabei Variabel. Der Vorteil ist, das ich mit den weiteren Sensoren am Roboter, die auch Ihre Daten mit einbringen, ab z.B. 3 Punkten im Feld, sicher von einem Objekt ausgehen kann. Die Rastergröße ist auch variabel einstellbar und die Ansichten können mit dem Schieber in der Mitte auch gezoomt werden. Sollte die Ansicht größer werden, erscheinen auch Scrollbalken.
Da ich dieses Semester an der Uni auch an dem dortigen Roboter mit festen GP2D12 Sensoren (glaub es waren 17) ein Ähnliches Projekt entwickelt habe, ist eine grobe Navigation zwar mit den Vektoren möglich (addition der Vektoren->Hinderniswertigkeit in einer Richtung), aber um Objekte, wie Wände zu erkennen und on-the-fly Durchgänge zu finden, eignet sich das Raster sehr gut.
Im Moment (diese Nacht *g*) arbeite ich daran, das ich nicht nur die Vektorpunkte beachte sondern auch den Vektor vom Roboter zum Punkt, denn dort ist ja frei. Es wird dann also bei jedem Rasterfeld eine Anzahl Punkte (=belegt) + eine Anzahl schneidender Vektoren (=frei) geben, welches mehr hat, wird recht bekommen, so kann ich hoffentlich ein noch genaueres Bild der Umgebung erzeugen, bzw. besonders "unsaubere" Messungen rausfiltern.
P.S. Startpunkt des Roboters ist (0|0), alle Sensor Vektoren werden von der aktuellen Position des Roboters gespeichert, es ist also ein Scannen während dem Fahren möglich (noch nicht umgesetzt). Meine Position will ich dabei durch die Fahrdaten (fahre mit Schrittmotoren) + 2 Laserscannern (aus der Laserfunkmaus) gewinnen. Erste Tests lassen mich da zuversichtlich stimmen, eine gute Genauigkeit auf flachem Untergund zu bekommen.
wie kommst du darauf, dass 230 Schritte 16s benötigen? Im Datenblatt steht nur, dass die erste Messung etwas unter 50ms benötigt, wenn alle Messungen solange brauchen, brauchen 200 Schritte 10s - ist es das was du meinst?
Was für einen Controller verwendest du?
Wenn ich dich richtig verstehe, willst du nur erkennen ob Hindernisse im Weg sind und diesen aus dem Weg gehen?
Was um alles in der Welt ist eine Laserfunkmaus? Meinst du optische Mäuse? Wenn ja - wie genau sind die? (Meine war nicht sehr genau, daher hab ichs gelassen...)
das sind optische mäuse, aber neuerdings mit laser halt statt ir:
https://www.roboternetz.de/phpBB2/ze...ight=lasermaus
https://www.roboternetz.de/phpBB2/ze...ight=lasermaus
okay, du hast recht, ich warte ja auch nur 16ms auf die spannung, das datenblatt nennt ja 5ms (nach dem ersten). 16ms sind mit meinem board wohl die untere grenze. dazu kommt bei mir nochmal 52ms wartezeit, bis der servo den schritt gedreht hat, wobei ich dies nicht berechnet habe, sondern ich nur bei dieser wartezeit verwertbare ergebnisse bekomme (sonst fehler), warum dies so ist, weiss ich nicht (wird wohl aber eher an meinem board liegen, das diese zeit zum senden o.ä. braucht), macht also: 230 * (16+52) = 15,64 Sek.
ich will damit nicht nur aus dem weg gehen, sondern komplett kartographieren und anhand der karte dann zu bestimmten punkten fahren können. kernziel ist also die kartographie und daran auch die objekterkennung (bwsonders halt wände, stühle etc.)
Berechtigungen
Zitieren
Lesezeichen