Roboterarm mit (noch nicht) linearer Wegführung

Fussballroboter, Autofabrik...
Modellideas &- presentation - Soccerrobot, Carfactory...
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von juh » 05 Jun 2019, 22:15

Hallo,

eine Frage an die Roboterprofis unter Euch, mir fehlt leider der fachliche Hintergrund, um mit vertretbarem Aufwand selbst weiter zu kommen:

Ich arbeite gerade an einem teach-in ft-Roboterarm dieser Bauart, allerdings mit Schrittmotoren an den drei Bewegungsachsen, gesteuert per C++/Arduino. Das Projekt ist eigentlich bis auf diverses Finetuning fertig und hinsichtlich meiner Ziele funktional. Was ich aber noch nicht hinbekommen habe, sind lineare Bewegungen des Arms von Punkt a nach Punkt b im kartesischen Koordinatensystem, also z.B. eine streng senkrechte Bewegung von a nach b.
resized_DSC_2427.JPG
Ein erster Video, am Anfang erfolgt das Homing, dann wird ein gespeicherter Pfad geladen und abgespielt:
https://youtu.be/DN5k5yBPx5c

Was klappt und was ich mir algorithmisch noch selbst gut herleiten konnte (Cosinus-Satz etc.), ist die kartesischen Koordinaten der Punkte a und b in die erforderlichen Winkelstellungen der beteiligten Achsen zu übersetzen und damit die Position b zielsicher anzufahren. Was ich auch noch hinbekomme ist, die Achsen so aufeinander abzustimmen, dass alle gleichzeitig am Ziel ankommen. Die AccelStepper library sorgt dabei für butterweiche Beschleunigungen.

Aber: der Weg ist halt nicht linear sondern je nach Strecke gekrümmt, v.a. bei den längeren Strecken kommt es unterwegs zu erheblichen Ausschlägen. Beim teach-in ist das äußerst lästig, weil man erst beim Abspielen merkt, dass ein Hindernis, das linear gar nicht im Weg wäre, angerumpelt wird. Natürlich kann man die Sicherheitsabstände vergrößern oder manuell Zwischenhalte einfügen, das ist aber wenig elegant.

Naiv würde ich eine Lösung durch Interpolation weiterverfolgen, also die Strecke in mehrere Intervalle einteilen, um v.a. grobe Ausschläge zu unterdrücken. Das impliziert vermutlich, dass ich die Beschleunigungen selbst implementieren muss, schließlich will ich zusätzlich eine fließende Bewegung über die gesamte Strecke.

Ich nehme an es gibt passende Lehrbuchkapitel oder Paper zu dem Problem (davidrpf hat hier auf Entsprechendes für Delta-Roboter verwiesen), mit meinem Vorwissen und Zeitbudget stoße ich dabei allerdings vermutlich an meine Grenzen, daher freue ich mich insbesondere über konkrete Tipps oder Hinweise auf fertige oder adapierbare Beispiele für diese Problematik.

Um das Problem zu vereinfachen wäre ich übrigens schon mit einer 2-Achsen Lösung hochzufrieden, die also nur die Armgelenke berücksichtigt und die Rotation der Basis außer Acht lässt.

lg
Jan

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von Karl » 05 Jun 2019, 22:44

Hallo Lars,
falls ich Dein Problem verstanden habe, googel mal nach "Lemniskate".
Hafenkrane sind meist nach diesem Prinzip gebaut weil der Last-Haken, in einem gewissen Bereich
der horizontalen Bewegung des Auslegers, die Höhe beibehält.
Für vertikale Bewegungen entsprechend umdenken.
Gibt auch ein ähnliches Fischertechnik-Modell im Kasten "Advanced Universal -Starter.
Vielleicht hilft es Dir weiter. :)
Zuletzt geändert von Karl am 05 Jun 2019, 22:57, insgesamt 1-mal geändert.

Benutzeravatar
fishfriend
Beiträge: 1791
Registriert: 26 Nov 2010, 11:45

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von fishfriend » 05 Jun 2019, 22:48

Hallo...
Bresenham?
2-Achsen - Abweichung - zu einer "linearen" Bewegung.
Im Grunde auch eine Zerlegung in kleine Schritte - nur halt das Y auch mehrere Schritte machen kann.
Manche der Erklärungen dazu, erwingen/setzen voraus einen Schritt in X-Richtung zu machen!

Man kann bestimmt auch eine dritte Achse dazu nehmen. Sooo schwer ist das auch nicht. Ich denke das es da noch andere Möglichkeiten gibt.
Wenn ich mir echte Roboter anschaue, kann man manchmal sehen wie ungenau die bei Bewegungen sind. Manche Zeigen das sogar an.

Meist kommt noch eine Weitere Regelung dazu die von der Last abhängig ist und noch die Massenträgheit einrechnet.
Sprich es ist ein Unterschied ob der Greifer gegriffen hat oder nicht.

Ich hab das Ganze mal für einen ft Plotter umgesetzt mit RoboPro. Gibts glaube ich noch im Download hier. Unter "Beschreibung" im RoboPro Programm gibts eine Erklärung.
Gruß
fishfriend
Holger Howey

PS Man kann das auch mit Winkeln machen.
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
fishfriend
Beiträge: 1791
Registriert: 26 Nov 2010, 11:45

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von fishfriend » 05 Jun 2019, 23:03

Hallo...
Lemniskate
Ja da hatte ich auch erst dran gedacht. Interessantes Thema und geht sogar mit Differenzialen wie bei den Marsrobotern. Wobei ich mich immer gefragt habe wie da MIT darauf ein Patent bekommen hat, für eine Technik die schon so alt ist, also Dampfmaschinenzeit.
Problem ist halt das die Kolbenstange eine gerade Bewegung machen soll. Ich glaube Watt hatte gesagt das dies seine wichtigste Erfindung gewesen sei und nicht die Dampfmaschine selbst.
Ist eine Interessante Lösung übrigens auch bei Hafenkränen die bei unterschiedlichen Armlängen eine lineare Bewegung hinbekommen. Du hast ja "nur" parallele Achsen bei dem Modell.
Gruß
fishfriend
Holger Howey

Etwas OT Lemniskate
PS Es gibt etwas was mich richtig Ärgert bei dieser Sache. Hier haben wir eine Technik womit man größere Hindernisse überwinden kann - im Verhältniss zum Raddurchmesser und Achshöhe,
wie es sonst bei normalen Fahrzeugen möglich ist. Warum - also wirklich - warum liebe Entwickler gibt es noch keine Produkte auf der Erde die das Sinnfoll einsetzen?
Elektrische Rollstühle haben solche Schwierigkeiten einen Bordstein oder eine Treppenstufe rauf zu kommen - warum wird diese vorhandene Technik nicht dafür eingesetzt?
Ich glaube vor 4 oder 5 Jahren hab ich mal ein ft Modell dazu gemacht. In der Realität ist dazu aber noch nichts angekommen.
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von Karl » 06 Jun 2019, 01:22

Hallo Holger,
"Lemniskate" - Die Hafenkrane habe ich nur als Beispiel genommen,
allein damit man sich eine Vorstellung für einen Einsatz machen kann.
Habe noch beigeschrieben für welchen Zweck diese Kurve an dem
Kran verwendet wird.
Der Ausdruck ist aus der Mathematik/Geometrie übernommen.

Wo ist ein Bild deines "Rollstuhl-Models"?

davidrpf
Beiträge: 252
Registriert: 14 Jul 2015, 14:27
Kontaktdaten:

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von davidrpf » 06 Jun 2019, 07:53

Hallo Jan,

es freut mich, dass du dich mit dem Thema Industrieroboter beschäftigst und dein Leichtbau Ansatz für einen dreiachsigen Knickarmroboter gefällt mir sehr gut! Kennst du schon meine Autofabrik? Der Montageroboter nutzt hierbei eine ähnliche Kinematik.

Nun zum eigentlichen Problem: Der Bresenham Algorithmus dürfte dein Problem nicht lösen können. Man kann ihn dazu verwenden, eine endliche Anzahl an Punkten auf einer linearen Bahnkurve zu bestimmen. Dann besteht aber immer noch das Problem, dass die Funktion, die kartesische Koordinaten auf Winkel (der Achsen des Roboters) abbildet, ich nenne sie im folgenden "Inverse Kinematik", nicht linear ist.
Ich habe das Problem beim Delta Roboter und der Autofabrik intuitiv auch wie du gelöst, indem ich die lineare Bahnkurve in sehr kleine Abschnitte zerlegt habe. Betrachtet man die Zeit-Geschwindigkeitsfunktion jeder Achse, wird man jedoch eine Zick-Zack Kurve erkennen, was nicht wirklich schön ist. Durch Anpassungen an der Schrittmotorsteuerung kann man das Problem eindämmen, sodass die Geschwindigkeit der Motoren näherungsweise konstant ist. Allerdings fällt so die Beschleunigung der Schrittmotoren quasi weg, weshalb man nur relativ niedrige Geschwindigkeiten einstellen kann.

Wie würde man das Problem also richtig lösen? Ich gehe davon aus, dass real-time Path-planning die Lösung für dieses Problem ist. Das ist mathematisch aber nochmals deutlich anspruchsvoller und ich habe auch noch nicht die Zeit gefunden, mich intensiv damit zu beschäftigen. Wenn du eine fertige Lösung bevorzugst, könntest du mal schauen, ob es vielleicht fertige Libraries zum Thema Inverse Kinematik von Knickarmrobotern gibt. Ich habe in einem anderem Zusammenhang auch schon gelesen, dass es sich ggf lohnt, eine 3D Drucker Firmware dahingehend anzupassen, dass sie mit der neuen Kinematik zurechtkommt.

Den Ansatz mit Lemniskaten bei Kränen kannte ich noch nicht, ich denke, dass es sich lohnt dies auch nochmals genauer anzuschauen.

Gruß
David
Polarkoordinaten Plotter https://youtu.be/u6XwKxZuxqk
Autofabrik: https://youtu.be/mX9JWcca6kQ

Benutzeravatar
fishfriend
Beiträge: 1791
Registriert: 26 Nov 2010, 11:45

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von fishfriend » 06 Jun 2019, 08:57

Hallo...
@Karl Ich hatte das Modell auf einer ft Ausstellung in Münster gezeigt. Damals noch im HBZ. Ich meine das es Bilder gibt. Ansonsten muss ich noch mal auf die Suche gehen.
Ich hatte merere Modelle dazu, auch einen normalen Rollstuhl und ein Modell nur mit der Mechanik. Das war auch zum ausprobieren für Kinder, um zu zeigen warum das mit Rädern ohne eigenen Antrieb nicht geht...

Ich gehe mal davon aus das 3D Drucker nur eine Ebene erstellen und ein eigenes Hoch und Runter haben. Somit zerfällt die Bewegung wieder nur in X-Y-Schritte.
G-Code gibt nur die Anfangs und Endposition an. Somit bleibt der Bresenham-Algorithmus um eine "lineare" Bewegung zu machen.

Man kann, wie bei echten Robotern auch, eine Überwachung der Ist-Position machen und um keine Dinge um- oder anzufahren, Bereiche definieren, wo er sofort stoppt.
Schade das die Beiträge vom alten Forum weg sind. Da hatten wir damals darüber gesprochen.

Gruß
fishfriend
Holger Howey

PS Ich -meine- eine "Mini"-Erklärung war in der Anleitung vom alten grauen Trainingsroboter. Der hatte ja auch das Problem aus Kruven heraus Punkte anzufahren.
Bin mir aber nicht sicher. Ich schau noch mal meine Sachen durch.
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von Defiant » 06 Jun 2019, 18:47

Mir fällt gerade leider auch nichts ein, aber die Frage die mir gerade in den Sinn kommt: Kann es auch vorkommen, dass es bei linearer Wegführung zu einer Kollision kommt?

MoveIt z.B. verfolgt übrigens den Ansatz die Strecke in kleine Teile zu zerlegen und dabei kontinuierlich zu prüfen ob es dabei zu einer Kollision kommt.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

davidrpf
Beiträge: 252
Registriert: 14 Jul 2015, 14:27
Kontaktdaten:

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von davidrpf » 06 Jun 2019, 19:51

Defiant hat geschrieben:Mir fällt gerade leider auch nichts ein, aber die Frage die mir gerade in den Sinn kommt: Kann es auch vorkommen, dass es bei linearer Wegführung zu einer Kollision kommt?

MoveIt z.B. verfolgt übrigens den Ansatz die Strecke in kleine Teile zu zerlegen und dabei kontinuierlich zu prüfen ob es dabei zu einer Kollision kommt.
Vielen Dank für den Link. Das Projekt sieht sehr interessant aus und bestätigt meine Vermutung, dass ein aufwändiger Path Planning Algorithmus benötigt wird. Angesichts des Umfang eines solchen Projekts dürfte ein einzelner Hobby Entwickler sowas kaum alleine umsetzen können.

@fishfriend: Du hast recht, dass 3D Drucker meistens nur in einer Ebene drucken und somit bloß zwei Achsen simultan bewegen. Mit dem Bresenham Algorithmus gelingt die Synchronisierung dieser Achsen, während eine Gerade gedruckt wird. Allerdings kann er nicht das Thema Beschleunigung lösen, sobald eine Richtungsänderung auftritt. Was man bei guten 3D Druckern (bzw. bei einer guten Firmware) häufig beobachtet, ist, dass "abgeknickte" Kurven nachgefahren werden können, ohne dass der Druckkopf vollständig abbremst. Dies erfordert eine raffinierte Trajektorienplanung, die die maximale erreichbare Geschwindigkeit sowie Beschleunigung einbeziehen muss.

Gruß
David
Polarkoordinaten Plotter https://youtu.be/u6XwKxZuxqk
Autofabrik: https://youtu.be/mX9JWcca6kQ

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von juh » 06 Jun 2019, 20:43

Hallo und danke erst mal für die lebhafte Diskussion.

@Karl und @Holger: Ich glaube das sind eher weiterführende Gedanken als Lösungsansätze für mein Problem. Zu Bresenham hat David ja schon geschrieben. Und Lemniskate ist interessant, aber ich will ja keinen neuen mechanischen Aufbau. Abgesehen davon leistet die Lemniskate, soweit ich das verstanden habe, eine lineare Wegführung nur in einer einzelnen Richtung, z.B. horizontal, nicht aber in beliebige Richtungen wie ich es brauche, und die algorithmische Frage wäre auch hier noch offen. Übrigens mein Google-Tipp: nehmt noch das Stichwort "Kran" dazu, sonst droht ein Esoterik-Schock. :o :D

@David: Danke für das Feedback, freut mich sehr. Den Video zur Autofabrik hatte ich in der Tat schon einmal angeshen, aber nicht mehr in Erinnerung, dass es da einen ähnlichen Roboter gibt.

Interessant, dass Du die Lösung auch bei Intervallen gesehen (und gefunden) hast. Ich glaube ich werde mich mal dran versuchen. Auf das Stichwort "Inverse Kinematik" war ich auch schon gestoßen, habe das aber erst nach Deinem Kommentar gerade nochmal gründlicher angesehen. Libraries gibt es in der Tat, v.a. für Python und Java. Sehr interessant auch dieser Überblicksreport, wenn ich richtig verstehe fällt der auch von mir verfolgte Ansatz per Cosinus-Satz unter Kap. "3.6.2 Triangulation Inverse Kinematics". Beeinrduckend, wie viele andere Ansätze existieren, wobei es insgamt um deutlich komplexere Anforderungen durch mehrgelenkige Arme geht. Mein Arm ist eigentlich ein Sonderfall, da es aufgrund der wenigen Gelenke und eingeschränkten Winkelbereiche immer nur eine Lösung je Zielpunkt gibt. Besonders interessant fand ich übrigens den FABRIK-Algorithmus.
Defiant hat geschrieben:Mir fällt gerade leider auch nichts ein, aber die Frage die mir gerade in den Sinn kommt: Kann es auch vorkommen, dass es bei linearer Wegführung zu einer Kollision kommt?
@Defiant: Ich glaube, Deine Frage geht von einem Arm mit Sensorik aus. Hier geht es ja um einen blinden und "dummen" Trainings-Roboter, der nichts von seiner Umgebung weiß. Dessen Wegpunkte sollte ich natürlich so trainieren, dass nichts im Weg ist. Wenn der Weg von a nach b aber nicht linear abgefahren wird, und man beim Trainieren das "Ausschlagen" aufgrund der eingangs beschriebenen Problematik nicht berücksichtigt, kann es eben zu Kollisionen kommen, obwohl der direkte Weg frei ist. Mir (und meinen Kindern) ist es bei Tests mit dem Modell deshalb laufend passiert, dass der Greifer knapp an einem Hindernis hängen bleibt. Daher mein Wunsch nach einer algorithmischen Verbesserung, die (annähernd) lineare Wege von a nach b schafft.

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von Defiant » 06 Jun 2019, 21:14

davidrpf hat geschrieben: Das Projekt sieht sehr interessant aus und bestätigt meine Vermutung, dass ein aufwändiger Path Planning Algorithmus benötigt wird. Angesichts des Umfang eines solchen Projekts dürfte ein einzelner Hobby Entwickler sowas kaum alleine umsetzen können.
Das ist auch der Ansatz hinter ROS: Anstatt das jeder alle Algorithmen selber implementiert wird einfach der bestehende Roboter an ROS/Moveit adaptiert.
juh hat geschrieben: @Defiant: Ich glaube, Deine Frage geht von einem Arm mit Sensorik aus.
Eigentlich nicht. Bei genügend Freiheitsgraden kann der Roboter mit sich selbst kollidieren. Deswegen hat er bei moveit ein Modell von sich selbst. Bei deinem Fall würde ich aber auf eine Kollision mit dem Regal tippen, richtig? Auch dies würde bei dem Modell für die Kollisionserkennung berücksichtigt. Zugegeben aber das Moveit hier etwas überdimensioniert ist.

Das sollte ja nur ein Denkanstoß sein anstatt der linearen Wegführung die Position stattdessen mit Kollisionsvermeidung anzufahren. Die Positionen die der Roboter nicht anfahren darf sollten ja relativ simpel sein. (z.B. wenn Motor 1 < 30° dann verbiete Motor 2 zwischen 60°-80°).
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von juh » 06 Jun 2019, 21:41

Ah, ok. Wäre in der Tat interessant, auch um den Benutzer davor zu bewahren, den Arm jenseits des mechanisch machbaren zu bewegen. Geht aber, ebenso wie das Codieren der Hindernisse, deutlich über meine bescheidenen Anforderungen hinaus. ;-)

lgj

Benutzeravatar
fishfriend
Beiträge: 1791
Registriert: 26 Nov 2010, 11:45

Re: Roboterarm mit (noch nicht) linearer Wegführung

Beitrag von fishfriend » 07 Jun 2019, 09:50

Hallo...
Mit was erstellst du deine Programme?
Bei RoboPro kannst du ja die Überwachung(en) in einem eigenen Prozess laufen lassen. Man "kann" auch von dort aus eine Korrektur machen.

Gruß
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Antworten