Hello, I was just wondering if anyone has a algorithm for tracing a circle on a 5 axis robotic arm (using ssc-32 and atom basic)? I thought it would be cool to try and make a program that can make my robot hold a pencil and draw a circle.
Any ideas how?
Bane
Basically, you need to “rotate” a vector (ArcAngle) through the angle 0 - 360. Then solve for the X and Y components.
rad = (ArcAngle / 180.0) * PI; /* Radians */
X = CircRadius * cos(rad); /* rotate point */
Y = CircRadius * sin(rad);
You get offsets from the center of the circle you want to draw. draw from one calculated coordinate to the next, and you get a circle. Simple plotter stuff!
Write a few plotter functions, like pen up/down, move, and “arc”, and you can draw most anything!
Alan KM6VV
thanks, so if i want the head of my robotic arm to do that (simular to this onelynxmotion.com/images/jpg/sesa01.jpg) i would need to do some math with the X and Y to have all the servos move the head in a circle movement, right? How do you get a servos variable (a word) proportional to a byte? Also, the atom must sent out every coordinate (with in increments) to the ssc-32; would i just keep adding a constant some variable to get this motion?
Bane
Hmm, while that approach will certainly work it is computationally intense. You might want to google the works of somebody called Bresenham which have a great deal to do with rasterization of functions like lines and arcs and ways to optimize their rendering. Yes I am deliberately sending you guys off on a research project because if you have never done anything with this you will be thrilled at how simply efficient plotting things can be with a few conditionals inside of for…next loops. 
Yes, math is required! Just simple trig. Basically, calculate a coordinate on your circle (is it flat on the table, at an angle, or vertical?), then do the IK calculations to move the end effector (pen in the gripper) to that point. Repeat for all points. I think I saw some IK for an arm somewhere on this forum.
Actually, this little task makes the arm sound interesting! I might have to build another arm (an LM arm this time)!
I suppose you could use Bresenham’s algorithm. I’ve never found it useful except for on-screen graphics. As I recall, these algorithms tend to calculate points in all four quadrants at the same time. OK for screen, but not so useful for plotter and motion control applications.
I suppose one could calculate a table first (get four table entries at a time), and then go through the table. You could also run BASIC first just to calculate the coordinates needed, and build a table. A small sine table could be used if desired.
Alan KM6VV
A problem with the brute force “I’ve got a cos function to do the work” approach should become obvious as the diameter of the circle increases. To keep the line segments between points small, so the illusion of a circle is maintained, the angle step must be increasingly smaller as the radius is increased. You are effectively doing a polar to cartesian conversion of every point on the circle. Every cos calculation takes hundreds to thousands of instruction cycles to complete, there are two required for each x-y pair, and then we top that off with another pair of floating point multiplications as well. How much time will the arm spend waiting for the next line segment pair to be calculated on a big circle?
Bresenham is integer based and executes within the cartesian point space directly. This requires an initial translation of the radius into “pixels” if you will. Once this is done the process of drawing a circle is broken into 8 arcs which operate at the pixel resolution of the drawing space. If anything you may find that drawing a circle could be slower using Bresenhams not because of the number of computation cycles required but rather due to the number of x-y pairs generated. That would probably depend on the resolution of your drawing space and arm.
Back on trig approach, for a precalculated table you would have to know the smallest angle step required and generate the table with enough accuracy to support returning unique values. If you are lucky you can always step the angle increment by integer multiples, otherwise you will need to interpolate between table entries for even more fun… or not fun or very efficient. 
Good points, and one that I forgot about, the integer calcualtions. but remember that one will want to move the arm between each point, so in that light maybe a a pair of sin/cos calcs wouldn’t be that bad. Certainly seems to be the case for plotter and CNC calculations I’ve seen. But then you need the FP.
Yes, octants and not quadrants as I stated. Good points on the cord sizes changing for different diameters. I know it’s problem from the CNC controller work I’ve done. Also makes it difficult to determine if a Gcode instruction is for a full circle, or a very tiny arc! (G02). I don’t remember if this is a problem for typical HPGL commands.
Thinking past just a circle, If I had an arm available, I’d consider writing an interpreter for either HPGL or Gcode, and use this to run the arm in a 3-D space!
Alan KM6VV
can you post a code snippet. I am using Hexapod with 3DOF. I want to draw a circle using one of the legs of HEXAPOD
