JoergS5 parallel five bar scara
-
@bondus I rechecked your video, the only weakness I see is the left arm (left from the view of the actuators) where the arm can swing in vertical direction because it is only one, not two rods. Your construction with two ball bearings to stabilize vertically is very good IMHO.
-
@bondus said in JoergS5 parallel five bar scara:
I have struggled to accurately measure the angles of the arms at the endpoints. And if they are configured even a fraction of a degree wrong the resulting models are quite badly twisted. To make this kinematics more user friendly I think some kind of calibration method would be needed. It's much easier to measure a distance moved or the length of a printed part than to measure an angle.
I had a similar issue when calibrating my single-arm SCARA printer. For an outline of how I solved it, see the Calibration section at https://miscsolutions.wordpress.com/2017/08/27/converting-the-robotdigg-scara-printer-to-duet-electronics/#more-2563. Maybe it will give you some ideas.
-
@dc42, your "dab" idea is a good alternative to print a large calibration object. I just have to figure out a way to solve the equation. You had only two arms and one angle to adjust, we have four arms and two angles. A brute force numerical method should work fine assuming the initial values are reasonable. One more reason to make a dummy RRF to plug in the kinematics c++ file into.
@JoergS5, the main weakness of my arms are the rotational stiffness of the U-beams. When the elbow is at 90° the z-forces to the hotend are applied as rotation on the inner arm. When the arm is closest to the base the y-forces on the hotend tip are rotating the arms. When the arm is extended x-forces to the hotend tip are rotating the arms. I can see this by moving the arm around and checking by hand how stiff it is and seeing where it flexes.
If you do some mechanical simulations this should be very visible.
For the selection of arm material/geometry this is important. A CF rod with all fibres in one direction might not be good for this application.I would love some harmonic drives. In my experience belted gears have pretty low backlash, but they are very limited in ratio. My current 1:6 gearing is too low (high?) for the size this arm turned out, it's almost down to 30 microsteps per mm at the bad areas. 1:30 or more would be a better gearing, the duet can run the steppers pretty fast.
I use normal deep groove bearings at the base, they are at a sufficient distance from each other to convert z forces at the hotend to horizontal forces. The thrust bearings, with grooved washers, in the elbows are not ideal for this use. They have to take some lateral forces which they are not designed for, but preloaded they keep things very stable, and the lateral loads are pretty low.
I should have put a large thrust bearing in the hotend joint too, there is one deep groove bearing there now. Cross roller bearings would be ideal in all joints, but $$$.@JoergS5, we should join sources. I am updated to latest RRF, but with some features not working as they should (such as IsReachable()). I could setup a RRF fork on github. Ideally it would be linked back to your fork, my git skills are not that advanced.
wall of text
-
@bondus The source is meant to be part of the official source of @dc42 at the end. I suggest we wait until I could test the code with my hardware. This will take until July.
I see two weaknesses in today's code which I wish would be clarified before publishing in the official RRF code:
- the resolution of printing depends on the x-y coordinate. The should be a recommendation of a "good safe" print area. This needs to be tested
- the movement speed varies with x-y coordinates. RRF segments the movement into small parts, so this may not be a problem, but I am not sure about that. I want to measure it to be sure (e.g. measure whether the filament extrustion is even enough).
A final improvement would be to give instructions and help how to change work modes. A safe solution would be to add an additional actuator to cross the singularity areas.
-
@bondus For the hinges, I bought some ball bearings from POM material, to be light. But they have a lot of play. Another possibility is using Hylite, which is polypropylen and has low backlash and is light. One could produce the part from the plates https://www.display.3acomposites.com/hylite.html
You are right with CFK, one must use the correct ones, there are different ones with respect to fibre direction.
-
@JoergS5, I found one more little possible issue. I noticed one more "stepping function" issue when running the code on my PC, after some digging I found an abs() in getAbsoluteAngle(). According to the c standard abs using int. But it looks like that in RRF it actually resolves to using floats, odd. It's better to use a fabs() or fabsf(). I saw no difference in the prints.
Another issue is that when you try to do a CartesianToMotorSteps() of a coordinate that is physically unreachable by the arms (too far away) it does not complain. constraintsOk() does not catch that since the resulting angles and coordinates from getInverse() are NaN. I added a bunch of isnan() to getInverse() to never cache nan values, that works fine.
Hylite is a fascinating material. I guess you have seen http://zatsit.fr/, a hylite based delta printer. I backed the kickstarter.
I managed to "port" the kinematics to my PC with some careful copy-paste, and implemented a small command line utility to output a resolution drawing as an SVG (the easiest way to draw things) . It's fun to play around with arm lengths and limits and see where you end up. This is what my machine looks like:
-
@bondus abs is int, so it is casting the float to int and assigning to float, casting again. It is better to use fabs.
I found an alternative to harmonic drives: https://hackaday.com/2016/12/02/abacus-drive-is-a-speed-to-torque-game-changer/ and a 3D thing: https://www.youmagine.com/designs/abacus-drive-v0-v1 which may be useful
Your PC program is nice. The paper https://pdfs.semanticscholar.org/8a6f/7990e92b13ed7474a2f05b2ac6031193c227.pdf analyzes safe print areas, the deviations of serial vs. parallel scara and gives some hints about stabilizing the arms.
-
I changed my microstepping from 16 to 128 and now my machine prints really nice. It has pretty good repeatability. Using a dial gauge to measure X or Y I can see that it returns within +-25um after moving around. Not bad for a printed machine.
The main issue now is the wobbly Z. Even if it is light and moves fast it needs Z strength to push away imperfections from the lower layers. As it is now it uses imperfections as a kind of jump and they propagate up and along the layers. Producing waves on flat walls.
It's also pretty undamped. It keeps vibrating almost a second after a hit.@JoergS5, running the kinematics on my PC and stretching it to the limits I can see that there are limitations and assumptions in the implementation. Inverse and forward transform do not always agree, and sometimes they returns very strange values.
It would be nice if it could handle the theoretical free robot with no limitations and no collisions of the arms. For all working modes.
I might go crazy on your code and make it behave in all corner cases... -
@bondus Your results are really good, congratulations.
You have some minor problems with Z left and jumping. If your arms are hollow, you could fill them with sand. Filling only about 30-50 % to give them the possibility to move a bit to take up the energy. Fixing them in the arm direction (my first idea was small bags). This would stabilize Z movement and reduce vibrations. The cost is higher inertia and lower maximum speed, but I hope not much.
Your robot idea: there are robot constructions with parallel arms, where the Z axis is included. Kinematics is more complex, but maybe worth implementing. An example is the Dobot Magician *). I would implement the arm elements as trapezoid rods to get the overconstraint and stability of parallel elements.
*) Dobot Magician is visually what I mean, but the rods are fixed. I mean a construction where the rods have hinges each, similar to the parallel scara. This should result in higher resolution and less vibration.
-
I have done some thinking
There are 3 unpowered joints that causes a singularity when they are at 180 degrees, and at 0 (or 360) degrees. Below 180 is stable and over 180 is stable. It would make sense to define the work modes depending on those angles. An angle at 0-180 is one state, 180-360 another state. This would create 8 different modes with the 3 joints (2^3).
First we have the 4 modes that you named:
And then there are the 4 "inside out" modes. The same as 1-4, but on the other side of the machine.
I think that it we use these constraints in the code to pick the right solutions from the equations we will get a fairly simple solution, and it will be complete and general. Both forward and inverse transform should have only one solution in a given working mode, or my theories are wrong.
A few fun positions:
-
@JoergS5 , that wasn't too hard to implement
. The code is a horrible mess and very inefficient, but it works. On my PC.I skipped the extra 4 modes I came up with, they require the arm to travel through a singularity with the hotend joint at 180 degrees. Or even at 0 degrees! I think that is more or less impossible with a stepper driven arm.
And here is a new updated resolution map from my bot (assuming no collisions with anything and full 360 degree actuators). Green is mode 2, blue and red is mode 1 and 4. Yellow is mode 3.
I'll port it over to the Duet after a cleanup. I only have a Maestro board for the Scara, it has no FPU. So I have to be careful with all the floating point trigonometry. An obvious optimization is to not actually compute the angles of the joints, all we need to know is if it's a left turn or a right turn, that is easy to do without trigonometry.
-
@bondus Your image is very nice. But for 3D printing, we need a continuous print area, so I would restrict it to the red-blue area. That's the main reason why I defined a printable area to be a rectangle. There is a bit additional printable area outside of the rectangle, but I expect only a few % gain.
You can change the print area for your printer by making the distance of the actuators variable (manuallly or by an additional actuator), so you can enlarge or reduce the print area. You mounted the actuators on one aluminium profile, so changing the distance is easy. For every object to be printed there will be an optimal distance: fitting print area with maximum resolution.
I design a printer where the heatbed fits the to be printed 3D object, so only the needed area needs to be heaten up. Together with the actuator distance and optimal arm lengths, a best print result can be achieved. -
@JoergS5, I have disabled all the limit checks just to see that all the math works as intended. When I turn the limits on all is back to normal. I'm a computer scientist, not an engineer. I want the theory right
.
Before this logic was implemented there were areas (even in reasonable print areas) where forward and inverse transforms did not agree. The changes for this are just the "if"s in getTheta() and getForward(), no major changes.There are some cases where the math breaks down and forward and inverse transforms do not agree. This is totally expected
since it is along the singularity lines. Figure 10 in the DexTAR paper (https://pdfs.semanticscholar.org/4f94/5b3db879c18c8fdf2b01860d8a9b2f9a274d.pdf) shows this very clearly. That is a fantastic figure.It's an interesting idea to have adjustable actuator distance. I think that if you want to build a useful printer you have to pick a work mode and choose the length of the arms and distance of the actuators to get a reasonable large printer area. Mode 2 benefits from having long distal arms, mode 1 and 4 are better with equal length arms and a big distance between the actuators. I imagine that for mode 1 and 4 you could even have different lengths of left and right to maximise work are.
I made a github repo, https://github.com/bondus/5barscara. Right now there are just the lab files for the kinematics (copy pasted from the kinematics from RRF) and the test program drawing those fancy pictures. I'll add my version of the RRF kinematics once I got the new stuff ported over.
Some pupils (actuators) for the masked five-bar-man:
Be careful with a partially heated bed, you might warp it.
-
@bondus nice face LOL - take it as logo for the printer...
I didn't mean a partially heated bed, but a small bed. For every to be printed object a separate heat bed.
-
I made the face interactive using some JS and html: https://fivebarscara.000webhostapp.com/test.html.
It's a little web page where you can input arm lengths, actuator distance and work mode. And interactively see the work areas, and the arms moving. Move the mouse over the work area and the arms will pop up. Different colours for different work modes.
It's quite mesmerizing.
I might add the angle limitations to the interface. It could be a useful tool for anyone brave enough to build a five bar scara. It's still useful to understand how fire bar scaras moves.
-
@bondus The tool is nice. I have ideas for improvement
I used arms lengths 400, so a zoom in/out would be nice. Showing the coordinates of the hotend point would be nice to know the printable area. -
I pushed my current 5 bar code to https://github.com/bondus/5barscara/tree/master/rrf, it's what I use on my printer right now.
The main thing compared to @JoergS5's implementation is the more general angle logic. As explained above.
And it's updated to the current RRF.
The code needs some love to be production quality, but it works good as is. -
I found this interesting implementation a few days ago, http://3dgems.blogspot.com/2016/01/scara-based-3d-printer-v3-details.html.
This kinematics should handle it. It is a work mode 2 arm with a very long negative cantilever on the left arm. It should work as long as the hotend is not offset from the straight cantilever. -
@bondus Thanks for the link, this seems to be a very stiff construction. The print area seems to be limited somehow, because the arms are in each other's way.
I've started building my Scara now, I will have images soon. Then I will update the source in RRF3 (including your improvements and bug fixes) and make a push request to David. My current plan to implement the endstops: set proximal arms perpendicular to base line and measure them for parallelism.
-
Looking forward to those images of your machine.
I have been struggling a bit with the calibration of the printer. It is not accurate enough to print parts for itself.
I made some experiments with printing a calibration item, measuring it and feeding it into a program to compute the actual homing angles, and adjustment to the arm lengths. I have not not been successful. Yet.
Your idea to move them to 90deg and measure parallelism and perpendicularity (is that a word?) is faster and easier. Adding S1 to a G1 command moves the arm to a specified angle, G1 S1 X90 Y90.
