Druckbare Version
Heute habe ich mal meine Papp-"Arena" mit Silikon gespachtelt. Da funzt alles gleich gaaanz anders und ich brauche erstmal keine anderen Wheels zu kaufen. Ob ich die 60 EUR ausgebe, mache ich von meinen Programmiererfolgen abhängig. Sonst wird das Thema Omni auf unbestimmt verschoben, und die Module anderweitig verwendet.
Beim Spachteln kam mir die Idee, aus der großen Pappe wirklich eine Arena zu machen. Sie bekommt jetzt eine Bande, und der Bot seine elektronische(n) Stoßstange(n).
Sigo
@sigo und Roberto,
hier ist eine Literaturstelle, die für Navigationsfragen hilfreich sein könnte (wenn auch ein bisschen theoretisch).
http://epubl.ltu.se/1653-0187/2007/075/index.html
Besonders die Seiten 29ff sind in Hinblick auf die Navigation interessant. Ausserdem wird auch das Kalmanfilter ganz gut erklärt.
Wenn's um den Einsatz zweckentfremdeter Optischer Mäuse geht, dann ist das hier
https://txspace.tamu.edu/bitstream/h...pdf?sequence=1
interessant, weil mit praktischen Experimenten und Quellcode. Wär' doch schade, Sigo, wenn Dein schöner Bot nur im Käfig herumtigern dürfte.
mare_crisium
Mare_crisium,
danke für die beiden sehr interessanten Links, ich habe schon eine gute Stunde geschmökert. Und gleich haben sich ein paar interessante Ideen gemeldet, die jetzt genauer durchdacht werden müssen.
Sigo
Unten noch 3 Fotos von heute:
Bild hier
Bild hier
Bild hier
Das Dreieck hat eine Solllänge von 300mm, ist ist irgendwas bei 306mm.
Das kann kann man ja noch skalieren. Offenbar gibt es auch noch einen systematischen Fehler, da die Drift in eine bestimmte Richtung geht. Mal sehen, ob sich das noch verbessern lässt..
Gripp hat die Arena jetzt definitiv genug.
Sigo
Sigo,
freut mich, dass Du die Texte auch so gut fandest :-). In Hinblick auf die Navigation berate ich Dich gerne. - Muss mich ja noch für Deine Unterstützung beim CNY 70 revanchieren...
Das zweite Deiner Bilder zeigt ja einen sehr interessanten Schlenker. -Sieht aus, als habe einer der Motoren eine etwas andere Kennlinie und fährt deshalb verzögert an. Oder fährst Du sie drehzahlgeregelt hoch?
mare_crisium
Hallo Mare_crisium,
alle Antriebe sind dgtital drehzahl- und lagegeregelt.
Sofern alle Inkrementalgeber einwandfrei funktionieren, sollte der Weg eigentlich stimmen. Ich muss nochmal kontrollieren, ob auch die Regelparameter in allen Endstufen gleich eingestellt sind. Vielleicht "federt" eine zu sehr durch.
Mir ist jedoch aufgefallen, dass die Räder nicht wirklich perfekt mit der jeweiligen 120°-Achse fluchten.; 1-3° könnte der Fehler schon betragen.
Ich werde versuchen, sie noch etwas besser zu justieren und den Rest per Software zu kompensieren.
Weiterhin habe ich schon die geringe Gewichtsdifferenz auf Störquelle ausgemacht. Wenn ich gegenüber der Platinen ein Gegengewicht anbringe, wird es merklich besser. Das könnte in der Beschleunigungsphase einen Einfluss haben; auf den Schlupf und auch auf die Regelabweichungen.
Evtl. kehre ich doch zu dem ursprünglich geplanten streng symmetrischen Aufbau zurück und baue die 3 Endstufen auch jeweils auf 120°. Die Ursprüngliche Idee, die Endstufen gleich mit an die Radmodule zu bauen, habe ich verworfen, weil sie doch nicht klein genug geworden waren. Evtl. ließe sich das aber mit SMD noch machen.
Navigation:
Ich denke für den Anfang (ohne Sensoren) komme ich mit den Ergebnissen von heute schon einigermaßen klar.
Wenn man die Hauptfahrrichtung so wählt, dass der Bot wie ein Differentialbot mit 2 Antrieben fährt (3. Rad rollt quer), könnte ich z.B. das 3. Rad in den Leerlauf schalten und mit dem Inkrementalgeber den Rotationswinkelfehler messen, und ausregeln. Wenn dann eine Verdrehung durch unterschiedlichen VOrtrieb auftritt, wird das 3. Rad verdreht und man kann die Abweichung wieder zu Null regeln. Das könnte den Geradeauslauf verbessern.
Ansonsten wird es eh nicht ohne externe Positionsmarken (Baken) gehen.
Der Omnibot ist ja eh nicht für den rauhen Einsatz geeignet. Ich denke, das Maximum wird unsere Terrasse werden. Ein definiertes Terrain.
Der könnte man prima rundum eine LED-Beleuchtung verpassen, der man nicht ansieht, dass sie in Wirklichkeit Positions-Codes sendet.. *gg*.
Insgesamt denke ich schon, dass die Omniwheels prinzipiell Schwächen haben, da die Querrollen einfach zu klein sind. Evtl. baue ich mir noch 2 Radmodule und einen Differential-Bot. (ala Asuro & Co.)
Sigo,
ja, wir müssen wahrscheinlich unser ganzes Amateurleben lang mit grösseren Fertigungstoleranzen leben. Jedenfalls solange wir nicht über das Geschick und einen Maschinenpark wie Klingdon77 verfügen :-). Ich glaube aber, dass man das durch ein ausgefeiltes und gut programmiertes Regelkonzept weitgehend ausgleichen kann.
Um einen Schlenker in dieser Grösse zu erzeugen, genügt schon die endliche Genauigkeit der Graycode-Scheibe (wenn sie direkt am Rad montiert ist) bzw. das Getriebespiel (wenn die Scheibe zwischen Motor und Getriebe sitzt).
Ich glaube, dass Du eine starke Verbesserung erreichst, wenn du als Istwert-Geber für den Ortsregler einen Maussensor verwendest, der direkt die Ist-Verschiebungen über Grund erfasst. Weil ich an einem ähnlichen Problem herumbastele, habe ich mir ein paar billige PS/2-Mäuse von P* besorgt. Jetzt bringe ich meinem ATmega8 das PS/2 Protokoll bei, damit er das Teil anzusteuern kann. Anschliessend werde ich versuchen, ihm mit Linsen von Astroversand eine "Brille" zu verpassen, damit er etwas weitsichtiger wird. Wenn Du Interesse hast, kann ich Dich über den Fortschritt auf dem Laufenden halten.
Navigation: Vielleicht kannst Du die Fähigkeit Deines Bots, ohne zu wenden in alle Richtungen fahren zu können, doch erhalten. Etwas kompliziert ist das Regelkonzept, weil es aus den Regelabweichungen (z.B Zieldistanz, Fahrtrichtung, Fahrtgeschwindigkeit) die Stellsignale für drei Motoren erzeugen muss. Das ist aber lösbar.
mare_crisium
Ich auch.Zitat:
Zitat von mare_crisium
Die Inkrementalgeber sind direkt am Motor montiert und haben über alles eine Auflösung von ca. 38.500 Inkr/m. Dahinter kommen natürlich Getriebe, Zahnriemen und auch das Seitenspiel der Omniwheels.,,,Zitat:
Um einen Schlenker in dieser Grösse zu erzeugen, genügt schon die endliche Genauigkeit der Graycode-Scheibe (wenn sie direkt am Rad montiert ist) bzw. das Getriebespiel (wenn die Scheibe zwischen Motor und Getriebe sitzt).
Super, halte mich bitte auf dem laufenden.Zitat:
Ich glaube, dass Du eine starke Verbesserung erreichst, wenn du als Istwert-Geber für den Ortsregler einen Maussensor verwendest, der direkt die Ist-Verschiebungen über Grund erfasst. Weil ich an einem ähnlichen Problem herumbastele, habe ich mir ein paar billige PS/2-Mäuse von P* besorgt. Jetzt bringe ich meinem ATmega8 das PS/2 Protokoll bei, damit er das Teil anzusteuern kann. Anschliessend werde ich versuchen, ihm mit Linsen von Astroversand eine "Brille" zu verpassen, damit er etwas weitsichtiger wird. Wenn Du Interesse hast, kann ich Dich über den Fortschritt auf dem Laufenden halten.
Ja, mit geeingenten Messwerte für die Korrektur, wäre das ja kein so großes Problem, da ich ja jetzt auch meine Zielwerte als Vektor hinterlege und dann die Komponenten für die Antriebe berechne. Natürlich kann man vorher den n+1. um den Fehler korrigieren, wenn man ihn denn kennt oder gut schätzen kann.Zitat:
Navigation: Vielleicht kannst Du die Fähigkeit Deines Bots, ohne zu wenden in alle Richtungen fahren zu können, doch erhalten. Etwas kompliziert ist das Regelkonzept, weil es aus den Regelabweichungen (z.B Zieldistanz, Fahrtrichtung, Fahrtgeschwindigkeit) die Stellsignale für drei Motoren erzeugen muss. Das ist aber lösbar.
mare_crisium
Sigo
Angeregt durch den WALL-E Thread von Hanno, habe ich mich entschieden, meinem Ring-O zunächst das Verfolgen (m)einer Person beizubringen. Dies wird das Herbstprojekt(chen) werden.
Ich werde hierzu auf meinem IR-Bumper aufsetzen, der weiter oben erwähnt wurde.
Materialbedarf:
8 - 16 IR-LEDs, 1-2 TSOP, 2 ATtiny2313 + ein wenig "drumherum"
Reichweite: ca. 4-10m
Energiebedarf
Sender: ca. 100mW
Empfänger: ca. 50mA
ggf. zusätzlich 1 Ultraschallsensor
Ring-O bekommt jetzt ein weniger mehr Prozessorleistung
:-b
Ein AVR32-UC3A1512-Modul, heut' bestellt:
http://shop.embedded-projects.net/pr...erplatine.html
Was mir an dem Modul neben der Rechnenleistung und der Sparsamkeit gefällt, ist, dass es reichlich Schnittstellen gibt.
Dieses Modul soll folgende Aufgaben erledigen:
Bahnsteuerung für die 3 Antriebsregler, div. Sensoren integrieren, sowie mit einem Host kommunizieren.
Dieser kann sowohl on Board des Robots sein (unixsystem), als auch ggf. über Funk angebunden sein.
Am Anfang wird die Einarbeitung / Auffrischung in C sowie diese neue Prozessorarchitektur stehen.
Sigo