Interesting thought about encoders..

[NickK]

As the house purchase is coming first.. and I'm seeing my DDM60 budget disappearing to the solicitors.. I'm looking at DIY direct drive with encoders

Now rather than use renshaw encoders, which are very nice but too expensive/hard to get just a one or two, I've decided to continue looking into my other option - optical mice.

Avago produce sensors for high speed optical mice - such as the logitech gamer series. These include laser based sensor giving a very good sensitivity of 8500 cpi.

My calculation here is:

1 arc second = 1 degree / hours / minutes / seconds = 1/60/60 = 0.000277777778 degree

At 8200 counts per inch or 25.4 mm

therefore 8200/25.4 = counts per mm = 322.834645669291339 therefore 1 count per 0.00309756097561 mm

we want to work out how many arc seconds per count

1. sin (0.000277777778 ) = 0.00309756097561 / hyp

2 hyp = 0.00309756097561/sin (0.000277777778 ) = 638.917813964132093 mm

3. 638.917813964132093 = 63 cm radius

4. by staggering a couple of these it should be possible to increase the accuracy.

5. They have an SPI attachment so it's possible to write a PIC to sequentially poll these at a very fast rate, resulting a single encoded point.

So searching for ADNS-9800 (the sensor in question) gives me this for a mere £24:

http://www.amazon.co.uk/computers-accessories/dp/B00BM7NXMW

So for £100 you get (ideal conditions) 0.25 arc sec encoder at 63cm, or, a slightly less accurate for a smaller diameter.

Interesting for a wedge fork mount...

[NickK]

So what do these sensor give? Why not use the mouse directly?

In short USB would be too slow. Having a PIC or ardunio close to the sensors on an SPI connection would result in a faster read cycle, not because of transfer rate but because of latency.

I have a dead MX 500 which as a ADNS-9500 at a slightly lower 5000 cpi which I may see if it's just the laser diode that has died then try and communicate with it using the blackfin or ardunio.

[Scooot]

Have you considered us digital encoders

http://www.usdigital.com/products/encoders/incremental/rotary/shaft

[Cath]

1.2 meter diameter is a big disk!

We have also been trying to think of a cheaper way of doing an encoder for direct drive. The high res mouse sensor is not a bad idea.

It wouldn't be impossible to burn an encoder pattern onto a standard writable DVD. This would give a very high resolution. The laser from a DVD drive could be used as the sensor.

Another idea might be to transfer a desired encoder pattern onto a length of 35mm camera film, and use that after it's been developed. Not sure what resolution of 35mm camera film is.

[pete_l]

Avago produce sensors for high speed optical mice - such as the logitech gamer series. These include laser based sensor giving a very good sensitivity of 8500 cpi.

My calculation here is:

...

3. 638.917813964132093 = 63 cm radius

I'm having a guess that you intend to couple the sensor onto the side of drum connected directly to the shaft of the mount.

There are about 1.3 million arc-seconds in a circle (360*60*60), so for 1'' resolution you'd need 1.3M ticks. At 8500 ticks per inch that would require a circumference of 152 inches, which is pretty close to your 63cm radius - check.

The problems that I see are:

1) getting the drum perfectly circular, otherwise you have your own version of P.E.

2) making sure the sensor doesn't slip it's contact with the drum (v. difficult)

2½) Likewise for whatever inside the sensor contacts the drum. IMO mice are made for *resolution* not accuracy

3) at a slew speed of 1° per second, you'd get 3,600 ticks, so you'd have about 300microseconds to process each one. Will your SPI routine work that fast, or would you need dedicated hardware? faster slewing drops this time proportionately.

4) how would you keep all this stuff clean, so that the surface / contact points are perfect. Dew, dust, insects, finger prints ...

Have you considered a TDM?

[Cath]

Another possible way is to use the interference of two patterns, digitize the analog quadrature signal to provide a much higher resolution than a basic digital encoder can produce.

[NickK]

The nice thing about the ADNS sensor package is that it keeps it's own count. The SPI only needs to read, therefore at any point in time it's possible to read the count. The SPI doesn't have perform for each count tick. The ADNS-9800 uses a LED array to produce a 'laser' coherent light source that is used to bounce off the target surface. The sensor then has a small CCD (in simple terms) that it uses to image the target. On the same chip is a DSP that then performs optic flow at about 12,000 frames a second. With a 16bit +/- count this means the package effectively becomes a fast processor. Infact the LED, optic sensor and DSP + interfacing logic are actually on the same piece of silicon!

The optical sensor can cope with changing distance (a few mm in fact) so a completely circular disk is required but it doesn't have to be CNC milled! Also because it's not using a specific encoding pattern, the sensor target doesn't need to be spotless. The laser version also has the added benefit that it will work on many more surface types compared to regular optical mice.

The ADNS-9800 mouse sensor package itself can cope tracking 100-150 inches/second. If the circumference is ~152 inches, then the sensor should be able to track a scope slewing from one horizon to the other in under one second. How accurate/precise it would be at that speed would be interesting to find out. However with a few running in parallel, a fast slew could switch to a majority voting system positioning. Back to tracking mode could make the system switch back to alternate stepping.

I had a look at the US digital, however they seem to top out about 2500 ticks. Then there is the requirement to attach to the axis in some form without slipping.

[NickK]

Just looking at the CD/DVD route. Plus points are a smaller disk size, possibility of a high accuracy read out however the electronics are far more complex and getting alignment is far more prone to problems if the disk moves. Note that a DVD would provide 2.16x the accuracy given the minimum pitch length is half at 440 nanometers. This is important because you would only be able to target the current track (and not provide a grey code). The minimum pit size is 400 nm for a DVD or 830 for a CD.

First point is shown by this

where the basic motor has hall encoders to help get a rough position but the CD would then still need to stand on it's own to support 1.3M ticks per rev - remember we can't store parts of a grey code on the other tracks. Also that the pit is one bit so if you wanted an absolute encoder, then log(1.3M)/log(2) = 20.3, ie 21 bits or pits. which means, approx 400*21= 8400 nm per encoder position.

A DVD would have 25.13 cm diameter (max and the recording surface less than that ), so 1 cm = 10,000,000 nanometers, gives a maximum of 251,300,000 nanometers along the 'ideal' outside track, then divide by 8400 gives a mere 29,916 absolute positions without having a variable encoding configuration to reduce the required position tags.

The required tag size would be 251,300,000 /1300000 = 193 nm which is less than a DVD pit size governed by the laser used!

Blueray drops the pit size to 150 nm - so an 8" blue ray based absolute encoder could work.

This shows why they use a multi-track encoding to read the absolute position and a larger ring size to reduce position tag size.

The second problem is that all the electronics attached to the mechanism are designed to follow the CD/DVD format and the way it works. That is all the disk format info etc. Instead that would have to be done using high speed electronics - probably more likely a FPGA - to DSP the incoming digital wave and process them.

Now that we've calculated you'd need a blue ray player the complication with alignment of the axis and then high data rates (a PIC would not be able to handle) probably lead up to one conclusion - using CD/DVD/Blueray is too difficult for a hobbyist.

Another option is to use multiple encoders on the axis.. (double sided etc) but you'd probably need a few encoders and hope that the axis shaft does not twist or bend..

if a double sided disk was used, then we'd only need 2x193 each side.. 386.. which is still less than the DVD pit size of 400-440nm!

[NickK]

Another possible way is to use the interference of two patterns, digitize the analog quadrature signal to provide a much higher resolution than a basic digital encoder can produce.

In a similar vein, you could use a sinusoidal wave pattern around the disk, then add in out of phase additional waves - then use an FFT but that requires change over time (ie the disk rotating) to give an adequate sample to FFT (i.e. at least one wavelength of the sine pattern). Hence you could not read the position without moving - as you'd only have one point of the curve (which could occur multiple times).

Using a grey code simply means that each point, the code will provide a different unique value. The point here being that the disk does not need to rotate to infer a position.

With the mouse sensors - it could be possible to reduce the size of the disk by using multiple sensors around the disk but not quite on phase boundaries to detect ticks. The problem here is that the mouse is a relative sensor and not an absolute. Nothing stopping combining the two - use a grey code to give a basic position with an optical sensor, then use multiple mouse sensors to detect the additional movement.

I think a disk size of 60 cm (diameter) could be possible given 4 sensors. Any change in one of their values is likely to indicate a tick movement. The sensors only need to be loaded on one side as you're only tracking from one horizon to another.

Thinking about pete_l's point about resolution not accuracy - the ADNS does about 800 pixels in something like a 28x28 images processed in realtime - however what is not clear is if it's interpolating. However it's worth scaling up and having a go with the EQ6 simply rotating the disk and the sensor monitoring the change.

[NickK]

Also for the microcontroller I have two SRV1 blackfin modules. The BF does about 500MIPS with DSP and each BF module has 4MB flash and 32MB SDRAM.

Looking at this http://en.wikipedia.org/wiki/Direct_torque_control makes me think this would be enough to poll multiple SPI devices and then use an internal map table.

[Cath]

It would be nice to have an encoder do absolute position, but it all can also be reliably done with a relative position encoder.

With relative position a simpler quadrature encoder would do (2 digital patterns or 2 analogue sine wave pattern). Then base your position relative to a reference marker on a disk. It would mean when you first switch on the axis would first need to be moved to find the reference point. XY plotters, CNC machines, printers etc all do it this way and it's not a problem.

[NickK]

Interesting that the TDM system is accurate to 1/8th arc second.

[Cath]

The TDM apparently uses a Heidenhain ERN-480 encoder, the encoder has about 5000 steps per revolution, but it outputs I/Q type sine waves (not square wave I/Q) which the CPU samples and calculates sub-resolution that way.

The encoder apparently uses an optical grating ..

[NickK]

I'm thinking that the multi-ADNS sensor would, for a resolution would show definitive pattern of increments over time that would be constant for each revolution. Storing this pattern would allow reference - similar to the sine waves that could be mapped. The pattern would be different for each sensor and may not be unique but the pattern over a period of movement would be. So putting a couple of hall sensors in for reference points would allow a fixed reference.

I can see how it creates the I/Q sine waves. The slots presented to the photocells aren't all or nothing, but would present a number of slits or % of light giving a value.

[NickK]

This is going to take a back seat for a bit - buying a house so every little penny helps atm :/

The good news is the house as a garden and a garage.. which is likely to become (partially) astro centre as Sandrine will want my junk out of the house

[NickK]

Don M over at CN has a great mount that would work with the mouse encoder/radial direct drive as it would allow the required size.

I was thinking of having the mount box trailer mounted and up-rate the suspension with air to help take out some of the bumps etc.

[RogerTheDodger]

Another possible way is to use the interference of two patterns, digitize the analog quadrature signal to provide a much higher resolution than a basic digital encoder can produce.

I have built several like this for medical equipment. Cheap to make too.

[NickK]

thought of another way todo this with fiber optics. Might be possible to use a single LED on the side of a fiber at the location and have a known length.. then use interference between the changing length to measure the change..

[NickK]

There's a few ideas that could be used to beef up the encoder.

1. Wavelength phase change - splitting a coherent beam into two, then varying the distance on one length. The resulting phase difference (just like the optical mirror tests) give a wave length accuracy. Thing is it's too accurate for most mechanical things. You could use a set of Bragg grating to analyse the phase difference, or simply watch the interference pattern on a small sensor.

2. Light based square wave phase change - producing a square wave (on/off) and doing the same as the wave length however the square wave means it's easier todo but slightly lower resolution. You can then see the difference between the two square waves. Add multiple sets of square waves to provide a course and fine count trigger.

3. Electrical "variable resistor" with square wave signal - use a variable resistor with a square wave to provide a varying path, then look at the electrical phase difference.

Another idea is to use a side-lit (ie leaky) optic fiber as the varying point. if the light hits the ITT angle (or at least some portion) then this would work. A non-leaky optic fiber of a known length is used to provide a reference phase and they both use the same coherent light source.

The idea is that the leaky optic follows the circumference of the fixed axis and picks up the light pushed in by the movement by the light attached to the moving axis. The sealed optic path then simply connects end-to-end.

Someone has tried this side light and said it didn't work but how it's lit is the good thing.

You could use a bragg grating in the fiber to provide a pulse count by reflection..

Also as a DIY mechanism, it's possible to sense change by pointing the two ends of the fiber into a mouse sensor. The change in the interference would then be picked up as a count change.

[NickK]

Hmm, been thinking about this a little more. 

I think I have a way to bring this down to 8-13 cm radius.. which should fit the EQ6 RA & DEC axis. I still need to experiment but I have also thought of a way to cope with slews too

[perfrej]

Here's a thought for you...

Whenever you try to mount something as accurate as millions of ticks per rev you are faced with the problem of aligning it perfectly with the axis. If it is, in any way, off from perfectly centered with the axis it is going to have errors that need to be mitigated in some way.

One way is to mount the encoder as well as you can, which for a millions encoder is to micrometer scale if it is to be perfect, and then model the assembly (axis plus encoder) with a proper renishaw rig. The results can be used to mitigate the mounting error.

Just a thought...

/per

[NickK]

First thing is to build a proof of concept  I've asked two mods if discussing what I have in mind is allowed and the response is positive.

I'll have to report back my findings..

[OzDave]

Why would it not be allowed?

Sent from my iPhone using Tapatalk - now Free

[NickK]

Why would it not be allowed?

I wanted to check if there was a point about discussing higher power devices on SGL.. 

[Horwig]

I wanted to check if there was a point about discussing higher power devices on SGL.. 

Death rays?