*********************************************************

EDIT: For those joining the conversation in this thread a little late, a short summary of the thread has graciously been put up by another poster (Graham S) to help bring you up to speed on what has been discussed. Many ideas have been presented and this synopsis should give a reader a good idea of what we are talking about in any new posts with our jargon and acronyms. Happy reading.

http://www.indoor.flyer.co.uk/digiarm.htm


*********************************************************

I'd like to model the inside of an automotive interior to machine plastic parts to fit against the countoured surfaces of the sheet metal.

I'm looking at purchasing a digitizing arm as it seems the next most affordable option after using a contact probe on a homemade 3-axis machine. A machine that needs to be setup quite differently since it needs to work 'inside' of boundries.

The Microscribe seems like a decent price at just over $3k, and I've heard the Faro arms are over $10k but instead of a 3ft arm can go to a 12ft arm! And I've seen some other companies market arms too. Anyone know of other affordable options?

I'd love to think that someone has worked out a DIY system for putting affordable 2000 count encoders on a homemade arm with rollerbearing pivots and software to translate the kinematics. But I'm not about to hold my breath..... :)

Cliff

I'd love to think that someone has worked out a DIY system for putting affordable 2000 count encoders on a homemade arm with rollerbearing pivots and software to translate the kinematics. But I'm not about to hold my breath..... :)

Cliff

I have never tried one, but after loking at a DIY structured light scanner, I was thinking last night that it would be possible....with great care in the design, parts, and machining. Commercial systems are not in my budget! I want to be able to digitize 1:18th scale die-cast models and import the points into AutoCAD for editing. The electronics would be fairly simple (counting clicks) and the software can easily be done in Visual Basic. I am looking very hard at this avenue. Who knows, it might just work!

Another 3K Arm with a 50" circular radius...
http://www.remtek.com/remtek/3d_contents.htm

DIY Touch Probe
http://www.indoor.flyer.co.uk/probe.htm

I like the arm idea and I'd be doing the exact same thing you're planning on doing Cliff_J.

Here's another on and they can be had with huge working areas.

http://www.nemi.com/product-pictures/digitizer%20telescoping.htm

Mike

Wow - those babys aren't cheap!
I wonder -- has vacpress done any more on the DIY "microscribe" varrient? He was going to use mouse bits and build a robotic arm digitizer.
Sounds like a good compromise if you could get close and work the fit after the fact.

On a similar project (car interior) I am planning on using the existing doorskins and dash - digitizing the backsides (the side against the door/firewall), create a point cloud and then go from there - figured the machine would probably run for a couple of days to get just one door done. - but hey - might save some plotting time - mirror the left and right. Here's hoping GM did a fair job building!
Cheers - Jim

Wow, a flurry of activity after a period of hibernation.... :)

I'd thought about using the mouse encoders as well, but have since purchased a used Microscribe off ebay. Its really quite nice, a bit small, but quite nice. Now its just a matter of figuring out how to 'leapfrog' the unit from place to place to capture larger objects.

My biggest concern with any arm was the resolution. Each step needs to be quite precise for the length of the arc covered by an arm. How Faro and Romer pull off .003" resolution on a 12ft arm is beyond me, that's like a super-encoder of 160,000 cpr and with zero backlash!

The Microscribe works for me, but if someone can work out the resolution with maybe a large encoding disk and a regular mouse encoding sensor I'd be open to trying to build my own especially if it could cover a larger working area. Someone with a lathe that could make a 6" or 8" disk with 10,000 slots cut in its perimeter would be a nice start, now you'd be looking at .003" resolution for a 4ft arm. Some ABEC7 bearings and aluminum extrusion and the mechanicals would be done. Now, about that pesky software to translate the rotations of the joints into cartesian co-ordinates...

It seems like its so close to a DIY solution that I can see it already. I fear the reality is I'm missing some of the difficulties in assembling the HW & SW into a usable system.

Cliff

Ciff:
What kind of resolution are you seeing on the unit you purchased? I've been doing quite a bit of research this weekend and am almost thinking a small touch probe unit would be easier to build and more accurate. I thought about rotary absolute encoders on the arm, but they are very expensive and you would need four! The Homemade Touch Probe (http://www.indoor.flyer.co.uk/probe.htm) site looks to fill the bill however.

Jason
South Carolina

The resolution seems to be .001 although if you are not holding your breath or keeping it against a surface it will dance all over the place. Just dragging it across a surface and it will bounce a little. As far as accuracy, its seems to be within about .008" which is better than its spec of .015" for surfaces that I consider to be flat. Unfortunately, I have no precision anything to check its accuracy beyond like the surface of my table saw or a metal striaght edge designed for workworking. For me, ignorance to the contrary is bliss and the unit seems quite precise. For nearly $2k, it'd better be. :)

Someone posted a link to a site that had a multitude of encoders that were 2000cpr with quadrature, and at only $50 each that seemed cheap. With a 12" arm, that would put the resolution at about .018" which might be good enough.

Cliff

Cliff:

I've been thinking on and researching this subject in my spare time this week. I have been reminded of something I read about servo motors and there operation several years ago. I went back to that book (my wife refers to it as my NERD book) and read that section. Maybe we are looking at the angular sensor issue all wrong. Why not use precision potentiometers in lieu of optic encoders? It appears that they my be both more accurate and more economical. I have emailed Novotechnik (http://www.novotechnik.com) for pricing. Their P6500 has a resolution of 0.007 degrees and linearity of +/- 0.05%. The best part would be that there would be no need to count "clicks". This would seem to reduce the overhead of the electronics. If you added an A/D converter or connected the fours pots to a microcontroller (ex. OOPIC) there would be even less overhead on the computer. Maybe I'm making this sound too easy. What do you all think?

Now this discussion is getting interesting, that's an awesome idea. We wouldn't need multi-turn since the arm can only pivot so far without colliding with itself and not having to deal with quadrature and indexed encoder wheels would be a huge plus.

The .007 degrees is awesome. We'd probably want a 16-bit A/D and most of the PICs I've seen are only 10-bit but this wouldn't be too much of an issue to figure out (I don't think) with a seperate A/D chip and a serial link to a PIC. I've been putting off learning PIC programming (for building a standalone DRO and manual CNC control) but this would be as good a reason as any. Plus many other people are proficient at it, we might be able to leverage other's expertise.

Two thumbs up Jason!! I like the idea, no caveats come to mind that haven't been mentioned with respect to optical devices and this would be much simpler.

Cliff

Next, lets talk about finding the location of our pointer. Treating each joint as a seperate entity, each arm segment can only rotate in one plane of motion. Within that plane the length of the segment is fixed thus the x,y co-ordinates for the 'free' end will always fall on an arc equadistant from the 'fixed' end.

So from any position of the tip to any other position of the tip the change in x,y,z would be exactly the same as the orthogonal vector addition of the change in each segments points? Could it be that simple?

Unless I'm omitting something substantial, I think this wouldn't be too hard to pull off with simple trig. Just write some simple software that pulls down the 4 or 5 numbers that represent the angle of each joint and compute the location.

This seems too easy. Hopefully the pots aren't too expensive and this would be simple enough to test using a sound card as a cheap A/D converter to see if a working model could be built 1 or 2 joints at a time with simple unity-gain op-amps to create a makeshift analog MUX for the number of joints and keep the electronics to an absolute minimum. If this worked, this would be awesome!

Cliff

VacPress! Where are you? You should jump in here too!
I'm very interested in this project - I would build one but have little tech (electronic/digital) abilities to contribute. Vacpress and I had an off-line discuss a while back about a similar project using mouse bits. I like the idea of using soundcards as A/D I need to research that somemore - use it for weather sat decoing but hadn't considered other possibilities. Anxious to see the effort progress! - I'll be lurking on the side.
:cheers: Jim

I got the information on the precision potentiometers this morning. I had asked her for a "Budget" price to see if this was an area to continue to research. The pots with the 0.007 degree resolution are approx. $135 each - not that bad considering the other options. The A/D chips are only about $5 plus a few bucks here & there. The cheapest way to determine if this thing will work is probably to build something using cheap pots and switch them out when all looks right and seems to work to get the resolution right.

On to the issue of resolving the points. I pulled out my "Vector Mechanics for Engineers: Statics" textbook this evening. After blowing off the dust I went to the vector introduction section for a brushup. Cliff, I believe you are right. I've thought about this all day and have looked at several "Vector Education" websites. The easiest way to determine the cartesian coordinates may be by converting the Spherical coordinates (distance with 2 angles - base & joint). There are fairly simple formulas for doing this. Seems to me that you could resolve the Cartesian coordinates of the joints until you got to the pointer tip or add the vectors and convert the resultant sphereical coordinates into cartesian for the solution. I think the software to run this thing should be kept as simple as possible. That should not be a problem.

I plan on doing several sketches this weekend - again mostly concerned with the math not the construction. I love a challenge, especially when it's for building something I can't justify going out and buying. Hopefully we can put our heads together and come up with a solution that is cost effective and within the skill level of most home machinists.

Vector Site - Vector Education (http://itc.utk.edu/itc/grants/twt2000/modules/mbreinig/Default.htm)

I'll have to read up on the vectors, I'm pretty rusty on geometry but thanks for the research. Its been a while since I took a statics or dynamics class and the textbook for the latter was horrible enough to mess up anyone's understanding of more than the homework problems.

I think I'll order some Alps (or other) precision pots from Mouser soon and try to keep the price down to $10-20 each. Then I'll see if I can find some websites on using the soundcard as the A/D solution. Kind of a Kleinbauer approach to build as cheap as possible and then work on the precision for the second generation.

Like I said above I've got a Microscribe we can compare to. If I can build one for 1/10th the price I'll be so stoked as then I can work on building one with a large enough envelope to handle my needs instead of leapfrogging a little guy all over the place. And I could probably build the larger one with the funds from selling the Microscribe on ebay....awesome!!

I called Novotechnik as well and they have the SP2800 which is used as a throttle sensor in CART/Indy/F1 cars with .03 degree repeatability and costs $57 which is one of their least expensive pots that we might consider. I think I'll try the Alps first for the prototype and if we can get that working....

Cliff

Hi guys, I’ve been watching from the side lines, mostly because I have nothing to add in the math or electronics area. I may be able to help with the mechanics and or modeling I have looked at the Faro arms longingly but will never have the money. I’ll go back to watching, if I can be of any help just ask.

Gary :D

Glad to see you're watching Gary.

What are your thoughts on constructing the machine in terms of materials and the joints and so on? And do you have ideas of other contributors on other forums that may be of assistance in the math arena?

Cliff

P.S. I just learned that most PC sound cards are high-pass filtered at around 10Hz or higher. So now we'll need to use an AC waveform or external ADC to find the potentiometer position, but this shouldn't be too hard. I just found some source code for VB that lets me read the output of the ADC in a sound card from an oscilloscope program. One more piece in our little puzzle.

The construction would be very similar to Faro, it’s about as simple as it could be. I wish I could find a nice off the shelf joint but it will likely be a machined item. How big are these encoders you’re talking about? I’m hoping the math will not be a big obstacle; we only need 5 axis positioning not 5 axis interpolation. I’m thinking of a pointer and a trigger to record a point then down load the point cloud into Rhino or TurboCad to create a surface. For myself I don’t have a need for a transducer probe.

Gary

I did some reading today. I kept reading the term Forward Kinematics - I don't remember that from my years at Clemson. Forward Kinematics is the term for solving for pointer coordinates of an arm - at least one application. In our case, we will have known distances and angles (4). Inverse Kinematics would be resolving the angles for a target point knowing the point and arm lengths. There appears to be a lot information on the web for this subject. I did a search for Forward Kinematics and found several interesting sites. Digging through the theory for the formulas will be the hard part.

I have been thinking about the construction. I'm assuming we will machine the parts out of aluminum. I don't have a mill, but have a family friend in that business. My mini-lathe should be large enough for the parts I can make. I'm thinking about making a prototype out of very light material to see this thing work and to iron out the bugs. I was thinking that I will blow the dust off my old OOPIC for my test bed A/D converter.

Gary: I believe the P6500 (0.007 degree resolution) pots are approx. 2" in diameter.

I have recently become a HUGE fan of forums such as this. I have been very impressed with how members are very willing to help folks find the solution that best fits their needs. It's interesting to bring folks with similar interests together and pool resources, talent and experience. I think this is the best way to approach challenging projects such as this. I personally just know enough about various things to be dangerous. :) I also have more time to read & plan than I do actual shop time.

Since I'm new to this forum, I'm assuming a "veteran" will suggest if and when we need to move this to the Open-Source or Projects area.

I’ll do a quick and dirty model so we have something to throw rocks at. I’ll use this pot as our encoder.

Gary

Great. I'm looking forward to seeing what you come up with. I'll be working on the math this weekend and digging out the information I have on the OOPIC. However, as Cliff said, we need all the help we can get on the MATH!

First draft.

WOW your fast! It sure does help to see it on the screen. A rotating base would give all the degrees of freedom needed. I hope to have something together tomorrow evening on the math/formulas needed - at least some good links.

Off to bed - 5 AM will be hear before I know it :)

With roating base will we only need 4 axis of movement? That looks good to me.

Here's a basic way to find the location. There is probably a better way, but this is pretty simple. The distance between the pivots (pots or encoders) will need to be very precise. Assume that the base has not rotated and the angle is 0°. You know the position of the first encoder. Treat each segment of the arm as the hypotenuse of a 90° triangle. Use pythagorean theorem, a^2 + b^2 = c^2. You have the length(c) of the hypotenuse (length of arm segment). The base(a) of the right triangle is cos(angle of first segment) x c. With a and c, b(height of the triangle) is c^2 - a^2. You now have the position of the next encoder. Use this as the base for another right triangle, to find the next encoder position. Repeat until you get to the point. Now you'll have a height and offset from the base, just use the base rotation to get your actual X,Y,Z value. Does this make sense.

While looking for the formula to rotate the base, I just came up with an easier way. Using polar coordinates, look at the first picture and formulas here.
http://mathworld.wolfram.com/PolarCoordinates.html

Once you figure out the point(tip) location's x,y, use spherical polar coordinates to get the actual x,y,z using the base angle and the new vector length from the base to the point. See here: http://www.astro.cf.ac.uk/undergrad/module/PX3104/tp4/node8.html

Simple, eh? :D Or am I way off base here?

Hmm, the polar coordinates seems to be over-simplified because once past one vertically pivoting joint we can no longer use our 'world' coordinates and now its pretty complex (to me anyways :) ) to handle addition of polar vectors. Also pythagorus doesn't help too much as we know the length of one segment and the angle - the other two segments change with motion.

I agree that forward kinematics is going to be a likely solution. Sifting through all this information should be a small task, seems there is some over-simplified information on constructing multi-jointed objects for animation in 3DS or similar and then high level stuff on what's required to solve mathimatically. This site has some stuff that makes sense but its about as clear as mud how to program from it:
http://www.euclideanspace.com/maths/geometry/affine/nonMatrix/index.htm
And here's one that explains things much better but leaves the 3D world alone, probably with good reason. :)
http://www.learnaboutrobots.com/forwardKinematics.htm

Jason, I'm with you on the move to an opensource forum once we get a proof of concept in motion. Like next week right? :) Hey, what's the difference between an OOPIC and just a regular PIC from Microchip like a 16F84?

Cliff

Gerry, my head hurts after looking at that. :eek: I guess that’s why I’m still a machinist. I’ll work on the mechanics and leave the math to others.

Gary :D

Actually, thinking about this more outloud (hopefully not too loud) using Gary's (duluthboat) image we have three joints that pivot on one plane. Using the math in the second link I posted above, we can find our x,y coordinates for our point at the end of the arm with respect to the world 0,0,0 that lies at the intersection of the arm's main pivot and the twisting pivot in Gary's second image (assuming we can machine the parts to ensure these two line up perfectly so their axis intersect). Now with the angle of the twisting pivot known we could translate this to world sphereical coordinates and then back to world cartesian coordinates. This seems so simple, so elegant.

Sorry if it seems like I'm ranting, but my mind just breathed a sigh of relief. I was thinking of existing solutions and reverse-engineering how they function, and that makes this more complicated than needed. The Microscribe has a 'wrist' joint that spins axially much like our own wrist joint, this destroys the planar relationship between the arm segments and makes the kinematics tough. The Faro and Romer arms offer like 7 or 8 DOF so those are even more a mind bender. A rotating plane, awesome. :cheers:

Cliff

:D Good night.

Gary :D

Good points guys. I think we're close to having the math beat!

Now it's still early, so bare with me here on my summary:

Since the segments of the arm are planar (XY) you can solve for the resultant planar vector (XY), translate into polar coordinates and rotate about the Y axis (where the xz plane is parallel to rotating base) to get the spherical coordinates. You would know the planar vector components and the angle of rotation about the z axis. As ger21 and Cliff have said, it seems too simple, but I think it's right. I had put together an excel spreadsheet (great for prototyping VB math) to calculate joint coordinates based on joint angles and a list of constants - arm lengths and base coordinates (for "leap frogging") - but quickly realized my math did not factor the rotation about the y axis (phi). Now I'm thinking I was on the right track except I needed to get the polar resultant (r, theta) of my planar vectors. By rotating the polar vector about the vertical axis you now have a spherical coordinate of the pointer. You would then use the following formulas to solve for the Cartesian coordinates (XYZ) -

x=r sin(theta) cos(phi)
y=r sin(theta) sin(phi)
z=r cos(theta)

Someone please correct me if I missed something.

Cliff: OOPIC (http://www.oopic.com/) is a PIC that has been programmed with an operating system - like Visual Basic (VB). I bought one 3 years ago and played around with it for a while. It will do most things you can think of - A/D, control servos, math, etc. It connects to you laptop through the parallel port. It appears that they have some new models that connect via serial port. It's very similar to the Basic Stamp (http://www.parallax.com/).

Gary - the model looks good. I think that's the basic idea.

I looked at both of Gary's designs [man he's good and fast]. I thought they could be quickly simulated using a pair of "dividers." (I was thinking the fixed lengths and pivots simplifies some of the maths - give it a go.)
So I did. Just to see what I'd get. Sorry no photos - so maybe a few words. If you wanted to digitize a coffee mug - I was having a cuppa at the time - you could capture the nearest surface and inside far edge, but would then have to rotate the mug once the "probe/scribe" gets past about 45 degrees of either side of centerline. An alternative would be the ability to pivot the probe/scribe about and then get the sides (more complexity in the maths). But the mug is in the way for much of the back side. So do I rotate the mug and "stiitch the solved points together, tie the rotation of the mug to the arm and math solution - ARGHHH -
So that brings me to the question(s)
1. If the end use is to digitize an inside surface (representative of an car interior/boat/concave like surfaces) a simpler solution - wouldn't fewer DOF ease the maths and costs - and still have high utility? I'd build one of those! "Keep the End in View!"
2. If the end use is to capture a Mug like object - foreground and backside - wouldn't centering the arm directly over the object (hanging inverted) capture all the surfaces - and still minimize the complexity of the maths and costs?
Not trying to complicate matters - just puzzleing over simpler ways.
I'll go back to lurking now. BTW Fine sites those on the maths! :cheers: Jim
For question 2, I'm thinking back to one of the hexapod designs and a probe - kill two math problems at once!

It all comes down to trade offs, adding one or two extra joints would not be that difficult. But if it makes the math to complicated, it might be easier to get the same results mechanically, by moving the part or moving the arm. One easy way to move the arm under controlled conditions would be to put it on a track. This would allow you to move the origin point a known amount.

I think this is a good start, I’m working on the joints, but this will be limited to my head for now as I have yard work to do.

Later
Gary :D

Actually, thinking about this more outloud (hopefully not too loud) using Gary's (duluthboat) image we have three joints that pivot on one plane. Using the math in the second link I posted above, we can find our x,y coordinates for our point at the end of the arm with respect to the world 0,0,0 that lies at the intersection of the arm's main pivot and the twisting pivot in Gary's second image (assuming we can machine the parts to ensure these two line up perfectly so their axis intersect). Now with the angle of the twisting pivot known we could translate this to world sphereical coordinates and then back to world cartesian coordinates. This seems so simple, so elegant.



That's what I was trying to say. It's easy to find the point before you make the rotation at the base, because it's simple triangles. 2 calculations for each one.

Base of triangle = length of arm x cos(angle of arm)
Height of triangle = length of arm x sin(angle of arm)

Do this 3 times and convert the resulting 2d point to spherical polar coordinates

x=r sin(theta) cos(phi)
y=r sin(theta) sin(phi)
z=r cos(theta)

Someone please correct me if I missed something.



From the link I posted earlier, it looks right to me. But for anyone just joining, the "r" above is the distance from the base to the pointer tip, phi is the angle from the base to the tip, and theta is the rotation angle of the base. r and phi need to be calculated before you use the above formulas.

this will be limited to my head for now as I have yard work to do.

Later
Gary :D

Get that yard work done on Friday nights. Makes the weekend a little more enjoyable. :)

One thing to think about is that this thing need to be pretty rigid, doesn't it? And you'll probably need some type of ball bearings in the joints to get very free movement with no play in them, which might let you get away with a little less rigidity.

Hi guys,
I have been following this thread and ger21 brought up a point of rigidity. I am not a machinist, not good at math, am not an engineer so I have very little to offer. With that said I am curious what your thought are on the materials for the arm itself? Does the arm need to be light weight but rigid or heavy and rigid? If you want light weight and rigid the best material you can use is carbon fiber with either the aluminum or nomex honeycomb core. Stiff stuff and if you have the equipment not too hard to work with.

Mike

ps Gary's idea of mounting the base on a track seems an easier math solution that a rotating base, from a non-math person though! :idea: Edited to add, this would allow you to make the size larger in one direction without having to make the arm any longer!

as there will be no loads as such, just the weight of the arms there should not be much flex, ali tubing would probably be OK but carbon fibre fishing pole (as in continental pole fishing rather than another name for rod) sections might be cool and quite cheap. The machine is essentially floppy rather than rigid, just rigid between flops :) Other than that the angular resolution of the encoders/pots and the quality of the bearing would seem to be the limiting factors, cool thing to try.

On encoders, they don't have to be expensive, US digital's are OK and sometimes really cheap surplus servos (in small sizes) come with them.

I think the maths will be pretty easy, as soon as you get a program that will keep track of the volts/encoders and store the numbers when you press fire then the code to convert that raw data into a point cloud would be pretty easy.

Graham (the homebrew touch probe guy)

Jason - you're math looks good to me. At first I thought one of the sin should be a cos but on second thought it looks correct. Nothing like publik skool edumakshun. :) And an OOPIC sounds much easier than a regular PIC since you can probably use variables and other typical high-level language constructs instead of assembly code.

For construction, I think aluminum bar might be the easiest because it can machined as a single assembly without the need for welding or epoxy that would need precise jigs to keep things in alignment. Or maybe short sections of bar machined into a square and circular profile that is stuck in the ends of the tubes for assembly with final maching of the pivots to follow assembly. I'd think a regular ABEC7 rollerblade bearing with its 8mm ID and 21mm OD could be doubled up on an 8mm shaft for good accuracy with low cost. Even with axial preload on the bearings, this is low RPM movement with small amounts of travel so I'd guess wear to be a small issue. A homebrew double angular contact bearing of sorts - yah/nah?

BTW, the machined aluminum on tubes is pretty much how the microscribe is constructed. Its an aluminum base and aluminum upright on the lazy susan pivot but from then on its aluminum ends with graphite/carbon fiber tubes connecting the ends. Some of the Romer/Faro arms look very similar.

Highseas - yes the lack of a wrist joint makes digitizing objects more challenging when there is an undercut or angled recess. But leapfrogging the unit to different points OR creating a turntable to rotate the objects on (with another precision potentiometer to measure the angle of roatation) would be much easier solutions (right now) than trying to add wrist joints because of the math which is considered graduate level robotics study. For my purposes of digitizing automotive interiors I almost need the 7 DOF offered by a Romer/Faro but as I get better using the Microscribe and Rhino this seems to be less and less of an issue.

The hexpod falls into the same math issue. I know Chuck had great ideas on the other forum about building one for machining, but the lack of understanding of the math pushes it outside our collective abilities for the moment. The way things are going though, who knows....we'll have our own ASIMOs serving up cold beers by next summer. :)

Cliff

Oh, one more thing. We'd probably need to machine in some sort of alignment pin we could use to 'lock' each joint at a specified angle. Then any trimming of the angle reference (whether mechanically on the potentiometer mount or in software) so we start with a known point since our math depends on it.

Cliff

P.S. I figure the .03 degree pots to give .003 inch resolution at 12" so with four joints our resolution would still be within .012" which is pretty awesome, and .007 degree would be .0007" at 12" so the collective error after 4 joints would be .002" which is likely better than the construction will be able to hold.

Hi Guys,
I just got through reading this thread from the beginning, WOW!. I am not a math guy either but I used to be a fabrication guy, draw a picture on a napkin and I could build it. Have you thought of using carbon fibre arrow shafts with machined aluminum joints on the ends for the arm? They are cheap, straight usually, and uniform in diameter. Just a thought now I'll also go back to lurking in the corner. That's what I do best. Ron

Great information guys. It still seems to me that the easiest way to resolve the coordinates is to use 4 pots on an articulated arm. The resulting voltage is run through a A/D converter, then the digital information is translated into joint angles. Once we figure out the math it will be a snap to write the program to resolve the point. I think we have identified the correct formulas to translate the data. It's just a matter of putting the puzzle pieces together and finding that first object to digitize! Okay, I will admit there is much to do between now and then, but with the interest we've seen here we have folks from many backgrounds, experience and talents.

I did a rough sketch of a joint design today using aluminum round bar turned down with one side forming an axle that inserts into the other side piece which has the ball bearing. The pot is externally mounted through the second piece connecting to the axle. The sketch hopefully will show it better. I'll try to attach it tomorrow afternoon. I had thought about aluminum bar or tube as segments between the joints, but the carbon fiber arrow shaft sounds interesting.

Maybe a list of objectives would help - if it's not taken as me being to controlling :)

1. General design - articulated arm, track mounted arm, etc.
2. Math to solve for particular design concept (we have run down the formulas for the rotating arm already - we think).
3. Parts list with contacts - joint material, pots, ADC/microcontroller, computer interface.
4. Shop drawings of parts to be machined - maybe several versions to see which work best and giving options depending on an interested individual's available shop equipment (lathe, mill, etc).
5. Assemby instructions - General.
6. Sampling Software - Freeware - OF COURSE :)

Let me know what you all think. Maybe each of us should focus on a certain area(s) as we see ourselves being best used. I just know for myself, I have a tendancy to go in too many directions and never ready accomplish my goals. For instance, I would love to design mechanical joints, but of the above list that is the area I have the least experience. I hope this does not sound too pushy :) , I would just LOVE to have an accurate Homebuilt Digitizer!!

Graham: I'm glad to see you joining in, your homebuilt touch probe website started my mind's gears turning - very interesting. I hope the concept here will intially be easier to run since we have no motors to control and can choose specific points at will. I compare of this device to land surveying for a topo map. You actually shoot the points that descripe the surface best - bottom of a ditch line, top of the slopes, etc.

Sorry to go on and on. I guess it fairly transparent how excited I am about this :)

A homebrew angular contact bearing would seem fine to me unless we think of some unusual off the shelf hinge that would work.

Build the arms from whatever suits you I would say.

Adding a wrist does not make the maths much worse, unlike a hexapod the arm is a serial set of joints that work one after the other so it is just addition of vectors. I am fairly sure a general solution could be programmed up where you put in arm lengths and when nessesary offsets (as some arms have the pivot line to the side of the arm for example).

My personal feeling is if you get an arm that will produce some numbers the software will come. Get building!!

Graham

I sat down a few minutes this afternoon and put together a spreadsheet that calculates XYZ of the pointer based on constant segment lengths and supplied joint angles (4) - nothing very fancy. I solved for the resultant vector (in polar coordinates) in the YZ plane and then rotated about the Z axis (to create spherical coordinates). I am attaching as a zip file - it will not let me attach xls file. Let me know what you all think. As you can see, these are fairly simple formulas. If we all agree that these are correct, all I would need to do is write a small VB program to read the angle values from the OOPIC.

After thinking last night about this arm, I believe for me the articulated arm is going to be the best solution. It will be small enough to put on the kitchen table (shop is cold in the winter) or could be enlarged to map the surface of a full scale vehicle.

I think we will need to place a calibration point on the base. This will be used to zero out the pots.

In my mind I see the segment offsets canceling each other out since they would alternate over the three segments. Do I have this pictured wrong?

I spent some time today reading up on some of the many things I don’t understand about this thing. I think I now know what a 00PIC is, and I know a little more about encoders. This may help to keep my eyes from glazing over when I read some of your posts.

I reworked the design, making the joints just large enough to hold the P6500 and .625” diameter carbon tube. The tubes in this model are 24" long only because that’s the size I need, they could be a little longer without being worried about flex. The pointer is in the same vertical plane as the center of the base. I now will try to covert some of this stuff to available items, the rod, bearings, and nuts. The rest requires machining but nothing to tough. Let me know if you see any obvious flaws. I may build a prototype this week.

Jason,
We can put a cal point on the base but I would also like the option to zero xyz on a spot of my choosing, I not sure if this is possible. Is this thing really as simple as it seems? Why isn’t there a low end model like this on the market.

Gary :D

Very nice model, Gary. I am very impressed. I think you demonstrated what I was trying to say earlier about the segment offsets canceling out.

I was thinking the same thing on the base point (benchmark) option. I think we still will need the calibration point on the base, but I think you are talking about a "benchmark" option to move this thing around large objects. Again I will compare this to surveying. If you are digitizing a large object, you will initially setup the arm at the "000" position. After you "shoot" all the points possible at that location, you will move to the next location. The second location will need to be within reach of the first position and one other known position (a defined point on the object). In surveying this is called taking your backshot so that you have the alignment of the instrument correct. It seems to me that if you built your machine big enough for the majority of the items you will digitize and have a routine in your software to allow you to change positions, you really can digitize anything.

It all does seem fairly simple. I'm sure there will be small surprises, but it will not be from a lack of looking at all sides of the problem. My problem will probably be something stupid like, "I can't find my soldering iron!" :)

My only thought on the pricing of the low end models is that they are priced at what they think the market will bare. With available technology what it is today and forums such as this one it does open up many options to the home DIY'er. I think this can only be a good thing because it will push the consumer market toward advancement to stay one step ahead of the homebuilder.

The calibration 'ticks' would need to be on each joint, otherwise just a single point wouldn't handle the angle of the pointer segment and the kinematics don't work out as too many variables would be open. A tube the pointer was inserted into may work, but if we had machined indexes into the joints to lock at 90 or 180 degrees a straight edge and simple workworking square could be used to check the calibration reasonably well and would alleviate the need for precision machining on the base and sub-assemblies and their fitment.

Gary, once the machine is calibrated one time mechanically it should not need it again until some future point in time. With the Microscribe (like lots of testing gear) the higher precision model is just one that's been calibrated by a person to fit a tighter standard. So just like a multimeter or oscilloscope that's $200 more than the base model the equipment is the same but its been adjusted better.

I'd imagine the software would be easy enough to program to accomodate this. Once the probe knows its own world coordinates, then using any user defined coordinate system should be easy enough to convert to by a cartesian-sphereical-cartesian function. With the Microscribe and Rhino when you first initialize the probe you click once to define 0,0,0 then a second time for the x-axis and a third time for a y-axis.

I think the low-end is the Microscribe and $3000 is a bargin in the corporate mindset. On the Rhino forums its amusing how many people talk about clients who shrug off Rhino as inferior software because it only costs $900.

Jason, I'll need to look at your spreadsheet tomorrow. It looks to be on the right track but a diagram would go a long ways to visualize what each letter represents. IMO the joint offsets don't really matter as long as they all are parallel and a single common plane intersects the joints so the polar/sphereical conversion works without kinematics. Your list looks good too.

Cliff

I noticed on the Immersion (Microscribe) website that the plugins to use this in different software packages can cost more than the Digitizer itself. Most likely, the software to control this thing will be a standalone app. Instead of having to create polygon Meshes in the software, you get just create the point cloud and get the free points2polys program here: http://www.metris.com/ Look under Paraform.

Can I suggest that a very basic diagram be made showing the arm configuration and the names that will be used for all arm lengths and angles. If offsets for joints are also included then they can be set to zero for certain configurations, used in other configurations or tweaked to correct errors in build quality. For a given build you would just have to tweak the constants to get the right results. The drawing should be for a full microscribe type digitizer, simplified ones can be found by just looking at the position of the wrist of the full model to produce the coordinates for Gary's suggested machine for example.

If we do this then is is easy for people to go away and sort out a set of off the shelf equations. They are not tricky as all we are doing is taking a set of lengths and angles that represent vectors and adding them up to make the resultant before converting to cartesian co-ordinates. Any offsets that there might be (wanted or unintentional are also just vectors as well.

Unlike a robot arm the angle of the tip of the probe is not important to us, there will be many different arm positions that can give the same x,y,z co-ordinates but that is fine, we know what angles we have and just add up the vectors to get the right tip position.

Graham

Something along the lines of the attached. The offset lengths are red and the arm lengths yellow. It includes a wrist and most offsets although I assume that a rotational axis will always be concentric with the arm or offset that connects to it including the base.

I have not added any labels jus thought I would start the ball rolling.

Graham

Graham - I agree, a diagram would ease the typing and descriptions for our little open-source style project. I see you added a wrist joint with an offset - yikes that makes the math hard. If we can eliminate the offset so the last pivot is directly centered on the wrist joint then its just a spherical coordinate that could be translated from the center of the wrist joint and our 5th axis would not be too difficult. Other than that little quibble your pic looks like Rhino and that makes me happy as that's what I'm learning now. :)

Maybe a letter convention? Like the segments are L,M,N,O,P,Q with L for our level base and each segment has a letter from there. Pivots called A,B,C,D,E starting with the pivot at the base and each pivot from there. Then our axes would be x for horiz and y for vert and z for depth. And I chose x,y as such so a 2D representation of the arm would be easier to work with before jumping into a world of 3D. Just a thought, anyone else?

Jason, looked at the spreadsheet again and I might need to pencil out the algerbra and see if the additions work as you laid them out but it would seem the individual segments add up as you have them in the excel spreadsheet. Should be easy enough to test when we get a prototype built. That was last month right? :)

Cliff

Graham -
Gotta say, "Thats a clever idea" - your suggestion to account for "build quality" in the planing/development stage! Makes good sense as the model, maths, and software come together. And the reference (as I take it) to an overarching solution that can be "tailored down" to meet less demanding requirements has a lot of merit given the diverse requirements of potential users.

From a mechanical and build perspective:
I suppose the offsets you suggest would only be valid (account for) for build errors "in plane" and not account for errors that are "out of plane." That is to say, if the arm and encoders are not perfectly aligned in a single (or parallel) plane, angular distortion could not be accounted for in the offsets.
Have I got that right?

On the other hand, could a "set zero ref" check position account for those errors? Maybe do one at an initial position and one at an extreme reference position? Kinda like dialing out backlash in software?

Cliff,
It looks like you and I were peking at the same tiime....Are there any conventions for Robotic Arms we've missed for naming the components. Certainly "wrist" is a useful term - but others previously chosen for this type of effort? Seems like some of those are "taken" for 4, 5, 6, + axis labels.

Cheers - Jim
(back to my lurking mode)

Joint#1
OK, don’t laugh, I know it’s big. :eek: Remember we’re still in development and this is a prototype. It may be big but so is the pot, there’s room for the pot, the shafts and some index holes. This thing is rock solid, simple, and cheap, a $6 bearing and $10 in stock. All it needs is a self locking nut and a plastic washer. So what are your comments on Joint #1?

Gary :D

Gary, built like a tank comes to mind. :D

It looks like the piece on the right is inverted and placed on the piece on the left. Then a nut can be threaded on and set the preload on the bearing. Where does the encoder go?

Cliff, I was trying to put accross that the offsets do not really make the maths any more difficult (if you do it thinking about vector addition), plus combining two joints and encoders at the wrist without at least the first off set is a seriously difficult task.

If we define the lengths and angles and give them names then boffins (I shall also try) can sort out the maths, it will still just be cos and sin. Once the maths is sorted we draw a few examples in Rhino and see if the maths works. As a PC is doing the calculations it does not matter how complicated they look. Plus I don't think they will look that bad really.

Jim, yes I could have added all sorts of angular offsets as well. My reason for assuming the hinges work in plane is that I think it is fairly easy to get them to act in plane, for example a carbon fibre tube solution can be glued up using a reference plane of some sort, surface plate or just a glass sheet for example. I think these offsets could also be added fairly easily as they just add a bit more phi to the next arm.

Gary, that looks cool! I think it should be nice and heavy like that, it will just get lighter and lighter to the tip.

Graham

Next, lets talk about finding the location of our pointer. Treating each joint as a seperate entity, each arm segment can only rotate in one plane of motion. Within that plane the length of the segment is fixed thus the x,y co-ordinates for the 'free' end will always fall on an arc equadistant from the 'fixed' end.

So from any position of the tip to any other position of the tip the change in x,y,z would be exactly the same as the orthogonal vector addition of the change in each segments points? Could it be that simple?

Unless I'm omitting something substantial, I think this wouldn't be too hard to pull off with simple trig. Just write some simple software that pulls down the 4 or 5 numbers that represent the angle of each joint and compute the location.

This seems too easy. Hopefully the pots aren't too expensive and this would be simple enough to test using a sound card as a cheap A/D converter to see if a working model could be built 1 or 2 joints at a time with simple unity-gain op-amps to create a makeshift analog MUX for the number of joints and keep the electronics to an absolute minimum. If this worked, this would be awesome!

Cliff

I don't believe it is that simple. As I recall from a computer graphics course to solve for a translation (move) in a 3D space you have to use a 4D matrix. I also believe quaturians were involved in the solution.

I will try to look up my notes on the subject. I think I may even have some code for doing this stuff in Java or in VRML.


Bill

Here is a link to an explantion of the math behind finding a points coordinates in 3D.

http://www.gamedev.net/reference/articles/article695.asp

Bill

I don't have the time to put a lot of thought into it right now, but because we are not rotating an object through 3D space, the matrix stuff shouldn't be required. We're finding a 2D point, in the XZ plane and rotating it around the Z axis. That simple. I havn't looked at the spreadsheet yet, or done any trials, either. I'll have to look a little deeper.

On the side I reverse engineer parts for my father-in-law's antique auto parts business business. We looked into the Faro Arm but there were a lot of issues at the time last year when they came out to provide the demo. The cost has gone up but the resolution is much better now. Ask them for prices on resale/used arms which are certified. They are a better bargain.
We purchased a Mitutoyo CMM to scan in the parts. We scan in plastic, metal, hard and soft rubber, etc to make molds. The problem is the scan still will have inflection points and not be perfectly smooth to generate CNC code without little inflections. What I am saying is you still have to perform considerable clean up after you scan in a part.
I am working with parts from .110 to 18 inches in size. I do not know your process and what you plan on doing with the scan but you must be careful. The best things I have noticed for the scans is measuring angles, precise hole locations, and copying spline/wavy surfaces. Flat planes and reference surfaces can be difficult to measure if you do not use the 3 point reference plane system.
There are just a lot of oddities when measuring with arms and CMM. If you want a part you will be able to directly roll over to CNC you may want to look into the laser scanning machines ($80K -$200K). Your tolerance for making molds/parts is your overall driver of your needs.
Just some considerations to be aware of.

mc_n_g

Mc_n_g thanks for the info, pretty much reinforced what I had learned thus far speaking with different vendors and using a Microscribe arm. No point-n-click expected here, I expect no simple models to go to production without cleanup, although rhino does assist in this with its tools. My tolerance for many things is quite loose, if I'm off .125" anywhere but the edges no one including myself would even be able to measure it so the model would be adequate. For the parts with better tolerance requirements, I'll work through that issue when it does arise. The Faro arms are just too far outside my means right now, hopefully in the future they won't and I'll just buy a 10ft arm with joints or a 'budget' laser scanner for $25k.

Bill, I'm well aware of the need for a 4D matrix for solving problems kinematics. That's why as Gerry summed it up we're finding a 2-dimensional location with basic trig and then rotating that in 3-dimensional space as sphereical coordinates. But if you can be of assistance in creating the formulas to solve with a 4D matrix you're help is certainly appreciated and multiple online beers is owed to you. :)

Cliff

Graham - I included a couple files to illustrate what I'm talking about. The line drawing on the left would be the last two segments after the wrist joint with no offset. The last joint allows the last segment to form the arc. The line drawing on the right is the same thing except with an offset between the two joints.

In the second diagram, they're rotated about the centerline of the wrist joint. The one on the left forms a partial sphere, whereas the one on the right forms a partial torus shape. Finding a spot on a torus sounds more difficult to me, but I've been wrong before....

Cliff

The joint, as it comes together, I’m sure we’ll find ways to make it smaller. The pot is roughly 2” (50.8mm) in diameter and .8” (21mm) thick; it is recessed into the fixed side of the joint. To get any real gains in size we will need a different (smaller) pot.

mc_n_g
As much as I would like to have all the advantages of a CMM, this arm will a have one feature you won’t find on a CMM, it is portable. I will be able to take it to the job, clamp it down and record the data. In Rhino I can use this data to construct what it is I want to cut. Until this thread started I figured I would never be able to afford such a thing.

I have found carbon fiber tube .619” OD .555 ID 58” long for $24. I have ordered a piece; it should work great for the main arms.

Gary

I'm going to try a do a sketch labeling the segments and joints represented in my spreadsheet. Gary, the machined joint looks great! I agree with some of the comments on precision. We are going to need to be very careful in the machining and construction, but as we've said, we are ONLY looking for good accuracy - close counts!

Here is a VERY rough diagram - nothing fancy! This shows what my spreadsheet items are based on. I was going to upload the AutoCAD file so others could add to it, but dwg is an invalid file type. If anyone would like it, email me and I'll send it to you.

I was lucky in some dumpster diving and scored a couple of rotary pots/encoders. They were used in some mil-spec-like "aiming equipment." Thats all I'll say about their origin. BUT, they seem to be the size we'd be looking for.
Some dimensions:
Shaft length : 12mm (under 1/2 in)
Shaft dia : 3mm (over 7/64 in)
Mount hole size: 9 mm (close 23/64)
Overall Dia : 22 mm (under 7/8)
Stack height 22 mm

Or about the size of $1.50 in quarters, 3 dimes, and a fat piece of spagetthi on top! ( sorry for the mates overseas - can't count in Euros yet!)

Anyway, they have pretty constant variable resistance (haven't yet worked out the relationship of ohms per degree But I've mouned one up to check out.

I have been looking for the past week or so to find the source - New England Instrument Company Part Number F7888502-M167 or MBU MKv.
They are rated at 5k ohms, and run 0 to 5.2Kohms over about 355 degrees -.
Hope someone can find a source if they're the right deal?

FOUND IT - or a brother! :banana: Don't know if its a player or no - http://catalog.sensing.honeywell.com/Author/Images/honeywell/pot/MKV_servo_dim.jpg
The pdf data sheet is for the 10kohm pot - more discrimination available - or no? I go back to lurking - :cheers: Jim

Bill,

There is no 4D matix to be solved even for the rotating wrist joint case. This is NOT like a robotic arm where you know the position you want and have to work out ALL the angles to get it. We know all the unknowns there is nothing left to find only the resultant of all the vectors that make up the arm. I hope this clears things up.

Cliff,

As I said before, you do not have to do the maths in your head. The offset case is actually just a shere again but shifted in X and Y. The maths is no more difficult it is just vector addition. I am not suggesting these offsets should be built in however just that they might as well be in the equations.

Graham

Jason - I finally figured out what you're doing. Nice and simple but the angles are all refereced to the y axis and that's what was throwing me off on the calcs. On the real arm if you moved segment 'A' up to a 45 angle then had segment 'B' and 'C' remain parallel to the y axis then both joint 'A' and joint 'B' will show a 45 angle.

Graham - picture a clevis joint like at the end of a hydrualic cylinder - the joint intersects perfectly along the axial centerline of a wrist joint (the piston) so there is no offset. If there is any offset than it needs to be added to each previous joint in their calculations as well since deviating from a single plane + pivot. Sure our computers (and code) can handle this, but less we need to calculate the better for a prototype. The first will be the most difficult....

After that, the 4D matrix is starting to gel for me. All it really is doing is accounting for each joints vector components and putting them all together in one formula.

Cliff

I know what no offset is but I just think a more general solution will pay dividends. The software is easy to test even without an arm

there is no need for a 4D matrix!!!!!!!!!!!!

A 4D matrix is just a set of four simultaneous equations because in the cases where you need a 4D matrix you have 4 unknowns that you are solving for. E.g. for a robot arm you have a known position you want but 4 angles you need to find to get that position. In the digitizer arm you have 4 knowns that go into one equation to find the one unknown (well three but one position in space).

Jason, the angles reference to the base are fine but dont forget that the outputs from the pots/encoders will be reference to the arm they are mounted to.

Graham

I know what no offset is but I just think a more general solution will pay dividends. The software is easy to test even without an arm
I agree. Writing one program with a user configuration file should take care of the differences in construction. Basically I think you are saying why not write one program that allows for the user to calibrate their arm to allow for errors in arm geometry.

there is no need for a 4D matrix!!!!!!!!!!!!

A 4D matrix is just a set of four simultaneous equations because in the cases where you need a 4D matrix you have 4 unknowns that you are solving for. E.g. for a robot arm you have a known position you want but 4 angles you need to find to get that position. In the digitizer arm you have 4 knowns that go into one equation to find the one unknown (well three but one position in space).
I think the spreadsheet that I posted demonstrates this. I have continued to look at other sources of 3d information, but it seems that the formulas used are correct - no matrix used (I've always hated matrix math anyway!!)
Jason, the angles reference to the base are fine but dont forget that the outputs from the pots/encoders will be reference to the arm they are mounted to.
Good point Graham. We will account for this in our software.

I hope it doesn't seem like I'm beating a dead horse with the issue, but here's just a simple example of the offset perpendicular to the axis of rotation. In both examples the top and bottom segments are both 2 units long and share a pivot on the left.

But the lower example shows that to actually calculate the coordinates of the end of the segment we'd need to use a different angle and segment length. They would need to be different to factor in the original segment length and the offset length to find the hypotenuse and new angle adjustment. We then could add the angle adjustment to the calibrated angles from the alignment pins on the joint.

This sounds to me like something difficult to measure accurately and an easy way to introduce errors, although even with the simple single-plane construction the inadvertent offsets could introduce similar errors when the spherical conversion is done. The offsets would need to be based on a pivot 'center' to ensure that the segment lengths and angles are correct.

With some quick calcs in a spreadsheet, even being off a 1/16" on a 6" segment means the angle is off by .6 degrees. I did a spreadsheet and this puts our coordinates off by .064-.089" just for that one offset error on just one joint. Cumulative over three more joints and the offsets make the device pretty hard to compensate for in software.

Thoughts? Am I missing something by trying to make the mechanical design fit a simple theoretical model? Measuring any offset that couldn't be determined by checking the arm segments with a straightedge is going to require some sort of special setup is it not?

Cliff

Cliff_J
Good "back of the envelope" analysis - well the modern envelope!
I was concerned with the point you're exploring. And was wondering what sort of a jig we'd need to build to get the bits all straight. Kinda' like building a bicycle - gotta keep the frame straight or it won't roll right. Your analysis shows how much a little impacts the results.
Then, I was thinking the matter gets complicated by using CF rod or tubes - but:

HEY! What if? We design the JOINTS and they are then machined/built like the old TinkerToy! http://burlingamepezmuseum.com/classictoy/tinker.html

Make the joints look like 2 of the round "puck" connectors. One holds the encoder and the shaft/tube of its segment, and the other puck the the adjoining shaft for the next segment, and the mating hole/attachment for the encoder it mates too. The surface could be quite precise and pre-drilling the shaft connections could be done accurately too.
Did I just wake up - or maybe thats what DuluthBoat was thinking all along?

An added plus: the Pucks could be machined to the appropriate size of the encoder and shaft and thereby create a scale-able setup. A micro version for small desktop work and up to larger. The maths all seem to be moving to a scaleable solution and if the software accomodates that certainly would have a lot of appeal.
I be quiet now. Cheers - Jim

Your example would be done in two steps, the vector for the offset "arm" would be produced from the encoder data and then the vector for the arm added to it with the known and fixed 90 degrees between the two. For the case of no offset the parameters for the offset would be set to zero and hence the vector for the offset would be zero leading to the upper diagram.

I am not really sure what we are actually arguing here, I am not forcing anyone to have offsets I just want them on the diagram, they can be ignored for specific machines or programs, do you program?

Here is a nice page on 2D vector addition, the principle still applies to 3D and is effectively what has been done above, when a wrist id added the final vector just needs a rotation of co-ordinates which is a little more tricky but again it only has to be done once by one person.

http://hyperphysics.phy-astr.gsu.edu/hbase/vect.html

A jig could be made for measuring offsets and ideed for adjusting them out for a no offset machine.

You also raise an interesting point, we talk about good enough resolution, well you showed that a small error in angle could create a large error in position, this may also be the case for using potentiometers, it might be an idea if someone tries to get an idea of the angular resolution we can expect to get from them. Remembering as well that the errors are added joint by joint.

For about $200 you could use 4 encoders including index pulse (for initial set up). Just a thought.

Perhaps we should change subject, getting the harware to get angles into the PC would seem the hardest challenge.

Graham

Graham - We addressed the resolution of the pots fairly early in this thread. The problem with encoders was the resolution & cost. The P6500 has a resolution of 0.007 degrees. They cost around $140 each. Going the pot route also helps on the electronics/software - we will not have to count clicks!

I didn't think we were arguing either. I just wanted to make sure we tried to follow the infamous Einstein quote and make this as simple as we could. A nice straight edge is simple enough to attain from even woodworking places, a jig sounds like too complicated to build with precision. That was my hangup.

I program but I'm a better hack than a real coder so I just use Visual Basic since it makes things very easy to to with the Microsoft toolset. But regardless of what code things are written in, they only do what they are told and that includes oversights! :)

Our angular resolution should be very good if we're using the ones Jason linked to earlier - a version of these from the P series was previously used in a Faro arm. The salesperson told me that Faro has since gone to optical encoders to improve even their budget arms precision. Hopefully we can construct one that is precise enough for our diverse needs but at least this is a good indicator that the pot is/was a sound engineering choice even if it is no longer in use. I have no idea where to find optical encoders with this high of a resolution and shudder to think of the pricetag.

Tinkertoys? Ha! Pretty funny although a slip joint 'plain' style bearing would probably work ok too instead of an actual rolling bearing so good point.

Ok, I've got a cheapie .25% linear potentiometer coming in this week from a Mouser order. How the heck do I test if this thing is accurate? Jason, you got ideas on how you plan on testing yours? I've got a fluke 87 but even that thing is .7% accurate. This precision thing is starting to present itself as our main challenge IMO.

Cliff

I never suggested offsets should be built into the machines, just the maths or at least the diagram.

$140 per axis is a lot of money to me. 0.07degrees is the repeatability, the ability to get that acuracy will come down to noise and ADC precision etc. The other issue with pots is that you would have to calibrate them to get degrees per volt for the used supply voltage. Using cheaper pots will bring about problems with wear and linearity.

One advantage is that they are an absolute encoder so no zeroing is required after initial set up.

For $57 from USdigital you can get a housed encoder with 2048 CPR, now correct me if I am wrong but if you use the edges of the quadrature you can get 4 times that resolution so that is 0.04degrees and no calibration or problems with noise. They are available with an index output that could be used as a home switch, wave the arm around until all the counters are zeroed and you are ready to go.

www.usdigital.com

As for voltage measurement over counting clicks well it seems to me that a pic can count clicks very well it just has to keep track of them, adding and subracting as the arm is moved. When the button is pressed the counts are sent to the PC for storage and later processing.

Graham

Graham - Look at that again. It's 0.007 degrees repeatability not 0.07. With a 2048 count encoder it's only 0.175 degrees. I'm not saying there are not challenges here, but for the accuracies that we are looking for, it should serve our purposes. I hope none of us think we will have a $4k machine for a couple hundred bucks. This all just means we can collect parts as we can (play money), add some elbow grease, and have a 3d digitizer that will allow us to gather points to "rough in" a 3d model based on those points. I think the geometry will be largely what we make it. As we build the software and the arm we will account for the geometry.

Cliff: I'm also in that "hack" category as far as programming goes using VB:)

LOL!!!
I love this, you guys are literally convinced the math and programming can be done. Your uncertainties seem to be about the mechanics. I, on the other hand, am convinced the mechanics is not a big deal. The model I started with is still changing but the basics are the same. I’ll admit it’s clunky, but you won’t find a simpler or more accurate joint. The machining is not difficult and given a little care in the assembly there should be no offsets. The refinements I see in the future will revolve around smaller pots and smaller bearings.

I started working on the swivel base and waiting on the shafting arrival. I have left the machining for the pots for now so changes can still be made without design changes if the pot we use has a radius of 1.5” or less from center of the shaft. We need to make a decision on the pot to use if not the P6500. Most projects like this usually have a few walls to climb over but I don’t see any yet for the mechanics.

Having fun
Gary :D

Sorry 0.07 was good enough anyway :)

As I said 2048 CPR gives you 4 times as many edges, so it is 0.04 degree resolution for the encoder at $57 with far less problems.

As far as I can see all we really need to do is build a DRO strapped onto an arm. Get the data into the PC and then convert.

Why get rough in accuracy at $140 per axis when you can get excellent accuracy at $57 with far less hastle.

Grhaam

p.s. A hack in VC++, C++, C, Matlab, in fact a hack in any program I end up using ;)

Gary, I am totally confident about the project too, including the mechanics, it really isn't all that hard once you break it down.

LOL, I used to catch slack from the C programmers and then I caught them prototyping code in VB as a proof-of-concept before committing to doing it in C and I wouldn't hear of it anymore. Besides, I was on the support side and from that viewpoint their C or whatever code didn't seem so superior anyways. :)

I think we're all on the same page. Please don't take anything I say as more than thinking out loud or 'brainstorming' or 'skunkworking' or whatever term you use for it.

I could've sworn I only saw 512CPR/2048PPR encoders last time I searched. Duh, my bad I now read their description as 2048CPR/8192PPR after quadrature. Back on the viable option especially if we could design a mount to line up the index mark with a mechanical alignment pin to allow registration from relative to absolute.

At .044 degrees it might seem worse than .007 degrees but its still ahead of a 12-bit ADC at .088 degrees as well. With a 16-bit ADC we'd have to ensure our noise floor is lower than the LSB or two or three...or else be in the same pickle. :)

If testing showed interference to be an issue, the encoders are also available with differential outputs so I'd guess simple CAT5 cabling and the benefits of CMR could fix any issues there for only a few bucks more.

Cliff

Just a bit of noise from the sidelines again.

If the digitizing arms are used for reverse engineering (as well as product validation).
Wouldn't it be helpfull to "reverse engineer" from a proven product?
This site has a few good items:

1. A set of names for the naming convention
2. A hint that a counter balance might be useful
3. Some free software to interface with various CAD programs
4. A software developers kit
5. Pinouts etc that may be of use

But then again you guys may have already researched this...
http://www.immersion.com/digitizer/support/

The revised quote that comes to mind:
We can see further when we stand on the sholders of Giants


I actually went looking for some parts diagrams and nomenclature to check their accuracies - will go back to lookin'.

Jim

" A hint that a counter balance might be useful"
With this baby I think a counter balance will be mandatory. I want to get a weight guesstimate before I played with it.

Are there any physical specs available for this other encoder?

Gary

A quick personal note, Graham do you ever sleep?

Gary :D

I had a thought while riding to look at a project (at a machine shop :) ). I know I might be changing my story with this - but I always reserve that right :) . I agree with Graham, encoders would be easier. I was hungup on the 2048 counts. Why could we not use a 2:1 gear ratio in lieu of a direct couple to the shaft for 2X the counts per revolution of the arm? This may be way off, then again hopefully it's a good thought. If that's the case, we install, make "click counters" - digital by nature, and pull into the computer. Simple. Right??

As far as the reference point goes, I think putting the pointer into a reference holder, zero out the machine (it knows the angles of that position), and start digitizing the object. This way the "clicks" and associated angles are resolved by referencing the "starting angle". Is this how the other production machines work?

Jason, I think that’s how the high resolution optical encoder’s work, it’s worth looking at. Given the right ratio even an IR encoder from a mouse might work.

Gary

Gary - I own the exact model you linked to except mine is red and not black. Only the joint that appears to be counterbalanced is, and while the unit weighs about 15lbs the arm is still fairly light to use and 'weighs' under a 1/2 pound in your hand about like an empty coffee mug. A little hollowed out area in the back of the main arm segment (at the shoulder joint) and some lead shot/epoxy and the user could counterweigh the unit easily enough.

Jason - with quadrature we're already 4:1 and up to 8192 counts per revolution. But I agree that we could use some simple spring-loaded anti-backlash gears to step this up even more and increase the resolution even better.

The Microscribe is like an enigma for how it works exactly. When I hook up to it in Rhino, part of the connection in the command to start the digitizer function is to specify in Rhino if I want to use 'world' coordinates or 'user-defined' coordinates.

To use the user-defined ones I simply place the pointer at the point I want to be 0,0,0 and click, then place somewhere on the x-axis and click, then somewhere on the y-axis and click and Presto!! I have my coordinates setup and the pointer in Rhino follows my every movement and is referenced to my origin. I'll fire it up sometime soon here and find out where the world coordinates of 0,0,0 are - my guess is the little holder slot but there's enough slop where I don't know if this is the best plan. Just a little dirt on the stops on the arm and this changes things a pretty good amount.

Did I mention the arm is touchy? :) Sure you may think you're steady like an old west gunslinger but a few thousandths at the end of your arm takes very little movement.

I like Graham's idea the best - power it up and then move it around so the index points can register and then the microprocessors can follow it from those points. As long as the index points were referenced to 0 or 90 or whatever degree then the math is pretty simple from there. And a DRO would be awesome.

I'd say lets get some basic software written to output some good point cloud data in an ASCII text file (that is easy enough to import into many programs) and then for like version 2 work on the support for Rhino and those by emulating an existing arm.

Cliff

I'm sorry guys, my bad. I looked back at the encoder information. I just totally missed the quadrature information. I was thinking it was 2048 w/quadrature. Looks like that should be the best route. It might actually make it easier - as Graham has been saying :)

Gary, I am in the UK, I work while you sleep alhough I was up till 3am last night trying to finish my PhD thesis (double yawn). Full specs including mechanicals of the optical encoders here: http://www.usdigital.com/products/s1s2/

Here is another idea, USB. Sounds like a real nightmare but perhaps not:

http://www.alanmacek.com/usb/project.html#HOSTSOFTWARE

This guy connected a PIC directly to the USB port to form a microphone, used standard microchip code for the PIC end of the comms and standard windows librarys for the PC end. Cool or what! Plus it can power the digitizer arm!!!

Graham

If there were some specs on this encoder:

http://www.phidgetsusa.com/viewproduct.asp?SKU=1052

that would be helpful too. It is already set up to USB - and you know they're making some money even at 30bucks.

They have another that is a plug in via audio cable (oh maybe soundcard a/d - is back?)

http://www.phidgetsusa.com/viewproduct.asp?SKU=1109

Jim

I seem to have started quite a wind storm with my 4D matrix comments :rolleyes: .

I will email my professor for clarification and also point him to this thread. Perhaps he will enlighten us (he is one of the smartest guys around, when it comes to graphics).

There may be no need for the 4th axis stuff unless we are rotating the object in 3D. Perhap a simple 3D matrix will do.....

I just got home from a business trip so I am tire :tired: and will jump on this later.

Bill

The 4th axis is needed to get around the object if it is curved at all, wrist joint or rotary table can be used. Fine without for a first try but I think needed eventually.

As I said the use of matrices is to simplify the maths of simultaneous equations. With all unknowns, known there are no simultaneous equations and hence no matrices 3D or 4D. I think your prof will concur once he understands what we are trying to do more fully.

Graham

Or to put it another way:

"I don't believe it is that simple. As I recall from a computer graphics course to solve for a translation (move) in a 3D space you have to use a 4D matrix"

We are not solving for a tranlation in 3D space, you do the move physically and then just work out the co-ordinates based on arms lengths and angles, completely different, apples and oranges

Graham

I found this interesting site this evening while searching GOOGLE for "building optical encoder circuit".

Building ISA Optical Encoder board (http://www.boondog.com/%5Ctutorials%5C7266%5C7266.htm) (It's not taken me long to get "back on board" with the optical encoders :) )

Reading this is making me question whether it's worth fooling with a microcontroller or if it would be just as easy writing a program to poll the serial (or USB) port for the click count from the on-board circuit. As I said, food for thought.

I did a little reading online as well. Little more involved than I'd imagined at first (with a super-simple vision of the A,B,Index outputs tied to parallel port pins) I'd read a little and found the quadrature IC used as well, with the best explanation for eliminating things like vibration issues in the link below.

http://zone.ni.com/devzone/conceptd.nsf/webmain/6F25CBA2CD73417786256869005E5FC3

If we can take one of the simple $30 USB modules to connect and poll the counters from some inexpensive ICs that would be easiest and coolest.

Cliff

The chips that convert quadrature to "step and direction" seem an excellent idea and if available will make development much easier.

That reminds me there is already free encoder based DRO software out there:

http://www.lindsayengraving.com/other_interests/dro.html

http://ns1.dicomm.net/~axtein/dro/

These are both versions of the same thing. AND source code is available, all that would really need to be added is an input for capture and that could be the keyboard to start with. The captured data could then be converted with our own software to a format for Rhino etc. They also use the parallel port so very simple only a buffer circuit is needed.

Cliff, which $30 module do you refer? One previously mentioned just seemed to be a USB potentiometer?

Graham

Graham - I'll butt in here having posted the encoder/USB pot. The same outfit has an A/D interface that costs $75.00. Its got:

8 Analog Inputs
8 Digital Inputs
8 Digital Outputs
and a 2 Port USB Hub and a 6' USB Cable.

A Power Supply is required to use the 2 Port USB Hub.

Board Dimensions: 6.8 x 10.2 cm
Mounting Holes: 4.5 x 6.6 cm

They also have some Java/VB also free, and appear to be helpful in their forums section as well (eg may help with some software aps to promote their product - my sence anyway. The softwaremay be a plug&play for the optical encoders as well. They have a bit of discussion regarding matching encoders in the tutorials section.
Regards, Jim

Yeah, and the chip is available right from US Digital for $3 so it makes a lot of sense.
http://www.usdigital.com/products/ls7083-84/

Here's the modules I was talking about:
http://www.futurlec.com/USB.shtml

I've only ordered from them twice and while their prices are awesome the 3 week wait to get the parts was almost too much. Here's the manufacturer and they have other products to make I/O super easy as you plug it in and then it emulates itself as just another serial port.
http://www.elexol.com/USB_Modules/

We might still need to tap the +5VDC from the computer unless we can just borrow from the modules above and our current requirements are low enough, but this shouldn't be too much of an issue.

Hmm, those websites you linked to Graham just use a pair of PNPs or an IC to isolate and drive the parallel port inputs - maybe my vision wasn't oversimplified. But for our application where 'switch bounce' type jitter could be an issue the ICs designed to eliminate this means less code and less potential errors.

How long before someone reads the mouse encoder link off the pages above and tries to build a digitizer for under $100? :)

EDIT: Jim, we're not talking about using the A/D anymore with potentiometers so you're post is relevant but a couple days late. :) Plus I believe their A/D was only 12-bit and the encoders we're talking about would be about 256x more accurate so that seems like a better choice. Thanks for sticking with us as we iron out the details. :cool:

Cliff

I think Jim was refering to the digital inputs for use with encoders rather than the A/D.

Your $30 module just allows 232, handy to make programming easy.

There are no switches to bounce in optical encoders. You can rely on the output to be error free, at least on the packages sold by Usdigital, they include circuitry for that sort of thing. The buffer circuit (logic gates on the one I looked at) is just a buffer. 5v supply will probably be needed, reference to ground on the parallel port.

Right then, no excuses get building!!!

Graham

If you were worried about vibration induced errors as mentioned in the NI site then we shall have to research the specifics of the encoder a little more.

I am also not sure if the speeds and vibration produced by a human user will cause problems, hard to say.

Graham

Speeds no, vibration possibly. Its not actually switch bounce but in terms of dealing with it by LP filtering or buffering with delay its similar. If you think of how small of an angle this thing can detect what are the odds the detector will end up at an edge and be at the threshold it will consider on/off it seems plausible it will happen and logical to use an IC designed to eliminate it. EDIT: Just re-read your post, the US Digital is already a buffered output. My bad. But the counting is still applicable.

So for $3/axis now we just count and don't need to write routines for quadrature. The 7803 with the up/down count seems easiest to program.

Yes, we're almost to the point of having worked out the difficult parts, now its just figuring out the details. What is our excuse for not having this done yesterday? :)

Anyways, should we use a PIC to store the counters in a couple registers for each encoder and then use our software to poll the PIC and pull in the register for each axis and calculate the angles? The PIC to handle the indexing of each joint so the counts are based on that (maybe an LED per axis to tell the user when that axis is indexed and being counted). Which PIC? Et cetera.

Cliff

I have been researching pot feedback a long time ago. High precission pots were pretty expensive then. On top of that high precission DAC chips were very expensive too. Maybe things have changed now.
I still have some contacts in the electronics world. I'll see if I can find something. I doubt 16 bit is really needed. 14 bit should suffice no? That's 16384 steps.
With a voltage feed of 12V, that's a resolution of 0.000732421875 volt. The ripple of the supply voltage needs to be at least half of this to get a good resolution! That not a lot!!!! That makes the supply voltage regulator very expensive. Thermal conpensation and such are necessary.

Contradict me if I'm wrong please.

Cliff, I should have taken the quotations around "switch bounce" more literally. I think there may still be issues with dithering where short pulses can be produced with vibration on a transition, these can be filtered out (according to your link) but perhaps already are in the USdigital encoders (I have asked on CCED, some boffin will know). I am not sure if the chips you mention do this filtering either but it is probably just a capacitor.

For our own software solution then those chips seem an excellent idea, daft not to.

Those chips also reduce requirements for I/O of the PIC, down to 3 per axis an input for aquire and the comms. I am not up on the current state of PICs and which is best etc. One that does easy comms would seem the preferable one, the counting is easy.

For now perhaps we should try the fully PC based solution as per the DRO's, we will at least be able to see numbers changing on a screen straight away. Having said that the time between wanting to make an arm and having one to use may be a tad high, I personnaly can's start building till the 1st of October. So there may be time to start work on the final software solutions.

bertvk,

I think most people will go with encoders now, $57 for 0.04 degrees is pretty good.

Graham

What's CCED?? And do you know how to monitor the pins on a parallel port from VB or have a C based module that we can instantiate an object from in VB to grab the pins Graham? Searching MSDN has become more difficult in the last couple years, so far I've found little info.

Bertvk - yes, 14-bit would be ok but the last 2 LSBs can always be thrown away on a 16 can't they? Yes the power supply would need to be rock solid. Never considered thermal. Nothing like an EE with actual experience to spoil a perfectly good idea. :)

Besides, now that a couple of us learned how to read the website on encoders (we had originally missed the PPR resolution), we're gonna go with the ones Graham mentioned above. Then after we get the software sorted out (insert evil "muhuwaha-ha-ha" laugh here) I'll go with the $200 encoders for my giant 10ft arm and they'll have resolution near 16-bit and differential outputs so a regular PC supply should work fine. A Faro/Romer arm for 1/15th the money would be an awesome achievement.

Cliff

Hey Guys - Thanks for being patient with me.
I see there are some definate advantages to the encoder option - I'm learning a lot more doing this than that extra summer session in EE! I'll be patiently waiting to see the details develop.
:cheers: Jim

Sorry, CAD_CAM_EDM_DRO, CCED is a Yahoo group on those topics. Some big guns hang out there, I am genrally too scared to post ;)

You can read direct from the parrallel port in C using the inport command. I am fairly sure there are C based things that run under VB for such things. It rather depends on the approach used but for comms to a PIC then the serial port or USB might be best, for the encoder monitoring approach then running the app under dos might be the only option as Windows does not like watching hardware much.

Graham

Useful:

http://www.lvr.com/parport.htm

Thanks Graham, more reading...

If my thinking is correct and you can just poll the pins at least twice as fast as you expect the highest frequency (assuming I can apply Nyquist here, dunno if I'm out of context) then you should be able to catch all the events. That's how the books on programming PIC have you do it, you don't look for edges or anything just logic on/off at a regular interval and then count if different. Seems simple enough.

Cliff

That would seem correct, the pages on DRO's suggest a 286 is overkill for that application however I wonder if an arm might be wafted faster than a lathe handle is turned. Probably mot much in it and I suspect most would go for at least a 486!

The problem under windows I think is that when you say, "look at that", windows tends to say "hang on a second I am just performing random tasks".

I know you can do pretty good real time type stuff under windows if you know the tricks (mach2 proves this I think) I just don't know them. Having said that if Linux can do proper real time control with EMC then windows should at least me able to count the odd pulse.

hmm, thinks of a google search

Graham

... then running the app under dos might be the only option as Windows does not like watching hardware much.
Followed with
I know you can do pretty good real time type stuff under windows if you know the tricks (mach2 proves this I think)


Graham- I'm betting on ya! I think you got it right - somehow ART has worked MACH2 into "getting under the skin of Windows" and has its own driver when you check the CP. Wonder how the Microscribe interface?

Cliff, does the Microscribe work under DOS only? How does it REALLY work? Continious input - or discrete points that are then smothened to form a surface? I note there is an option for a foot switch - is that used to ID the points to capture - or turn on/off as you capture a "data line"?

On the other hand - grabbing a stream of data and then "flushing" to the pc might be useful - but wouldn't know if you captured the right stuff 'til way later. It would seem to make a difference in the polling requirements if discrete points vice streaming data were captured.

Now I know why I'm such a procrastinator sometimes, I'm use windows too much! :)

I'd hope we can poll faster than the data rate of any port, and a PIC running at 4MHz could poll at say 40KHz so that would be 10ms for a 180 movement of the arm - basically a drop! We could setup things up to re-index each time that point was passed as well, that might help.

So far I like the looks of inpout32.dll from http://www.logix4u.net, it seems to do what I need it to and the price is free. Hmmm, now I need to setup some switches and test this...

Cliff

Nice find Cliff

My thoughts:

Quick and dirty: use the DRO software and modify it

Decent job: use a uP and serial or USB data link.

Part of me just doesn't think it is worth writing from scratch for the parallel port. I just worry about getting the polling right. But hey, that doesn't stop you!

Also a dead easy thing to check, just wiz the encoder around a bit and then see if the index is where you left it. Could even write a little program just like that for testing a given PC.

Graham

I wrote a scalehouse program (I work for a asphalt paving company) once upon a time in VB. I had to make my program interface with extremely old technology. I bought a book - Serial Connections in Visual Basic - I think?? I used the comm control in VB. I set it up to collect from the serial port buffer and strip the data of all "less than important" characters, convert it to a number for calculations, converted it to a string, and put it in a text box. I never got to see the entire program function since we finally figured I should be estimating (my job) instead of supporting a program (hobby - at best)! I did do several tests at the scale, reading the data. Very interesting challenge. Now, finally, all that time/effort might actually come in handy :)

In my desire to get as far as possible from Microsoft (no escaping at the office :frown: ), I now use a Mac at home and have looked into Linux. I am concerned that Windows, with it's HUGE overhead, would lose data/counts. Since I am a VB hack, I do realize however Visual Basic would be the easiest way to to program a great user interface.

My first thought is to do a simple program, on a MSDOS machine, that would allow you to see certain information on the screen (coordinates, joint angles, etc) and dump the collected data to a disk. Simple enough.... I think. I have ZERO experience programming MSDOS!

Another option (the coolest) is to have a on-board PIC (OOPIC, Basic Stamp, etc) counting "clicks", solving for the angles, and collecting the points when triggered (finger or foot operated). The connected computer (Windows) is only going out to check for buffered points and pulling them into your favorite CAD or modeling program using a timer control. Both the OOPIC and the Basic Stamp have neat LCD displays that could function as your DRO. I know from experience that the OOPIC is as easy as VB for programming - it's operating system is based on VB.

Jim, the Microscribe works a few different ways and I've only used the Rhino arm support. You can just point and click and have it enter just that point, or you can have it capture continous points as you move it. The continous is sorta annoying, the tip 'bounces' a little as you move it across the surface and unless you had some very hard surface you wouldn't mind a hardened steel point damaging its more likely to skate a little because you're not using pressure.

I'm not so sure if the DRO software is applicable to this setup. They have a very linear relationship to count clicks and multiply by the pitch to find distance. We need to use the cos/sin of an angle cumlative over joints and convert sphereical to cartesian. So I think we're sorta writing from scratch no matter what we do. But I do like the idea of using the index as a means of checking counting accuracy. It would be easy enough to take one of my steppers and write some simple G-code to swing the encoder back and forth on some pattern of movement to test the repeatability, and we could spin the encoder faster than we'd likely move it. Also I'd probably try to figure out some 4ft arm of wood to attach to the encoder so I could mark out like 1/4" intervals on the wall and check to make sure it averages ~16 counts per division with repeatability.

A standalone DRO would be cool, I agree. I guess I'd want to use the PC first though, its easier to use since there is little learning curve and more data to troubleshoot (did I use cos when I should've used sin or did I calculat that angle with the previous one factored in type stuff) and only use a PIC once I get the routines sorted out. Learning a new chip, code, LCD all at the same time makes this a bigger project and I'd rather get a small step done first and then move on to cool stuff. But we can divide and conquer. Besides, you have a shell (if you installed it) or can use SoftWindows to write some code and find plenty of C compilers if you so desire. :) After using the shell as much as the GUI and having Final Cut crash repeatedely on my dual G4, I gave up and just stick to windows. Its like a Chevy, it may not be the fanciest or most pretty but I can fix it and keep it running forever for cheap.

Cliff

Jason, The DRO software I mention is such a simple dos based program, already set up to read 4 encoders (if you use V5.1) and even has a nice screen. All that needs to bbe added is a write to disk/memory command.

Although you could try and put everything in the PIC/OOPIC I don't think it is such a good idea, you want to be able to alter things easily (everyones arm will be different) and that should preferably be on the PC. All it really has to do is keep track of the counts so these can be output via a serial link etc to the PC, the angle conversion can be sorted by a second program, as the exact numbers of pulses per degree might change between machines this makes more sense.

Jim, the DRO program is totally applicable. Sure is shows a linear distance but this is just a click count multiplied by a magic number, guess what, that magic number can be such that the output is the click count. Besides, in the software you could remove the scaling to get the pulses. So all you need to add is an extra input for "aquire" and a write to file function.

Then just to reiterate yet again once you have a set of numbers on file (click counts of linear distances directly proportional to them) you have a simple second program (or spreadsheet!!) to convert the click counts into angle and then sin then or cos them or whatever to find the co-ordinates.

My thoughts are still:

Quick and dirty: use the DRO software and modify it

Decent job: use a uP and serial or USB data link.

Added to these is a simple random number to co-ordinate generator program.

Graham

Back to the calibration/home point. According to what I've read about the Microscribe, the pointer position/holder on the back of the base is the calibration point/0-0-0. I'm not saying that we should not allow in our software to setup another point as the 0-0-0 base point, I'm just thinking about calibration. If the pointer was in a known geometric position when powered up then our "clicks" would be referenced to that angle.

Example (based on 8192 counts for 360 degrees):
Starting position for Joint angle A - 45 degrees. The arm is moved to the first point "shot". The counter for Joint A shows 2048 "clicks". The Joint A angle would then be 90 degrees. The arm is moved to point #2. The counter for Joint angle A shows 1024 "clicks". The Joint A angle would now be at 67.5 degrees.

Is this example how you guys see this thing working? I guess to do this thing "quick & dirty" you could save your counts for each point "shot" and then post-process with some VB application. These points could then be imported into your CAD of choice.

I am not sure if you need to regulate the angle of the sylus as well as the position of the tip for zeronig but a tube was suggested.

Or you just waft the arm about until all encoder index marks are detected, zeroing the encoders as they meet them. The actual position of the home (in terms of encoder position) is irrelevant as long as you know what it is and how it relates to 0,0 in space.

Graham

Graham: I guess the reason I was saying we needed to use the Home/Calibration location (tube, clip, etc.) is to keep us from having to know the index locations (angle of Joints). Since our resolution is so good with the encoders running at 2 or 4 times, it would be very easy to miss the alignment by several "clicks". I also know it will be hard to be super-precise on the "known" joint angles.

I know a lot of information has been posted here since my 7-31-2004 reply to Cliff's original post on 5-21-2004. It might be good if someone went through and summed up the information for us. Just a thought :)

This thread has been a great learning experience for me. I'm not sure however, if I have enough need right now to build one of these or if I should spend those resources (time, thoughts, play money) in building my first router/plasma table. Either way I have GOT to use some encoders - I've learned too much not to! My gut says make a table to make some parts/dust!! Any advice out there?

Jason, not sure what you mean by "keep us from having to know the index locations (angle of Joints)", these still need to be known. Indeed if you have a tube/clip and you know the geometry of the arm well (which you need to ayway) then you can assume the joint angles and zero them. But to do that you need to be precise about where this tube is in space and the angle it is at, not actually that simple perhaps.

It is fairly easy to add some form of mechanical index or locking pin to a joint to hold it at say 90 degrees (this idea mentioned by someone else) so if the index outputs of the encoders were used as a reference for the angle then you would go through a setup procedure:

You run a little program, it would say "insert locking pins". The joints are now at 90 degrees to each other (or straight or whatever, but known). You confirm this and the program zeros the encoder count. It then says "waft arm about", you remove pins and then waft the arm about, the program tracks the encoders and watches the index, when it sees the index then it knows the relationship between the locked angle and the index point on the encoder. This would be something you did only once, this offset would then be shoved in the config file for your machine. This saves trying to align encoders. When you first come to use the arm you just waft until the indexes are seen, the software then just zeros the encoder and adds the offset so it is actually zeroed to some known reference line. In fact this only needs to be done when you come to convert encoder counts to co-ordinates, the data capture software could just record counts from the index mark where ever that was, the offset would just be shoved in the conversion program as a parameter.

The alternative is to add the locking pins each time data is captured and then zero the machine and ignore the index outputs.

The exact way the mechanical locking pin/index is done might be more of a challenge than anything else if you want mega accuracy.

Graham

The methos you describe is exactly what is done in joystick calibration in Windows. you center, move to end points and center again. This calibration needs to be done only once theoretically. In practice you need to do it every time you feel the joystick is not working properly.
Personally I think doing this every time you start measurements is not too bad. Move the arm to one extreme (known angle), capture measurements, move the arm to other extremes (known angles), capture measurements and move the arm back again to know the repeatablility. This data captured allows you to know what angle corresponds to what data measurement. Of course it might be necessary to use some hysteresis callibration table to get exact output. Nothing fancy really.
When you start the measurements the first thing you do it set the relative 0,0,0 point and start measuremets in regard to that. Pretty standard stuff.

A summary may be a good idea; it may help some of the lurkers give their $.02. I for one am still very excited about getting an arm that will be useful and not break my bank. Using the encoder I was able to down size the joint with the same bearing and shafts, still rock solid still simple but a little less clunky. I should have it finished in a week or so then it will need electronics and software. To keep this process moving forward we need to settle on an approach and rough something in. This is what my finished arm should look like.

Gary :D

I think if your encoder calibration is changing between uses then there is something a bit wrong. Plus the wrist rotation has no limit and probably the same for the base?

"