Spezieller Roboterarm gesucht

[HaWe]

Prinzipiell haben wir hier doch einmal zwei Randbedingungen und den Hinweis das der TO kein Bastler ist.
Also fallen Umbauten die z.B. das öffnen und umlöten von RC-Servos beinhalten raus.

Wenn ein Arm bereits eine eigene Steuerung hat, muß diese in der Lage sein mit dem PC zu kommunizieren und zur Laufzeit Daten (z.B. Zielpositionen) von dort zu übernehmen.

Besteht der Arm nur aus Mechanik, Motoren und Sensoren (Endschalter, Referenzschalter, und Encoder).
Bedarf es einer Schnittstelle die das alles bereitstellt und PC Seitig einer Schnittstelle die dazu passt.

Für Industrie PCs gibt es PCI-IO Karten, die liegen für 32 Digital IOs gerne bei über 200,-€
USB-IO Module sind auch möglich, kommen mit entsprechend vielen IOs dann aber auf ähnliche Preise (und man muß genug USB Ports oder einen Hub haben)
Bsp.:
https://www.velleman.eu/products/vie...g=en&id=351346
mit C++ Library

Prizipiel: ein (normaler) Roboterarm führt eine Bewegung durch ob da ein Hindernis ist oder nicht.
Dabei wird der Roboterarm entweder das Hinderniss zerstören, sich selbst zerstören (mechanisch oder Motoren) oder seine Verankerung zerstören.

Dagegen hilft die Überwachung der Motorströme, um damit Rückschlüsse auf die Drehmomente zu ziehen und der Vergleich mit hinterlegten Grenzwerten.
Eine von den Motoren unabhängige Dreh-/Biegemoment Überwachung mit Kraftsensoren (bedingt die Integration in den mechanischen Aufbau des Arms) oder ein vollständiges Bedecken des Arms mit Taktilen- oder Abstandssensoren.

Für eine Motorstromüberwachung müssen die Motortreiber diesen als Signal bereitstellen oder man muß entsprechende Stromsensoren nachrüsten.

Eigene Kraftsensoren an allen Gelenken haben vorraussichtlich nur Arme die deutlich das Budget sprengen.

Das vollständige Bedecken mit taktilen Sensoren dürfte auch das Budget sprengen und bedingt das der Arm baulich dafür geeignet ist.

Am einfachsten ist es wohl nach Armen zu suchen, die es Erlauben den Motorstrom zu messen.
Da RC-Servos die Motorregelung integiert haben, bleiben ohne größere Bastelarbeit: DC-Motoren, (EC-) BLDC-Motoren und bedingt Schrittmotoren.


Geht man von einem Arm aus, der nur Mechanik, Antriebe und Sensoren bereitstellt und die gesammte Regelung und Steuerung vom Rechner durchgeführt wird, dann hat man bei einem 6-Achs Vertikal Knickarm Roboter mit elektrischem Greifer. maximal 7 Stromregelungen, 7 Drehzahlregelungen und 7 Positionsregelungen (vermutlich als PD oder PID Regler) die gleichzeitig laufen. Plus zusätzlich die Bahnsteuerung und weitere Funktionen, da das Programm ja "recht umfangreich" ist. In wie weit das in allen Betriebszuständen ohne Real Time OS zuverlässig funktioniert, lasse ich mal so im Raum stehen. RT ist ja "Unsinn".
Offensichtlich reicht meine Berufspraxis von über 250 gebauten, 3 bis 12-Achs, CNC Anlagen mit Robotersystemem nicht um das zu beurteilen.

betr.:
- "(i_make_it: ) Vorraussetzung für eine eigene Robotersteuerung auf Linuxbasis ist aber schon mal die Aktivierung von RTLinux sonst wird das mit Regelungen etc. nicht besonders zuverlässig."
- "(HaWe: )Robotersteuerung auf Linuxbasis erfordert kein RT Linux, das ist Unsinn."
- "(i_make_it: ) Offensichtlich reicht meine Berufspraxis von über 250 gebauten, 3 bis 12-Achs, CNC Anlagen mit Robotersystemem nicht um das zu beurteilen. "

mit der letzten Bemerkung kannst du Recht haben, denn das gilt höchstens eingeschränkt, aber nicht allgemeingültig. Betrachtet man Raspis, die Hardware-timing besitzen, gilt es z.B. nicht.
https://www.raspberrypi.org/forums/v...ca9685#p670800
https://www.raspberrypi.org/forums/v...ca9685#p670946
Und das gilt offensichtlich nicht nur für die 2-4 festen Hardware-pwm-Pins, sondern für bis zu 26 pwm GPIO Pins für bis zu 26 Servos, wie joan scheibt - und er muss es schließlich wissen, denn er hat ja die pigpio lib geschrieben.

Auch ohne Hardware-Timing sind aber z.B. auch auf Raspis die Standard-GPIOs so schnell zu schreiben oder zu lesen, dass man locker Encoder auslesen kann zur Positionsbestimmung (wie erwähnt, 25-96 MHz):
https://www.raspberrypi.org/forums/v...13887#p1318115
https://www.raspberrypi.org/forums/v...13887#p1317269
- und auch das ganz ohne RT Linux Kernel!

Man braucht auch nicht unbedingt Stromüberwachung, wenn man z.B. Rotationsencoder hat, denn dann kann man die Drehposition und (per Änderung über die Zeit) die Drehgeschwindigkeit laufend erfassen, und wenn es zu "stalling" kommt vor dem Ziel, dann heißt es: er hängt irgendwo fest.

MT per pthread mit verschiedenen Thread priorities für verschieden zeitkritische Threads hilft dabei enorm, die Roboter-Routinen zeitlich zu optimieren. Weiter optimieren lässt sich das zeitliche Verhalten, wenn man bestimmte cpu-cores für zeitkritische Routinen reserviert:
"instruct the Linux kernel to not schedule tasks on a particular core, then run your program on that free core"