Welche SW (Freeware) zur Steuerung v. Robot Arm

Hi "theothermike",

schön zu höhren das da noch jemand dran ist. Ist halt ein Hobby und wenn der eigendliche Drucker läuft, ist das ja nicht so vorrangig.
Aber ein wenig wundern tut es mich schon, das so viele Ahnung von der Materie haben und keiner sich da so richtig dran traut.

Wenn ich da so an die ein od. andere SW denke, dann überhäufen sich die Beiträge und jeder hat da noch was rausgefunden und
dort noch was gelesen. Aber hier wo es mal richtig interessant wird und es eine wirkliche Herrausvorderung gibt,
ward keiner mehr gesehen.
Wenn´s aber denn nacher fertig ist, dann pass mal auf wie sie dann aus den Löchern geschossen kommen, mit den Kretiken.

Na ja, ich lass nicht locker. Das wird schon was.
Nur Geduld, meine Entwicklungen gehen weiter.

Beste Bastlergrüße Didi

---

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 . . .

Hi Didi,

ja, muss man halt Geduld haben....wenn ich an mich und meine Basteleien denke, dann dauert das auch immer ewig lang! Liegt halt daran, dass man vielfältig interessiert ist und eigentlich zu wenig Freizeit für solche Sachen hat...

Bei den 3D-Druckern habe ich halt das Gefühl, dass einfache Druckergeometrien mit bestehender Software halt den Löwenanteil haben.
Solch Robotersteuerung ist halt echt schwierig und die eigentliche Trajektorienerstellung aufwendig.
Bei ich sag mal "unserem" Projekt ist das ganze noch relativ übersichtlich wegen den wenigen Achsen, aber ein kartesischer Drucker ist und bleibt halt mit deutlich weniger Aufwand und geringeren Kosten sehr präzise aufbaubar.
Das macht so einen Robotarm halt vom mechanischen Aufwand schnell teuer wenn man eine gewisse Genauigkeit haben möchte. Ich habe das Gefühl, dass deshalb auch viele davon abgeschreckt sind.
Dieser hier ist ja z.B. genial...aber halt mit 15k€ doch etwas ungünstig:
[www.youtube.com]

Ganz in unserem Sinne liegt ja quasi der "DOBOT":
[www.youtube.com]
Und da ist zu erkennen, dass die Bahnkurve halt doch etwas wobbelt....der Killer für viele die was damit drucken möchten.

ABER, der dobot soll open source werden...! ( [www.kickstarter.com] ) Wie es dann mit der Firmware aussieht muss man mal schaun, aber gegenwärtig basiert er auch auf der Arduino Plattform und sollte man im Auge behalten.


Und dann gibt es ja auch noch den "Arm3" hier:
[www.marginallyclever.com]
für welchen bereits eine Firmware existiert !!!!:
[github.com]

Grüße,
Mike

Hi Mike,

> Bei ich sag mal "unserem" Projekt ist das ganze noch relativ übersichtlich wegen den wenigen Achsen, aber ein kartesischer Drucker ist und bleibt halt mit deutlich weniger Aufwand und geringeren Kosten sehr präzise aufbaubar. <

Das ist es ja warum ich das nicht so ganz verstehe. Hat den keiner mal Traute sich an was dran-zu-setzen, was halt nicht jeder Hinz-und-Kunz kann?
Das dieses ein recht anspruchsvolles Projekt ist, ist schon klar, aber wenn´s fertig ist, dann . . .

Ich könnte mir das sogar als ein Uni-Projekt vorstellen. Aber die Studenten die ja mittlerweile alle so gut drauf sind, haben ja bestimmt Wichtigeres zu tun.
Aber was viel schlimmer ist, hat dann einer was erstellt, dann bleibt es nicht Open Source zum Weiterentwickeln, sondern wird geschützt und
mit all seinen Macken teuer vermarktet.

Ich finde es schon ein wenig schade, das man bei solchen Sachen (bei allem Fortschritt und Industrie 4.0) immer wieder das Rad neu erfinden muß.

Gruß Didi

---

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 . . .

Na dann würde ich sagen Didi....du besorgst dir Bücher einer Programmiersprache deiner Wahl...und los gehts.

Da musst du wohl selbst ran...also auf....

---

[www.facebook.com]

Power is nothing.....without control!

Hallo, grüßt Euch.

Ich stelle mir da gerade eine Klasse mit rund 100 Schülern vor, der Lehrer stellt eine Aufgabe vor und dann wird so eine Antwort in den Raum geworfen.

> Da musst du wohl selbst ran...also auf.... < Damit hast du zwar die Lacher auf deiner Seite, aber nicht wirklich einen guten Beitrag zur Lösung des Problems beigetragen.

Ich möchte die Leute erreichen und animieren, denen es mit Sicherheit leichter fällt etwas zu programmieren od. eine SW zu ändern als Dir od. mir.
Und davon gibt es mit Sicherheit genug.

Mal davon ab, muss ich mir immer erst eine Kuh züchten, wenn ich mal ein Glas Milch trinken möchte?
Ich glaube schon das auch ich (so wie Viele hier) meinen Anteil geleistet habe (und auch noch weiterhin werde), um nicht zuletzt zu demonstrieren das DIY und Open Source
eine sehr gute Sache ist und bestens zur Entwicklung von Produkten beiträgt.

Wo sind die anderen "Macher"?

Beste Bastlergrüße Didi

---

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 . . .

Das war auch nich böse gemeint Didi....

Es gibt eben nur gaaanz wenige...die das können. Damals, als du das hier angefangen hast, hab ich aus Spass auch mal jemanden über Facebook kontaktiert. Der ist Jungingenieur bei KUKA. Auch der wusste nicht...wo er hätte anfangen sollen.

Und der Vergleich mit dem Lehrer ist mies. Denn der Lehrer muss es selbst können.

Vielleicht verstehst du einfach....das es nicht für jedes Problem einfach so jemanden gibt.


Also doch lieber Bücher kaufen...und mit einem Grundgerüst wiederkommen.

---

[www.facebook.com]

Power is nothing.....without control!

Hallo Sven,

ich weis das das nicht bös gemeint ist und der vergleich mit der Klasse ist nicht mies, sondern mir fiel ehrlich gesagt im Moment kein anderer Vergleich ein.

Zudem kommt die Aussage die mir zu Anfangs unter anderem auch "repetier" , auf meine Frage der Machbarkeit, geäußert hat, das das eigentlich nicht so schwer sein dürfte.
Oder das es machbar sein müsste. Das, hat mir halt auch Mut gemacht und die vielen Roboterarme die da Draußen laufen und auch funktionieren.
Wie z.B. der "DOBOT".

Ich hoffe das "Michael K" noch im Boot ist, denn das hörte sich doch recht gut an, was er schrieb.

Gruß Didi

---

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 Liebe "Einarm-Roboter-Interessieren", grüßt Euch.

Wir haben eine Zusage bekommen, das in eine Neue 32Bit-Firmware, die Roboterarm-Steuerung mit eingebunden wird.

Für diese Aktion wird aber noch ein wenig Unterstützung benötigt.


Hier ein kleiner Auszug:

Ich entwickele meine Firmware von Grund auf so, daß man sowas machen kann. Es ist - soweit der Plan bis jetzt - tatsächlich nur ein einziges Modul, welches hinzugefügt werden müsste. Dieses wird dann ganz einfach im obigen Skript per "M667 S7" (die Zahl hinter dem S ist jetzt erstmal willkürlich gewählt) aktiviert. Dann müssen noch die Treiber des jeweiligen Boards mit den Achsen/Motoren "verbunden" werden und das war es dann auch schon. Um den Rest kümmert sich dann die Firmware.

Ich habe in meiner Spieleentwickler-"Karriere" mal ein wenig mit inverser Kinematik und virtuellen Muskeln experimentiert. Auch in Sachen Physiksimulation (sprich Physik-Engine) habe ich mit entsprechenden Joints und deren Simulation gearbeitet. Ich denke, daß man aus der Richtung eine Lösung für die Bewegung des Arms entwickeln könnte. Sowas selbst entwickeln kann ich aber nicht. Die Mathematik die dahinter steckt ist mir leider zu hoch. Wenn mir jemand die entsprechenden Formeln erarbeitet, dann wäre das aber ein eher kleines Problem. Als große Herausforderung sehe ich da insbesondere zwei Aspekte:

• Rechenzeit - eine inverse Kinematic zu berechnen ist nicht ganz ohne. Da werden einige Matrix-Operationen durchgeführt, die etwas Rechenzeit benötigen. Ich habe sowas auf relativ schwaren ARM-Prozessoren (Windows Phone der ersten Generation, 1 Kern, unter 1 GHz) bereits gemacht. Die AVRs sind aber noch mal eine ganz andere Nummer und haben nochmal deutlich weniger Rechenleistung (locker Faktor 10-20 würde ich mal schätzen) und es muss ja noch eine Menge anderes gemacht werden. Ich kann ehrlich gesagt noch nicht abschätzen ob das realisierbar ist, da mir zwei Informationen fehlen: Wieviel Performance benötigt die Berechnung der Motor-Positionen des Arms und wieviel Leistung hat ein AVR tatsächlich.
• Geschwindigkeit und Beschleunigung - Besonders wichtig ist ja beim 3D-Druck eine gleichmäßige und sanfte, aber doch möglichst schnelle Bewegung. Kleine Ruckler oder Ungenauigkeiten sieht man deutlich im Druckbild. Mechanisch kann man das Problem sicherlich ganz gut in den Griff bekommen. Softwaretechnisch kommt hier wieder die Mathematik ins Spiel. Wie beschreibt man die Arm-Bewegung möglichst gleichmäßig und sanft. Das hängt auch wieder eng mit dem vorherigen Punkt zusammen.

Was ich anbieten kann ist, daß ich den "Einarm-Robot-Drucker" in der Entwicklung berücksichtige und somit alles in meine Firmware einbaue, was für den Betrieb eines solchen Druckers notwendig wäre. Wenn mich jemand bei der Mathematik unterstützt bzw. mir die Formel vorgibt, dann kann ich die auch gerne in die Firmware einbauen und somit ein experimentieren ermöglichen. Was ich aber in jedem Fall nicht möchte ist, daß dieses "Nebenprojekt" zuviel Zeit verschlingt. Meine erste Priorität ist bei der Firmware, daß ich meinen Drucker (karthesisch) mit echtem ABL ans Drucken bekomme. Die nächste Priorität ist dann die Delta-Kinematic zu implementieren, da ich als nächstes vermutlich einen Delta bauen möchte. Danach (oder vielleicht auch parallel) kommt CoreXY (CoreXZ und CoreYZ) dran, da es viele mit so einem Drucker gibt und ich so sicherlich viel Erfahrung gewinnen kann. Ich denke aber, daß die Teilprojekte gut koexistieren könnten :-)

Kurz und knapp also: Ich helfe gerne, kann aber die Softwareseite nicht alleine stemmen und möchte das erstmal nicht mit höchster Priorität angehen.


Also wenn das kein Ansporn ist, dann weis ich´s nicht.

Beste Bastlergrüße Didi ................................................................................ Link zum ThirtyTwo - Eine 32 Bit-Wirmware . . . Beitrag

1-mal bearbeitet. Zuletzt am 29.09.15 07:30.

---

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 zusammen,

leider ist es hier ja doch recht ruhig geworden...sehr ruhig.....
Gibt es denn etwas neues zu der "ThirtyTwo" hinsichtlich Arm??

Selber bin ich leider auch nicht mehr allzu weit gekommen, war viel familiäres zu tun und etliche Reparaturen stehen im Vordergrund.
Außer (kleiner) Recherche ist nicht viel gelaufen...

Mal was generelles, weiß jemand einen Link o.ä zu einer Beschreibung wie eine Armsteuerung im industriellen Format (KUKA o.ä) heutzutage aussieht?
Also wo mal Syntax, Befehlssequenzen, Schnittstellen, die "Sprache" und der Prozessablauf an sich erklärt wird? Hab da noch kein vollständiges Bild..

Grüße
Mike

Hallo,

da ich gerade jeden Beitrag hier gelesen habe bin ich ganz gut im Bilde. Der DOBOT funktioniert ja auch irgendwie. Auch wenn er sicher etwas wobbelt könnte man den als Grundlage analysieren.
Leider sind die CAD Files nicht mehr zu finden. Wenn Sie jemand zwischengespeichert hat kann er sich ja mal melden. OpenSource scheint wohl nur so lange zu gelten bis man merkt ihn verkaufen zu können.

Ist das Projekt noch aktuell? Ich würde gerne ein wenig mitkonstruieren wenn es möglich ist. Auch wenn alle über einen Delta schimpfen, habe ich ihn aufgebaut und auf ein sinnvolles Maß optimiert. Also warum sollte es nicht auch mit dem Einarmigen gehen?
Es ist schon krass was hier schon vorgedacht und geleistet wurde. Respekt !

Viele Grüße
G3org

Hi g3org,

wahrscheinlich haben immernoch einige das Projekt im Hinterkopf. Ich ebenfalls.
Die mechanische Konstruktion ist gar nicht mal das Problem.
Der dobot, palletizing robot usw. sind ja eigentlich alle ganz einfach aufgebaut. Didi schnitzt sowas wahrscheinlich an einem Nachmittag.

Problematisch ist halt die Software- und Ansteuergeschichte. Habe auch schon viel Zeit investiert und in diverser Software rumgepfuscht ...bin halt zu dämlich dazu. Da fehlt echt der Background. Mechanik ins CAD zu bringen fällt da ganz einfach.
Gedanklich schwirre ich da immer wieder um das Smoothieboard umher. Da ist schon viel bzgl. 3d-print-Integration sowie Kinematiken verfügbar, wenngleich die für den Arm nicht. Aber wie implementiert man da die IK? Wie Referenzfahrten? Streng genommen sollte man auch offsets zwischen Werkstück und Düse bzw. Werkzeug komfortabel und ohne ständiges neu kompilieren eingeben können ! (Werkstück anfahren, Nullpunkt bzw, Koordinaten setzen, Hotend tauschen,...).
...

Grüße
Mike

Die Dobot CAD files habe ich glaub leider auch nicht, aber hier ist ja auch noch was nettes:

[learn.marginallyclever.com]

Grüße
Mike

Hallo "G3org",

schön zu lesen, das es noch weitere Interessierte zu diesem Thema gibt.
Das es geht, ist nicht die Frage, schließlich gibt es ja diverse Einzelprojekte bei denen das Drucken mit einem Einarmroboter schon realisiert wurde.
Industrielle Lösungen gibt es ja auch einige, aber hier im Bereich DIY tut man sich damit wohl sehr schwer. Wie du schon richtig erwähnt hast,
> OpenSource scheint wohl nur so lange zu gelten bis man merkt ihn verkaufen zu können. <

Außerdem die zwei/drei Personen die sich bis jetzt zum Thema Software-Entwicklung geoutet haben, reichen wie man sieht nicht aus,
weil die ja auch noch genug andere Baustellen haben. Es wird auch bestimmt noch genug Andere geben, aber die sind bestimmt nicht
daran interessiert, das Erarbeitete für alle zu Verfügung zu stellen damit durch weitere Innovationen auch diese Ergebnisse weitere Früchte tragen können.

Hallo Mike,

schön das du auch noch dabei bist. Leider halte ich diese Konstruktionen für etwas "hibbelig" und die Industrie hat da schon gute erfolgreiche Arme,
die man auch im nicht kommerziellen Bereich gut nachbauen kann oder sogar hier ihren Ursprung haben.

Bin der Meinung, das man mit ca. 600 - 1000 € einen sehr brauchbaren Prototypen erstellen kann.
Sollten die ein oder Anderen diversen Bauteile und Elektronik vorhanden sein und man viel Mechanisches selber umsetzen kann,
dann kann Er natürlich weitaus preiswerter ausfallen.

Habe auch schon elegante druckbare Lösungen gesehen, sowie diverse Kombinationen aus Alu-Profilen.
Fakt ist es hapert nicht an der Hardware, sondern schlicht weg am Engagement und am guten Willen.
Das ist sehr schade, denn wir nehmen uns und anderen damit selber die Möglichkeit unsere Ideen umzusetzen.

Beste Bastlergrüße Didi

---

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 . . .

[github.com]
Damit läßt sich Dein Arm zumindest ausprobieren. Mit Ramps 1.4. z.B.

Herzl. Grüße

Hallo Didi,

Lösen wir doch die Sachen die man durch Fleiß lösen kann. Ein vernünftiger mechanischer Arm ist auch nicht an einem Nachmittag gebaut. Bis dahin werden wir auch eine Lösung für die Software finden. Oder wir müssen ein crowdfunding starten und das jemand professionell machen lassen :-) . Ich denke so weit muss es nicht kommen. Vielleicht kommen beim Bau auch weitere interessierte Leute dazu die sich um die Software kümmern.
Da ich persönlich so ziemlich jede Druckerbauform gebaut und betrieben habe, bin ich durchaus bereit ein paar € und Zeit in das Experiment zu investieren. Klar kann es zum Fehlschlag kommen, aber Leute das gehört zum entwickeln einfach dazu. Und erzählt mir nicht, dass ihr jedes begonnene DIY Projekt zum laufen bekommen habt. Ist ein solider Arm geschafft, gibt es ja auch viele andere Anwendungsbereiche jenseits des Druckens. Es ist also auf keinen Fall umsonst. Natürlich werden wir, schon allein aus Kostengründen, keine Konkurrenz zu Industriearmen schaffen. Aber das ist auch nicht das Ziel.

Was sind denn die echten Parameter des Arms die wir mindestens erreichen wollen.

mir fällt dazu folgendes ein. Vorschlag:

Hardware:
1.) Effektiver Bauraum 200x200x200
2.) Auflösung an den entferntesten Ecken 0.1 mm
3.) Material Aluminium
4.) unter 900€ für den Prototyp

Software:
1.) kompatibel zu Marlin/ andere Standard FW.
2.) leicht zu parametrisieren


Wer ist dabei ?

vG
g3org

Wie viele Freiheitsgrade soll denn der Roboter haben? Sobald es mehr als einen Weg gibt, die Bahn zu fahren, muss man das aufwändig Steuern. Da ist es dann nicht mehr mit Slicer/Gcode fertig.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

bzgl. dem "Marginallyclever":

Quote
vw-styler
... Leider halte ich diese Konstruktionen für etwas "hibbelig" und die Industrie hat da schon gute erfolgreiche Arme,
die man auch im nicht kommerziellen Bereich gut nachbauen kann oder sogar hier ihren Ursprung haben.
...
Beste Bastlergrüße Didi

Da bin ich ganz bei dir, die Konstruktion des Arms ist auf den ersten Blick etwas "hibbelig",
ABER: Die Software-Toolchain sowie die Ansteuerung passt! Das Teil arbeit mit Steppern, der Code ist zugänglich!

D.h. eine verbesserte Variante dieses Arms ließe sich mit der zugänglichen Software wohl recht einfach steuern.

Darüberhinausgehend, d.h. mehr Komplexität als dort, liefert die Problematik welche Wurstnase soeben angedeutet hat. Folglich fehlt es dann bereits an der Trajektorienerzeugung.
Hierzu müsste wohl ein Mehrachs-CAM-System verwendet werden, welches die Pfaderzeugung übernimmt.
Dabei gibt es die Möglichkeit eine Ausgabe für kartesische Maschinen in Robot-Code zu übersetzen, oder aber das CAM ist direkt für Robot-Code zu gebrauchen.
Beides habe ich so noch nicht im Hobby-Bereich gefunden.

Am sinnvollsten erscheint damit (zunächst) ein Arm auf Basis eines "Palletizers", oder?

Wenn ich mir das hier anschau geht das schon gut in die gewünschte Richtung:
[www.youtube.com]

Grüße
Mike

Hallo grüßt Euch.

vor einer Woche habe ich bei einer großen Aufräumaktion meinen ersten Prototypen des Roboterarm`s entsorgt.
Habe nicht mehr damit gerechnet das es hier noch weitergehen könnte.
Aber, . . . Gedanklich ist das Thema noch lange nicht vom Tisch. Man muss auch schon mal Platz für Neues machen

In der Entwicklung bin ich aber ehr bei der Variante: Nema17 - Alu-Strukturen oder Profile oder Alu/Kunststoff Kombinationen
keine Kopie von diesem UR3 Robot , aber eine DIY-Lösung in diese Richtung.

Der vorgestellte realisierbare Bauraum: DIN A4 - ca. 200mm hoch.
Und jetzt kommt`s: Ich könnte mir sehr gut vorstellen diesen Druck-Roboterarm mit einem Schnellwechseldüsen-System (Düsen-Revolverkopf)
(wie ich ihn in einem meiner anderen Beiträge (Idee für eine Automatik-Düse) als Vorschlag von "chaoscrack" als gute Möglichkeit bezeichnet habe), auszustatten.

Dieses würde die Druckzeit erheblich beschleunigen. Aber solche Sachen sind erst einmal Nebensache und für dieses Projekt nicht relevant.

Zurück zum Thema:
Ein neuer Grundaufbau ist relativ flott erstellt. Nema17, im Baumarkt gibt es Alurohr für Lolladen, eine Steuerungselektronik ala Rumba od. sonstige
dürfte auch kein Problem sein, ein Sensor im Kopf zur Druckbetterkennung. Bleibt nur noch die Frage der FW.

Was die Frage der gleichzeitig verfahrbaren Wege betrift, sind das max. drei und das müsste doch eigentlich realisierbar sein.
Das trift doch auf einem Delta auch zu. Nur sind hier in unserem speziellem Fall des Roboterarms noch weitere Faktoren zu Berücksichtigen,
die wir ja schon vor ein paar Seiten zuvor erläutert haben.

@ Mike - man müsste diese FW mal testen (für mich z.Z. nicht möglich), in wie weit die hilfreich ist.

Es ist allerdings schade, das "Glatzemann" mit seinen anderen Ativitäten so beschäftigt ist, das er mit seiner SW (* ThirtyTwo (32Bit RepRap-Firmware) )
da auch nicht zu kommt, dort weiter zu machen. denn das war meine große Hoffnung, weil er ja auch im Thema war und die Problematiken kennt.

@ Georg - Ich bin nach wie vor dabei und baue gerne noch einmal einen weiteren Prototypen auf.

Mal sehen wer noch dazu kommt. Je mehr mitmachen, um so erfolgversprechender wird es auch als Projekt und nicht nur als Anregung
zur Entwicklung einer Firmware.

Beste Bastlergrüße Didi.

---

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 . . .

Schön zu hören, dass es einigen wir geht und der Gedanke noch im Kopf nicht archiviert wurde.

@Didi Deine ersten Versuchsaufbau habe ich gesehen.
Du willst also einen Nema 17 mit ,Getriebe wahrscheinlich , nach Vorbild des UR3 bauen?
Sehe ich das richtig, dass die Gelenke die Motoren sind? Wie machen die 360° im Demo Video? Schleifkontakte? Oder wickelt sich ein Kabel irgendwie ums Gelenk.
Wenn man das Rohr durch einen rechteckiges Gebilde aus 3mm Sperrholz ersetzen würde, wäre der prototypische Ausbau erheblich leichter. (CNC Fräse vorhanden).
Aber natürlich ginge auch ein Alu Rohr welches man mit Motorenaufnahmen aus den 3D Druckern bestückt.
Ich würde gerne parallel mitbauen. Wäre das ok ?
Gibt es schon ein Dropbox share?

Die Motoren wären doch sicher der Klassiker. Zumindest für die Armgelenke. Für die Axiale Drehung wird die Auflösung sicher nicht reichen.

VG
g3org

Hallo G3org, grüß Dich.

An diesem Punkt sollte man drüber nachdenken, ob man hierfür einen neuen Beitrag unter der Rubrik "Projekte" startet,
damit es diesen Beitrag der SW nicht zerreißt.
Nema17 ja, aber nicht als Getriebeausführung sondern Standard. Nicht als Gelenk benutzen, sondern implantieren und die Bewegung mit Ritzel auf einen Zahnkranz,
der mit dem Alu-Rohr übertragen verbunden ist.
Ein maximaler Drehbereich von 180° reicht für alle Achsen aus, man muss nur jeweils den Startpunkt sinnvoll (einstellbar) festlegen.
Werde dazu CAD-mäßig noch was erstellen.
Bitte nicht aus Holz, damit ist "Automatic-Wobbel" vorprogrammiert. Die Motorenaufnahme, die Ritzel und den Zahnkranz, kann man sehr gut drucken.

Eine Hebel-Lösung, damit die Parallelität der Hotendaufnahme und der Druckoberfläche relativ einfach gewährleistet werden kann, ist auch nicht verkehrt.
Oder intern ( wenn genug Platz ist) über Zahnräder, ist ja noch alles offen. Je simpler und sicherer, desto besser

> Ich würde gerne parallel mitbauen. Wäre das ok ? < selbstverständlich ist das ok, das ist doch der Sinn der ganzen Aktion, DIY und Open Source,
damit das innovativ bleibt.

> Gibt es schon ein Dropbox share? < nein. Logischerweise noch nicht, da sich bis jetzt noch nicht genug potenzielle Aktive gemeldet haben.

Beste Bastlergrüße Didi

---

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 zusammen,

nun krame ich das Thema mal wieder raus...

De facto gibt es für Armgeometrien welche über einen "Palletizer", d.h. 3 Achsen, hinausgehen keine für uns Hobby-Leute verfügbaren CAM-Programme zur Trajektorienerstellung. Die Bewegung eines 3-Achs-Arms kann man noch direkt aus dem kartesisch generierten gcode ableiten über die inverse Kinematik. Folglich bleibt das erst mal mein Ansatz da am ehesten umsetzbar.

Encoder-aufgelöste-Stepper werden in Kürze auch relativ günstig verfügbar sein ("Mechaduino"), was das gesamte Armprojekt nochmals interessanter werden lässt.

Vor einiger Zeit hatte ich mal den marginallyclever Arm3 hier eingetragen.
[github.com]
[learn.marginallyclever.com]
[www.thingiverse.com]

Hat sich vll. schon mal jemand mit dem Teil näher beschäftigt??
So wie ich das sehe ist das eigentlich genau was wir benötigen, quasi schon fertig. Über den mechanischen Aufbau brauchen wir uns nicht unterhalten, da man das ja je nach Lust, Laune und Budget stabiler und in gewissen grenzen modifiziert machen kann. Es geht ja um die prinzipielle Steuerung. Und für mich Noob sieht es so aus, dass das ganze mit einem Ramps 1.4 lauffähig ist. Parameter wie Armlängen, Offsets u.ä. können eingestellt werden, Endstops und initiales Homing sind auch bereits drin. Fraglich ist für mich nur, ob das auch mit den typischen hosts wie printrun o.ä. zusammen funktioniert ?

Eigentlich sehr seltsam, warum das Teil nicht weiter vom Konstrukteur verfolgt wurde?!?

Jedenfalls, ich werde mal in den kommenden Wochen ein paar Versuche diesbezüglich machen, da ich nichts ähnliches bisher gefunden habe. Ein Testmodell ließe sich zudem extrem minimalistisch aufbauen...
Mal schaun.

Grüße
Mike

Hi Mike,

ist Microsofts Robotics Studio noch aktuell? - die wollten doch eine kostenlose Software zum Ansteuern von beliebigen Roboter-Geometrien (auch industrie-6-Achsen) entwicken ...

---

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 Viktor,

mmh, guter Punkt, aber das war zumindest mein letzter Stand: "Microsoft Shuts Down Its Robotics Group" --> 2014. Vll. gibt's ja mittlerweile andere Neuigkeiten dazu?
[spectrum.ieee.org]

Alternative wäre womöglich noch "ROS" , Robot Operating System. Aber da blicke ich gar nicht mehr durch !!
Das wirkt halt erst mal so, dass noch weit, weit mehr zu tun wäre als "nur" die Kinematik zu implementieren....

Grüße
Mike

... hmmm ... "stable release" von 2012 und Schwerpunkt auf "Roll-Roboter" mit der Kinect als 3D-Sensor - [en.wikipedia.org]

Ich hatte mich vor etwa 3 Jahren mit der Programmierung bzw. Umbau von älteren ABB-Industrie-Robotern von 1996 beschäftigt und ein "Interface" zwischen einer USB-I/O-Karte auf dem PC und der Robotersteuerung gebaut, um vom Rechner aus beliebiege aus Referenzpunkten berechnete Positionen für den Werkzeugwechsel an einer CNC-Fräse anfahren zu können.

Es gab da schon Software zum Datenaustausch und Fernsteuerung per PC übers Netzwerk, das hätte aber mehrere Tausend Euro für den Update der Steuerung gekostet, so daß ich das auf wunsch meines damaligen Chefs quasi 'kostenlos' über die SPS und die USB-I/O-PC-Karte gelöst habe ...

---

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]

denke auch, hauptsächlich irgendwelche umherfahrende radgetriebene "Tele-Bots" u.ä.....

Die USB-I/O-Karte wäre aktuell ja quasi der Arduino, oder? Du hattest ja damals sicherlich ein CAM um die Referenzpunkte zu erzeugen, ein Teach-Pad o.ä. bzw. das waren Trajektorien die man zu Beginn einmal von Hand berechnet hatte?
Für einmalig zu definierende, einzelne Trajektorien würde das ja bereits ohne Inverse Kinematik und einem ganz normalen gcode-Interpreter funktionieren. Aber Ansatz ist ja schon, dass ein komplexes gcode-Programm umgesetzt werden sollte.
Vll. schaue ich mir auch mal noch den Robot-Overlord oder wie es heißt an...

Das größte Problem ist die gleichmäßige Geschwindigkeit, aber ihr scheint das nicht zu glauben.
Genau deshalb verschwinden die ganzen Projekte, weil die Leute das nicht hinbekommen.
[ocw.mit.edu]
Auf Seite 6 und 7 sieht man schön den Zusammenhang zwischen Position und Geschwindigkeit des Endpunktes.
Für jeden Motor muß man nicht nur den Drehwinkel berechnen, sondern auch die korrekte Winkelgeschwindigkeit.
(Gleichung 5.3.2 und 5.3.3 auf Seite 6)
Sonst ruckt es halt.

Herzl. Grüße

... hier hatt ich ein Video von dem Teil in einem Dauertest-Run hochgeladen - [vimeo.com]

Ich habe pro Regal nur zwei Positionen in der "Mitte" geteacht, um die Umstellung auf links-/rechtshändig zu definieren, ab dann war das ein berechneter Offset zum jeweiligen Fach mit zusätzlich noch einer "Korrektur"-Datei, um eventuelle Abweichungen in XYZ pro Werkzeugposition per File mitgeben zu können.

Der Arm kann mit bis zu 7m/s (!!!) durch die Gegend schießen -- in dem Video hatte ich ihn glaube ich auf 0.5m/s begrenzt ...

---

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]

AlterBastler, das glaube ich nicht nur, das weiss ich auch und ist absolut klar, dass die Geschwindigkeit ebenfalls betrachtet werden sollte.

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.
Außerdem, geringfügige Geschwindigkeitsfluktuationen sind kein Hindernis, da man ja z.B. den Extrudervorschub oder Laserpuls ja synchronisieren kann. Außerdem ist Super-Highspeed aktuell kein Anspruch.

Viktor, das Video kenne ich ja sogar....schon heftig! Nur, wie sollten wir es heute im kleinen bewerkstelligen ? ;-)

... die Software ist schon immer die größte Hürde gewesen -- ich würde erstmal mit einer einfacheren Kinematik anfangen - z.B. Scara oder besser Parallel-Scara ...

---

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]

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.
Schwierig ist nur, dass keiner der sich mit der Firmware auskennt einem mal klar und deutlich beschreibt wie man die Kinematiken implementiert und was für Variablen/Bezeichnungen/... für was gut sind. Würde es gut erklärt werden, dann hätte der Programmierer es wohl in derselben Zeit auch selbst schon implementieren können.
Die Mathematik dahinter verstehen wir hier alle, nur die Gedanken des Programmierers zu erahnen macht das ganze so schwer. Dass ich die Trajektorie in Segmente zerlegen muss ist klar, wie man die Real- in inverse-Koordinaten umrechnet ist auch klar, nur nicht wie die Firmware das ganze verarbeitet, deklariert, usw. Und dann kommt noch die Homing-Routine, welche i.d.R. total kryptisch aussieht...
Naja, ich gebe jedenfalls noch nicht auf ! ;-)