gCode2SCARALinux (Mint) executable 37.98 kB  12/14/2018 at 00:44 


fish6.ncCartesian (gCode) input filexnetcdf  706.74 kB  12/14/2018 at 00:39 


xnetcdf  313.67 kB  12/16/2018 at 01:17 


test.ncSCARA (gCode) output filexnetcdf  80.18 kB  12/14/2018 at 00:39 


gCode2SCARA.cSource codetext/xcsrc  19.55 kB  12/14/2018 at 00:39 

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 pullups to fix the problem:
Preprocessing "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 microstepping):
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 coopted 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 microsteps
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 microsteps
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=AATAN[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*RL2*L2)
SinA=sqrt((2*L1*RCosA)*(2*L1*R+CosA))
U=atan2(Y,X)atan2(SinA,CosA)
CosA=(R*RL1*L1L2*L2)
SinA=sqrt((2*L1*L2CosA)*(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 preprocessing or onthefly (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 onthefly (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.
Preprocessing only.
AlanX