This was originally going to be a comment response to Tim’s blog entry, Scanlime’s Perler Bead Hopper Sorting Suggestion:
I was looking at Scanlime’s 3D Printed Vibrating Perler Bead Hopper: and I was thinking how best to sort out the different color beads. I thought that if scanlime used one main hopper with the color sensor ([photo] & [sparkfun]) and one hopper for each color. There would need to be a way to put the bead in the correct hopper for each color. I was thinking that a rail and belt system like the X (maybe Y I don’t know) of a Reprap Mendel to move the main hopper/color sensor to the correct hopper. There would also need to be a tilting platform to drop the bead into the correct hopper for that color. I decided to make a 3d layout of my ideas.
But then it started to get longer, then I wanted to include diagrams… so here we are 🙂
Good idea, Tim, and thanks for the writeup. I had thought about various ways of sorting the beads out per-color. This method looks like it’d be good at storing larger bulks of colored beads. Originally, I’d been thinking about using a rotating magazine of cylinders that held vertically stacked beads. Here’s a crude pencil sketch of that idea. There would be some sort of gate mechanism to let one bead through at a time. One possibility is a rotating drum like the one I printed above. The other, shown in the sketch, is a scheme involving two alternating levers or hammers. One holds bead N, one holds bead N-1.
I might try one of these sorting approaches for a second revision of the robot. But for the first revision, I wanted to keep things simple. A minimum of moving parts, a minimum of things to go wrong. For example, what happens if you have a color in your hopper that never gets used in the design? Eventually that sorting bucket will overflow, and you need a way to handle that. Is there some other discard area that you use when the sorting bucket overflows? This all adds more complexity to the design.
I saw a different way to approach the problem. Instead of moving to a particular location on the build surface, then looking for a bead of the right color, I wanted to do the opposite. Get a bead, any bead. Figure out what color it is. Then do something with it. Looking at the problem this way, instead of searching for a particular bead, you’re searching for a place to store it. Maybe I’m just too big a computer nerd, but it starts to look like a storage or memory system to me.
The simplest solution would involve only three moving parts:
- A build surface, with some sort of X/Y motion
- The hopper with vibrating funnel
- A gate, drum, disk, or any other way of releasing a single bead at a time
With these parts, your build procedure looks like this:
- Turn on the vibration motor
- Wait until the color sensor detects a bead (Reflected light is above a set threshold)
- Turn off the vibration motor
- Based on the sensed color, find a location for the bead and move there. Preferably the closest location on the grid where that color bead is used. If we don’t need any more beads of that color, we can dump the bead on the floor.
- Use the gating mechanism to release a single bead.
My current plan is basically this, but with one small optimization. My gating mechanism is a 3D-printed disc that has a tapered shape which (I hope) will capture a single bead without jamming, even if the bead heights vary a little bit. The disc starts out in a centered position, directly below the vibrating hopper and directly above the color sensor. When we want to let a bead through, the disc rotates. The solid portion of the disc blocks the exit from the vibrating funnel, while the bead is deposited in a chute that leads to the build platform.
Since the disc is driven by a hobby servo, I can easily add two exit chutes. If I rotate clockwise, for example, I could deposit the bead on my build surface. If I rotate counter-clockwise, it could go directly to a discard/recycle chute without taking the time to move the build platform at all. I have some more chicken-scratch to illustrate this design:
I suspect it will work alright, especially since the current plans I’m hatching for build surface movement might actually be really fast. (A perler bead robot needs much less accuracy than a RepRap or Makerbot!)
However, if it needs to be faster, a sorting system like your reprap-style trolley or my rotating magazine would function like a cache. It lets you break the problem into two stages, first storing the beads in buckets/cylinders, then placing them. Since you get an extra degree of freedom, now we can start to make some optimization choices in software. Perhaps a better analogy even is instruction reordering in a CPU. Using the sorting bins, we can effectively “look ahead” some fixed (but perhaps very large) number of beads, and optimize the path we use to place them.
I find it helpful to look at the extremes. If we had infinitely large sorting buckets, it would be trivial. We could sort all of the beads ahead of time if we really wanted to. Or we could run the sorting and placing tasks concurrently, with the placing task waiting on more beads when it runs out of a particular color.
If we had a zero-size sorting bucket, of course it looks like the sketch above. But if the sorting system was much smaller.. let’s say it only had room for a dozen beads. Then what would it be like? If we know what beads are coming, perhaps we can optimize the path we take. If the vibrating funnel gave us a blue bead, then a yellow bead, then a black bead, we could notice that there’s a blue bead and a black bead adjacent to each other in the pattern, and the machine could choose to place the beads out-of-order. A tiny sorting system like this could save almost as much time as a larger sorting system, and it could be much smaller and perhaps simpler.
So, in short, I agree it’s not the most efficient design, but I have a hunch that it’s a good tradeoff between complexity and operational speed 🙂
Update: I posted the work-in-progress design files on Thingiverse, as Thing 7332.
