Homemade Digitizing Arm Project
This project involves trying to make a homemade digitizing arm such as those sold by Microscribe and Faro.
These arms have angular measuring devices in each joint and by placing the tip of the arm on an object the angles may be read to a PC and along with the known arm lengths be converted into co-ordinates of the tip. By placing the tip on parts of an object and writing the co-ordinates to file the object may be digitized for later import into a CAD package.
Firstly, this project is not my own but as described by this thread started by "Cliff J" on the CNCzone. On this page I will just try and distill some of the discussion and collect the relevant links for easy access.
Here is the basic configuration of an arm:
The whole arm rotates on the base joint and A, then hinges B and C follow. D is a wrist swivel joint and E is another straight hinge. The wrist swivel is optional and to some extent leaving it out simplifies the maths but does limit the geometries that can be digitized. Adding a rotary table for the object to be digitized can get around this but also adds complexity, however it is still a useful tool for many applications such as digitizing apertures etc. Gary "duluthboat" is building an arm like this that should serve as an excellent test bed.
To measure the joint positions requires some kind of encoder. High precision potentiometers were suggested but the expense and difficulty in getting full resolution amongst the noise has brought us over to optical encoders. USdigital sell a packaged quadrature rotary encoder with 2048 lines per revolution. The quadrature part means that there are two pulsed outputs with a 90 degree phase shift between them. This means that the direction can be deduced. The lines per revolution means that the encoder disk has 2048 lines on it, this produces 2500 pulses per revolution. HOWEVER, a pulse has two edges and so if you count both edges on both quardratures you get 4 times the pulse rate so that is 10000 pulses per revolution. That is a resolution of 0.03 degrees which is pretty good, especially for $67. Some of the encoders also come with an index pulse that pulses just once per revolution, this can become part of the zeroing procedure. The cheap encoders are incremental, they only pulse as they go around. To know where you are you need to zero the count at a specific position and then count the pulses from there. For example you may zero the count with the joint straight so that the number of pulses either way can be converted to the angle from straight.
So you have some encoder outputs: 2 quardrature and 1 index, what to do with them? Well one nifty thing is to use a quadrature clock converter, this takes the two quadrature clock pulses and converts them to step and direction signals. A description of these chips may be seen here, (thanks to Cliff J for the link). These are also available from USdigital for a few dollars. They take care of potential errors due to dithering at edges and also make any programming much easier.
Then what? this shows a few options:
Once the tip of the arm is on the correct part of the object then you need to tell the software to capture the encoder positions. This is sometimes done by adding a touch probe to the end of the arm but much more simple is a button, this might be added to a joint as per some Faro arms (for convenience as the joint must be supported by one hand) or by a foot pedal or fire button. This signal and the encoder signals needs to go somewhere:
Option A:
One option is to connect them directly to a PC parrallel port. Some people have already done this, producing homemade DRO (digital read outs) for machining equipment. There code may be downloaded here:
And a modified version for upto 4 axis:
Both essentially poll the port inputs and keep track of the encoder inputs, they don't bother with quadrature clock converters.
To use these pieces of software, modification would need to be made for data capture, the raw encoder count is available so it is probable that the capture button could be connected to the parallel port and a "save to file" function added to save the information. ALSO a 5th axis would have to be added if a wrist rotation was wanted.
Alternatively software could be written from scratch, this might have to be done in DOS to avoid windows overheads causing problems but it is unknown as yet how much of a problem that might be. There are also issues in outputing to the parallel ports in windows XP but these seem to be bipassable.
Option B:
Some sort of microprocessor might be used to keep track of encoder signals, when the capture button is pressed the uP would send the info to the PC via serial or USB. This means the real time part is done by a dedicated processor and then just communicated to lazy windows. There are a variety of micro processors out there such as PICs and OOPICS and basic stamps and the like, some are better than others some easier to program. Oh and USB might not be as hard as it sounds.
But hang on, these are just pulses, what about actual angles?
Well as always there is more than one way to skin a cat. Here is a flow chart of some possible ways:
Starting with the encoder information (in other words where the joints are in terms of encoder pulses). Taking the left branch, these might just be saved to disk by the aqusition software. So you might have a text file full of big numbers, all reference to the index of the encoder perhaps.. You could then run a simple program that contained information about your machine, things like the distance between joints and the number of pulses of the encoders per revolution and the offset between the index and the physical zero angle point of the joint (if any), this program would then do the maths creating a text file full of X, Y, Z co-ordinates. These files may be imported directly into CAD programs such as Rhino3D.
The right hand branch just combines the first two steps, the same software that gets the info converts it to the X,Y,Z co-ordinates, these could then be written to a points file for CAD import or if you take the route that microscribe do it is sometimes possible to import each point directly into the CAD package. How easy this is, is not known and it may involve trying to emulate a microscribe or the writing of Rhino scripts, this is the nicest sounding but possibly least flexible and easy approach.
Newsflash, Swedish genius to the rescue:
I had been talking to my good friend Andreas Pain about the digitizer project, he is a bit of a programming master and knocked up some code for a PIC to read encoders signals and send them to the PC via serial link and also a program to read those signals and write the encoder counts to disk. To cap it off he has written a program to convert the encoder counts to x,y, co-ordinates for arms with upto 8 axis.
We shall post the programs here as they are fully tested. To start with the final convert program:
You need: Convert.zip
This contains:
convert.pdf - Read me file and manual.
convert.exe - The program that is run (read, readme first).
config.ini - contains example arm configuration.
testraw.csv - an example encoder data file.
Various .dll files - Just make sure these are in the same folder as the .exe