Zitat Zitat von i_make_it Beitrag anzeigen
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.