Spezieller Roboterarm gesucht

[HaWe]

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.