Five bar parallel Scara

JoergS5

@dc42 @bondus I made a PR #297 now into v2-dev. The files compile ok, the PR should only contain the two files .h and .cpp of the kinematic. Please include into your main RRF. I am sure there are bugs or improvements left, so there will be updates.

bondus, I changed a few of the methods to be the same signature as the original methods, because they were overridden methods. I hope I didn't break your code. (I saw now that the changed methods are due to changes between v2 and v3)

bondus

@joergs5, Sweet!
After some battling with the RRF build (the build environment is quite fragile) I got it building and running. It works perfectly fine.
I never managed to get v3 running properly. After some workarounds with the homing issues I got it moving. But it refused to print any gcode files, it did nothing after starting a gcode file.

JoergS5

@bondus I will try RRF3 after finishing my printer build. First priority is to build the optical encoders for the endstops with ESP32-CAM (I will use the mechanism for Z axis also), then as stiff arms as possible. I will try dry plain bearings with plastic surfaces at the sliding surface. PTFE (teflon) has lowest friction, nylon a bit worse (but easier to 3D print).

oliof

@JoergS5 slightly offtopic, but: would the optical encoder based endstop also work on a traditional SCARA arm?

JoergS5

@oliof yes, it will work with all actuators which rotate. The advantage is that the endstop can be approached from both sides and can tell the absolute angle at any time. I will write a documentation for diy steps and software.

dc42

@joergs5 said in Five bar parallel Scara:

@dc42 @bondus I made a PR #297 now into v2-dev. The files compile ok, the PR should only contain the two files .h and .cpp of the kinematic. Please include into your main RRF. I am sure there are bugs or improvements left, so there will be updates.

v2-dev is no longer used, it was for the initial development of RRF 2.0. The branch used for firmware 2.x is now the dev branch. So that is there your PR should be targeted.

JoergS5

@dc42 I am confused now. Which branch shall I use for the PR. Or other proposal: I implement it for RRF 3 dev branch and withdraw the PR 297. When you finished your Duet 3, I will be ready for the RRF3 PR.

dc42

@joergs5, yes a PR for RRF3 on the v3-dev branch would be good, if you have tested it.

JoergS5

@dc42 I will change to RRF3 and correct the bug we found. Good luck with your Duet 3, I am very curious what it will be like!

bondus

@JoergS5, @dc42. I should give RRF3 another go to get five bar scara going. But me and Eclipse have a decade long battle that never settles.

JoergS5

@bondus That's good news if you can test RRF3.

I am used to use Eclipse for Java, but I am often confused by the eclipse behaviour. Especially at RRF I am confused by the different setting for the different hardware and the error message that pop up here and there for some .h files not being compilable. I understand why David has it in the code, but my Eclipse tells me about errors, because a grayed file cannot be compiled or found.

I thought about a fork and throw out all those RADDS, Duet 085 and other hardware which is not relevant for my hardware. And I would like to throw out Delta, heatbed calibration code to have the pure logic in the code which I need, and to understand the code. But it's a lot of work, and then I have to synchronize somehow.

bondus

I woke up my old printer and gave it a new fancy 300x200mm machined bed.

Only to realize why I have not used it very much. Straight lines are not always straight when printed. It is not made with the precision needed for an arm like this.

I need to properly measure all the arm lengths and homing angles and put them into the firmware and all should be fine.

JoergS5

Nice build, @bondus. I thought about calibration for my printer also. Ich will go the other way: meassure the results for a given configuration and then calculate back what the dimensions of the arms are.
E.g. move to 0,0 and 300,300 with Gcode and then check what abbreviations of the expected positions are. Calculate back the true arm lengths and actuator angles. I hope this will give some corrections of other errors also (hinge movements, arm bending e.g.)

bondus

@JoergS5 said in Five bar parallel Scara:

meassure the results for a given configuration and then calculate back what the dimensions of the arms are.

I tried an approach like that a while back but never got it working, it should work in theory, so it was my execution that was wrong.

There are 7 unknowns that might need adjusting: The length of each of the five "bars" and the two homing angles. You will need quite a few measurements to get a single solution to the adjustment equation.

Now with a bigger, and very flat, bed I also noticed that the head does not move in a perfect plane, it's about 0.3mm higher at the left and right edges compared to the middle. The quick and dirty solution is to add a bed probe, or I could start looking for non-perpendicular angles on the machine.

JoergS5

@bondus My ideas for better Z accuracy are (sorted by cost, cheapest and easiest first):

counterweights at the other side of all hinges at the opposite side of the arms (leverage law or ball bearings could produce your 0.3 mm differences)
hinges supported with two arms each vertically, so the hinges are more precise
hinges with metal material

bondus

@JoergS5, I really think that some critical parts of the arm should be machined. Tiny errors in precision in the parts holding the proximal arms are amplified further out. Possibly you could make some clever parts where you could tune it by tightening/loosening different bolts. This is not unique for this kind of robot arm, any arm moving by rotating a join will have the errors amplified. Linear rails are far easier to use.

My design with the whole arm assembly moving up and down on the z-axis is tricky to design. There is very little room to place screws from the lower part to the upper part, to preload the bearings. The large pulleys and the goal to keep the arms rotation range as big as possible does not make it easy. The current version is far from ideal.

I am working on a better version, but every time I start fusion I lose a day. It's very mesmerizing to 3D CAD.

I installed an old precision piezo to measure the Z error properly. I had one of the the old crummy versions with a drilled piezo element laying around. It still works fine.

I can see that the arms lifts the actuator the further out the actuator is. It's not due the tower being at the wrong angle, or the weight of the arms bending it down. Some other angle(s) are wrong. It's a complicated machine

It's officially spring here now, at least on my balcony. The bulbs from last year are flowering.

Phaedrux

@bondus Holy crap, is that a flower? It's the dead of winter here. I feel like I haven't seen colours like that in ages.

JoergS5

@bondus Nice narcissus, it becomes spring!

I was thinking a lot about precision of parallel scara the last months, especially of the hinges. Additional ideas to my last ideas are:

supporting the arms by steel wires like at some cranes like in This goes into the direction of tensegrity also.
from compliant mechanism replacing ball bearings with something like in https://3dprint.com/252086/developing-3d-printed-soft-actuators-for-robotic-arms/ (I mean the black one, called revolute joint in the image) or https://www.youtube.com/watch?v=0MQXoVKrRbo One can get about 30 degree with the first one, called butterfly hinge also. Other ideas are Hylite hinge and crossed springs (german: Kreuzfedergelenk), but one gets only about 15 to 30 degree rotation. Hylite is very interesting, because the multimaterial polypropylene with something carbon based could be printed easily with the new multimaterial printers.
trying calibrate the actuators separately by rotating them the three directions each, so hinge errors are minimized. But I didn't calculate how to do it best.

I final idea: we had some interesting discussion about uneven printing, so a fast z movement would be interesting. This movement can be small (layer height * small number), so some piezo actuator which moves the hotend could be used. This piezo mover could correct your arm height errors also. The supplier https://www.cedrat-technologies.com/en/technologies/actuators/piezo-actuators-and-electronics.html show what is possible with stacked piezo elements.

bondus

It's fun to see Fusion 360 struggle with the five bar kinematics. It's doing a surprisingly good job.

I'm working on a smaller version with greater movement range that will eventually evolve into a version 2 of the printer. The current version has many flaws.

I wish I had a lathe and a router to make some small items. There are some critical parts in the joints that would benefit greatly from being made in steel or aluminium. Perhaps there is a makerspace nearby...

JoergS5

@bondus this is the direction I go also. My construction has a larger big wheel (your red ones), so the gear between stepper and wheel is about 1:30 (results stepper 10 turns/s => arm hotend speed about 10/30*300 = 100 mm/s). The hinges are critical imho, so I support the axis with two ball bearings each. I have not decided yet wheter I will use two arms each or using wires to stabilize. Instead of steel arms you could use carbon fiber also: similar e-module, lighter and less thermal expansion, but more expensive and more difficult to glue/connect.