Category Archives: AutoScope

AutoScope : Part 5 : Displays

Dr.  Dan Kott is a task master. At this point I’ve got steppers working, IR and Joystick Control, and have figured out our 3D printed part issues (at least when it comes to gears). In about a week. But, what does he have, more!

Take this with a grain of salt, because I consider Dan a friend. This is an inspiring person. A Renaissance Man in the truest sense. Tell me how many 85+ year olds are have more Raspberry Pis and Arduinos than most people have TVs. I’ve joked with him that his living room has enough computing power to send mankind to the moon. But, the moon would not be good enough for him — Mars, at least.

So, Dan wanted a display. I wanted to go with a large scale LCD display, but — I don’t have enough free pins on the microcontroller. (Most basic LCDs require at least 6 pins, and I’m using a cheapie Nano — which is busy doing motor control and IR remotes.)

And so I hunted down a cheap I2C (serial) OLED display on Amazon. These are pretty amazing devices, since you just need two pins to drive them (clock and data), plus power. Horray! A display that uses fewer pins.


Oh, but so small! Here it is next to a larger sized LCD display:

AutoScope_DisplaysAnd can you guess what problem I had? Not enough I/O pins? No, I went with a serial display to avoid that. But, the library size!

LadyAda has created an excellent OLED library for this type of display. But, when I try to compile — not enough memory. At first I was going to “slim down” her library. But I gave up. Instead, as a good programmer does, s/he finds an optimized version of the code.

Now, don’t get me wrong, Limor’s library is excellent. But I didn’t need graphics. I just needed text. And found (on github, again) a basic library called SSD1306Ascii. The SSD part is the display driver chip. The Ascii tells us that it only displays ASCII text (letters/numbers/basic characters).

With this slimmed down library I was able to compile and load the code onto my Arduino Nano board and get things running. With the remote, I can even enter direct coordinates:


Next up: improving the motor mounts




AutoScope : Part 4 : Manual Controls

Based on the examples provided by Brainy Bits, we started with controlling the motors with an analog joystick. These are really cool devices that work nicely with any microcontrollers (PIC, Arduino, Propeller, Pi, whatever).


The added bonus? The Geek Mom automated Etch-A-Sketch project already included excellent code for “normalizing” the joystick input. If you are using one of these joysticks with Arduino, get her code. What it does is translates the X/Y into values from -1 to +1. And ignores random centered values. No more converting from 0-1023 (Arduino analog values). No more complicated code. She has figured that out already. Did I say I liked her code? Well, I love it.

For a while I had the scope moving around happily with the joystick. And, it’s pretty awesome to see the scope move around using this little thumbstick.

But — now I needed to add features. Like entering coordinates. Like starting and stopping. Like taking photos. Buttons. And guess what? With the “old school” stepper controllers I need 4 I/O pins per motor — so just X and Y take 8. Want to automate focus? That’s another four. And the joystick takes X/Y/Button just on it’s own.

And so it was time to say goodbye to the joystick.

Fortunately, I remembered that I had purchased a cheap IR remote and Receiver from Adafruit — about 5 years ago. I never got to that project, but look at the remote — it has exactly what I needed:

AutoScope_IR_ControlArrows! Start/Stop! Setup! Numbers! Everything I need.

And, the best part, I could get all those commands through just one data pin! So, goodbye lovely joystick, hello IR remote.

AutoScope_IRSetupSo, I got back into the code. And ripped out all the beautiful joystick logic (sorry!) and replaced it with IR logic. Which requires a library.

Of course, there are a ton of IR libraries out there. There are the ones written by Limor Fried (Lady Ada), there are super powerful one written by Ken Shirriff. But, guess what happened?

Memory happened. As I add libraries, the memory constraints on the Arduino Nano became tighter and tighter. Ken’s library did everything I needed — and more — but was pushing my memory limits (remember: I still need to support a display, and maybe internet connectivity).

An aside: This is one of the reasons why I love working with microcontrollers — they limit you. In current development tools, you just throw more servers at a problem. What used to be solved with a 2K program is now in a 2Gb deployment package. And that’s crazy. It allows you to be sloppy, instead of really thinking through a solution. We landed men on the moon with less computing power than your pocket calculator (which has been replaced with a super computer — i.e. your telephone).

And so I searched and found a slimmed down version of Ken’s IR library. In a nutshell, it removes all the transmit code (which I don’t need) and the remote-specific code (ex. Sony, Panasonic, Sanyo, etc). I didn’t need that code since I have a no-name remote and had to map everything manually anyway.

So more trial and error, cleaning up code, and  I was able to control our scope with an IR remote (one data pin!). And can now handle things like direct coordinate entry, automatic homing, and more. And if my IR remote doesn’t have enough buttons? I find one with more.

Next: Displays



AutoScope : New Ideas from the Austin Maker Faire

One of the things I like about the Maker Faires is the feedback you get. You meet all sorts of interesting people. Some are technical, many are not — but love to see the stuff. And I love getting feedback and ideas from others.

Some ideas from teachers:

  • The Wet Slide problem. One teacher mentioned that viewing “pond life” (a drop of water) and showing it to the kids is a problem. By the time you’ve focused on an organism, it’s moved. The AutoScope would allow the teacher to project the slide onto a screen and then follow the critters with the remote control. Almost turns the process into a video game!
  • A Pathologist can use it as a teaching/test tool. For example, s/he locates items they want the students to find and identify. Students then take the slide and must find and tell the teach the coordinates/region they found the item in.

After telling the story the 100th time (trust me, I didn’t mind!) I realized that the scope could be used for remote analysis of slides. Let’s say you’re in the middle of nowhere, but have a microscope and this setup — you could allow a pathologist, or other physician, from anywhere in the world to control your scope. No need to ship or digitize the slides.

The cost factor was also a great turn-on. The commercial products, which include controlled stages and scanning, are just so expensive. The AutoScope allows not only schools access at a low price point, but also under-served communities, around the world.

While many were happy enough to look at a slide (the kids loved it) I found a number of older adults were very pleased with the project. The idea of making an expensive endeavor affordable. The ability for serving communities that can’t afford local pathologists. Helping people throughout the world. The reaction was really wonderful. I had more than one group walk away talking about how they could use this in their school or hospital. And, the most satisfying for me, people walking away thinking that the world is a better place — because there are folks out there making things to help humanity.

AutoScope : Part 2 : Gears

The original design for the microscope’s gears were nicely done. They had set screws and mounted securely to the knobs (from what we can tell from the video). Unfortunately, our microscope used different control knobs, so we couldn’t use the original 3D models.

So, Dan and I started from scratch. The most important item that Dan discovered, with the help of the Australian pathologist, was that the gears were designed in part in OpenSCAD using Parametric software.

OpenSCAD is an open source program which allows you to program 3D models. You write code instead of drawing objects. This is very handy when it comes to creating repeating objects — like gears. Let the math and the computer figure out the shapes needed for a given pitch/size.

I spent some time using the Parametric Pully program written by droftarts. It allows for a lot of nice things, like different gear profiles, retainers, set screws, and whatnot. In the end, I decided to go with a simple “idler” style.


Why an idler? Because it’s simple — just a ring of gears. At this stage I’m testing fit and the general idea — so I wanted something simple that would print quickly.

Since these gears will slide onto existing knobs — not motor shafts — the inside diameter is much larger than normal. For example, a NEMA17 Stepper Motor has a 5 mm shaft. I needed 26 and 30 mm!

OpenSCAD needed the ID — which I knew. But is also needed the number of teeth, which I didn’t want to guess at.

To help me figure out the problem, I put together a simple Excel sheet which calculates the Diameter and Number of Teeth given a tooth pitch (we’re using 2mm 2GT / GT2 belts) and tooth height (found on belt spec sheet — 0.75 mm).

It’s a simple calculation, where I had the number of teeth as a variable in the calculation. The idea was to get a ballpark idea of the gear size. Since I know that the OD needed to be at least 35mm, I could scan down the list and see how many teeth this would be.


Scanning down the list, I saw that anywhere from 50 to 70 teeth would work fine. I went with 60 because it’s a nice even number (60 minutes in an hour) and it was about the right size.

After plugging the numbers into OpenSCAD I was able to get two nice 3D models of my gears. There was a LOT of trial and error — my measurements of the knobs were exact, but 3D printers aren’t. And the knobs are slightly tapered, and I’m going for a friction fit. We’re talking 1/4 mm changes here — very small.

You’ll notice that I didn’t put a flange or retainer on the gears. (The retainer keeps the belt from slipping off.) Why? Because I printed one with a flange and the 3D printer created a bunch of supports. These support just get broken away when you clean up the part — BUT, they resulted in poorer quality gears. Instead, I’m printing the gears as one part and the retainers as the other parts. I can then glue them together. A little more work to assemble, but MUCH cleaner teeth on the gears.

Another important design decision I made was to make the gears a little oversized. Remember how my knobs are different sizes? Well, I didn’t want my gears to be. Why? Because then they’d have different ratios, making coding a bit trickier. And I already have enough to deal with. So, I sized everything to the larger knob. This resulted in two gears with exactly the same number of teeth (60), the same OD (about 38mm), but different IDs (about 26mm and 29mm).

The result is a pretty clean look.


Next up, controlling the steppers.



AutoScope : Part 1 : Overview

Dr. Dan Kott, a member of our local maker community, came to us with a problem. He had come across a microscope automation project created by a pathologist in Australia. Because of other commitments, the Australian doctor was unable to complete the project, and Dan wanted to complete it.

The idea is this: automate an inexpensive, but good quality, microscope. In other words, motorize the stage. Instead of manually moving knobs, motors and a microcontroller would take the place of your hands.

Why do this?

  1. You can make the microscope joystick controlled. This means you can remotely move around a slide. Very handy in a teaching situation where a video camera is connected to the microscope and the teacher is pointing at an overhead projection.
  2. Samples can be “marked up” for reference. An automated scope knows exactly where X/Y are on the sample slide. Therefore, a physician can find an element of interest, say a cancer, note it’s location, then give the slide and location to a student for review. (“See position 1456, 2345 — that’s an abnormal cell wall.”)
  3. Slides can be automatically scanned. The automated microscope setup means that an entire slide can be photographed in very high resolution. Those photos can be “stitched” together to make a single high resolution image.

While Dan had some videos of the rig, and copies of the 3D models for holding the motors, there were a number of challenges. These included:

  • Creating gears which would fit onto the existing knobs of a common series of microscope.
  • Determining which stepper motor controllers and software to use.
  • Choosing a microcontroller and writing code for it.
  • Getting the basic setup to work, so that additional functionality can be added.

First stop: the gears.