I have been busy working through the design of the slew ring (i.e. Lazy Susan).
Now that I am happy with this, I thought looking at the "required" envelope would be useful:
I was targeting a rectangle two times arm length (width) by one time arm length (height).
Also minimising the working area. The parameters where:
The 145 degrees on Arm 2 may be tricky for the current design:
The maximum rotation is 113.5 degrees (red arm).
After optimising the problem I get:
The parameters where:
After working with the parameters for a while I can see an analytical solution to this.
I coded a spreadsheet:
D | 125.00 | Working Area Height |
L1 | 125.00 | Arm 1 Length |
L2 | 125.00 | Arm 2 Length |
A1Min | -18.42 | Calculated Motor 1 Range (Min) |
A1Max | 103.45 | Calculated Motor 1 Range (Max) |
A2Min | 10.00 | Motor 2 Range (Set Min) |
A2Max | 140.00 | Motor 2 Range (Set Max) |
Dx | -116.91 | Bottom Left Corner |
Dy | 85.51 | Bottom Left Corner |
Here is the image:
Here is a design for 180mm length arms (rather than the 125mm length arms calculated above):
The work area is 360mm x 180mm and the platform is 480mm x 480mm.
Here is the design in section:
All good!
I often start a mechanical design with Aluminum (steel is too hard for my China CNC machine to cut (unless I am desperate). Aluminium is easy to cut if you use the right cutter (i.e. single flute). Aluminium angle is light and stiff, but cutting both sides of the angle accurately is an unresolved problem. Aluminium flat bar is a good compromise. It just becomes a design issue.
Alloy 6061-T1
Thickness 3 mm
Young's Modulus 69 GPa
Ultimate Strength 210 MPa
Yield Strength 110 MPa
Working Stress 80 MPa
The stuff looks good and the "good" stuff lasts. I find most of the stuff I get stress cracks after a few months. So although I am keen to use it, I dare not as I don't know if I have the "good" stuff.
Thickness 3 mm
Young's Modulus 3.2 GPa
Yield Strength 70 MPa
Working Stress 45 MPa
I use an online laser cutting service and the thickest they offer is 6mm.
Thickness 6 mm
Young's Modulus 4.0 GPa
Bending Strength 18 MPa
Working Stress 12 MPa
So MDF is pretty weak but it is thicker. So why use it?
There are lots of failure modes and serviceability requiements that real mechanical design needs to consider, but for toys only "stress" and "deflection" are important.
For a canterlever flat bar (beam) of length (L), width (b), thickness (h) and a point load of (F):
Young's Modulus E
Moment of Inertia I=b*h^3/12 (m^4)
Section Modulus Z=b*h^2/6 (m^3)
Moment M=L*F (Nm)
Stress S=M/Z (Pa)
Deflection d=F*L^3/I/E/3
So what does all this mean?
From a serviceability point of view, deflection is important.
A "floppy" CNC machine is not much use.
We can either use very stiff (high Young's Modulus (E)) materials or use thicker materials.
The deflection equation tells us that if the material is twice as thick (6 mm versus 3 mm) then the deflection will be 1/8. So although Aluminium is 17 times stiffer than MDF, as the MDF is twice as thick the deflection will only be twice that of Aluminium!
One of the advantages of MDF is that you only need to glue two pieces together (for 12 mm thickness) and it will be much stiffer than Aluminium and just stiffer than 3 mm steel (E=210 GPa).
The other reason to use MDF is that so long as it does not get wet it is dimensionally stable.
---
Although I considered doubling up the thickness of the first arm of the SCARA, I have "another trick up my sleeve", I can epoxy fibreglass on both sides of the MDF to increase both strength and stiffness.
AlanX
A simple laser SCARA:
It uses 50mmx25mmx3mm aluminum bracket.
The main downsides are:
Still it should be useful for testing.
Reworked the design away from 50mm x 25mm 3mm aluminum angle.
Here is a 6mm MDF design:
And the laser cutout (300mmx300mmx6mm MDF sheet):
The bending moment calculations suggest less than 0.5mm deflection (assumes 2.5N end load). Maximum end load is 30N (~5mm deflection).
I sent the design away to be cut by a professional laser cutting company.
AlanX
Created a GUI version of gCode2SCARA, call SCARA2gCodeTest (I seem to have messed up the name!). The GUI has the added advantage of communicating via a serial port (real or USB) to talk directly to Grbl:
Here is a typical input gCode file (that can been filtered using the input tolerance slider):
And the output (SCARA) gCode (that can also be adjusted to smoothness):
Note, I have deliberately set the offsets so that port of the file is out of bounds.
Just for fun, the stepper motor steps per revolution can be reduced (from 19200 to 3200):
Some minor bugs. with the filter code. Exporting some blank lines.
---
More bugs!
Implemented a Feed Speed control for the SCARA (it is a laser engraver after all). UV space is non-linear so need to issue an updated SCARA feed speed more often.
I have assumed Grbl is set to 100 steps per mm for each axis, so his needs to be added to the GUI interface.
---
If I abort Grbl while running, it locks it self. Even after soft-reset it needs a $X to unlock.
---
Updated the serial code to accept ttyACM0-7 as the AtMega2560 Pro-mini uses a different RS232 chip.
---
Otherwise, all good, AlanX
Here is the Stepper Motor Driver Board:
Almost no documentation in the Internet on this board! It is cheap and I have used it before.
Mapping/tracing the Nano pins I get:
There are also:
One fault with these boards is that the shunts to control the micro stepping does not work. I added these 10k pull-ups to fix the problem:
Pre-processing "cartesian" gCode with gCode2SCARA allows the use of Grbl for a SCARA arm (UVZ type). This what I would recommend to get started.
Is some code that I wrote that will also do the job.
Is some more code that I wrote (but needs some work of the interpreter) that could also do the job. I intend to finish this code off to work with gCodeFilter and gCode2SCARA at some point of time.
If you have not realised, gCode2SCARA is a command line program program designed to be used via a batch file. Here are the current options:
-i Input File
-o Output File
-t XY Space Tolerance (mm)
-s UV Space Tolerance (full steps)
-xc gCode X Offset (mm)
-yc gCode Y Offset (mm)
-L1 Arm 1 Length (mm)
-L2 Arm 2 Length (mm)
-M1 Motor 1 Steps
-M2 Motor 2 Steps
This project could benefit from a "Visual Windows" programming approach, so probably time to look at what is available for Linux that is simple to use.
AlanX
The code is basically done, some check work remains.
Here is the XY space (filtered from 45984 points down to 2029 points, i.e. -t 0.01):
And here is the UV Space (-s 0.01 and 2029 points, no additional inserted point):
The UV plot (i.e. the output) however does not consider the step resolution (i.e. UV space is floating point). The plot seems to be in the wrong quadrant (it is possible as I have changed the reverse kinematics mathematics).
I will will have to create another plot window to show the effect of step resolution.
So just some tidy up remains.
Yesterday I was helping my partner clean her house after the floor boards were sanded and varnished. So no work!
The code checks out, need to do something better for when the arms will not reach, currently just set the location to (0,0). Better to make it obvious in the imagery.
Checked that the reverse kinematics works in all quadrants. Here is an example with the arm movements shown:
Added a Bressenham trace (yellow/green), in this case for M1 and M2 equal to 400 steps each (note, the image has been shifted to exceed the limits of the reach of the arms):
Here is the case for M1 and M2 equal to 1600 steps (1/4 micro-stepping):
And finally M12800 (1/32 micro stepping):
Note that G0 (rapid movement is an arc rather than a straight line).
So other than modifications required (discovered) when I actually use the code on a machine, it is done.
AlanX
Its a rather "long road" to write a Grbl replacement (perhaps later), but converting gCode from XYZ to UVZ is not. I have seen that someone has already done this on the Internet (sorry I have lost the link). So basically after conversion you can use Grbl instead.
Perhaps I am wrong but Grbl does not appear to handle UVZ coordinate systems.
I already have a gCode Filter project that can be co-opted into service.
After filtering the gCode to remove "redundant" segments (i.e. the main function of gCode Filter), I only need map the UVZ space and to insert the critical points.
I have made a start, set up two graphical results windows, one for XY space and the other for UV space. Still about a days coding left to complete (wishful thinking perhaps?).
One of the issues for construction of a SCARA is the bearing. Nearly all the projects I have looked at are DIY. It would be nice to get something reasonalbe (lazy susan bearings are pretty bad!) off the self.
For a big project a car one piece stub axle looks like an option (~AUD50):
After a bit of searching I found good candidate, a bicycle front wheel hub:
Are you excited yet? AlanX
After playing with the Options presented in my first post, I have decided Option 1 is the best. Why? It should have the least number of the expensive reverse kinematic calculations. Consider a very coarse tolerance (=128):
Note that the UV space (blue lines) has only 6 points (the straight lines between them are Bressenham lines).
Now the medium tolerance case (=32):
Here there is only 13 reverse kinematic calculations.
Now the very fine tolerance (=8):
Here there is only 25 reverse kinematic calculations.
Finally ultra fine tolerance (=1), has 67 calculations:
Although the number of reverse kinematic calculations are a minimum, there still may be advantage is fast (integer?) methods. The CORDIC algorithm comes to mind, especially for the ATAN2() and sqrt() functions. ArcSin/ArcCos should also be possible.
Here is my version of Rect2Polar (i.e ATAN2() and sqrt()) using short (i.e int16) integers:
// Include libraries
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <math.h>
#include <stdbool.h>
void rect2polar(short X,short Y,short *R,short *A)
{
// ATAN_Table is the values of ATAN(1/(2^i))*400*32/2/Pi micro-steps
short ATAN[12]={1600,945,499,253,127,64,32,16,8,4,2,1};
short i,Xnew,Ynew;
(*A)=0;
if (X<0) {
(*A)=200*32; // 180 degrees
X=-X;
Y=-Y;
} else if (Y<0) {
(*A)=400*32; // =360 degrees
}
for (i=0;i<12;i++) {
if (Y<0) {
// Rotate CCW
Xnew=X-(Y>>i);
Ynew=Y+(X>>i);
(*A)=(*A)-ATAN[i];
} else {
// Rotate CW
Xnew=X+(Y>>i);
Ynew=Y-(X>>i);
(*A)=(*A)+ATAN[i];
}
X=Xnew;
Y=Ynew;
}
// Adjust for gain (=X*0.607252935)
X=X>>1;
(*R)=(((((((((((((((((X>>2)+X)>>2)+X)>>1)+X)>>1)+X)>>2)+X)>>1)+X)>>2)+X)>>1)+X)>>3)+X;
}
int main(void) {
short A,R,X,Y;
X=-439*32;
Y=-439*32;
// R=621*32 max
rect2polar(X,Y,&R,&A);
printf("Rect2Polar x %8.3f y %8.3f ang %8.3f hyp %8.3f\n",X/32.0,Y/32.0,A*360.0/400.0/32.0,R/32.0);
printf("atan2() x %8.3f y %8.3f ang %8.3f hyp %8.3f\n",X/32.0,Y/32.0,360+atan2(Y,X)*180/M_PI,sqrt(X*X+Y*Y)/32.0);
return 0;
}
Here is the result:
$ ./ShortCAtan
Rect2Polar x -439.000 y -439.000 ang 225.028 hyp 620.812
atan2() x -439.000 y -439.000 ang 225.000 hyp 620.840
$
So about 4 digits of accuracy with 16 bit integers.
I reworked the mathematics to suit CORDIC:
Here is my ArcSin CORDIC:
// This version works properly but has a multiplication in the main loop
short arcSin(short R, short S) {
// ATAN_Table is the values of ATAN(1/(2^i))*400*32/2/Pi micro-steps
short ATAN[12]={1600,945,499,253,127,64,32,16,8,4,2,1};
// SEC[i]=(int)((1/COS(ATAN(1/(2^i)))-1)*(2>>14)+0.5);
short SEC[15]={6787,1935,505,128,32,8,2,1,1,1,1,1,1,1,1};
short i,Rnew,Y,Ynew,A;
Y=0;
A=0;
for (i=0;i<=11;i++) {
if ((Y<S)&&(A<100*32)) { // 90 degrees
// Rotate CCW
Ynew=Y+(R>>i);
Rnew=R-(Y>>i);
A=A+ATAN[i];
} else {
// Rotate CW
Ynew=Y-(R>>i);
Rnew=R+(Y>>i);
A=A-ATAN[i];
}
Y=Ynew;
R=Rnew;
S=S+((S*SEC[i])>>14);
}
return A;
}
The down side of my ArcSin CORDIC is the multiplication inside the main loop. I remember I had to do the multiplication to avoid instability.
AlanX
Here is an example of the type of SCARA that I want to model:
Two X and Y arms and linear Z (say):
L1 = 200mm
L2 = 150mm
Z = 150mm
Two stepper motors:
M1 = 400 steps (assume direct drive for the moment)
M2 = 400 steps(assume direct drive for the moment)
Also I want to use an Arduino Nano for the motion controller.
Ignoring the Z axis for the time being, the forward kinematics represented by (U,V) to (X,Y), where (U,V) are polar motor steps and (X,Y) are the "real world" cartesian coordinates:
The forward mathematics is:
Ignoring the Z axis for the time being, the reverse kinematics represented by (X,Y) to (U,V):
or
I have reworked the equations to:
R=sqrt(X*X+Y*Y)
CosA=(L1*L1+R*R-L2*L2)
SinA=sqrt((2*L1*R-CosA)*(2*L1*R+CosA))
U=atan2(Y,X)-atan2(SinA,CosA)
CosA=(R*R-L1*L1-L2*L2)
SinA=sqrt((2*L1*L2-CosA)*(2*L1*L2+CosA))
V=atan2(SinA,CosA);
The reason is that sqrt() and atan2() is a well known for embedded applications.
Two issues:
For example:
Note how straight lines in XY space are curves in UV space, and motor step resolution (in UV Space) maps into jagged steps in XY space.
(The plotted square is 125 mm x 125 mm, the arms are 200 mm and 150 mm, and the motors are both 400 steps.)
Okay, the third problem is the need for gearing as the motor step resolution is too low.
---
I have tried three methods for accurate XY space to UV space.
Segment the UV space curves into straight lines (by inserting points) using a tolerance (i.e. if the tolerance is not exceeded then a point need not be inserted):
This works well for feeding the mapped UV space directly into a Bressenham's Line Algorithm (i.e. Grbl).
This option could be pre-processing or on-the-fly (i.e. on the motion controller).
Nearest UV space point mapping (path search):
The method seems to be efficient (with look up tables) and path search algorithm can certainly be improved. This algorithm would replace the Bressenham's Line Algorithm (i.e. exports to the motor controller hardware directly).
This option would be on-the-fly (i.e. replaces Grbl).
This options breaks the XY space lines into very small segments that are then mapped to UV Space. Duplicate UV space points can be removed. Simple but inefficient.
Pre-processing only.
AlanX