Roboterbasis mit Mecanum Wheels

Moin!

Zum Jahresende finde ich wenigstens mal die Zeit, noch so diverse halbfertige Projekte zu bearbeiten, die ich noch in der Pipeline habe ... :-) Ein bißchen weitergekommen bin ich in den letzten Tagen mit folgendem:

Neben den Allseitenrädern, mit denen ich bisher schon ein wenig experimentiert habe, gibt es ja noch die sog. Mecanum Wheels. Ich habe mir kürzlich einen Satz 100 mm Mecanum Wheels direkt vom chinesischen Hersteller nexusrobot besorgt, um auch diesen Radtyp mal praktisch kennenzulernen. Die Räder machen einen sehr guten Eindruck.

Anhang 29536 Anhang 29537

Ich habe Adapternaben zum Verbinden der Räder mit vier Getriebemotoren, die ich noch rumliegen hatte, angefertig:

Anhang 29538 Anhang 29539 Anhang 29540

Die Motoren mit den Rädern wurden ihrerseits an einer einfachen Rahmenkonstruktion aus Aluminium-Strangprofilen befestigt. Somit war auf ziemlich simple Art eine mobile Basis mit Mecanum Wheels schnell fertiggestellt:

Anhang 29541 Anhang 29542 Anhang 29543

Der nächste Schritt besteht nun darin, die Motorachsen mit Drehencodern auszustatten und geeignete Motortreiber aufzubauen, um die erforderliche Drehzahlregelung für die vier Achsen umzusetzen.

Auf meiner Homepage gibt's noch ein paar Bilder mehr.

Fortsetzung folgt ... :-)

Gruß
Malte

Mal ein kurzes Update ...

Ich habe mittlerweile die Elektronik für die Getriebemotoren fertig. Jeder Motor bekommt eine Platine mit eigenem mega168. Die AVRs werden als I2C Slaves von dem übergeordneten Master-Controller angesprochen, optional ggf. über einen PCA9600. Ein AS5048A (magnetischer Drehencoder) misst die Stellung des Motorabtriebs. Das klappt bei dem Motor sehr gut, weil der Abtrieb auf der Rückseite des Getriebekastens rausguckt. Dort befindet sich der Magnet für den Encoder, die Platine mit dem Encoder und dem Rest der Elektronik ist über Sechskantbolzen in den Befestigungslöchern der Getrieberückwand verschraubt. Dadurch ist die Platine genau ausgerichtet. Motortreiber ist ein - eventuell etwas unterdimensionierter - DRV8801. Der lokale AVR wird dann später auf dieser Grundlage eine Drehzahlregelung für das jeweilige Rad durchführen. Die Regelung zu implementieren ist jetzt der nächste Schritt. Hier ein paar Bilder:

Anhang 29821 Anhang 29822 Anhang 29823
Anhang 29824 Anhang 29825

Fortsetzung folgt!

Gruß
Malte

Mich wunderts, dass das hier keiner kommentiert.
Ich finde, du hast da eine wirklich elegante Lösung aufgebaut, schön kompakt.
Ist der Controller eigentlich nur da, um Daten durchzureichen (PWM, Sensordaten) oder direkt den Motor zu regeln, sodass man ihn nur mit Sollwerten füttern muss? Letzteres wäre ja eigentlich sinnvoller. Aus eigenen Tests mit solchen Sensoren und Getriebemotoren hab ich in Erfahrung bringen können, dass das Getriebespiel sich gerne mal negativ auf die Regelgüte auswirkt, hast du da schon ein wenig mit herumgespielt oder kommt das erst noch?

Hi,

Zitat:

---

Mich wunderts, dass das hier keiner kommentiert.

---

Naja, ich stelle ja nicht direkt irgendwelche Fragen, insofern kann ich mir schon denken dass man mal draufguckt und dann weitergeht - würde ich vielleicht auch so machen ... :-)

Zitat:

---

Ist der Controller eigentlich nur da, um Daten durchzureichen (PWM, Sensordaten) oder direkt den Motor zu regeln, sodass man ihn nur mit Sollwerten füttern muss?

---

Letzters. Es ist genau die Idee, dass die Antriebe lokal regeln, und nur "von oben" gesagt bekommen, was sie machen sollen. Für diese Anwendung will ich ja nur eine Geschwindigkeitsregelung realisieren, aber da der Encoder die Position absolut ausgibt, kann man natürlich auch noch eine Positionsregelung drüberlegen. Dann hätte man einen relativ kompakten Stellmotor, einen etwas kräftigeren Servo quasi.

Mir gefällt dieses starkt modularisierte Konzept grundsätzlich gut, auch wenn es in manchen Fällen (scheinbar) etwas overkill ist. Ist ja quasi objektorientiert in Hardware: vier "Instanzen" eines gleichen Antriebs, der dann nur spezifisch konfiguriert und angesprochen wird.

Ich habe bisher fast ausschließlich mit Schrittmotoren gearbeitet (und sie dabei auch wirklich lieb gewonnen ;-)), insofern fehlt mir die Erfahrung mit Geschwindigkeits- (oder gar Positions-) regelungen von DC Motoren. Klar ist Getriebespiel da ein Problem, ich würde aber vermuten, dass das bei Positonsregelungen noch deutlich stärker reinhaut als bei Geschw.reglungen, weil das Spiel dabei ja gerade um den Punkt herum auftritt, wo man hin will.

Gruß
Malte

Das stimmt, das Problem ist bei Drehzahlregelung eher weniger spürbar. Das Konzept mit der dezentralen Regelung finde ich auch sehr gut, so kann man alles recht übersichtlich halten. Besonders interessant finde ich ja die Integration der Elektronik mit dem Motor, ich hätte es wahrscheinlich eher so gemacht, dass die Elektronik irgendwo in der Nähe des Hauptcontrollers liegt und dann Kabel zum Motor und Sensor gehen, so hätte man aber nur Versorgungsleitung und Busleitung, die man dann wohl auch einfach hintereinander hängen könnte. Verringert den Verkabelungsaufwand schön :)
Nur müssten sich dann die Motorregler auch vernünftig addressieren lassen. Wie machst du das eigentlich genau mit der Datenkommunikation? Gerade da hatte ich irgendwie Probleme mit, weil ich da einfach nicht weiß, was da gut geeignet wäre. Sind die Regler-Controller auch über den Bus parametrierbar?

Hey,

Zitat:

---

Das Konzept mit der dezentralen Regelung finde ich auch sehr gut, so kann man alles recht übersichtlich halten. Besonders interessant finde ich ja die Integration der Elektronik mit dem Motor, ich hätte es wahrscheinlich eher so gemacht, dass die Elektronik irgendwo in der Nähe des Hauptcontrollers liegt und dann Kabel zum Motor und Sensor gehen, so hätte man aber nur Versorgungsleitung und Busleitung, die man dann wohl auch einfach hintereinander hängen könnte. Verringert den Verkabelungsaufwand schön :)

---

Die Platine direkt am Motor unterzubringen war - für meine Begriffe - in mehrerlei Hinsicht nur folgerichtig. Erstens ging es ja wie gesagt um ein modulares Konzept. Wenn alles klappt und funktioniert, habe ich eine in sich abgeschlossene Einheit, die man so wie sie ist auch an anderen Stellen einsetzen kann. Weil ich den AS5048 als Encoder verwenden wollte (interessierte mich weil ich mal den AS5045 mit SSI im Einsatz hatte, hatte außerdem noch Samples davon), war klar, dass ich eh eine Platine brauche, die sich über dem Abtrieb des Getriebes befinden muss. Und weil es natürlich auf eine präzise Ausrichtung des Sensors ankommt, war's auch irgendwie logisch, die Schraubenlöcher im Getriebekasten zur Befestigung zu verwenden, die sind nämlich sehr genau zu dem Lager der Abtriebswelle ausgerichtet. Außerdem hätte ich es nicht so schön gefunden, die recht hochfrequente und leistungsstarke PWM für die Motoren über unnötig lange Kabel zu verlegen. Ich hab quasi keine Ahnung von EMV, aber intuitiv würde ich sowas vermeiden, wenn's anders geht. Umgekehrt hätte ich auch das 2 MHz SPI über längere Strecken "frei fliegend" verlegen müssen, wenn ich nur den Sensor am Motor gehabt hätte und den Rest zentral. Auch das ist sicher machbar, einfacher ist es aber vermutlich doch, auch das lokal zu lassen. Die Verkabelung ist so eigentlich auch recht schmerzfrei: Es gibt den Stromversorgungsanschluss für den Motor als Schraubklemme und einen Flachbandkabelanschluss für die Logikversorgung und den Bus. Weil der Bus I2C ist (s.u.), kann man mehrere von den Antriebseinheiten auch als Daisy-Chain hintereinander hängen wenn man will, oder eben sternförmig vom Master - das habe ich jetzt hier geplant.

Zitat:

---

Wie machst du das eigentlich genau mit der Datenkommunikation? Gerade da hatte ich irgendwie Probleme mit, weil ich da einfach nicht weiß, was da gut geeignet wäre.

---

Tja, das ist auch so ein Thema, gerade für größere Roboter ... Wollte immer schonmal einen Thread dazu hier eröffnen, mache ich vielleicht bald mal :-). Weil es praktisch für mich gut klappt, verwende ich für solche Zwecke seit mehreren Jahren I2C. Das ist natürlich kein Feldbus, aber weil er relativ wenig overhead hat und auch low-level gut zu beherrschen ist, ist das für meine Zwecke eine gute Sache (ich brauche idR keine allzu großen Bandbreiten). Im Endeffekt ist der I2C auch erstaunlich robust - meiner unmaßgeblichen Erfahrung nach. Ich mache die Pull-Ups immer möglichst klein, dann funktioniert das sogar über längere Kabel. Meistens baue ich in das Protokoll noch eine minimale Fehlerkontrolle (CRC), damit ist es dann recht stabil. Diesmal habe ich auf der Platine noch einen PCA9600 vorgesehen, der macht aus dem I2C einen differentiellen Bus, den man quasi als Feldbus einsetzen kann. Ich habe noch keine Erfahrung damit, und mich bisher ehrlich gesagt auch nur oberflächlich eingelesen. Dieses Projekt war mal eine Möglichkeit ein wenig praktische Erfahrung mit dem Baustein und dem Konzept zu sammeln ...

Zitat:

---

Sind die Regler-Controller auch über den Bus parametrierbar?

---

Das ist ja nur eine Frage der Firmware :-)

Also über die Frage eines geeigneten Busses für (größere) Roboter würde ich durchaus gerne - ggf an anderer Stelle - nochmal diskutieren, auch wenn für dieses Projekt die Wahl auf I2C gefallen ist.

Gruß
Malte

Sehr schönes Konzept und ich finde eine Modulare Lösung auch immer schöner, da es einfach weniger Kabel sind und man oft gleiche Komponenten verwenden kann. In Bezug auf Daisy-Chain würde ich dir empfehlen pro Platine zwei Datenstecker vorzusehen, dann kann man einen Stecker als Eingang und einen als Ausgang verwenden. Ist ein wenig angenehmer beim verkabeln.

I2C sollte eigentlich für alle Hobby Roboter ausreichen, auch wenn es ein Protokoll für Platinenbus ist.

Hi,

Zitat:

---

In Bezug auf Daisy-Chain würde ich dir empfehlen pro Platine zwei Datenstecker vorzusehen, dann kann man einen Stecker als Eingang und einen als Ausgang verwenden. Ist ein wenig angenehmer beim verkabeln.

---

Ich habe ja einen Stecker für Flachbandkabel-Quetschverbinder vorgesehen. Ein Flachbandkabel mit mehreren Buchsen schleift die Signale ja quasi auch einfach nur durch. Insofern braucht man für Daisy Chain nichtmal mehr als eine Buchse pro Slave.

Ich habe mir mittlerweile mal ein paar Sprungantworten des Antriebs angeguckt. Ich habe dazu die PWM in Schritten von 16 von 15 bis 255 (8 bit PWM) erhöht und rückwärts wieder erniedrigt. Währenddessen habe ich die Drehzahl in einem Intervall von 2.048 ms aufgezeichnet. Die Treppe habe ich viele Male wiederholt und dann samplegenau gemittelt. Das Video nur zur Anschauung, hat ansonsten keinen Erklärungswert.

http://youtu.be/izpkCuhH2BE

Abgesehen von einer Schwelle am unteren Ende des Drehzahlbereiches verhält sich das Ding recht linear - besser als ich erwartet habe. Ich habe die Ausgleichsvorgänge nach einem Sprung mal als PT₁-Glied gefittet (f(t) = k*(1-e^-t/τ)), auch das kommt sehr gut hin. Schaut man sich die Zeitkonstanten über sämtliche Sprünge an, sind sie einigermaßen im selben Bereich, wiederum abgesehen vom ersten Schritt nach der Schwelle, aber das ist ja auch nicht weiter überraschend. Folgend mal als Bild (die x-Achse ist etwas wild, aber man sieht wohl was es bedeutet). Die mit höherer Auflösung gezeigten Sprungantworten sind beliebige Beispiele.

Anhang 29857

Jetzt muss ich mal überlegen wie ich weitermache. Ein wenig (wirklich nur ein wenig) mehr Erfahrung habe ich mit Temperaturregelungen, die Regelstrecken mit denen ich da bisher zu tun hatte, konnte man enigermaßen als PT₂ modellieren, was eine Parametrisierung über die klassischen Einstellregeln erlaubt hat (wobei ich dann immer auch noch per Hand nachgetuned habe). Da das PT₁ natürlich keine Verzugszeit hat, die bei den Einstellregeln (ich kenne nur Chien/Hrones/Reswick und Ziegler/Nichols wie hier beschrieben) aber immer im Nenner steht, kann man diese nicht sinnvoll verwenden. Vielleicht ist das mal ein Anlass, ein ordentliches Modell in Matlab zu basteln.

Gruß
Malte

Ah, es geht weider :)
Eigentlich sollte so ein Motor auch PT2-Verhalten haben, da man als verzögernde Elemente sowohl Massenträgheit als auch Induktivität hat. Die elektrische Zeitkonstante ist allerdings meist viel kleiner als die Mechanische, daher ist davon nicht viel zu merken. Ich hab meinen Regler jedenfalls größtenteils durch Variation der Reglerparameter eingestellt, also viel herumspielen, bis das Verhalten passt. Ist sicher nicht die effektivste Methode, aber so bekommt man schonmal ein wenig ein Gefühl dafür, welcher Regleranteil was bewirkt. Ich hab auch schon versucht, von meinem Motor ein möglichst komplettes Modell in Simulink aufzubauen, mit dem Versatz in der PWM, mit Spannungsbegrenzung und mit Getriebespiel. Was da herauskommt sieht allerdings immernoch anders aus als das, was ich messe. Kommt vielleicht auch ein wenig daher, dass der fertige Block für Getriebespiel (Backlash) nur anhand der Geschwindigkeit umschaltet und nicht anhand der wirkenden Kraft. Es können aber auch noch andere Unstimmigkeiten vorhanden sein.

Dachte mir schon, dass du es so gelöst hast, finde ich persönlich aber nicht so gut. Der Grund ist schlicht, dass man dann ein Flachbandkabel hat und die Positionen der Buchsen sehr genau vermessen muss, damit es später ordentlich aussieht. Abgesehen davon kann man den Aufbau nicht so leicht modifizieren ohne gleich ein komplett neues Kabel zu fertigen. Es scheint jetzt auch nicht als hättest du ein Platzproblem auf der Platine.