Optical mouse sensor as position feedback

First of all, I have to state I'm not exactly a fan of stepper motors.
They consume a lot of power, are noisy and expansive.
My idea is to modify a printer to use a "simple" geared DC motor plus position feedback.
However, I found the linear encoder stripes to cost FORTUNE. So does the linear encoder and encoder chip.
So, my idea:
- drive the belt for the printer using DC motor with no encoder
- use optical encoder from an old PC optical mouse to measure the movement of the belt itself

Today, even cheap Chinese mouse have >800 DPI resolution. 800DPI (if I'm not mistaken) results in 0.003mm resolution.
I doubt I'll be able to command the DC motor with such precision, but I should be able to achieve 1/10th of the resolution, getting very close to regular NEMA17 servo, while it'll be much cheaper and quieter.
The usage of the optical sensor on the belt will also compensate for any backlash, skipped steps, etc.
I think I'll need some ATtiny or some other chip to reliably control the feedback from the sensor and provide data to the DC motors (to unload the main RAMPS board) and I'll also need to modify the routines for the Repetier firmware that I like, but from my perspective, this can result in cheaper, more accurate and quieter technology.
Anyone already tried something similar?

Yes, but I found it very hard to connect to the motor such that the data was reliable. In the end bought a very cheap encoder on ebay

I think this idea may be workable, but I see a snag. With a mouse, it doesn't matter if the sensor occasionally fails to detect movement, or can't work out how much movement there has been, because the user will correct the position of the mouse pointer as necessary. But in a 3D printer, we need to be certain of exactly how much movement there has been. Will an optical mouse always signal the correct amount of movement? Maybe it will if you select a good target surface.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Sounds Like a good idea, people keep saying it's expensive to implement, but after seeing this video the other day I thought perhaps its time to start thinking more about rotary encoders.

Ahh..I now read that you want to measure the belt and not the motor..silly me That would work rather well I think, mounting is then easier and you can beter control the distance between the belt and the lens of the sensor. Besides the resolution you also have to check the max speed it can do. An ADNS-2051 will have max speed of 14 ips or ~355mm/s

I used the information from this link as a starting point [www.bidouille.org]

How many pulses per turn for this rotary encoder and how do you drive it from the belt ? What about holding a position, PID servos control ....

Well, to answer the questions:
1. Yes, I want to measure the belt - I am affraid of the slips and skips that can occure due to questionable PID control implementation - so to measure the target medium can be much more reliable than the source (motor shaft).
2. I am not sure what ips rating the mouses will have - I ordered 2 pcs from Aliexpress the same day I wrote this, they got shipped today, so it will take 3-4 weeks to get here. However, even 300mm/s is way more than I desire in the printer - I will target quiet operation, therefore also slower head speed. But as soon as I have the mouse, I'll identify the optical sensor and derive the measurable speeds from that.
3. PIDs are a problem. I played with 6 DC motors of various sizes, voltages and power last few days and all of them seem to respond to PWM signals in completely different manner. I am investigating how to measure the parameters. For now, I am able to detect the minimal movement current by sensing movement using optical sensor while increasing slowly the PWM signal - therefore I can identify the voltage required and by knowing the motor coil resistance, I can calculate the current. But that's as far as I got within last 3 days of try-and-fail tests (don't have that much time as I desire).
But there is a good progress on replacing servo with DC motor here: [www.thingiverse.com]

Preliminary results:

• Mouse obtained - I've got a cheap PS2/USB mouse from Aliexpress: PS/2 mouse
• Mouse contains the MX8733 sensor - capable of 800CPI (datasheet PDF)
• Connected to arduino - Report mode not working, so I had to switch to stream mode
• Printed enclosure jig for the PCB+optical sensor - current version works for X and Y, the one I printed only works for Y axis Thingiverse model
• Have got some very disappointing results

To describe the problem - as long as the belt is moving extremely slow, everything is fine and VERY precise (10ths of mm resolution no problem).
However, as soon as I start to move the belt just a bit faster, VERY large differences occur.
I did a simple test - draw a line on the belt, slowly moving it 5-10 times back and forth through the encoder - everything worked OK, when returned the line to initial position, the readout was within range of +-1.
But, as I started to move faster, even with just 5 movements back and forth, I ended up with -80 or +200 and similar - totally unpredictable results.
So I looked at the serial monitor to find out, what's going on - I can see the numbers reported. When moving slowly, the mouse sensor detects and reports movements within range 0-3 very accurately (including slowdowns and speed-ups). However, with fast movements, I got readouts of 0, then 1, then 5 and all of a sudden 17, jumping back to 2 and finally 0.
The 17 shows up just for 1-2 readouts, but it throws the results off by a magnitude in the end.
I tried to investigate if this has something to do with resolution enhancement tricks, lowering down the resolution and setting multiplier to 1:1, but the result is the same.

I'll re-print the new version of enclosure and I'll try to do the same tests for X axis, but I am afraid this is a "feature", not a bug in the optical sensor, therefore the whole endeavour will be useless
I hope at least someone else will read this and use it to not waste his/her time

Thanks for sharing!

What do you mean with "draw a line on the belt"?
Could it be because of the acceleration profile at higher printer speeds that it's missing "steps"?

PS Did you readout all directions? If the sensor is not 100% in line with the belt then you need to combine the x and y data

Edited 1 time(s). Last edit at 03/06/2016 06:57AM by Frans@France.

Quote
Frans@France
What do you mean with "draw a line on the belt"?

Well, I simply took a permanent marker and marked a line on the place the belt was entering the jig above.

Quote
Frans@France
Could it be because of the acceleration profile at higher printer speeds that it's missing "steps"?

Most probably. Unfortunately, it seems that it's a "feature" of the encoder - to provide somehow better feeling for the mouse user - as you move your hand faster, it tends to gradually increase the steps in random numbers to deliver "better feedback". For a mouse user, this feels like better responsiveness. For my purpose, it's total no-go.

Quote
Frans@France
PS Did you readout all directions? If the sensor is not 100% in line with the belt then you need to combine the x and y data

Yes, I did, but as the belt was moving through the jig above, the X direction was -1 to 1 tops, usually 0 until I pulled seriously hard to one side and back.

I had an mouse with an ADNS-2030 laying around so cut it up and connected it to a DUE. Measured the flat side of my Prusa I3 bed (y) belt

Tested it with pronterface with a motor speed of 3000mm/mm and 6000mm/min. Moved the bed 100mm, got the data from the mouse, moved the bed back, reset the mouse and did it again. 6 times for both speeds. Registered both x and y and used Pythagoras to calculate the length.

The mouse was set at 800cpi and checks were build in for overflow and LED Faults, none of those events were triggered. Weird thing is that using 800cpi and then translating the counts back to mm did not return 100mm(!) but ~ 58mm@3000mm/min and ~53mm@6000mm/min Which would mean ~470cpi The ADNS-2030 has an SQUAL register (Surface QUALity) which measures the number of features visible by the sensor in the frame, I will include that in the next version to see if the belt was maybe not correctly hovering over the mouse LED.

Results for 3000mm/min: maximum difference between values in x=2counts, max difference in y=30 counts. Using 800cpi that would relate to ~0,95mm.
Results for 6000mm/min: maximum difference between values in x=7counts, max difference in y=51 counts. Using 800cpi that would relate to ~1,63mm.

After these tests also had the bed step a few 0.1mm steps@6000mm/min. Sometimes I had to make 2 x 0.1 steps to have 1 count being registered but after 7 steps out en 7 steps in the mouse that started at (x,y) 0,0 came back to 0,0 from 0,5. Again this is also not 800cpi but more ~180cpi

The datasheet mentioned "Changing the frame rate results in changes in the maximum speed, acceleration limits, and dark surface performance." so maybe frame rate has to be adjust for this black timing belt.

Edited 2 time(s). Last edit at 03/06/2016 06:14PM by Frans@France.

Quote
rklauco

Quote
Frans@France
Could it be because of the acceleration profile at higher printer speeds that it's missing "steps"?

Most probably. Unfortunately, it seems that it's a "feature" of the encoder - to provide somehow better feeling for the mouse user - as you move your hand faster, it tends to gradually increase the steps in random numbers to deliver "better feedback". For a mouse user, this feels like better responsiveness. For my purpose, it's total no-go..

I thought that that normally is a OS mouse driver setting that the user can tune and the optical chip just reports counts.

As far as i know, mouse sensors are very sensitive to distance between lens and surface. Belt vibration may cause errors.

Belts are too glossy and have a solid color.

A ruler mounted (printed) on a rail and sensor on a carriage will work better (perhaps).

Colour the belt teeth then you have a colour contrast?

Ben

After looking into it in some more detail I think the problem is/was the led, the setting was "always on" but despite that the led reaches full intensity only after registering the first movements. When I have some time I will re-route the power for the led making sure it's always full on and redo the test.

This won't work. It's a known issue with the mouse firmware to use some sort of "acceleration" technique and screw up with the reported values. The classical ball mouse, with optical encoders on two axis does exactly the same.
[youtu.be]

you could buy a fancy gaming mouse, logitech has some sensors that have absolutely 0 acceleration and a bunch of fancy testing equipment to prove it

That would actually defeat the purpose of a cheap solution It's gonna be cheaper to buy the optical strip and sensor as used in 2D printers then.

exactly, that's the best solution. But let's not forget about the Mechaduino ... really clever thing, not yet on the market, but it won't take long.

While I like the project, the price seems outrageous for me
I thing I would be able to do the same with misan's DC servo code...

Quote
rklauco
It's gonna be cheaper to buy the optical strip and sensor as used in 2D printers then.

I really want to see people rig up a 3d printer with some of these strips and use cheap DC motors for x/y, once the patent expires i'm sure there will be pre-builts sold this way.

---

If you need some help, or don't understand what I just said, feel free to send me a PM anytime

Printer: Prusa i3, 2 E3D v6 Hotends, Arduino + RAMPS 1.4 with a Bypassed 5V Regulator, 400w Insignia ATX PSU, Custom Designed Bowden Extruders

You mean like this?

Neat, wonder how how involved setting up those encoders in firmware is..

Quote
DaGameFace
Neat, wonder how how involved setting up those encoders in firmware is..

You don't even have to touch the firmware. The way to do it (and how that guy in the video done it) is to offload the encoder reading / motor control to external MCU's. You need three of them, one per axis. Program it to take step/dir inputs and that's all. If your encoder gives you 20.000 pulses per revolution, you adjust your firmware like you would be having steppers with 20.000 steps / rev. There will be issues like smoothing out jerkiness and oscillations, but that's the principle.

Yeah, correct.
But I went another way.
I measured how many pulses I need for 100mm movement and adjusted the firmware steps/mm values accordingly.
Problem for the tiny MCU (I used 3 ATtiny85s in the video) is that it is not fast enough to count the high-frequency incoming pulses from both the electronics and the motor.
But for small applications such as the 3D printer in my video (modification of ToyRep printer), this works great.

Quote
rklauco
Yeah, correct.
But I went another way.
I measured how many pulses I need for 100mm movement and adjusted the firmware steps/mm values accordingly.
Problem for the tiny MCU (I used 3 ATtiny85s in the video) is that it is not fast enough to count the high-frequency incoming pulses from both the electronics and the motor.
But for small applications such as the 3D printer in my video (modification of ToyRep printer), this works great.

Exactly what I said. Those number of pulses for 100mm movement come from your encoder resolution. Of course you have to compute it for a specific travel speed, this is how all 3d printer controller firmware works, you got my point Have you tried with Atmega MCU's as well ? Like an Arduino Nano or Mini. They should have enough power to do the computations if you use one for each axis.

None of the other Atmel processors (ATmega328) have enough punch to count 2 optical encoders and at the same time 2 step/direction inputs.
And you will still need 3 as you have 3 axes.
The ATtiny85 seems like the best choice here - it has just enough pins to do it and it is fast enough to do it for one axe.
So I went this way.
One other driver here was the price - less than $1 for the chip, no need for crystals or anything

Quote
MechaBits
Sounds Like a good idea, people keep saying it's expensive to implement, but after seeing this video the other day I thought perhaps its time to start thinking more about rotary encoders.

Hi! I'm posting about 10 months too late but I watched your video. If you made that video, you did a really good job explaining IR encoders.

In the video, I saw a mechanical encoder used in one of the demonstrations. If you are interested in making an IR version capable of direction & speed, I have OpenSCAD and STL files available on Thingiverse here: http://www.thingiverse.com/thing:1904929.

FYI, plastic does not seem to block IR light so you'll need to paint it. For you to make your own encoder circuit, the main components that you'll need are two photodiodes and an IR LED. You can find an explanation and a video here: http://www.filamentroller.com/how-it-works/.

IR is more flexible on alignment than mechanical encoders, and ofcourse it imparts no friction on whatever you're trying to measure. Using the free OpenSCAD files on the Thingiverse (see versions 1-3) you can print encoder wheels of differing resolution (I have tested upto 160-position (40-slot) wheels up there).

=)

Quote
rklauco
You mean like this?

That is an extremely cool video! And for $10/unit. Wow...

Thanks We finalized our movement and now I am working on PrintTable printer, but I'll get back to this for sure. I love the smoothness and quietness of the printer. Lost a lot of time on trying to do DC-powered extruder (no success)...