Welche SW (Freeware) zur Steuerung v. Robot Arm

Nur mal so nebenbei. Ich habe vor 1 1/2 Jahren das erste mal C++ außerhalb der Uni (~Anno 2003) gesehen.

Also SourceCode deiner Lieblingsfirmware angucken und versuchen zu verstehen. Wenn dann Fragen kommen, Leute suchen die sich damit auskennen. Ich kenne Marlin und Teacup. Gerade was Pfadplanung angeht, Kinematik ist ja die gleiche, unterscheiden sich beide sehr stark. Repetier ist auch wieder anders. ReprapFirmware geht einen komplett anderen Weg.

Also, Entscheiden, Angucken, Verstehen und dann erst Fragen stellen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
theothermike
Nur, dass deshalb die Projekte in der Art verschwinden glaube ich nicht so ganz. Denn sonst gäbe es einige die bis zu diesem Punkt bereits vorgestellt worden wären.

Gibt es ja... Bis zu dem Punkt, wo die Mathematik böse wird.

Herzl. Grüße

Quote
theothermike
Naja, Ansatz ist halt schon ein 3-Achs-Arm und da die Kinematikberechnungen zwischen SCARA und 3-Achs-Arm quasi identisch sind was den Komplexitätsgrad anbelangt ist halt klar, dass der Arm eher reizt.

Da liegst Du falsch! Zwischen serieller und paralleler Kinematik gibt es gravierende Unterschiede.

Herzl. Grüße

Quote
AlterBastler
Da liegst Du falsch! Zwischen serieller und paralleler Kinematik gibt es gravierende Unterschiede.
Herzl. Grüße

Da liegst leider DU falsch, denn ich habe nicht gesagt, dass es keine Unterschiede gibt, sondern dass

Quote

die Kinematikberechnungen zwischen SCARA und 3-Achs-Arm quasi identisch sind was den Komplexitätsgrad anbelangt

. Die Mathematik ist hier keinesfalls böse, sondern lediglich ein wenig anders.




Wurstnase, ganz großer Sport ! Danke für die Hilfe, das mache ich. Ach ne halt, das habe ich schon versucht ( [forums.reprap.org] )
Leider bin ich nicht DU und leider raffe ich C++ auch nicht so wie du, da ich noch nicht mal einen Kurs dazu an einer Uni hatte.
Wenn du so versiert bist in Teacup und Marlin, und C++ so einfach für dich ist, warum gibst du dann nicht einen Tipp anstatt hier zu schreiben wie schnell du es geschafft hast?? Normalerweise schätze ich deine Beiträge hier im Forum als Power-User...

Ist echt schade, dass es hier etliche Beiträge der folgenden Art gibt: "Geht eh nicht", "viel zu schlechte Auflösung/Geschwindigkeit", "zu schwierig" oder "schau es dir selber an", "lern doch einfach 1.5 Jahre intensiv", "frag nicht so unbedacht".

Ja, ich will lernen, ich bin auch bereit dafür etwas zu machen, aber wenn man fragt "wie funktioniert eine Linse", warum ist dann die Antwort "lern erst mal jahrelang Optik" ? Da wäre eine hilfreiche Antwort eher: "Schau dir mal Strahlenoptik oder die Linsenmachergleichung an". Got me ??

Am besten guckst du dir an wie die Delte-Kinematik verwirklicht wird. Das habe ich bisher noch nie genau. Die einfache Kinematik gibt mir schon genug zu tun.

Mir fällt nix leicht. Ich habe einfach nur viel Zeit investiert. Wenn du spezielle Fragen hast bei, aktuell, Teacup, setze ich mich hin und versuche das selbst, aber hier Allgemein etwas zu erklären führt zu weit.

Eines kann ich dir sagen, beim Delta werden Segmente so berechnet, dass dazwischen die Motoren sich linear bewegen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich verstehe nicht, wieso die doofen Japaner über das Thema ganze Doktorarbeiten verfassen...
Ist ja doch simpel!

Herzl. Grüße

Wurstnase: Danke !! Sehr gerne, es ist ja schon mal ein Anfang wenn man in die richtige Richtung geschickt wird.

AlterBastler: Ja, da hast du Recht. Das habe ich vergessen. Und wenn selbst die Japaner Doktorarbeiten drüber verfassen, na dann sollte man das ganze lieber direkt sein lassen.
Dieser ganze Thread hier ist nämlich pure Anmaßung und Blasphemie. Jawohl !!
Wie wir hier nur auf die Idee kommen können einen ultraschnellen closed Loop 6-Achsen-Roboterarm inkl. Software-Toolchain, Automatischer Kalibrierung, Kollisionserkennung und Elastizitätskompensation innerhalb weniger Wochen entwickeln zu wollen, tststs.

Quote
theothermike
Leider bin ich nicht DU und leider raffe ich C++ auch nicht so wie du, da ich noch nicht mal einen Kurs dazu an einer Uni hatte. [...]

Ja, ich will lernen, ich bin auch bereit dafür etwas zu machen, aber wenn man fragt "wie funktioniert eine Linse", warum ist dann die Antwort "lern erst mal jahrelang Optik" ? Da wäre eine hilfreiche Antwort eher: "Schau dir mal Strahlenoptik oder die Linsenmachergleichung an". Got me ??

Zunächst einmal enthält die Teacup kein C++, nur profanes C. Der wichtigere Aspekt ist, dass das programmieren selbst der einfachste Teil ist. Wenn man mal weiss, was man genau will, kann man es tatsächlich einfach eintippen.

Ein kleiner Exkurs, warum viele Firmware-Programmierer recht schnippisch sind. Es liegt in der Natur der Dinge, dass man Software nicht sehen kann. Obendrein lässt sie sich noch mit einem Fingerschnippen kopieren, so dass den allermeisten Leuten entgeht, dass da tausende Stunden Arbeit drin stecken. Nicht tausende Stunden eintippen von Code, sondern tausende Stunden Mathematik, ausprobieren, Haare raufen, von Vorne anfangen und dergleichen mehr.

Da kommen dann Leute daher mit "Ich habe gerade einen 7-Achs-Drucker gebaut, das war kompliziert, wer kann mir eben mal die Firmware darauf anpassen?" Noch ignoranter geht's ja wohl nicht. Ganz sicher ist: sieben Achsen zusammen zu schrauben ist trivial im Vergleich dazu, diese 7 Achsen dann auch koordiniert per Software zu bewegen. 3D-Drucker waren nie eine Frage der Mechanik, passende Mechanik gibt es seit über 100 Jahren. 3D-Drucker sind eine Frage der Software.

Was macht man also mit so einem Möchtegern-Helden? Richtig, man sagt ihm "mach mal". Denn er muss selbst lernen, dass er den schwierigeren Teil noch vor sich hat. Die Meisten ziehen da beleidigt ab, weil sie das Problem nicht sehen, und das ist auch besser so.

Was machen die, die nicht abziehen? Nun, die überlegen sich eine Mathematik mit der man bestimmen kann, wann welcher Motor den nächsten Schritt macht. Das ist "Alles", mehr macht eine Firmware nicht. Diese Zeit zwischen zwei Schritten wird dann an den Timer übergeben und der Drucker läuft. Dazu noch ein bisschen Voodoo, damit diese Mathematik schnell genug berechnet wird, doch das kann man auch erst mal weglassen.

Wenn Du jetzt also mit Formeln daher kommst, die genau die Pausen zwischen zwei Motorschritten berechnet, dann tippe ich Dir das gerne ein. Kannst Du dann aber auch selbst machen, denn die Programmiersprache zu erlernen ist im Vergleich dazu ziemlich einfach.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... als ich 2007 meinen Delta vorgestellt und mir mit Diskussion im Thread die Ansteuerung überlegt habe, wollten mir zwei Leute beim Programmieren der Software helfen -- trotz relativ 'einsichtiger' Vorgaben für die Kinematik sind beide nach einem halben Jahr ausgestiegen

Erst Jahre später ist das mit dem Rostock weitergegangen ... ab dem gibt es auch Firmwares für Deltas in verschiedenen Varianten ... also Alles eine Frage der Zeit ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Hallo Theothermike,

Quote
theothermike
Leider bin ich nicht DU und leider raffe ich C++ auch nicht so wie du, da ich noch nicht mal einen Kurs dazu an einer Uni hatte.
Wenn du so versiert bist in Teacup und Marlin, und C++ so einfach für dich ist, [...]

du musst einfach verstehen, dass du da jemanden um mehrere Stunden wenn nicht sogar Tage Arbeit bittest.

Hier im Forum gibt es reichlich Leute die in Metallbearbeitung geübt sind und diese ganzen tollen Werkzeuge haben.
Da gehe ich auch nicht hin und erwarte, dass die sich für mich mehrere Stunden an die Drehbank stellen.
So etwas zu erwarten wäre einfach unangemessen.

Bei der Firmware-Entwicklung ist es genau so.
Auch ein geübter Programmierer muss sich in die Firmware einlesen und verstehen wie sie funktioniert.
Das kostet einfach Zeit und die ist kostbar.

Gerade wenn du gut mit Mathematik klar kommst sollte es für dich ein Leichtes sein eine Programmiersprache zu erlernen.

2-mal bearbeitet. Zuletzt am 01.07.16 06:51.

---

Best regards / Viele Grüße
Till

Quote
VDX
... also Alles eine Frage der Zeit ...

Du meinst also, irgendwann würde sich schon ein Doofer finden. Nun, für meinen Teil habe ich da sehr viel Sitzfleisch.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hallo zusammen,

ja, da bin ich ganz bei Euch, volles Verständnis !!! Wirklich !!
Ich sage ja schon seit langem, dass die Mechanik das einfache hierbei ist und die Firmware-Umsetzung das Problem ist. Das zieht sich auch hier im Thread durch.

Aber ich habe und hatte auch nie den Anspruch, hier zu rufen : "programmiert es mir".
Nein, nein, falls das so rüberkam war das wirklich nicht so gemeint! Also großes Sorry, falls ich hier jemandem unbewusst auf den Schlips gestiegen bin.

Sämtliche Fragen gingen eigentlich immer eher in die Richtung: "Wo muss man anfangen, wo muss man die Kinematik implementieren, was ist zu beachten,..."

Im Gegenteil, ich habe großen Respekt vor den ganzen Firmware-Konstrukten und den jeweiligen Programmierern die bei all den Unterprogrammen, Verweisen und Überschreibungen den Überblick behalten können. Womöglich auch zu großen....Ich scheue mich eigentlich davor weil ich denke mehr kaputt zu machen als zu modifizieren und eher von vornherein denke, dass es eh nicht wird wenn ich drin rumbastel.
Ich habe da auch schon viele Tage rumprobiert, aber die stilistischen Eigenheiten in den teils wohl historisch gewachsenen Programmblöcken zu erkennen fällt echt schwer. Es gibt auch keine, oder zumindest habe ich es nicht gefunden, Programm-Ablauf-Schemata oder Begriffsdefinitionen an denen man sich entlang hangeln kann. Was eine Schleife macht und wie ich sie aufbauen muss kriege ich nach Recherche schon hin. Nur wo macht sie Sinn und was passiert im Hintergrund und ist diese eine Variable wirklich die, welche nahe liegt oder doch eher nur irreführend bezeichnet?

Nachdem es ja bei Teacup mal zeitweise den SCARA-Branch gab, dachte ich auch mal das wäre ja ein Ansatz...die Segmentierung der Pfade usw. schien ja dort zu laufen und Videos von akzeptablen Ausdrucken gab es. Der Part der IK war zu finden und die Variablenzuweisungen von Real- in Inverse Koordinaten mit der Rechnung verknüpfbar. OK, sollte ja wohl irgendwie änderbar sein. Woher und wie man den dritten Motor überschreibt und umrechnet stand zwar in den Sternen, aber letzten endes lief der Branch dann doch nicht, die Motoren haben nie einen Ruckler gemacht. Traurig. Und woran klemmte es? --> Muss man mal debuggen. Prima, wassn das und wie?...

Naja, mal schaun, vll. gibt's ja in ein paar Jahren einen neuen Hype. Jedenfalls hätte es das Potenzial dafür.

Jeder hat halt so seine persönlichen Fähigkeiten, Schwerpunkte und besonderen Vorlieben.
Das war ja der Gedanke des Threads, dass man gemeinsam eine Neuheit erzeugt indem man die jeweiligen Kompetenzen verbindet. Es geht ja auch nicht drum einen dummen zu finden der die Arbeit macht, sondern um konstruktiven Austausch und sinnvolle, faire Aufteilung. OK, Didi war da vll. nicht ganz sooooo bereit in die Software einzusteigen, aber nun gut. ;-)

Grüße
Mike

PS:

Quote
Traumflug
Formeln ..., die genau die Pausen zwischen zwei Motorschritten berechnet...

. Bezieht sich das nun auf das eingangs genannte Ruckeln bei den Bewegungen? Also, dass die Bahnkurve des Endeffektors keine unstetigen Geschwindigkeitssprünge aufweist? Ich dachte die Firmware macht "lookahead" oder wie das heißt? Oder ist das in der Firmware wieder was anderes? Warum lief dann der SCARA trotzdem, die Pfadsegmentierung muss da doch ebenfalls erfolgen?

Ein paar Dinge:

- Den Zweig Scara gibt's immer noch, sowas geht nicht verloren. Bei dem sind noch ein paar Fragen offen, deswegen ist es immer noch ein Zweig. Er ist eben inzwischen weiter nach hinten gerutscht, ansonsten aber unverändert.

- Kaputt machen kann man nichts, denn es gibt die Versionskontrolle (Git). Mit Git kann man jederzeit die vorherige Version wieder herstellen. Man kann auch an mehreren Versionen parallel arbeiten, z.B. wenn man verschiedene Strategien miteinander vergleichen will.

- 3 Motoren für 2 Achsen zu haben wirft ein ganz erhebliches mathematisches Problem auf: die Motorstellungen und damit die Motorbewegungen sind nicht mehr eindeutig definiert; es gibt mehrere Möglichkeiten, einen bestimmten Weg zu fahren. Aber das weisst Du vermutlich schon.

- Das mit der Segmentierung ist eine Krücke. Eine recht weit verbreitete Krücke, denn bislang haben es die Firmware-Entwickler nicht besser auf die Reihe bekommen. Ausnahme ist die DC42-Firmware. Der DC42 hat es tatsächlich geschafft, jedes einzelne Zeitintervall für jeden einzelnen Motorschritt eines Deltas zu berechnen. Bislang bin ich nicht dahinter gekommen, wie er das macht, obwohl ich den Quellcode auf der Festplatte habe. Er sagt, er hätte "die Formeln gelöst" ... doch welche Formeln?

- Eine weitere Ausnahme ist LinuxCNC, das nicht in Entfernungs-Segmenten rechnet, sondern in Zeit-Segmenten. Für jedes Segment wird die Soll-Position am Ende des Segments berechnet, daraus die erforderliche Geschwindigkeit jedes Motors und daraus dann der Schrittabstand berechnet.

Wie man zu den einzelnen Motorschritten kommen kann, kann man hier sehen: [www.embedded.com] Da geht es "nur" um die Bewegung eines einzelnen Motors mit einfacher, linearer Beschleunigung. Für eine komplexere Mechanik kommt da noch die Kinematik oben drauf, denn die erforderliche Geschwindigkeit eines Motors hängt dann von dessen aktueller Position ab. Und das Ganze muss man so berechnen, dass trotz Rundungsfehlern am Ende kein Schritt fehlt und auch keiner zuviel ist. Letzteres ist vor Allem eine Frage der Perspektive, wenn man immer vom Ende her, also "noch 5 mm zu fahren, noch 4,5 mm zu fahren, ... rechnet, kommt man automatisch bei Null, also genau dem gewünschten Endpunkt raus.

Quote
theothermike
PS:

Quote
Traumflug
Formeln ..., die genau die Pausen zwischen zwei Motorschritten berechnet...

. Bezieht sich das nun auf das eingangs genannte Ruckeln bei den Bewegungen?

Das bezieht sich auf jeden einzelnen Motorschritt. Damit sich ein Motor ein wenig bewegt, bekommt er ja bekanntlich einen Puls. Der zeitliche Abstand zwischen zwei Pulsen ergibt die Geschwindigkeit. Werden nicht immer weiter Pulse mit der erforderlichen Pause dazwischen nachgeliefert, bleibt der Motor stehen.

Gäbe es ein halbwegs allgemeingültiges mathematisches Modell oder eine allgemeingültige Vorgehensweise, wie man von der (gekrümmten) Bahnkurve mit Beschleunigung/Bremsung und Kinematik zu den einzelnen Motorschritten kommt, wären die Firmwaren einen erheblichen Schritt weiter.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

2-mal bearbeitet. Zuletzt am 01.07.16 11:19.

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Hallo Traumflug,

vielen Dank für die offenen Worte !!!
D.h. in Teacup ist dieses von dir verlinkte Verfahren ( [www.embedded.com] ) für die kartesischen Bewegungen hinterlegt?!
Das lässt alles natürlich klarer werden und muss man mal noch etwas wirken lassen....aber ich glaube ich sehe nun die Problematik mit dem Timing und der Kinematik...Danke schon mal hierfür!!

Viele Grüße
Mike

Quote
theothermike
D.h. in Teacup ist dieses von dir verlinkte Verfahren ( [www.embedded.com] ) für die kartesischen Bewegungen hinterlegt?!

Das war es bis vor etwa 3 Jahren. Man kann das noch im Git-Repo sehen: [github.com]

Dieses Verfahren führt für jeden einzelnen Schritt eine neue Berechnung aus, was den Prozessor überfordert, wenn man mehr als etwa 10'000 Schritte/Sekunde ausführen will. Deswegen wird jetzt die Beschleunigungsberechnung in konstanten Zeitintervallen von 2 Millisekunden ausgeführt. Dadurch sinkt die Rechenbelastung und man schafft mehr als 40'000 Schritte/Sekunde.

Das Prinzip ist aber nach wie vor das Gleiche, die Berechnungsformel ist jetzt hier: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY