Arexx Roboterarm MINI RACS positioniert trotz Kalibrierung falsch

[Pali64]

Hallo liebe RoboterArm benutzer und Bauer.

Erst einmal Danke für das Forum, super Sache

Schnell was zu mir: Ich programmiere eigentlich hauptsächlich in Assembler und NICHT ardunio habe also Proböleme damit, einfach weil ich andere Prozis Programmiere und ihn nicht kenne.
Auch ligt mir "C" nicht wirklich (Bring gerade mal mit Müh und Not ein par Mod's in bestehende Programme hin).
Nun habe ich mir einen Arexx MINI zugelegt (Normalerweise Programmiere ich Große von Fanuc und Kuka usw) nun habe ich aber Probleme damit und im Arexx Forum scheint Funkstille zu herrschen. Deswegen hoffe ich hier Hilfe zu finden.

Nach angehenden Startschwierikeiten mit Win7 64 Bit habe ich nun mit dem XP Emulator doch noch hingekrigt den Loader zum laufen zu bringen.
Nun alles ausgeführt Kalibriert und RACS_v3_HEX für meinen Mini V3 geladen.
Soweit funst fast alles nur das Trotz ausgeführter Kalibration die positionen nicht stimmen. das wäre weiter eigentlich nicht schlimm, wen nicht das Problem bestehen würde das Servo 3 die eine Position nicht erreichen kann, dafür aber in der anderen Position den Servo an seine Lastgrenze bringt!
Habe dan eines der beigelegten Demoprogramme in den Mikrokontroller geladen, und die Positionen angepasst, dan fährt der Arm alle Positionen richtig an und er kann auch servo 3 in die Endposition bringen (Arm schön zusammenlegen) also ligt es devinitiv nicht am Zusammenbau oder Servo.
Auch wenn ich nach der Kalibrierung den Test ausführe verhält sich Servo 3 Richtig (und die andern alle auch).
Sobald ich nun aber wieder in die RACS software gehe, positioniert er wieder falsch (So wie wenn im die Kalibrierung eigentlich egal wäre)
So kann ich dan den Arm nicht (Schön zusammenlegen) biis ich den Servopower Haken wegklicke, dan legt der arm sich richtig zusammen [Klar ohne strom ]
Wo liegt das Problem? Ignoriert die Racs Software die Kalibrierung?
Wie kann ich Servo 3 dazu bringen doch in die Endposition zu Fahren (Erreiche sonst nicht den gewünschten Actionsbereich)

Es wäre auch toll wen man die Geschwindigkeit und nicht nur die Positionen dem Arm senden könnte.
Vieleicht hat ja jemand von euch ein Programm für diesen Arm geschrieben mit welchem ich dan diesen von Meinen Programmen auf den PC über Schnitstellen befehle steuern kann?
Leider fehlen mir nämlich auch da die Informationen wie man den Arm anspricht.
Wie ich oben schon geschrieben habe bin ich leider nicht in der Lage ein Programm für den Ardunio selber zu schreiben (Kein Werkzeug und zu wenig Wissen über Ihn).
Und eine Neue Steuerung dazu mit den Prozessoren die ich sonst verwende ist mir zu aufwendig, (dafür habe ich mir ja den Arexx MINI Gekauft)

Bitte um Hilfe DANKE

Liebe Grüße an Alle Pali64

[Dirk]

Hi Pali64,

die Kalibrierung dient nur zur Festlegung der 0-Position der Servos auf der Ebene des Atmega und wird möglicherweise im RACS Programm nicht genutzt. Leider ist der Sourcecode davon nicht veröffentlicht.

Wenn du eigene Programme für den Atmega des Arms schreibst (z.B. in GCC oder Assembler), dann kannst du darin die Kalibrierungswerte nutzen, sie befinden sich dann im EEPROM des Atmega.

Übrigens: Mit einem Arduino hat der Controller des MINI RACS nichts zu tun.

[Pali64]

Danke Dirk für deine Antwort.
Wie schon geschrieben, auch ATMEGA ist für mich "Unbekanntes Land" ich arbeite mit Industriesteuerungen und habe deshalb mit diesen MC's keinerlei erfahrung.
Das heißt demzufolge: Entweder ich Lerne Ardunio zu proggen, oder Baue eine andere Steuerung ein(Was ja beides nicht gerade mein Ziel ist) oder ich Suche einen anderen Roboter?

Sind keine Rosigen Aussichten! hat irgend jemand eine Software die ich in den Arm laden kann, welche ich dann mit Hilfe eines bekannte (oder mindestens Mitgeteilten) Protokoll ansprechen kann?

Offen gesagt habe ich nicht die Zeit dazu mir das Werkzeug zuzulegen und mir dann Atmega anzueignen. Den da würden die Anderen Projekte darunter leiden.
Falls irgend jemand eine Software hat die auch funst, wäre ich sehr froh darüber.
Analog dazu werde ich mal versuchen Arexx dazu zu bewegen den Sourcecode rauszugeben.
Damit denke ich wäre auch anderen geholfen.

Gruß Pali64

[Dirk]

Das heißt demzufolge: Entweder ich Lerne Ardunio zu proggen, oder Baue eine andere Steuerung ein(Was ja beides nicht gerade mein Ziel ist)...

Nochmal:
Der Controller, der zum MINI RACS gehört, hat mit Arduino NICHTS zu tun und wird also auch nicht "in Arduino programmiert", sondern z.B. in GCC, Bascom oder Assembler.

Wenn du den Arm via PC Programm steuern willst, must du für den Controller des Arms ein Programm (GCC/Bascom...) schreiben, das auf entsprechende Befehle ("Protokoll") vom PC (via USB, serieller Schnittstelle, ...) reagiert und diese in Servopositionen umsetzt.

[Pali64]

Hallo Dirk,
Besten Dank für deine Antwort.
Ja habe ich verstanden war ein Vierschreiber meinerseits SORRY ist mir Klar ATMEGA.
Das ändert aber leider nix daran das ich weder Programmer noch Werkzeug für den MC habe.
Und das schlimmste weder Zeit noch Erfahrung damit.
Den zwischen Industrie und MC klafft eine Kluft der Entwicklung.
Manchmal habe ich das Gefühl die Industrie hängt noch im Letzten Jahrhundert (Siehe Kuka oder Fanuc)
da gilt wohl (never touch a running system), aber ich muss nun mal Kunden-bedingt damit leben.....
so habe ich aber meine Regen Probleme mich mit ATMEGA & Co klar zu kommen.

Deshalb wäre ich nach wie vor froh um Unterstützung von jemandem der damit (ATMEGA & Co) Erfahrung hat..

Gruß Pali64 und nochmals danke dir Dirk für die Antworten.

[Pali64]

Arbeitet hier niemand mit der RACS Software? Weder im AREXX Forum noch hier eine Antwort auf mein Problem?
oder habt ihr alle den MINI von Arexx in die Ecke gestellt hmm?.?
He Leute ich brauche HILFE weil ich echt mit dem ATMEGA & Co überhaupt nicht klar komme und auch kein Werkzeug dazu habe

[oberallgeier]

.. Es wäre auch toll wen man die Geschwindigkeit und nicht nur die Positionen dem Arm senden könnte ..

Na ja, für eine (halbwegs) saubere Bahnsteuerung ist das nötig - und das sogar für die einzelnen Gelenke. Die perfekte Bahnsteuerung rechnet dann aus Bewegungsrichtung (bzw. Abfahrt-Ziel) des TCP die erforderliche Geschwindigkeit der einzelnen Gelenke aus, prüft jedes einzelne Gelenk auf individuelle Maximalgeschwindigkeit und berechnet beim Überschreiten von einem Maxiumum oder mehreren Maxima "rückwärts" die mögliche, zulässige Geschwindigkeit des TCP. Andernfalls treten merkliche Bahnabweichungen auf.

[Pali64]

Hallo oberallgeier,
Wie recht du damit hast, zeigt sich bereits wenn man die Abarbeitungsgeschwindigkeit bei RACS zu hoch stellt.
Der Arm fährt die Positionen nicht mehr korrekt an, und "Räumt" die umliegenden "Utensilien" weg
Das heißt man will etwas von A nach B mit dem Arm transportieren, Geht es Schritt für Schritt durch bis alles passt.
Dann will man das Programm abfahren und bei zu schnell eingestellter Abarbeitung hebt die Software den Arm zu wenig an.
Damit stößt er dann alles um was er vorher schön positioniert hat....
Iwi ist RACS wohl keine Software sondern eher ein Armutszeugnis
Hoffe immer noch auf Hilfe aber habe die Hoffnung langsam verloren.
So wie es aussieht ist RACS wohl von niemandem verwendet...Schade eigentlich.

Gruß Pali64

[oberallgeier]

.. So wie es aussieht ist RACS wohl von niemandem verwendet...Schade eigentlich ..

Nicht hilfreich ist die Vermutung dass das Teil öfters verkauft wird, aber die Betreiber (hier kommt "betreiben" von "betrübt") resignieren und mit den Unfertigkeiten und Unpässlichkeiten leben.

Dir viel Glück damit. EINE Lösung wäre es selbst Hand anzulegen.

Wir (Sternthaler, mare_crisium, andere und ich) hatten uns vor Jahren über Bahnsteuerung (neee, eigentlich über Bahnplanung) unterhalten. Wenns Dich interessiert, etwa ab hier (auch noch davor). Dazu hatte ich einige Anlagen zum Thema beigesteuert; die sind in den genannten Postings erreichbar.

Nachtrag: Meine im genannten Thread vorgestellten Abläufe betreffen die Berechnung in einer Koordinatenebene. Da sich der Roboter üblicherweise im R3 bewegt müssen die Abläufe für jede der drei Projektionen separat erledigt und danach durch superponieren zusammengebaut werden. UND jetzt kommt natürlich der Gag dazu, dass die resultierenden Kurvengeschwindigkeiten in den Raumkurven schon wieder zu groß sein können - - und zu verschiedenen Zeiten anfangen (Folge: taumelnde Übergänge). Dann geht die Arbeit weiter - *gg*.