Manipulator Hardware Empfehlungen/Erfahrungen ROS

Hallo,
ich bin auf der Suche nach Hardware für einen Manipulator. Das System soll über ROS gesteuert werden, vorerst ist hierfür ein Raspberry Pi vorgesehen. Im Moment denke ich daran einen Tensy als controller (PIC) zu verwenden und L298 driver. Hat jemand Erfahrungen oder sonstiges Know-How mit einem solchen Setup? Komplet offen ist im Moment die Frage nach den richtigen Getriebemotoren. Sehr gut wäre wenn hier eine ganze Serie von möglichen Motoren(Übersetzungsverhältnissen) verfügbar wäre, da möglicherweise die Kraft später verstärkt werden soll. Generell soll hier ein "Modularsystem" entstehen, welches später um zusätzliche Motoren erweiterbar sein sollte. Auch Potentiometer/Encoder (PIC) und Kraftsensoren (Kraftbegrenzung zur Sicherheit) sollen mit eingebunden werden. Beim Theme Encoder/Potentiometer als Feedback Geber bin ich im Moment noch total planlos, da ich hier noch keine speziellen Produkte ausfindig machen konnte. Bin über für jede Hilfe Dankbar.

Nachtrag:
Raspberry Pi 3b
Tensy 3.5 (vor allem wegen der vielen Analogen Ein und Ausgänge)
l298 Dual Motor Driver max 2A 12 volt

Ausgehend von den ausbleibenden Antworten ist das Thema wohl zu allgemein bzw. speziell für das Froum.

Hat jemand vielleicht eine "gut" funktionierende Kombination aus Driver-DC Getriebemotor-Encoder die er oder sie empfhelen kann? Wie gesagt am besten ein Motor den es auch in verschiedenen übersetzungsverhältnissen gibt. Würde mich über antworten freuen.

Vielleicht solltest du etwas spezieller werden, Motoren mit Encodern gibt es wie Sand am Meer.

Ich hatte mal einen Roboter-Arm mit EMG30 Motoren für alle Gelenke bis auf den letzten. Bei dem letztem Gelenk und beim Greifer wurden Servos verwendet. Im "Low-Cost"-Bereich der Manipulatoren scheinen aber ansonsten die Robotis Dynamixel sehr beliebt zu sein, die enthalten das Komplettpaket inkl. PID-Controller und werden über einen Bus angesteuert. Verwendet werden diese Motoren z.B. im OpenManipulator, welcher deine modulare Anforderung erfüllt. Ich überlege auch gerade meinen Roboter durch so einen Arm zu erweitern, bin mir nur noch nicht ganz sicher, ob ich mir die teuren Dynamixel Aktoren leisten will.

Ansonsten gibt es natürlich noch die vom Wild Thumper bekannten Motoren in verschiedenen Übersetzungen.

Danke für die Antwort. Ja, genau das "Sand am Meer" bei den Motoren ist mein Problem, ich suche da einfach etwas günstiges was aber auch nicht der letzte Dreck ist, oder gar gefährlich. Die "Wild Thumper" Motoren sind genau was ich gesucht habe, danke dafür. Die Dynamixel sind nichts für mich zu teuer und das System sollte so modular sein, dass man einen Motor der das Feedback als Aktuator von einem Poti gekommt, auch in einem anderen Projekt mit Decoder Feedback als Antrieb nutzen kann. Die PID möchte ich gerne selbst in einer ROS Node programmieren (copy paste und anpassen ;). Die Node soll dann über ROS-Serial angesteuert auf einem Tensy 3.5 laufen.

Ich würde den PID auf dem M4 laufen lassen, weil dieser in Echtzeit reagieren kann.

M4 was ist das? Auf den Tensy bin ich gekommen weil er Arduino kompatibel ist aber stanardmäßig sehr viele Analoge I/Os mitbringt, scheint für zukünftige erweiterungen ideal zu sein.

Zitat:

---

Zitat von Graugelb

M4 was ist das? Auf den Tensy bin ich gekommen weil er Arduino kompatibel ist aber stanardmäßig sehr viele Analoge I/Os mitbringt, scheint für zukünftige erweiterungen ideal zu sein.

---

M4 = ARM Cortex M4, hat eine zusätzliche fpu, gibt es von teensy (3.5 und 3.6) und von Adafruit (M4 in den Platinen-Versionen Metro, Feather und ItsyBitsy).

Übrigens, Riesen-Vorteil, wenn du einen Raspi nimmst für PID statt einen Arduino:
hier hast du pthread mit preemptivem Multithreading zur Verfügung, das ist Gold wert, wenn du mehrere Motoren simultan steuern willst (jeder in einem eigenen PID Thread) - so was gibt es leider nicht bei Arduino, der cooperative-multithreading Scheduler z.B. ist ein absolutes Gemurkse.

Danke für den Input. Du bist also der Meinung bei zu koordinierenden Motoren/Aktuatoren soll ich einen PI für die Steuerung nehmen und direkt die Driver daran anschließen? Den Teensy weg lassen und beim PI mit ExtensionBoards (I²C) die IOs erweitern? Bisher habe ich eben immer von einem Microcontroller ("realtime" Vorteil) hinter einem PI (oder ähnlichem) als Best Practize gelesen. Ein System in dem der PI die z.B. Target-Velocity vorgibt und der Microcontroller über PID dann dafür sorgt das diese erreicht wird.

Zitat:

---

Zitat von Graugelb

Danke für den Input. Du bist also der Meinung bei zu koordinierenden Motoren/Aktuatoren soll ich einen PI für die Steuerung nehmen und direkt die Driver daran anschließen? Den Teensy weg lassen und beim PI mit ExtensionBoards (I²C) die IOs erweitern? Bisher habe ich eben immer von einem Microcontroller ("realtime" Vorteil) hinter einem PI (oder ähnlichem) als Best Practize gelesen. Ein System in dem der PI die z.B. Target-Velocity vorgibt und der Microcontroller über PID dann dafür sorgt das diese erreicht wird.

---

ja, genau so.
Ich selber habe für meinen Pi stapelbare Extension-Boards (Dexter BrickPi3, per SPI) für Encodermotoren mit M0-cpus (mit onboard-H-Brücken für je 4 Encodermotoren, max. je 1A pro Encodermotor, per Zusatzschaltung allerdings auch stärkere H-Brücken ansteuerbar).
Dabei können diese sogar PD per multithreading ganz alleine von sich aus (eigene Firmware mit Python oder C++ API).

Es gibt solche stapelbaren HATs/Shields auch fertig von Adafruit (nur Python API) - oder du baust sie selber.
ARM Cortex M0 cpus sollten die HATs aber schon haben.

Danke für die Antwort. OK, verstehe, das sind dann aber Controller mit eigener Logik und nicht nur einfache Driver HATs. Meine Idee war da eben diese Produkte aus Teensy und Driver "selbst zu bauen", um mehr Kontrolle zu bekommen (z.B. Position eines Aktuators, beeinflusst PID Werte eines Zweiten - Erklärung: Ist der Manipulator Arm ausgetreckt und wird mit Hoher Nutzlast gefahren so hat es der Aktuator an der Basis mit ganz anderen Kräften zu tun, als wenn mit wenig Nutzlast auf kurzen Hebel gearbeitet wird.) und vor allem viele Motoren darüber steuern zu können (so ganz schnell wie beim Balance-Bot müssen die bei mir nicht sein). Hast du Know-How, Keywords oder Links wieviel Motoren mit einem Teensy koordiniert gesteuert werden können und in welcher Qualität (Latenz)?

Gibt es Threads, Youtube, Blog, Github, oder so zu deinem Build-Projekt, sonst kommen da jetzt noch mehr Fragen in mir hoch.

also, da jeder meiner HATs mit M0 je 4 Encodermotoren steuern kann mit je 2 Pins für Encoder und mind. je 2-3 Pins für die H-Brücken => 4*(2+2)=16 bzw. 4*(3+2)=20 Pins, denke ich, dass das auch schon etwa das Limit ist.
Ob du jetzt die M0 Rechenpower auch noch nutzt für komplexere Regelungen, ist fast, aber nicht ganz zweitrangig, denn wenn du alle raw Einzeldaten zur Steuerung der 4 Rotationsencodermotoren per i2c hin-und herschaufeln willst, brauchst du schon eine seeeehr schnelle Anbindung. Geht aber, habe ich prinzipiell auch schon gemacht, für PID reicht prinzipiell eine 10ms-Regelungsschleife.

Teeny ist ja aber != Teensy, es gibt die mit sehr unterschiedlich leistungsfähigen Prozessoren. Ein 3.2 mit M0 sollte schon sein, wie gesagt.

Blogs gibt es keine mehr, das alte Forum, in dem ich es gepostet habe, ist offline, und an dem einzigen Video kann man nicht so schrecklich viel erkennen:
https://www.youtube.com/watch?v=IBvyu2-AAKM

Ich könnte es zwar noch hier ins Forum portieren, das ist mir aber wegen der umständlichen und Datenmengen-begrenzten Forumssoftware zu aufwändig. Anfragen dazu hat der hiesige Forums admin noch nicht einmal beantwortet.

Danke für die Antwort. Ich dachte an einen Teensy 3.5. Auf den Teensy Weg bin ich gekommen weil das ganze über ROS laufen soll, und da gibt es bereits eine Anbindung für den Arduino und der Teensy sollte da kompatibel sein. Andere Controller schauen da nach ziemlich viel Arbeit aus. Beim Teensy brauche ich auch keinen I²C da der selber mehr als genug IOs ab Werk besitzt (direkt PWM to Driver) und über USB? mit dem Roscore Computer (dachte an PI3, kann dann für Pathplanning, LIDAR etc. auch was größeres werden in Zukunft) verbunden ist.

Blöde Idee?

klar, der 3.5 hat ja doch wohl einen M4 mit 120 MHz - den kenne ich allerdings nicht persönlich, ich selber habe Adafruit Feather und Itsybitsy mit (leider) weniger GPIOs.
ROS aber würde doch auf dem Pi laufen, wie der Huckepack MCU damit seriell kommuniziert, ist doch dann egal...?

PS,
mein Arduino Due mit M3 kann 6-7 Encodermotoren steuern und kommuniziert per UART/USB
Ich bin aber heilfroh, dass meine BrickPi3 HATs den MT-fähigen PD Regler onboard haben.

Theoretisch schon aber da geht der PI dann schnell in die Knie wenn man Pathplanning, Navigation etc, dazu nimmt irgendwann (besonders saubere PWM Signale sollen ein Problem sein = Servokrampf etc.), "Realtime" wird da sehr schnell zum Problem. Wie ein anderer User geschrieben hat ist der M4 eben sehr gut für "Realtime" geeignet. Auch ist es so das ich evtl. einen Forcesensor in die Steuerung einbinden möchte um Überlast bzw. Kollisionen zu erkennen. Bei den Controller HATs ist ein zusätzliches Feedback und dessen Berechnung leider nicht vorgesehen. Lässt sich über den PI machen, Latenz ist da nicht so wichtig, wenn das aber alles über den Controller realisierbar wäre fände ich die Architektur halt sauberer, als wenn das auf verschiedene Hardware verteilt wird.

Zitat:

---

Zitat von Graugelb

Theoretisch schon aber da geht der PI dann schnell in die Knie wenn man Pathplanning, Navigation etc, dazu nimmt irgendwann (besonders saubere PWM Signale sollen ein Problem sein = Servokrampf etc.)

---

nein, geht er nicht.
Du kannst pthread threads (joinable) mit unterschiedlicher Thread Priority auf dem Pi2/3 laufen lassen, der schafft das 10x !
Da kannst du sogar noch parallel über WLAN youtube videos auf HD Screen gucken! 8)
Realtime ist da auch kein Problem, ich kann dann sogar noch locker GPIOs mit 500ns (!) Latenz lesen und schreiben!!
Und dann kannst du sogar noch so kompilieren, dass einzelne Raspi-Cores ausschließlich nur von deinem Programm und nicht vom kernel benutzt werden!

PS,
für pwm zur Servosteuerung: auf JEDEN FALL einen PCA9685 benutzen!!

Good Stuff HaWe! Ich habe sogar ein PCA 9685 auch noch einen adafruit ADS1015 ADC 12-bit wandler board. Dann brauch ich da also noch H-Brücken Driver und gut ists? Danke nochmal! Ist das jetzt neu mit dem PI2/3? Die ganzen Tutorials etc. sind halt oft schon ein paar Jahre alt und schnell obsolet wie es scheint.

P.S. Wäre mir auch egal wenn ich dann doch noch einen zweiten PI oder ähnliches brauche um Pointcloud etc. zu verarbeiten.

Das mit pthread ist nicht neu, auch nicht das Kompilieren nur für einzelne reservierte Cores - aber das letztere war noch nicht mal nötig für meine Zwecke.
Je mehr du aber auf dein Motor-HAT an Aufgaben auslagerst, desto besser: du sagst dann nur noch;
Motor1 auf Encoderwert 2500, brake wenn erreicht
Motor2 auf Encoderwert -3000, coast wenn erreicht
Motor3 auf Encoderwert 1000, brake wenn erreicht
Warten bis alle Zielwerte erreicht sind...

Alles andere machen dann die PID/PD-Routinen auf dem HAT und melden nur auf Anfrage Zwischen- oder Endwerte zur Kontrolle zurück.
SPI ist besser als i2c, da full-duplex und meist schneller als i2c, und weitere i2c Geräte auf dem Bus wirken auch nicht bremsend.

Ob Pi2 oder Pi3 macht da auch keinen großen Unterschied, egal ob ARM7 oder ARM57, Hauptsache Quadcore!

Die PIDs laufen dann hier also auch auf einem externen Controller (HAT) und nicht auf dem PI selbst. Kommt doch auf dasselbe heraus wenn ich es über den Teensy to Driver Weg löse?

das war nur ein Beispiel für komplexe Highlevelbefehle, um z.B. 3 Robotarmachsen zu drehen. Die müssen auch nicht immer unbedingt gleichzetig das Ziel erreichen, sondern nur simultan drehen, und ggf ist dann eben 1 früher fertig als andere.
Für Plotter sieht das ntl anders aus, da musst du u.U. Einzel-Schrittchen für Einzel-Schrittchen häppchenweise setzen - mit Plottersteuerung kenne ich mich aber nicht aus.
PID ist nur allgemein ein Algorithmus für verschiedene Zwecke, der dafür sorgt, dass man Überschießen und Schwingen und Verrecken unter Last vor dem Ziel vermeidet, für ganz unterschiedliche Anwendungsfelder, und je nach Tuning und Feintuning das eine oder andere davon mehr oder weniger.

Danke für die Antwort. "Einzel-Schrittchen für Einzel-Schrittchen häppchenweise" das sollte über PID möglich sein, halt eben etwas komplexer.

Siehst du konkrete Probleme beim Teensy to Driver Ansatz? Ist doch nahezu dasselbe wie ein Controller HAT, halt mehr Kabel Wirrwarr.

Zitat:

---

Zitat von Graugelb

Danke für die Antwort. "Einzel-Schrittchen für Einzel-Schrittchen häppchenweise" das sollte über PID möglich sein, halt eben etwas komplexer.

Siehst du konkrete Probleme beim Teensy to Driver Ansatz? Ist doch nahezu dasselbe wie ein Controller HAT, halt mehr Kabel Wirrwarr.

---

grundsätzlich - theoretisch - nicht, kommt eben auf die Steuerungsimplementierung an.