Cheapo mouse as shaft encoder

Nophead expected that his build quality could be realized on a Darwin. Obviously this is very exciting. What he said was probably still needed was:
1. a shaft encoder for better filament feed control
2. precise temperature management
3. minimal comms delay

All three points are being solved, as we speak. As an alternative to an specialized optical or magnetic encoder (which cannot be bought anywhere) there is of course the mouse... computer mouse, that is. Besides having enought DPI nowadays and being very cheap (~5 euro or 0 if you have an old one somewhere), I think that interfacing with it shouldn't be that hard. USB mice are usually PS/2 compatible. PS/2 is pretty simple for a PIC to interpret (wires: clock, data, Vcc, ground, etc.). After a few searches, I came across this:
[imakeprojects.com]

If a simple 16F6x8A can do it, the Arduino should also be able to do it (I guess, I've only got experience in more powerful PICs). The most obvious problem is the I/O pin requirement... (could be 1 pin if a dedicated PCB is designed).

If a PCB is designed for this (could be quite simple) it could be with a USB socket reducing the need for a USB to PS/2 adapter. But the PCB could have a spot for an optional PS/2 connector as well. When I have more time I can start with this, but I just wanted to get the idea out there. I'd really enjoy it if someone else picks this up before I get the time...

The mouse, or relevant part from it, could be stripped from its housing (or not). There are many creative ways to do this, so I will not suggest one yet.

A wireless mouse could also limit the extra wiring needed, but it's all a matter of choice. Perhaps you could also use the mouse buttons (including wheel) to gain 3+ I/O pins instead of losing (probably) two.

Of course this could also be used for X/Y/Z encoders, but for the extruder it's most important...

What do you guys think?

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

I agree that encoder feedback on the extruder will need to be added at some point as we try to increase our printing accuracy. Does Nophead currently have this enabled? I don't seem to recall reading about him using an encoder, but I have certainly overlooked important things before!

What RPM does the extruder motor generally turn at? I know that Adrian designed a fringe-wheel sort've thing at some point, but I'm not sure if it actually has the necessary resolution to accurately control the angular speed of the motor. In the robotics applications I work with we generally look for something on the order of 10,000 ticks/second to provide feedback for PID loops on our drive wheels. The extruder may not need this kind of resolution, but more is almost always better (I say almost because you can over-saturate your IO pins and/or processor if you are getting ticks too frequently!).

its even easier than that...

i'm currently working and experimenting with a Magnetic Rotary Encoder board that is soon to be released. Among other things, it offers quadrature outputs. Its also very precise and awesome.

Since quadrature is a standard method of interfacing with encoders, it would be very simple to take an encoder out of an old mouse, and integrate it to your extruder. then you'd just wire the 2 quadrature pins to your arduino (and update the quadrature steps init variable) and be good to go.

of course if you want the easy route, the MRE board will be available as a kit and as raw PCBs in a couple weeks (i get them next week, will document and such as well.) the only downside is that the main chip is surface mount. i'm looking into getting the board manufactured.

there is an experimental GCode intepreter for the arduino that i'm working on that reads the data from this encoder and controls the extruder motor precisely. i'll have more details on it as i perfect the code and such.

Kyle,
Yes I use my optical encoder which has 204 quadrature pulses per revolution. I just tell my s/w what size filament I want, and at what speed, and it does the rest. The problem with open loop is not only does it require trial and error to set up, but the speed varies with motor temperature and spring tension, etc.

The motor rotates at about 60 RPM max.

On my Darwin I intend to try eD's fringe wheel with two opto's. I think it will have enough resolution but I may have to implement full PID instead of the P algorithm I use at the moment.

I will also investigate using a small stepper and some gears.

---

[www.hydraraptor.blogspot.com]

That's good news, Zach, I look forward to trying that!

There's no need to use quadrature if you don't need to know the direction (which is already determined by the direction current). If you happen to have a quadrature signal you will increase resolution which is of course nice. But otherwise, one raw pin from an old mouse is enough. But perhaps you can solder a lead somewhere on the mouse where the signal is already cleaned?

But for this system, you would need an old-fashioned ball mouse (not one with CCD), which will not remain available for long (they're not sold anymore for a while)...

A USB / PS/2 mouse seems to me a pretty complete solution as an encoder.

Being able to use any USB mouse would still be nice, and reduce electro waste, reduce th need for a magnetic rotary encoder. I agree that it's good to have this magnetic rotary encoder based system, since it does what it should do and no more (and it's standardized).

Another Idea: using an opto and a printed gradient on an overhead-sheet (is transparancy the British equivalent?). If you use A/D you could get quite some resolution (10 bit: 2^10 = 1024 steps)... Also, it would require only an optoswitch, one I/O pin and one two resistors (no specialized chips). I don't know, but I'm afraid that aliassing effects of the printer resolution might ruin things... Of course, there are many roads that lead to rome.

Then again, I like choice.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

If you don't use quadrature you can get errors when the shaft rotates backwards, which it can do with the flexible drive as it unwinds a bit when the power is removed.

You also get an error if the motor stops with the opto half obscured. You can then get a signal that dithers with vibration and backlash.

Quadrature solves these problems.

---

[www.hydraraptor.blogspot.com]

nophead, I hadn't thought of it that vibration could spoil the signal, but it's acutally pretty obvious.

I found this project which interfaces the Arduino with the DSP. Besides X,Y movement coordinates, the ADNS-2051 allows you to use read 16x16 images. This makes it possible to make a scanner. I know it goes beyond what is needed for speed control, but perhaps (with the appropriate lens) it allows for a 3D scanning option if you place it on the X carriage. The 16x16 resolution is low, but if you combine it with the cartesian bot and take many shots, it might be alright.

[www.bidouille.org]

It would also be fun (not useful at all) to just make your mouse have a blue/green led instead of plain vanilla red (well, okay, vanilla yet is another color)

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Hi Eric,

... for a bot-project we used single optical-mouse-chips with an Atmega-Controller programmed in C and Java: [www.ctbot.de] (more images here, in my gallery: [www.ctbot.de])

It's nearly the same solution, but our chip has a 19x19-sensor and too was 'misused' as camera: [www.ctbot.de]

With a normal webcam you have much more resolution and simpler interfacing, but for singlechip-microcontrollers the 'mouse-camera' with the serial communication is easier to adapt ...

Viktor

Yeah Viktor, I found your comment just after making this duplicate thread... I didn't have time to look into it yet and couldn't resist posting my own idea and especially my view of the advantages above 'specialized encoders'. When I heard nohead say that his print quality was due to the shaft encoder, I wanted to find and discuss a way for everyone to have a shaft encoder. Everyone has some mice laying around. I should've reposted to my earlier thread though.

At least we have multiple options now, and even arduino code (see link in prev. post)

B.t.w. Vik, I'm confused about your nationality, you are from New Zealand right? I'm seeing some links to German sites, products and .de in your e-mail address...

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

ErikDeBruijn Wrote:
-------------------------------------------------------

> B.t.w. Vik, I'm confused about your nationality,
> you are from New Zealand right? I'm seeing some
> links to German sites, products and .de in your
> e-mail address...

I think that you are confusing Vik Olivier, a core team member who is living in New Zealand with Viktor who seems to be either from Germany or at least has strong affinities for that country.

... yep, i'm Viktor from Germany in respect to Vik from New Zealand

Viktor

I was just musing to myself - is it better to use a stepper or a high torque DC brushless motor with an encoder in terms of precision?

Instead of outputting PWM you receive it as an input, is backlash a problem this way?

J.

Hi John,

i think with the "tick and forget"-method moving the stepper is much easier then the close-loop with an encoder (when you didn't stall the stepper)

In my CNC-mill i have motors with 200 steps per turn and a threading with 5mm per turn, so i have a resolution of 25 microns per full-step.

My controller drives with half-step, so the resolution halfs to 12,5 microns.

Now i'm on assembling a second controller with 1/256-microstep-drivers, what means i can enhance the resolution down to 0,1 micron or 100 nanometers with the same motors!

In reality it's not so simple, as the accuracy of the feedings and bearings is in the range of 1 to 2 microns and the rigidity of the mechanic isn't so exorbitant, so for milling the microstepping shouldn't be more then 1/32.

But for some different mechanical setups for 3D-printing and laser-curing i want to try with highest accuracy and test the results

Viktor

Ok, it's hard for me to concentrate on things I don't already know, so these questions might sound a little silly.
I would love to get the quality that Nophead is getting and that's just what he has so far.
1. comm delay. I saw that problem mentioned in the buffer mentioned in the blog as being basically gone using a decent buffer. yay
2. Temperature management. I've seen the host sofware reading the temp way too slow and I've heard that it jumps too many numbers coding before it displays the next number.
3. shaft encoding. This is where I am lost. I can understand doing this for axis control and making a cheaper "stepper" but what is the reason to do this on the filament feeder. If it's just to make sure it's turning, then the resolution doesn't have to be as high as you all are mentioning. Not only that, but the feed mechanism could be redesigned to give a constant pressure and combine that with the piano wire nozzle idea and it should work out just as well with less effort.
Unless there is a reason I don't know about.



As you can see, I've tried getting past the problems the current head has with the breaking wire shaft and the metal eating away at the filament. I'm just using lego wheels and gears connected to the DC motor (not pictured). This way the rubber and the wheels will push the filament forward but once it backs up in the nozzle or is stopped from the piano fire fix then the tires will just slip on the filament without causing any damage to the head or putting too much force on the filament.

If that's all there is to the encoder issue, please let me know.

I use the shaft encoder to make the motor run at a constant, accurate speed. Without it the speed of a DC motor depends on its load, the temperature of its windings, how much oil, etc.

Also it makes it much easier to set up the machine. If I want filament anywhere between 0.5mm and 1mm all I do is tell the firmware to extrude the correct volume of plastic to make that happen. Without the shaft encoder it becomes trial an error.

When I saw Adrian and Vik's Darwins at Cheltenham they were having problems with the filament jambing due to the filament diameter varying a bit. I think my machine copes much better because if it finds it heavy going it just ups the power to compensate.

---

[www.hydraraptor.blogspot.com]

Hi Dylan,

Adrian and Vik tried made a pinch wheel extruder prototype. But according to Vik, in the "The extruder motor and changes needed in extruder robustness" thread at:
[forums.reprap.org]

"We tried pinch wheels in the MkI design. See the Wiki for why that didn't work."

The link to the document he was referring to is:
[staff.bath.ac.uk]

Hopefully you'll have better luck

One of the problems they ran into is that the pinch wheels did not push the slippery plastic enough. A few speculative solutions include, use pinch wheels with very good grip, use coarse grinding wheels for the pinch wheels to dig into the plastic, put magnets on the pinch wheels to pull them together without putting extra force on the bearings.

Another problem they ran into is that when the extruder was off for a long time, the pinch wheels would slowly dig in to the plastic. A few speculative solutions include, before shutting down the extruder reverse the filament so that only the top pinch wheels are holding the filament, and put weak springs on the top wheels while still having strong springs on the bottom wheels. Another possibility is to make a hinge mechanism that pinches the wheels together only when they are turning forward. A more complicated possibility is to use a solenoid in series with the motor to pinch the wheels when power is applied to the motor.

By the way, does your filament winch work now? If so, roughly how much force can it apply?

I think I see the problem with the initial pinch wheel system. Smooth metal wheels won't allow for any play in the size of the filament. I never even thought of that. I am using rubber wheels that will slip when there is too much resistance in the base of the heater barrel but rubber has a fairly high friction to begin with, so it should keep a decent amount of force applied.
Using the grinding wheels for extra grip like you mentioned would be about the same (imo) as the current system of the drive screw.

I just did my first test on my design (without the heater barrel on) and it works fantastically. I could hold the filament back by hand, but I had to use a decent amount of force to do so, and when I did, I could hear the extra strain on the motor (means I have a high friction level), but the wheels still slowly turned as to not burn out the motor completely. I think there was too much friction on the wheels for how bad the motor sounded, so I am melting a little groove in the wheels to give it just a little more space and then I'll retry it. I also just put on my nichrome and will probably do a full test in a day or two.
For what's out there at the moment, I still think a good pinch wheel system would work, we all know how bad that wire breaks on the mk2. Nophead mentioned a 20 hour lifespan.


I do think there is a better way still, but I'm not too sure how to implement the nitty gritty of it just yet. The pinch wheels described on the site and the current screw would both turn faster than it would feed the filament even with the encoder you wouldn't be able to tell if the filament is actually moving, just how much force is being applied to the motor.
What we really need is a feed system that would only move the filament as needed. Such as a slow speed, medium torque, high friction system. If that doesn't make sense, an example would be to use grinding wheels like what was mentioned, but make it slow enough that one turn of the wheel would only move the filament forward the same circumference of the wheel per rotation.


The hopper and barrier screw idea might work best once the head distrabution problems are worked out. There also shouldn't be too much extra work converting a "plastic shredder, filament extruder" to make granules instead (the same way they make bread or candy in factories). The hard part about this is trying to keep a consistent pressure in the extruder barrel. I suppose for this an encoder attached to the shaft to measure speed vs power input (like described for the current system) should be able to work the same way if a reservoir were used.
This is just a mockup visual of this idea:


This way a feed system could be used for the granules and it would only release a few granules to drop down the hopper when the pressure started to drop in the chamber. This would mean a fairly consistent pressure and feed rate. It would also keep from melting the supply of granules like what happened to Adrian (http://reprap.org/bin/view/Main/GranuleExtruder).

"Lose the worm drive - direct would be better and simpler" I don't know what Adrian meant by this. There needs to be some method of applying pressure.

Anyway, my brain is shutting off for the night, but I think I got a few good ideas out. A granule extruder and filament extruder seem to be the only 2 options and these are the ideas that I think are feasable solutions.

~Dylan

I am working on a pinch wheel design . . .
my current thoughts are to address the drawback of th pinch wheels tried so far pinching the SIDE of the filament (and causing 'dents') as the point of contact is a point.
The current feed screw design drives along the axis of the filament but has high friction loading - the filament slide in its saddle and the threads sliding across the filament.
My idea is to roll the drive screw around the filament like planets in a planetary gearbox. 3 axial rollers each with a long, axial contact and balanced pressure.
I have mocked up a test (using 3 off M10 bolts in a plastic plane bore housing) - it feeds a threaded bolt beautifully, but a plain plastic rod just goes round - the 'planet' bolt threads grip, but dont form threads in the filament in a way that makes it feed.
My next development is a little more complicated - same basic idea, but each of the planet rollers is canted over slightly. THey cannot run in a housing as this would then proceed in the opporsite direction, but the rollers can have end bearings onto a 'cage' which then takes the axial thrust.
Ok, so the contact is no longer fully axial but the rollers could be slightly concave to compensate.
for a 3mm filament, the rollers can be around 10mm diamater allowing plenty of room for bearings etc and no teeny high precision bits.
Radial pressure could be applied by using spiral type circlips (acting as the housing, but running in shallow groves in the rollers and thus prevented from shifting axially)

I intend to attampt a build as part of my RepStrap, currently in planning

Dylan Wrote:
-------------------------------------------------------



> This way a feed system could be used for the
> granules and it would only release a few granules
> to drop down the hopper when the pressure started
> to drop in the chamber. This would mean a fairly
> consistent pressure and feed rate. It would also
> keep from melting the supply of granules like what
> happened to Adrian


Dylan at al,

I like the idea of using a screw/auger to feed pellets into an extruder, but I wonder whether this idea would suffer from air bubbles in the extruded plastic (probably *not* a good thing.) It seems to me that one virtue of using 3 mm filament is that it's solid, and carries no air with it into the melt zone. Is entrained air bubbles not a problem (only a red-herring in my mind?) I seem to recall that commercial injection-molding machines use some sort of auger feed. Could anybody reading who knows how they keep air bubbles out of the melt please describe how they do that?

Thanks,

-- Larry Pfeffer
ursine at gmail d0t c0m

I'm not too sure what the factories do for this, but from a physics standpoint it shouldn't have any bubbles anyway. If you only put a few pellets in at a time, they would melt and change shape, sink to the bottom, slide forward and add to the goo at the end. The air (if any) would rise to the top of the melten plastic and works it's way back on the auger as the pressure changes.
If you dump a lot of pellets at the same time and they actually melt fast enough to cover the auger shaft top to bottom, any air actually trapped would be able to push back against the molten plastic because it's to pliable.

There might be more to it than this, but I did pretty well with physics in school and it makes sense to me this way.
I guess we might not know if we need more until we try.

Pellet feeders - I did some googling last month and found that the barrels have vents in htem to vent air. They seem to rely on the viscosity and motion of the plastic to only let the air out - the vents are tangential in the barrel.
Also the screw has several sections of differing pitch so pressure along the barrel is varied. The melt is performed in the screw, not after it.
(tried looking for the pages again but cant find them)

Back on topic:

I hooked up a PS/2 mouse to the Arduino using the Library Wade pointed me to [www.arduino.cc]. This kind of works. I got what seems like proper feedback on the serial port. I'll try a USB mouse to see if it can default to PS/2 protocol if no higher protocol is negotiated. This should work with any mouse. I guess we're one step closer to using scrap stuff.

I will try to hook it to a geared motor and try speed control, but I will be very busy with other things next weeks.

Running this code makes the arduino show the signed integers for X and Y movement. The buttons could make up for the loss of two I/O pins (data and clock). I will try to confirm that direct USB mice will also switch back to PS/2 compatibility mode. This uses the same clock/data wiring and the adapters are passive.

Would also be nice to position the RepRap cartesian bot with a mouse
I'll do that when I'm further progressed with the Gen 2 electronics (switching from gen 1 right now).

This is the example code that worked for me:

#include

/*
* an arduino sketch to interface with a ps/2 mouse.
* Also uses serial protocol to talk back to the host
* and report what it finds.
*/

/*
* Pin 5 is the mouse data pin, pin 6 is the clock pin
* Feel free to use whatever pins are convenient.
*/
PS2 mouse(6, 5);

/*
* initialize the mouse. Reset it, and place it into remote
* mode, so we can get the encoder data on demand.
*/
void mouse_init()
{
mouse.write(0xff); // reset
mouse.read(); // ack byte
mouse.read(); // blank */
mouse.read(); // blank */
mouse.write(0xf0); // remote mode
mouse.read(); // ack
delayMicroseconds(100);
}

void setup()
{
Serial.begin(9600);
mouse_init();
}

/*
* get a reading from the mouse and report it back to the
* host via the serial line.
*/
void loop()
{
char mstat;
char mx;
char my;

/* get a reading from the mouse */
mouse.write(0xeb); // give me data!
mouse.read(); // ignore ack
mstat = mouse.read();
mx = mouse.read();
my = mouse.read();

/* send the data back up */
Serial.print(mstat, BIN);
Serial.print("\tX=");
Serial.print(mx, DEC);
Serial.print("\tY=");
Serial.print(my, DEC);
Serial.println();
// delay(20); /* twiddle */
}

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

I've read a small article on some equal subject almost a year ago.
alberto ricci bitti (very smart guy indeed) mentioned to use a mouse as a relative x-y encoder, because that is exactly what it is
[www.riccibitti.com]

Would be nice if we could use a mouse not only to have the shaft encoded but to have the repetitions of the RepRap's movements checked too.

'sid

You could check the repeatable movements though the endstop sensors. You just move around a lot in safe ranges (not near the end all the time) and keep count of movements to know the position. If the endstop suddenly appears closer or farther away, you know that there's been a skip.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Sure, but you have to come close to the endstop to know about.

with a mouse-encoder you know in realtime that there's something wrong and you could eventually adjust the position immediately to not ruin the reprapped part
without having an additional unneeded movement.

'sid

I found this whilst googling for some stuff with the Arduino and SDIO.

[www.martijnthe.nl]

This guy us using the SDIO capabilities of an arduino to read the optical gear inside an optical mouse.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

... here - [www.ctbot.de] - and here (esp. the images at bottom): - [www.ctbot.de] - we made some images with a single mouse-camera-sensor for measuring the exact position and movement of the bot over a marked surface.

I have the complete ct-bot with the source-code, the especial 'mouse-camera'-program and a second mouse-sensor-PCB, but it would be some work to extract the part from the source.

Maybe someone is interested in going in? Then i could support you with all the information and some parts maybe ...

Viktor

Erik, I took it that one step further and slapped a PS2 mouse encoder wheel on the 2nd shaft of my GM3, used polymorph plastic to stick on the mouse detector circuit board, and wired it to a second Arduino that I had kicking around. Check out the photo.


So, I get some nice output from that PS2 library as I spin up my extruder, but there's a few issues. Number one is that I now have to figure out how to code this into the Arduino firmware, and I'm no expert coder. But, even I can see some issues here:

I set the mouse hardware to its highest resolution, and free running my GM3 only gave me outputs in the range of 0 to 12 at an update rate of several times per second. Sorry, I haven't worked out all the scaling factors yet.

At first glance that seems like plenty of resolution for setting a general extrusion speed, but I don't think it's going to fix my lumpy extrude problems - I'm going to need to get the timing on individual quadrature pulses for that. Which won't be easy, since I'm going from quadrature to RS232 to the Arduino, so there's some delay and loss of timing resolution.

It was cheap though. Mechanical mice are easy to find now, although they are going out of style. Think I'll try one of Zach's new encoder boards too; they look like a nicer and more robust solution.

Wade

Now that you've got the hardware all set up it might be worth it to try to use quadrature directly. IIRC the quadrature should be usable and there might even be code for it, but perhaps Zach can give us a hand. I'll definitly build the hardware then. Too bad I don't have the axis of my GM3 protruding to both sides. But maybe there's a way around that.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

I think I would be inclined to demount the opto electronics from the board and reconstitute them on stripboard or some such. To see if i could get them to work with the slotted wheel without all the PS2 gubbins etc.

Quadrature is easier to work with than you think.

AKA47

---

Necessity hopefully becomes the absentee parent of successfully invented children.