1986er (1985er) Trainingsroboter-meine Version

[atzensepp]

Hallo,

Simon's Vorschlag ist "betörend". Daher habe ich ihn gleich mal ausprobiert und habe dabei Jan's Potentiometerhalter gedruckt und eingesetzt.
Da diese Potentiometer auf 270 Grad ausgelegt sind, ist die Auflösung nicht so gut wie bei der Lösung mit dem Servo-Potentiometer. Müsste man ggf. noch eine Übersetzung einbauen. (Was natürlich auch elektronisch ginge)

TR2.JPG (50.26 KiB) 1287 mal betrachtet

Und hier die Arretierung auf der anderen Seite:

TR1.JPG (53.49 KiB) 1287 mal betrachtet

EDIT: Auf jeden Fall läuft die Steuerung mit PID deutlich besser. Ich nehme an, weil keine Zahnradübersetzungen mit Spiel dazwischen sind.

Allerdings werde ich vermutlich auf Magnet-Encoder umrüsten. Die haben eine höhere Auflösung und ich muss nicht mit Übersetzungen arbeiten.
Hier wie das beim unteren Arm aussehen könnte:

TR3.JPG (58.93 KiB) 1287 mal betrachtet

Nicht so elegant und eine i2c-Weiche ist nötig aber man tut sich vielleicht etwas leichter mit der Handhabung.

[XG BC]

Hallo,
Danke! War gerade am überlegen wie ich das arretieren sollte, du hast mir die lösung geliefert!
Grüße,
Simon

[atzensepp]

Hallo Simon,

vielleicht gefällt Dir diese Arretierung besser, weil man sie justieren kann.

TR4.JPG (48.28 KiB) 1244 mal betrachtet

Viele Grüße
Florian

[XG BC]

So, habe heute mal deine nicht justierbare Version gebaut:

Hier die andere Seite:

Funktioniert sehr gut, habe mein Programm noch etwas angepasst (zum test deines Programms bin ich leider nicht mehr gekommen). Ich habe den Roboter auch wieder komplett Schwarz gemacht, das gefällt mir persönlich besser als Schwarz/Grün.
Grüße,
Simon

[atzensepp]

Hallo Simon,

das sieht schon cool aus. Aber ich finde, das grün hat was. Es passt zu Deinen Potentiometern.

Mein PID-Programm ist noch nicht getuned. Ich habe immer noch einen Offset oder Oszillationen.
Mit meinen Potentiomentern bin ich noch nicht ganz glücklich:
Für die 90-Grad-Potis muss ich Übersetzung einbauen, was dann wieder Spiel rein bringt und die
270-Grad-Potis haben (ohne Verstärkung) einen zu geringen Spannungshub bzw. ich müsste in die andere Richtung übersetzen.

Grüße
Florian

[XG BC]

Hallo Florian,
Hmm ja, dann entweder doch 180 grad servo potis finden, oder auf magnetisch umbauen. Du könntest evtl. auch die spannung verstärken mit opv, dann wäre der Unterschied den der arduino dann bekommt größer. Das wäre dann effektiv eine "Übersetzung" nur halt ohne spiel (wie stark das dann rauscht keine Ahnung).
Grüße,
Simon

[atzensepp]

Eine mechanische Lösung, die mit dem Encoder von Jan passabel funktioniert, nutzt eine Übersetzung von 15:10, die 180 Grad auf die 270 Grad des Trimmers abbildet.

Juhencoder.JPG (52.46 KiB) 1051 mal betrachtet

Ich habe hin und wieder den Effekt, dass sich der Potiwert nicht ändert, obwohl sich der Arm bewegt als ob das Poti irgendwie hängt. Habe noch nicht rausgefunden, woran das liegt. Diese Tirmmer haben ja einen mechanischen Widerstand. Vielleicht ist es ja das.

[atzensepp]

Ich messe jetzt die Armwinkel magnetisch.

MS1.JPG (59.05 KiB) 1029 mal betrachtet

Die PID-Regelung funktioniert damit deutlich besser. Keine Überschwinger mehr, fast kein Offset.

[atzensepp]

Inzwischen habe ich alle Positions-Sensoren auf Manget-Encoder umgestellt. Der Aufbau musste noch mal höher gelegt werden, um Platz für einen Encoder direkt unter der Drehachse zu schaffen. Und leider musste ich wegen der Halterung des Magneten eine Kunststoffachse nehmen.

TR028.JPG (55.38 KiB) 952 mal betrachtet

Der Drehteller-Antrieb wurde auch noch mal geändert:

TR027.JPG (79.46 KiB) 952 mal betrachtet

Und der "Fail-of the week": Die Umstellung des Drehantriebs auf m05-Zahnräder hat nicht funktioniert.
Vor allem die Schnecke ist immer durchgerutscht. Müsste ich vermutlich dünner drucken. Allerdings sind bei meinem 3d-Druck die vertikal gedruckten Schneckenprofile etwas aufgebläht. Die horizontal gedruckten Zahnräder sind sauber und funktionieren.

[Harald]

Vor allem die Schnecke ist immer durchgerutscht. Müsste ich vermutlich dünner drucken. Allerdings sind bei meinem 3d-Druck die vertikal gedruckten Schneckenprofile etwas aufgebläht.

Bei Zahnrädern könnte man etwas tricksen: Profilverschiebung (einwärts), oder vielleicht auswärts kombiniert mit einem kleineren Modul. Bei der Schnecke natürlich auch, da ist die Frage, ob das CAD-Programm sowas kennt.

Gruß,
Harald

[XG BC]

Da mein greifer mit dem erweiterten bewegungsraum am arm hängenbleibt, habe ich ihn mal bisschen umgebaut (nur ein prototyp, ich werde das noch mal schöner bauen)
PXL_20250616_212942168~2 by XG BC, auf Flickr

Der motor ist jetzt über dem gestänge, nicht mehr dahinter, daher ist das ganze etwas kompakter, und vor allem kürzer.
PXL_20250616_212952534 by XG BC, auf Flickr

Ich habe auch noch ein Paar andere dinge geändert, 3d modelle und bilder folgen.

Grüße,
Simon

[Karl]

Hallo,
ohne Worte....

[XG BC]

Hallo,
ohne Worte....

Was soll ich sagen, es passte einfach zufällig zusammen, die anderen Teile des Horns waren im weg, daher habe ich sie abgeschnitten.

Screenshot 2025-06-17 141639 by XG BC, auf Flickr

Ich habe die Befestigung der Hubmechanik noch etwas geändert, Poti ist jetzt wie gesagt auch direkt, ohne Gestänge montiert.

Screenshot 2025-06-17 141702 by XG BC, auf Flickr

Die arretierung der achse ist wie bei Florians nicht justierbarer version, das funktioniert gut.

Screenshot 2025-06-17 141811 by XG BC, auf Flickr

Zum Schluss habe ich noch die befestigung der Motoren der Drehung geändert, und die Kopplung anders gemacht, jetzt werden die Ausgänge mit z10 zusammengeschaltet, das ist stabiler.

Screenshot 2025-06-17 142534 by XG BC, auf Flickr
Das ist noch die modifizierte Anlenkung des Endes, da ansonsten die Ausgleichsmechanik dagegen stößt.

Grüße,
Simon

[XG BC]

So, gerade den greifer noch "schön" gemacht





Grüße,
Simon

[atzensepp]

Sehr elegant! Ein Kritikpunkt wäre evtl. die dünne, hinten stehende Verblendplatte, die den Greifer mit dem Oberteil verbindet (wegen Verbiegungsgefahr) Aber die Gewichte, die gehoben werden, sind ohnehin so gering, dass das wahrscheinlich keine Bedeutung hat.

[XG BC]

Die dünne Platte war absicht, damit der greifer so kurz und leicht wie moglich wird, aber es ist okay, man hebt ja keine gewaltigen lasten. man könnte das ganze natürlich auch stärker verbinden.

Grüße,
Simon

[atzensepp]

Der Schneckenantrieb tut sich bei mir ziemlich schwer infolge der hohen Last. Daher habe ich jetzt einen größeren Hebel für den unteren Arm eingebaut und auch die Befestigung am Arm verstärkt. Beachtet auch die etwas kürzere BS7.5-Schiene am Motor, damit der Läufer bis unten ran kommt.

TR031.JPG (66.57 KiB) 314 mal betrachtet

Die Übersetzung wird dadurch noch etwas langsamer aber der Motor tut sich damit leichter.

Die Kinematik rechne ich jetzt nicht mehr mit Newton-Verfahren aus, sondern direkt (von Copilot generiert und von mir bis zum Laufen debugged (3 Fehler)).
Der Winkel theta1 ist der Inklinationswinkel des unteren Armes und theta2 der Winkel zwischen beiden Armen.
Der Vorteil ist, dass man bei doppeldeutigen Lösungen, eine auswählen kann.

Code: Alles auswählen

typedef struct { 
    float theta1; 
    float theta2; 
    int valid; } ScaraIKResult;

typedef struct {
    float x;
    float y;
} ScaraFKResult;

ScaraIKResult scara_ik(ScaraFKResult fk, float L1, float L2, int elbow_up) {
    ScaraIKResult result;
    float x,y;
    x=fk.x;
    y=fk.y;
    float r2 = x*x + y*y;
    float c2 = - (r2 - L1*L1 - L2*L2) / (2 * L1 * L2); // Cosinus-Satz
    if (fabs(c2) > 1.0) {
        result.valid = 0;
        return result;
    }
    float s2 = elbow_up ? -sqrt(1 - c2*c2) : sqrt(1 - c2*c2);
    result.theta2 = atan2(s2, c2);
    float k1 = L1 - L2 * c2;
    float k2 = L2 * s2;
    result.theta1 = atan2(y, x) + atan2(k2, k1);

    result.valid = 1;
    return result;
}

[atzensepp]

Die Kinematik und die PID-Regelung funktionieren jetzt einigermaßen. Allerdings habe ich dem unteren Arm eine Rückholfeder spendiert:

tr033.JPG (57.44 KiB) 178 mal betrachtet

Der obere Arm funktioniert sehr leicht. Aber beim Unteren tut sich der Schneckenantrieb immer noch schwer und die Bewegung ist deutlich langsamer als vom Oberen, was dazu führt, dass der Endeffektor beim Verfahren in x-Richtung immer erst nach oben oder unten schwingt. Eigentlich möchte man ja eine horizontale Bewegung.

Ich bin am überlegen, ob man den Schneckenantrieb nicht auch durch einen Flaschenzug ersetzen sollte und den Roboter dann eher mit klassischer Kran-Mechanik wie dieser hier aufbaut.

tr034.JPG (49.36 KiB) 178 mal betrachtet

EDIT: Nachteil dieses Aufbaus: unterer Arm kann nur bis 90 Grad und nicht zurück. Mit langsamerem Windenmotor kann ich inzwischen (unter bestimmten Bedingungen) auch gerade Linien fahren.

[rubem]

Hi all,

Meanwhile, here is my version (for now):

Traning robot.jpg (698.45 KiB) 37 mal betrachtet

I'm using a different approach. I'm trying to replicate the original as closely as possible but use only modern, easily available parts. The most obvious exceptions are the aluminium beams, but these can easily be replaced with statics, as you are already doing. I decided for a TXT 4.0 with encoder motors, which avoids the need for custom encoders. Other alu beams in the original are replaced with standard B30 blocks reinforced with steel axles and blocks 5 at the ends. A really exotic component is the 3D printer's sleeve 160549 which I use to couple the servo to the axle that drives the Z30 gear in the gripper mechanism... But I'm not satisfied with the gripper anyway, so maybe I'll break my own "pure ft" rule and use Simon's gripper which is such a brilliant idea . A solution using a mini-motor and two switches would be too bulky, but maybe I'll give it a try as well. Let's see. Another point I still don't like about my project is that the slewing ring rotates too slowly because a Z20 gear (like the ones used in the other motors to double the speed) hits the Z10 gear's collets.

Any comments and suggestions will be much appreciated!

Many thanks (again) and best regards,

Rubem

----------------------------------- Google Translate

Hallo zusammen,

Hier ist meine Version (vorerst):

[Bild]

Ich gehe einen anderen Weg. Ich versuche, das Original so genau wie möglich nachzubilden, verwende aber nur moderne, leicht erhältliche Teile. Die offensichtlichsten Ausnahmen sind die Aluminiumträger, die aber problemlos durch Statikteile ersetzt werden können, wie ihr es bereits tut. Ich habe mich für einen TXT 4.0 mit Encodermotoren entschieden, wodurch keine speziellen Encoder benötigt werden. Andere Aluminiumträger im Original wurden durch Standard-B30-Blöcke ersetzt, die mit Stahlachsen und Blöcken 5 an den Enden verstärkt sind. Ein wirklich exotisches Bauteil ist die Hülse 160549 aus dem 3D-Drucker, mit der ich das Servo mit der Achse verbinde, die das Z30-Zahnrad im Greifermechanismus antreibt... Aber ich bin mit dem Greifer sowieso nicht zufrieden, also breche ich vielleicht meine eigene „Pure-Foot“-Regel und verwende Simons Greifer – eine wirklich brillante Idee . Eine Lösung mit einem Minimotor und zwei Schaltern wäre zu sperrig, aber vielleicht probiere ich es auch mal. Mal sehen. Ein weiterer Punkt, der mir an meinem Projekt noch nicht gefällt, ist, dass sich der Drehkranz zu langsam dreht, weil ein Z20-Zahnrad (wie es in den anderen Motoren zur Verdoppelung der Geschwindigkeit verwendet wird) auf die Spannzangen des Z10-Zahnrads trifft.

Für Kommentare und Vorschläge bin ich sehr dankbar!

Vielen Dank (nochmals) und beste Grüße,

Rubem

[atzensepp]

Hallo Rubem,

da hast Du wirklich ein sehr schickes Modell gebaut. Gratuliere!

Ein Plan, vor allem für Deinen Greifer wäre interessant.

Du verwendest zwei Schneckenantriebe. In meinem Modell habe ich für den unteren Arm einen schwarzen XM-Motor, der normalerweise stärker als der rote Encodermotor ist. Um den Arm bewegen zu können, muss ich von Z10 auf Z30 gehen, was den unteren Arm deutlich träger macht.

Mich würde jetzt speziell interessieren:
Reicht das Drehmoment bei Deiner Z20:Z10 aus, um den Arm gut liften zu können?
Sind die Geschwindigkeiten der beiden Arme vergleichbar?

Viele Grüße
Florian