[High Seas]

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

[duluthboat]

" 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

[duluthboat]

A quick personal note, Graham do you ever sleep?

Gary

[jtedmonds]

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?

[duluthboat]

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

[Cliff_J]

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

[jtedmonds]

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

[Graham S]

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

[High Seas]

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

[bgriggs]

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

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

[Graham S]

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

[Graham S]

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

[jtedmonds]

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

Building ISA Optical Encoder board (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.

[Cliff_J]

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....256869005E5FC3

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

[Graham S]

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/othe...rests/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

[High Seas]

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

[Cliff_J]

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.

Cliff

[Graham S]

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

[Graham S]

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

[Cliff_J]

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