Spezieller Roboterarm gesucht

Druckbare Version

26.05.2018, 16:43
Willi1

Spezieller Roboterarm gesucht

Hallo,

ich bin viel mehr Programmierer als Bastler und suche einen Roboterarm, den ich mit meinem schon vorhandenem sehr umfangreichen C++-Programm (läuft unter Linux) steuern kann.

Außerdem soll der Arm (bzw. der einzelne Motor) es unbedingt zurückmelden, wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann (, weil da ein Hindernis ist, oder so). Geht sowas überhaupt mit Servos?

Mit einem Arduino würde ich grundsätzlich klarkommen, aber ich kann keinen nehmen, weil er viel zu klein und zu langsam ist. Mein PC wiederum hat keine IO-Pins.

Ich wäre bereit 1000,- Euro für so einen Arm auszugeben.
26.05.2018, 17:45
HaWe

Zitat:

Zitat von Willi1

Hallo,

ich bin viel mehr Programmierer als Bastler und suche einen Roboterarm, den ich mit meinem schon vorhandenem sehr umfangreichen C++-Programm (läuft unter Linux) steuern kann.

Außerdem soll der Arm (bzw. der einzelne Motor) es unbedingt zurückmelden, wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann (, weil da ein Hindernis ist, oder so). Geht sowas überhaupt mit Servos?

Mit einem Arduino würde ich grundsätzlich klarkommen, aber ich kann keinen nehmen, weil er viel zu klein und zu langsam ist. Mein PC wiederum hat keine IO-Pins.

Ich wäre bereit 1000,- Euro für so einen Arm auszugeben.

hallo,
zunächst: ein Arduino ist dazu niemals zu klein, da er bis zu über 70 I/O Ports hat (Mega, Due). Soviel hat kein RasperryPi oder Beaglebone. Außerdem sind Arduinos sehr schnell mit ihren IOs und echtzeitigfähig, im Gegensatz zum Linux Userspace.
Daneben lassen Zusatzshields alle möglichen Porterweiterungen zu.

Aber zum Thema:
wieviele DOFs soll der RA haben,
welche Reichweite
welche Gesamt-Größe des Arbeitsraums,
welche Nutzlast soll er in jedem Falle heben und bewegen können,
und welche Rotatonsgeschwindigkeiten sollen an den Achsen erzielt werden (leer und beladen)?

Eine Rückmeldung über die Stellung ist möglich, wenn du zusätzliche Rotationsencoder anbringst, zumindest wenn nicht die Servos selber eine Rückmeldung bringen können.
26.05.2018, 18:01
Willi1

Hallo HaWe, Danke für die Antwort.

Zitat:

Zitat von HaWe

wieviele DOFs soll der RA haben,
welche Reichweite
welche Gesamt-Größe des Arbeitsraums,
welche Nutzlast soll er in jedem Falle heben und bewegen können,
und welche Rotatonsgeschwindigkeiten sollen an den Achsen erzielt werden (leer und beladen)?

Das ist mir nicht so wichtig. Hauptsache, ich kann ihn irgendwie aus einem normalen C++-Linux-Programm heraus steuern und ich bekomme dort die Rückmeldung, wie die Bewegung funktioniert hat.

Zitat:

Zitat von HaWe

Eine Rückmeldung über die Stellung ist möglich, wenn du zusätzliche Rotationsencoder anbringst, zumindest wenn nicht die Servos selber eine Rückmeldung bringen können.
26.05.2018, 18:04
HaWe

ok, wenn das alles nicht so wichtig ist, dann nimm doch diesen:

https://www.ebay.de/itm/Official-DOI...53.m1438.l2649

Plus die besagten Rotationsencoder. Ggf brauchst du für Raspis etc. noch eine Zusatzplatine oder Porterweiterungs-HATs etc. für die vielen IOs für Servos und Encoder, ggf auch einen Huckepack-Arduino.
26.05.2018, 18:18
Urinstein

Zitat:

Zitat von Willi1

Außerdem soll der Arm (bzw. der einzelne Motor) es unbedingt zurückmelden, wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann (, weil da ein Hindernis ist, oder so). Geht sowas überhaupt mit Servos?

Zitat:

Zitat von HaWe

Eine Rückmeldung über die Stellung ist möglich, wenn du zusätzliche Rotationsencoder anbringst, zumindest wenn nicht die Servos selber eine Rückmeldung bringen können.

Den Encoder kann man sich auch sparen, es reicht den vorhandenen Drehwinkelgeber des Servo abzugreifen. Sieht dann so aus:

Bild hier
Bild hier

Bei dem Servo im Bild müsste der Abgriff U_Pot dann an den mittleren Pin des Poti, also ans gelbe Kabel. Auf der anderen Seite dann an an einen analogen Eingang des Controllers. Habe schon mehrere Servos so modifiziert, klappt super.
26.05.2018, 18:23
HaWe

ich schrieb ja auch:
"... zusätzliche Rotationsencoder... , zumindest wenn nicht die Servos selber eine Rückmeldung bringen können."
26.05.2018, 18:27
Willi1

Zitat:

Zitat von HaWe

ok, wenn das alles nicht so wichtig ist, dann nimm doch diesen:

https://www.ebay.de/itm/Official-DOI...53.m1438.l2649

Plus die besagten Rotationsencoder. Ggf brauchst du für Raspis etc. noch eine Zusatzplatine oder Porterweiterungs-HATs etc. für die vielen IOs für Servos und Encoder, ggf auch einen Huckepack-Arduino.

Ich habe noch eine -wahrscheinlich dumme- Frage:

Man steuert einen Servo mittels PWM. Das geht mit einem Arduino ganz einfach. Aber wie macht man das von einem PC?? Ein PC hat ja keine IOs. Gibt es da käufliche Schnittstellen und Beispielcode?
26.05.2018, 18:35
robosapiens

Wenn es um eine fertige "Lösung" geht, kann ich sehr den UFactiry uArm empfehlen. Dieser basiert auf Schrittmototren mit zusätzlichen Encoder, bietet diverse Schnittstellen, z.B. für ROS und kostet in der Basisversion ca. 850€ : https://www.mybotshop.de/UFactory-uArm-Swift-Pro-Body

Ich bin nicht ein all zu großer Fan von PWM servos, da diese keinen integrierten Encoder und sehr großes Backlash besitzen. Ich verwende für meine Projekte sehr gerne DYNAMIXEL Servomotoren. Dafür gibt es eine große Community und diverse Shields.
26.05.2018, 18:37
HaWe

Zitat:

Man steuert einen Servo mittels PWM. Das geht mit einem Arduino ganz einfach. Aber wie macht man das von einem PC?? Ein PC hat ja keine IOs. Gibt es da käufliche Schnittstellen und Beispielcode?

Dann würde ich den PC mit einem Raspi oder Arduino per USB über ein serielles Terminal etc. verbinden, so dass diese wie IO-Interfaces oder Slaves funktioneren.
Arduinos haben dazu ja das serielle Terminal der Serial() Class.
Das ist aber ein anderes Thema, mach dazu besser ein neues Topic auf.
26.05.2018, 18:59
i_make_it

Einen Roboterarm der eine Kollisionserkennung bietet, wird wohl etwas teuerer werden.

Ein Arm mit Modellbau-Servos (RC-Servos) oder Schrittmotoren wird das nicht hergeben.

Kleine Professionelle Roboterarme haben DC-Getriebeomotoren mit incrementellen Drehgebern.
Bei meinem Eshed-Robotec (heute Inellitec) Scorbot ER 5 Plus kann ich für jeden Motor den Motorstrom messen und Schwellwerte festlegen.
Beim Greifer nutze ich das um ein rohes Ei mit einer geringen Greifkraft und einen Stahlblock mit einer hohen Greifkraft zu greifen.

Bei großen Robotern und CNC-Maschinen werden Servomotoren genutzt (funktionieren wie Brushles DC Motoren).

Modellbau Servos werden nur angesteuert (sollwert als 20ms PPM Signal). Es gibt keine Rückmeldung (der Positionsregelkreis befindet sich komplett im RC-Servo).
Ein üblicher Servoregler hat eine Stromregelung, eine Drehzahlregelung und eine Positionsregelung.
Entsprechend sind so ausgerüstete Roboterarme etwas teuerer.

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.

Es gibt für PCs Steuerkarten, wenn es unbedingt über einen PC laufen soll.
Auch USB IO-Module gibt es.
Alternativ ein Raspberry, der ist auf Linux Basis und hat IOs.
Ein Arduino wird auch in C++ programmiert, hat IOs und mit Timerinterrupts auch echtzeitfähig programmierbar.
26.05.2018, 19:32
HaWe

Zitat:

Zitat von 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.

Robotersteuerung auf Linuxbasis erfordert kein RT Linux, das ist Unsinn.
Der Raspi kann das für seine GPIOs mit dem ganz normalen Jessie oder Stretch, er braucht dazu noch nocht einmal eine Servoplatine, (edit: ) wenn die Pins für Hardware-timings ausreichen.
joan, der Autor und Entwickler von pigpio hat dies oftmals betont, z.B. hier: https://www.raspberrypi.org/forums/v...ca9685#p670800
(edit: ) und hier: https://www.raspberrypi.org/forums/v...ca9685#p670946
Ansonsten plus zusätzlicher PCA9685.
read und toggle IO ist auf allen GPIOs mit 25-96 MHz auf einem Pi 3 möglich.

Der OP hat aber keine IOs an seinem PC, daher muss eh irgendwas anderes als IO-Interface dazwischen.
==> eigenes neues Topic !!
26.05.2018, 20:03
RoboHolIC

Es gibt doch auch fertige CNC-Fräsen-Software, die mittels Centronics-Port des PCs die Positionierantriebe ansteuert. Das kann grundsätzlich auf einen Roboterarm übertragen werden.
Centronics-Port gibt es noch auf vielen existierenden Mainboards, zumindest als Header; dafür kann man noch ein passendes, fertig konfektioniertes Flachbandkabel kaufen oder basteln.
Oder eine Centronics-Karte nachrüsten.
Das bringt beide Male meines Wissens 8+4 Ausgangsleitungen und 5 Eingangsleitungen.
26.05.2018, 20:10
HaWe

Zitat:

Zitat von RoboHolIC

Es gibt doch auch fertige CNC-Fräsen-Software, die mittels Centronics-Port des PCs die Positionierantriebe ansteuert. Das kann grundsätzlich auf einen Roboterarm übertragen werden.
Centronics-Port gibt es noch auf vielen existierenden Mainboards, zumindest als Header; dafür kann man noch ein passendes, fertig konfektioniertes Flachbandkabel kaufen oder basteln.
Oder eine Centronics-Karte nachrüsten.
Das bringt beide Male meines Wissens 8+4 Ausgangsleitungen und 5 Eingangsleitungen.

Centronics für "moderne" Linux-PCs mit PCIe-Slots?
Und dann für welchen Roboterarm genau?
26.05.2018, 20:31
RoboHolIC

Man könnte sich vielleicht darüber auseinandersetzen, was die zukunftsträchtigere Technik ist - die Centronics hat jedenfalls das Potential für das bessere Timing- Ob das OS das dann auch so umsetzt, kann ich nicht beurteilen. "modern" ist mir jedenfalls kein Argument im technischen Kontext. Und für die gestellte Aufgabe ist ein Disketten-Linux oder ein Windows 95 vielleicht sogar noch die bessere Wahl.
Das man nicht auf aussterbende Technik setzen mag ist allerdings ein verständliches Anliegen.
26.05.2018, 21:11
HaWe

Zitat:

Zitat von RoboHolIC

Man könnte sich vielleicht darüber auseinandersetzen, was die zukunftsträchtigere Technik ist - die Centronics hat jedenfalls das Potential für das bessere Timing- Ob das OS das dann auch so umsetzt, kann ich nicht beurteilen. "modern" ist mir jedenfalls kein Argument im technischen Kontext. Und für die gestellte Aufgabe ist ein Disketten-Linux oder ein Windows 95 vielleicht sogar noch die bessere Wahl.
Das man nicht auf aussterbende Technik setzen mag ist allerdings ein verständliches Anliegen.

mit "modern" meinte ich nur einen zeitgenössischen Linux-PC, den der OP höchstwahrscheinlich hat, und wenn der nicht sehr sehr alt ist, wird er wohl keine PCI Steckplätze und erst recht keine Centronics Stecker haben.
Unabhängig davon ist aber meine Frage bezogen auf konkrete Roboterarme, nach denen der OP fragt, die er dann mit seiner Centronics Schnittstelle überhaupt ansprechen könnte?
Gefragt ist ja vorrangig nach einem Robotarm per Linux-gpp, und dann muss da jetzt ja auch die parallele Schnittstellensteuerung dazu passen.
27.05.2018, 13:04
i_make_it

Zitat:

Zitat von Willi1

suche einen Roboterarm, den ich mit meinem schon vorhandenem sehr umfangreichen C++-Programm steuern kann.

soll der Arm (bzw. der einzelne Motor) es unbedingt zurückmelden,
wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann
(, weil da ein Hindernis ist, oder so).

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".

Zitat:

Zitat von HaWe

Robotersteuerung auf Linuxbasis erfordert kein RT Linux, das ist Unsinn.

Offensichtlich reicht meine Berufspraxis von über 250 gebauten, 3 bis 12-Achs, CNC Anlagen mit Robotersystemem nicht um das zu beurteilen.
27.05.2018, 15:33
HaWe

Zitat:

Zitat von i_make_it

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"
28.05.2018, 10:16
i_make_it

Zitat:

Zitat von HaWe

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.

Wenn Du das schaffst, lass es Dir patentieren. Denn dann kannst Du etwas, was kein Roboterhersteller bisher geschafft hat.
Das Signal vom Enkoder nimmt man für die Positionsregeleung. folglich wird der Fehler größer und damit wird die Drehzahl des Motors erhöht um den Fehler zu verkleinern.
Die üblichen Folgen sind dann entweder ein Getriebeschaden oder das Bauteile Verbiegen oder brechen.
Bsp.: Extremfall waagerecht gestreckter Arm und es wird um A1 gedreht (sonst keine Achse).
Der Enkoder ist formschlüssig mit der Achse verbunden (misst also die tatsächliche Position und nicht die Motordrehung).
Arm trifft nahe des TCP auf ein Hinderniss.
Spiel in Antrieben und Lagerungen erlaubt das Weiterdrehen der Achse.
Motorstrom steigt an wegen größerem Kraftbedarf.
Enkoder bildet Schleppfehler und vergrößert die Regelabweichung.
Regler versucht auszugleichen.
Elastische Verformung der Bauteile lässt weitere Drehung zu.
Motorstrom hat schon lange einen kritischen Bereich erreicht.
Enkoder Schleppfehler wird größer.
Regelung versucht noch stärker auszugleichen.
(das Ganze spielt sich in wenigen Millisekunden ab)
Jetzt könnte man, wenn man denn eeinen Vergleichswert hat, der den maximalen Schleppfehler an dieser Stelle und zu dieser Zeit der Bahnbewegung, definiert. Abschalten.

Was macht man aber mit einer Achse, die nicht Quer zur Schwerkraftsrichtung liegt?
Sondern bei der die Masse des "Werkstücks" und der Winkel des Arms relativ zur Wirkrichtung der Schwerkraft zu ständig wechselnden Schleppfehlern führt.
(Das selbe Problem hat man mit dme Motorstrom auch, aber jetzt kann man den Strom und die Positionsänderung mitenander vergleichen. Bringt mehr Strom auch mehr Bewegung oder wird die Trotz steigendem Strom kleiner, da es ein Hinderniss gibt?
auch ohne exaktes, vorherberechnetes oder aufgezeichnetes Bahnprofil kann man eine Kollision erkennen.
Die Profilaufzeichnung war mal etwas, was man Ende der 80er Jahre gemacht hat, damit gab es aber immer Probleme, da bei Änderung der Zykluszeit die Werte ja nicht mehr passten. also musste man bei jeder Änderung, über mehrere Zyklen neu anlernen.

Wie gesagt da haben sich schon alle Hersteller von Roboterarmen in den letzten Jahrzehnten Gedanken drüber gemacht.
Wenn Du da eine Lösung hast, die bisher noch kein Ingenieur gefunden hat, schnell zum Patentamt. Da ist richtig Geld mit zu machen.
Alleine die deutlich billigeren Regler die man dann nehmen kann, da man die ganze Stromüberwachung pro Achse nicht mehr braucht.

Übrigens Habe ich bei RT nicht von 26 PWMs geschrieben, wo man "nur" Ausgänge zur frichtigen Zeit umschaltet sondern von 21 PD bzw. sogar PID Reglern, x Eingängen die nichts verpassen sollen. x Ausgängen die zur richtigen Zeit gesetzt werden sollen, dem Parsen des eigentlichen Roboterprogramms (Fahrprogram) und ggf. noch einer GUI.

Und das halt in allen Betriebszuständen.
Ohne RT mag das in den meisten Fällen und über einige Stunden gut gehen.
Aber garantieren kann das keiner.
Mit RT ist sichergestellt, das jeder Task/Prozess zur definierten Zeit rankommt.

Als Beispiel: die Driveunit meines Scorbot ER 5 Plus ist mit 4 Dual-Achskarten bestückt und könnte maximal 12 Achsen Steuern.
Zusätzlich je 6 digital Ein- und Ausgänge und je 8 analog Ein-und Ausgänge.
GUI/Programmier-/Zellensimmulationssoftware läuft auf einem PC.

Ich hatte in der Firma auch ein (IT-System) das funktioniert hat, aber alle knapp 96 Stunden kam es zu einem Timerüberlauf und es gab ganz kurz einen Fehler.
Das ging über ein Jahr gut, bis dier Zeitpunkt genau mit dem eines anderen Systems zusammenfiel. Danach war es ein Fall für die Versicherung.
Mit dem nachgewiesenen (aus den Logs war der Intervall erkennbar) Bug hatte der Hersteller dann seinen Spaß was Schadensersatzansprüche anging.

Klar schreiben wir hier in einem Forum wo es ums Hobby geht, aber wer außer dem OT weis wofür der Arm eingesetzt werden soll und ob da dann keine verlässliche Steuerung notwendig ist.
Bei eine preofessionellen CNC-Steuerung gibt es z.B. zusätzlich Watchdog Ausgänge die durch einen eigenen Task ohne IRQ ein Rechtecksignal erzeugen.
Das wird z.B. auf ein externes Sicherheitsschaltgerät gegeben (Die auch die Not-Aus Taster überwachen) und selbst wenn das RT der Steuerung und alle internen Watchdogs ausfallen, führt das Schaltgerät immer noch einen Not-Aus durch.

Beim Raspi (und auch anderen Linux Distributionen) kostet einen RT nichts, da man nur den Patch einspielen muß.
Von vorneherein damit zu planan und die Programme angepasst zu schreiben tut nicht weh.
Dafür macht man nicht alles nochmal von null an neu wenn man mit dem Timing nicht mehr von Hand hinkommt.
Und das Programm ist ja laut TO schon recht umfangreich.
28.05.2018, 12:56
HaWe

Zitat:

Zitat von i_make_it

Wenn Du das schaffst, lass es Dir patentieren. Denn dann kannst Du etwas, was kein Roboterhersteller bisher geschafft hat.
Das Signal vom Enkoder nimmt man für die Positionsregeleung. folglich wird der Fehler größer und damit wird die Drehzahl des Motors erhöht um den Fehler zu verkleinern.
Die üblichen Folgen sind dann entweder ein Getriebeschaden oder das Bauteile Verbiegen oder brechen.
Bsp.: Extremfall waagerecht gestreckter Arm und es wird um A1 gedreht (sonst keine Achse).
Der Enkoder ist formschlüssig mit der Achse verbunden (misst also die tatsächliche Position und nicht die Motordrehung).
Arm trifft nahe des TCP auf ein Hinderniss.
Spiel in Antrieben und Lagerungen erlaubt das Weiterdrehen der Achse.
Motorstrom steigt an wegen größerem Kraftbedarf.
Enkoder bildet Schleppfehler und vergrößert die Regelabweichung.
Regler versucht auszugleichen.
Elastische Verformung der Bauteile lässt weitere Drehung zu.
Motorstrom hat schon lange einen kritischen Bereich erreicht.
Enkoder Schleppfehler wird größer.
Regelung versucht noch stärker auszugleichen.
(das Ganze spielt sich in wenigen Millisekunden ab)
Jetzt könnte man, wenn man denn eeinen Vergleichswert hat, der den maximalen Schleppfehler an dieser Stelle und zu dieser Zeit der Bahnbewegung, definiert. Abschalten.

Was macht man aber mit einer Achse, die nicht Quer zur Schwerkraftsrichtung liegt?
Sondern bei der die Masse des "Werkstücks" und der Winkel des Arms relativ zur Wirkrichtung der Schwerkraft zu ständig wechselnden Schleppfehlern führt.
(Das selbe Problem hat man mit dme Motorstrom auch, aber jetzt kann man den Strom und die Positionsänderung mitenander vergleichen. Bringt mehr Strom auch mehr Bewegung oder wird die Trotz steigendem Strom kleiner, da es ein Hinderniss gibt?
auch ohne exaktes, vorherberechnetes oder aufgezeichnetes Bahnprofil kann man eine Kollision erkennen.
Die Profilaufzeichnung war mal etwas, was man Ende der 80er Jahre gemacht hat, damit gab es aber immer Probleme, da bei Änderung der Zykluszeit die Werte ja nicht mehr passten. also musste man bei jeder Änderung, über mehrere Zyklen neu anlernen.

Wie gesagt da haben sich schon alle Hersteller von Roboterarmen in den letzten Jahrzehnten Gedanken drüber gemacht.
Wenn Du da eine Lösung hast, die bisher noch kein Ingenieur gefunden hat, schnell zum Patentamt. Da ist richtig Geld mit zu machen.
Alleine die deutlich billigeren Regler die man dann nehmen kann, da man die ganze Stromüberwachung pro Achse nicht mehr braucht.

Übrigens Habe ich bei RT nicht von 26 PWMs geschrieben, wo man "nur" Ausgänge zur frichtigen Zeit umschaltet sondern von 21 PD bzw. sogar PID Reglern, x Eingängen die nichts verpassen sollen. x Ausgängen die zur richtigen Zeit gesetzt werden sollen, dem Parsen des eigentlichen Roboterprogramms (Fahrprogram) und ggf. noch einer GUI.

Und das halt in allen Betriebszuständen.
Ohne RT mag das in den meisten Fällen und über einige Stunden gut gehen.
Aber garantieren kann das keiner.
Mit RT ist sichergestellt, das jeder Task/Prozess zur definierten Zeit rankommt.

Als Beispiel: die Driveunit meines Scorbot ER 5 Plus ist mit 4 Dual-Achskarten bestückt und könnte maximal 12 Achsen Steuern.
Zusätzlich je 6 digital Ein- und Ausgänge und je 8 analog Ein-und Ausgänge.
GUI/Programmier-/Zellensimmulationssoftware läuft auf einem PC.

Ich hatte in der Firma auch ein (IT-System) das funktioniert hat, aber alle knapp 96 Stunden kam es zu einem Timerüberlauf und es gab ganz kurz einen Fehler.
Das ging über ein Jahr gut, bis dier Zeitpunkt genau mit dem eines anderen Systems zusammenfiel. Danach war es ein Fall für die Versicherung.
Mit dem nachgewiesenen (aus den Logs war der Intervall erkennbar) Bug hatte der Hersteller dann seinen Spaß was Schadensersatzansprüche anging.

Klar schreiben wir hier in einem Forum wo es ums Hobby geht, aber wer außer dem OT weis wofür der Arm eingesetzt werden soll und ob da dann keine verlässliche Steuerung notwendig ist.
Bei eine preofessionellen CNC-Steuerung gibt es z.B. zusätzlich Watchdog Ausgänge die durch einen eigenen Task ohne IRQ ein Rechtecksignal erzeugen.
Das wird z.B. auf ein externes Sicherheitsschaltgerät gegeben (Die auch die Not-Aus Taster überwachen) und selbst wenn das RT der Steuerung und alle internen Watchdogs ausfallen, führt das Schaltgerät immer noch einen Not-Aus durch.

Beim Raspi (und auch anderen Linux Distributionen) kostet einen RT nichts, da man nur den Patch einspielen muß.
Von vorneherein damit zu planan und die Programme angepasst zu schreiben tut nicht weh.
Dafür macht man nicht alles nochmal von null an neu wenn man mit dem Timing nicht mehr von Hand hinkommt.
Und das Programm ist ja laut TO schon recht umfangreich.

@i_make_it
da hast du das mit dem zusätzlichen Encoder völlig falsch verstanden: er soll nur die aktuelle Position zurückliefern, wo der Arm gerade steht, und auch um festzustellen zu können, ob und wann der gewünschte Endpunkt erreicht worden ist, aber der Encoderwert soll nicht direkt in eine Steuerung eingehen - das wurde nirgends behauptet.
Nur eine Rückmeldung über die Stellung war ja das, was der OP wollte, und das ist mit einem Rotationsencoder wirklich kein Hexenwerk. Wie der OP dann mit der gemessenen Stellung programmtechnisch umgeht, ist ein ganz anderes Thema.

Was RT angeht, versuchst du dich wieder rauszureden - aber es wird dir nicht gelingen...:
Du hast erst behauptet, ein RT kernel wäre notwendig, und das stimmt allgemein betrachtet NICHT.
Manchmal vlt ja, evtl. zB auf singlecore-cpus, aber wie oben mit Quellen belegt: z.B. nicht auf einem Raspi mit Quadcore ARM und Jessie oder Stretch.
Das betrifft sowohl pwm-Generierung für Servos als auch GPIO-R/W, (edit: ) als auch Programmcode, wenn du genau nachliest.

Ich habe auch nicht behauptet, dass RT hinderlich wäre - aber nötig, wie von dir behauptet, ist es eben im allgemeinen nicht.
Wie man das genau erreicht, habe ich auch erklärt (bzw. verlinkt) .

Letztendlich aber wollte der OP laut TOP einen Roboterarm (Hardware) für ein Linux-C++-Programm, und ein Programm scheint er ja zu haben.
Daher sollte man hier on-topic bleiben und nicht immer wieder durch off-topic Einwürfe (und dann zu allem Übel auch noch falsche oder fehlerhafte) dieses Topic zerfasern und verwässern.

Falls der OP Infos zur Ansteuerung möchte, möge er ein eigenes Topic öffnen.

Bleibt zu ergänzen, dass der OP eingangs ja von eimem "PC" mit Linux sprach .... und man dabei auch nicht vergessen sollte, dass der Raspi selber ja (auch) ein vollwertiger Linux PC ist.
28.05.2018, 15:46
i_make_it

Zitat:

Zitat von Willi1

Außerdem soll der Arm (bzw. der einzelne Motor) es unbedingt zurückmelden, wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann (, weil da ein Hindernis ist, oder so).

Also der Arm oder einzelne Motor soll unbedingt zurückmelden wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann Das ist allgemein eine Kollissionserkennung.
Entweder plant man eine Roboterzelle und definiert Sperrzonen in die kein Teil des Arms hineinkommen darf.
Oder in der Realen Umgebung halt mit Drehmoment erfassung über den Motorstrom, eigenen Drehmomentsensoten (Teil der mechanischen Konstruktion des Arms) oder Taktilen-/Näherungssensoren.
Von Enkodern steht im Einganspost gar nichts nur diese klar definierte Bedingung. Die halt mit Positionsmeßsystemen so nicht erfüllt werden kann.

Ich habe geschrieben ohne RT wird die Regelung sonst nicht sehr zuverlässig.
Unzuverlässig geht also im Umkerhschluss auch ohne RT.
Bei der Anzahl An Reglern und dem weiteren Code ist das mit der Zuverlässigkeit halt so ene Sache. sonst müsste man das Ganze Spiel auch nicht bei Roboter, SPS und CNC Steuerungen betreiben. Man kann es ohne machen ja aber dann nicht mehr zuverlässig in allen Betriebsszuständen.

Da ich davon ausgehe, das man wenn man schn bis 1000€ ausgeben will, ein System erstellen will was zuverlässig/robust ist und nicht immer mal was macht was es nicht soll.
Bei einem Arm der 400Gramm händeln kann, ist das nur doof. Bemerkt man diese Fehler aber nicht und denkt sich, kann man jetzt ja auch mal größer bauen, ist das schnell nicht mehr nur doof sondern von Teuer über schmerzhaft bis zu schlimmeren.
Wenn das alles egal ist, kann man sich auch für 40€ einen Vellman Robotic Arm aus Plastik holen und mit rumspielen.
Dann ist baer keine der Bedingungen des Eingangsposts erfüllt.
Allerdings 40€ für den Arm, ein 6V Netzteil, und 5 H-Brücken sind auch deutlich günstiger.
Enkoder hat man da dann aber auch nicht.

habe grade in der Bucht geschaut, da gibts grade eine Auktion eines Mitsubishi Movemaster RV-M1 mit Drive Unit. Halt zum selbstabholen.
Aber aktuell 201€ bei 28 Stunden Restlaufzeit der Auktion.

Schaut man sich dort aber die Preise für gebrauchte an, stellt man fest das man eigentlich nur die verschiedenen Kickstarter Kanidaten für unter 1000€ bekommt.
28.05.2018, 17:52
HaWe

Zitat:

Zitat von i_make_it

Also der Arm oder einzelne Motor soll unbedingt zurückmelden wenn die angeforderte Bewegung nicht oder nur teilweise durchgeführt werden kann Das ist allgemein eine Kollissionserkennung.
Entweder plant man eine Roboterzelle und definiert Sperrzonen in die kein Teil des Arms hineinkommen darf.
Oder in der Realen Umgebung halt mit Drehmoment erfassung über den Motorstrom, eigenen Drehmomentsensoten (Teil der mechanischen Konstruktion des Arms) oder Taktilen-/Näherungssensoren.
Von Enkodern steht im Einganspost gar nichts nur diese klar definierte Bedingung. Die halt mit Positionsmeßsystemen so nicht erfüllt werden kann.

Ich habe geschrieben ohne RT wird die Regelung sonst nicht sehr zuverlässig.
Unzuverlässig geht also im Umkerhschluss auch ohne RT.
Bei der Anzahl An Reglern und dem weiteren Code ist das mit der Zuverlässigkeit halt so ene Sache. sonst müsste man das Ganze Spiel auch nicht bei Roboter, SPS und CNC Steuerungen betreiben. Man kann es ohne machen ja aber dann nicht mehr zuverlässig in allen Betriebsszuständen.

Da ich davon ausgehe, das man wenn man schn bis 1000€ ausgeben will, ein System erstellen will was zuverlässig/robust ist und nicht immer mal was macht was es nicht soll.
Bei einem Arm der 400Gramm händeln kann, ist das nur doof. Bemerkt man diese Fehler aber nicht und denkt sich, kann man jetzt ja auch mal größer bauen, ist das schnell nicht mehr nur doof sondern von Teuer über schmerzhaft bis zu schlimmeren.
Wenn das alles egal ist, kann man sich auch für 40€ einen Vellman Robotic Arm aus Plastik holen und mit rumspielen.
Dann ist baer keine der Bedingungen des Eingangsposts erfüllt.
Allerdings 40€ für den Arm, ein 6V Netzteil, und 5 H-Brücken sind auch deutlich günstiger.
Enkoder hat man da dann aber auch nicht.

habe grade in der Bucht geschaut, da gibts grade eine Auktion eines Mitsubishi Movemaster RV-M1 mit Drive Unit. Halt zum selbstabholen.
Aber aktuell 201€ bei 28 Stunden Restlaufzeit der Auktion.

Schaut man sich dort aber die Preise für gebrauchte an, stellt man fest das man eigentlich nur die verschiedenen Kickstarter Kanidaten für unter 1000€ bekommt.

ok, wir können das gerne weiter diskutieren mit dem Thema "Zuverlässigkeit".
ich vermute, du hast dir die von mir verlinkten Threads nicht komplett richtig durchgelesen.
Also:
Warum soll ein Multicore-Linux System (ohne RT) nicht zuverlässig sein?
Probleme gibt es nur, wenn der kernel als Besitzer der cpu diese unvorhersehbar erheblich bis komplett in Beschlag nimmt.
"Meine" Lösung war 3-stufig:
1.) Hardware-Timing
2.) Multithreading mit hoher pthread thread-priority für zeitkritische Threads ("normal wichtige" Linux-threads haben die priority=40 (CMIIW), alles was im eigenen Roboterarm-Programm höher priorisiert ist, wird also auch vom kernel gegenüber anderen threads bevorzugt (z.B. 60-100)
3.) dem kernel optional per setup zusätzlich verbieten, 1-2 der 4 cores überhaupt zu verwenden für sein OS Scheduling, und das eigene Roboterprogramm nur auf den 1-2 reservierten ausführen: Dann verhalten sich diese 1-2 reservierten cores wie µC-cores im bare-metal-Betrieb - und da pfuscht jetzt kein Linux Userspace mehr unvorhersehbar rein.

So what?

das mit den Encodern gebe ich auf, es dir erklären zu wollen.
Aber du musst es ja auch nicht verstehen, sondern der OP, wenn es ihn interessiert.
29.05.2018, 17:30
HaWe

den hier habe ich zufällig gerade noch entdeckt - schön dran ist, dass er fertig zusammengebaut ist, und dass die 6 durchweg verbauten LD-1501 Servos mit höchstwahrscheinlich (?) ~1,7Nm bei 7,2V etwas stärker sind als die in meinem obigen, ersten Link.

https://www.ebay.de/itm/Assembled-6D...53.m1438.l2649

der PS2 Controller mit Interface ist ne nette Zugabe und kann mit Sicherheit durch Servoplatinen (z.B. PCA9685) für Arduinos oder Raspis ersetzt werden.
Ich denke, der könnte mich auch interessieren.

edit,
ja scheint zu stimmen mit dem Drehmoment: Pololu schreibt 240 oz-in, das sind rund 1,7 Nm : https://www.pololu.com/product/1057