Hallo, ich benuzte einige Systeme mit GRBL Steuerungen. Nun muss ich aber einen Dreharm steuern, also 2 Motoren. Eine Z-Achse ist am Ende vom Arm dran. So jetzt hat man ja nicht nur die X & Y zu Winkel/ Schritte um zu rechnen sondern hat sozusagen ja auch noch Bereiche die man selber umfahren muss. Der Arm kann halt nicht auf seine Drehachse fahren und wenn man auf der einen Seite steht und auf die andere Seite will dann muss man den Arm halt irgendwie da hin bekommen ohne durch seine Aufhänung zu fahren. Auch darf der 2. Armbereich nicht über den 1. drüber fahren, sonst bricht die Z-Achse ab. Auch im Aussenbreich (Ecken) gibt es Punkte die man nicht erreichen kann weil wir ja nur einen Kreis fahren können. Diese müssen somit auch irgendwie abgefangen werden. Das ganze wird man wohl am Ende noch kalibrieren müssen, also eine Kammera vorne dran und eine Punktmatrix abfahren. Dann die positionen ablegen und mit den berechnetten Positionen verrechen. Das wird garantiert besonders Lustig werden und auf keinem AVR mehr laufen. Gibt es dafür schon eine Software oder hat jemand einen Tipp wie man das am besten umsetzen kann.
Versuche es lieber bei roboternetz. Da laufen einige rum die da schon viel mit gemacht haben.
Da hier anscheined niemand sich damit auskennt, oder die Personen sind gerade nicht online, denke ich auch das dieses Thema woanders besser ankommt. Ob es nun das roboternetz ist muss ich mal sehen, es gibt auch noch andere die vielleicht für meinen Fall noch besser sind. Aber wenn hier jemand ist der damit Erfahrung hat wäre mir das am liebsten.
Was ist IK? Industriekaufmann? :-) Nee, im Ernst, ein System bzw. der Anwender sollte natürlich schon "wissen", wo die Bereiche sind, an die man nicht hinkommt (Ecken oder Standpunkt). Und um aus kartesischen in polaren Koordinaten umzurechnen, braucht man auch keine Supercomputer. Aus dem errechneten Radius r lassen sich dann auch nebenbei die Grenzwerte ablesen. Wenn r <= Mindestabstand Arm - Drehmittelpunkt, dann "komm ich nicht hin". Wenn r >= Maximalauslenkung Arm, dann "komm ich auch nicht hin". Müsste mit AVR gehen, wenn auch etwas langsam, wegen Atan und Wurzel. Gruß Joachim
GRBL kann man auf PIC32 portieren. Da gibt es mehr Ressourcen und mehr Rechenleistung. Habe gemacht, funktioniert wunderbar. Wobei der GRBL müsste vermutlich massiv umgebaut werden. Bin jetzt nicht so sicher ob das im Code nur wirklich eine Umrechnung bedeutet. Könnte sein dass es irgendwo anders noch Probleme macht und dann fängt der ganze Spass an.
Speed ist da fast nebensache, der Arm braucht ja auch seine Zeit. Klar wenn es der normale AVR 328p macht dann brauche ich noch nicht mal eine Hardware bauen. Davon habe ich immer genug als Ersatz hier liegen, incl Motortreiber und den ganzen Leiterplatten dazu. Aber ich denke das der AVR um alles zu machen dann doch einem stm32f103 oder so weichen muss. So weit ich das sehe muss ich "nur" G00 & G01 ändern und etwas aufräumen. Das was Du da schreibst sind aber dann die wirklichen MAX und MIN Werte. Da kommt aber dann noch hinzu das Du nur vor der 1. Achse rum fahren kannst. Aber der Arm links hinter der Achse steht und ein G-Befehl den nach rechts hinten schickt. Also zB. von Y-100 X-100 nach Y-100 X100 was eigentlich nur das Verfahren der X Achse bedeuten würde, ich aber jetzt nach vorne, nach rechts und wieder nach hinten den Arm bewegen muss. Dabei wird dann auch noch die 2. Achse entsprechend gedreht. So eine Ablaufsteuerung ist jetzt nicht SOOOO kompliziert, aber wenn es da schon was gibt wo man abschauen kann, klar noch besser kopieren kann, dann muss ich ja nicht allse neu Erfinden. Ich finde leider nur noch nichts. Dann noch eine echte Kalibrierung und eine Limit MAP und ich kann die Maschine starten.
Das Ding was ich da habe nennt sich wohl "SCARA Robot Arm". Vielleicht hilft das weiter.
Uli schrieb: > Aber der Arm links hinter der Achse steht und ein G-Befehl den nach > rechts hinten schickt. Also zB. von Y-100 X-100 nach Y-100 X100 was > eigentlich nur das Verfahren der X Achse bedeuten würde, ich aber jetzt > nach vorne, nach rechts und wieder nach hinten den Arm bewegen muss. > Dabei wird dann auch noch die 2. Achse entsprechend gedreht. Was heisst "2. Achse gedreht"? So wie ich da verstanden habe, ist es eine Drehachse und eine Laufachse am Arm bzw. Ausleger. Also im Prinzip das, was als Baukran an jeder Hausbaustelle steht. Falls dem nicht so ist, bitte Erklärung. Du scheinst nicht den Unterschied zwischen kartesisch und polar verstanden zu haben. Im Polarsystem müssen immer beide Achsen fahren, wenn eine gerade Linie gefahren werden soll. Im kartesischen nicht. Sollen nur Positionen (Punkte) angefahren werden oder Linien gezogen werden? Punkte anzufahren ist über Radius+Azimut kein Problem. Du brauchst dann nur eine Software, die die Punkte ins polare umrechnet. Dann die Achsen von GRBL entsprechend verwenden, also X wird z.B. Radius und Y wird Winkel. Je nach Antrieb muss eben nur aus dem Winkel z.B. 270° eine entsprechende Schrittzahl für den Motor umgerechnet werden. Am GCODE und auch am GRBL an sich muss nichts geändert werden. Du überträgst nur andere Zahlenwerte im normalen GCODE. Wenn Dein Arm z.B. 10.000 Schritte für eine Umdrehung braucht, dann hast Du 0,036 Grad / Schritt. Damit lässt sich doch leicht beim gewünschten Winkel der zu fahrende Schrittwert berechnen. Die Berechnung also NICHT im GRBL Kontroller machen, sondern in einem Postprozessor, welcher das dann ganz normal an GRBL sendet. Eine Umrechnung direkt in GRBL müsste ganz am Anfang des Interpreters geschehen. Aber das stelle ich mir aufwändiger vor, als ein kleines Übersetzungsprogramm. Sollen Konturen gefahren werden, also die Achsen interpolieren, dann kann man GRBL eh vergessen. Denn der dort implementierte Bresenham-Algoritmus geht nicht in diesem Koorinatensystem. Das müsste komplett umgeschrieben werden. Da es sowohl bei X/Y als auch Radius/Winkel einen Nullpunkt und einen Maximalwert gibt, kann das System nicht aus Versehen über Null oder durch sich hindurch fahren. Es gibt polar kein Plus/Minus. Es gibt nur 0-360 Grad und einen Radius. In Deinem Fall würde man also z.B. von (r, 225°) nach (r, 315°) fahren, wobei der Arm natürlich eine Kreisbewegung macht und keine Gerade zeichnet. Auch müssen bei der Nutzung der gesamten 360 Grad die Quadranten bei der Umrechnung berücksichtigt werden. Ist aber alles 1000fach beschrieben und keine KI. Natürlich wäre eine genauere Erklärung der Anwendung hilfreich. Gruß Joachim
Ergänzung: Habe gerade gesehen. Ach so, dann wird es natürlich etwas lustiger :-) Jetzt ist das mit dem 2. "Dreh" Arm klar. Gruß
Nennt sich: Horizontal-Knickarm-Roboter oder Schwenkarm-Roboter. (SCARA) Selective Compliance Assembly Robot Arm Hätts das gleich gesagt, hätt ich mir die Antwort sparen können.
Sorry, das der so genannt wird habe ich erst vorhin gesehen. GRBL ist wo möglich nicht der richtige Ansatz, Marlin oder Smoothieware hat das angeblich schon drin. Mal sehen der Code ich auf der Platte und jetzt muss ich mal lesen was da so drin ist.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.