Robotersteuerung auf Linuxbasis erfordert kein RT Linux, das ist Unsinn.Zitat von i_make_it
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 !!
Geändert von HaWe (26.05.2018 um 23:00 Uhr)
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?
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.
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.
Geändert von i_make_it (27.05.2018 um 14:13 Uhr)
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"
Geändert von HaWe (27.05.2018 um 16:33 Uhr) Grund: typo
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.
Geändert von i_make_it (28.05.2018 um 11:43 Uhr)
@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.
Geändert von HaWe (28.05.2018 um 16:36 Uhr) Grund: typo
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.
Geändert von i_make_it (28.05.2018 um 16:53 Uhr)
Berechtigungen
Zitieren
Lesezeichen