Where We're At
When we set out on this project, we established a few simple requirements that we thought helped define what a useful LEGO® sorting machine would look like. The hardest one was throughput: 6 parts per minute. We've been insanely locked in for the past few months, and I'm excited to share that we've hit it.
Machine as of today
In November, I shared my very hacky, very janky prototype of a working LEGO® sorting machine. Building a LEGO® sorting machine that works for a video is hard, but designing one that can be reproduced is a whole other level. Making it as useful and reliable as other tech we've become accustomed to is so difficult it's hard to comprehend.
But it seems a lot of people agree with me that it's cool and important, and since then, a team of extremely talented engineers has emerged to make automated LEGO® sorting at scale a reality. Our Discord has grown to over 800 members with experts in every domain this machine touches. There's a core team of about 8 people driving the core implementation, and every day, high-quality, truth-seeking discussions are taking place to truly boil down the answer to one question: what is the simplest way to automatically, efficiently sort LEGO®?
Sorter V2 Uncut Footage - March 2026 Speed
Sorter V2 is sitting steadily at 7 PPM. That's about 10,000 pieces per day, each categorized by exact type and color.
To be honest, we didn't carefully select that number. We picked something that felt like a reasonable goal we'd be proud to achieve. In retrospect, though, I think it was exactly the right number. 6 PPM is right around where the machine has no downtime while it's working. You're watching it and it's always doing something. Skilled humans can sort 10-15 PPM, but a machine runs 24/7. Over a full day, it roughly matches a person.
V1 couldn't do this. At its best it clocked about 3 PPM, often hovering around 2. It was embarrassing to stand next to it while it worked. V2 is not nearly as boring to watch, and I think that's actually a meaningful checkpoint.
Almost all of this improvement comes down to the feeder.
The Feeder
The feeder has been the primary area of "research" for the Sorter project, and it's really starting to bear fruit with fundamentally better approaches to feeding LEGO®.
(This is the thing that takes the bucket of pieces, and dispenses one at a time for sorting, referred to as "singulation")
V1, and the first two months of V2, depended on vibrating v-channels to singulate pieces. These things suck. Not this specific implementation, but in principle they suck.
This entire machine has been a war on complexity. There's still more to go, but I think simplifying is the single greatest lever we have on every attribute we care about. If the design is simple, it's almost certainly more reliable, faster, quieter, and going to lead to fewer problems down the road.
A big hunk of plastic on springs with a vibrating motor has all six degrees of freedom, it can move freely in every axis. These are difficult to tune to work at all, and when they do, they're slow and fail to accommodate rubber pieces. The incentive to get rid of them was huge.
And perhaps most insufferable of all: the noise. Improvements can be made, but there's no path to silence. If you want to suffer through it, check out this video.
Despite all this, vibrating v-channels are what all the LEGO® sorting machine prototypes online depend on, and so we forged ahead. Our plan essentially resolved to "we'll just iterate the problems away, I guess." Looking back, I don't think we had a plan.
Tobias Has an Idea
But sometimes the universe throws you a bone. Or more like a free lunch.
In early January, Tobias, an active member in the basically Discord, called all the core contributors together to present an alternative approach to singulation he had been developing for the last few months. And he didn't disappoint.
His mechanism was very simple: flat, rotating turntables that pieces ride on top of, with an offset, curved wall intersecting their path.
A clump falls onto the first turntable, which largely separates on impact. Then, as pieces move along with the turntable, they intersect the curved wall at different points and times. As they make contact, they're forced to slide and rub along the wall. A clump of pieces would stretch along the wall and eventually fall off the edge, so the turntable ejects a smaller clump than it received. Hopefully it even ejects a single piece, which means the job is done and singulation is complete.
Tobias' original demo
The group was enamored. Not only was it simpler, it was nearly silent and looked like it could handle a wider variety of pieces, faster, than any solution dependent on vibration.
The turntable approach abruptly ripped us out of the local minima we, and LEGO® sorting machine projects at large, had been in since their inception. The #turntable-experiment channel quickly became the most active in the server, filled with experiments designed to understand this principle and figure out how to integrate it into the main system.
Turntable concept buildout by Chris
In theory you could stack turntables in series for compounding accuracy. If each had a 75% chance of successfully separating a clump, two in sequence would be ~94%, and three could reach ~98%. That is, unless a turntable can undo a former one's work by accidentally recombining pieces, which unfortunately they could :/
Blue wedge slope re-combines with other pieces
The reason is the mechanism itself. Once a piece hits the wall, it moves slower than it does on the rest of the turntable, especially compared to pieces still riding the outer perimeter. Additionally, depending on its distance from the center of rotation and the piece's geometry, its speed on the wall changes. The result is that, despite arriving separated, pieces riding the outer perimeter can inject themselves into other pieces slowly riding the wall and force them to re-clump.
The turntables could be more intelligently controlled with computer vision or motor-actuated walls, but this would come at a substantial cost to speed. We also tried various arrangements of walls to see how they changed the separation behavior.
Manually controlled exit door
Spiral wall test
Ultimately, the issue lay in the fact that there was no safe place to store a singulated piece until the machine was ready for it.
More People Have Ideas
A great characteristic of the v-channels we were using before is that, once the pieces are separated, they're probably going to stay that way. They're in a neat, linearized queue, and you can just dispense one when you need one. This led Marc to a clever next step: combine these two approaches with a circular v-channel where the inner cone spins as the turntables do. Perhaps it could be the last stage, or a stage between each turntable, or even the entire system?
Safely queue pieces
Any of those three strategies would probably solve our problem, but the last is certainly the most interesting. I built a prototype to test a hunch: vibration is not the important part of the vibrating v-channel, the channel and the drop is. Pieces separate when they fall into the V-shape because the walls encourage them into a controlled line, not because they're being shaken. Vibration is really just there to move them along. So, how do you convey pieces through the channel without it? Marc already showed us.
Original stacked concept
Manual control demo, 10x speed
Although this was a mechanical turk demo, the results were perfect on the first run.
We dubbed the result "c-channels," spinning circular v-channels that separate only by dropping pieces and convey pieces without any vibration at all. After a few rounds of iteration and Marc's implementation for the actual machine, we got some great results. Here's some notable improvements from the journey:
- Inverted geometry. Cameras are an integral part of all of these solutions. The mechanisms don't work on their own, they need active intelligent control. The original stacked concept had pieces drop from one channel onto the next through a tunnel in the center of the system. That gave the cameras almost no visibility and put large pieces at risk of jamming in the tunnel. Flipping it so pieces fall out of the channel, riding the outside and falling off the edge, solved both problems.
Early render with short travel path
- Rotor texture. To ensure that all pieces keep moving, and to perhaps encourage further separation as they traveled, we tried different textures on the rotors. Some early examples include spoked grooves and these cutout spirals.
Marc's c-channel test bench
The biggest issue, however, was the friction balance between the rotor and the stator walls. A large flat piece sitting on a perfect cone has almost no contact area with the rotor, but two points of contact against the stator walls above it. Two against one: the stator wins, and the piece stays put while the rotor spins underneath.
Large pieces resist moving, 3x speed
We tried adding a single rubber strip to the rotor that would move all the pieces that didn't move normally on its next pass, which actually worked a bit too well. The rubber completely crashed the balance the other way.
Test with single rubber line on rotor
Finally we landed on a faceted concept, designed by Jose: flat panels instead of a cone. The flat surface gives the rotor a much larger contact patch, enough to overcome the two stator points, and the facet transitions add a subtle wave motion that helps disperse clumps along the way.
- Lighting. Each c-channel got a dedicated light so the rotor and any piece on it are evenly lit for the cameras.
COB LED
Camera POV
- White rotors. Black pieces on rotors printed in black were quite hard to detect, but switching them to white gave a more even glow, and resulted in contrast that made all colors, including white, visible.
- Multi-cam. Instead of a single overhead camera, we've transitioned to one camera per channel. They can be cheaper and lower-resolution, but sit much closer to the rotor, so we actually get more detail. Each camera also has a fixed view of its own channel, so we always know exactly where the channel sits in the image.
- Bulk bucket. By simply extending the walls and adding a lid, one of the c-channels is able to function as our bulk bucket.
Combining this breakthrough with the computer vision approach that worked so well with V1 gave us pretty fast, pretty quiet, pretty consistent results. And it's nearly silent, listen for yourself.
This is where most of the 7 PPM rate is derived from.
What's Coming
Despite becoming quite a capable machine, Sorter still has a lot of sharp edges. We're currently walking down the long tail of engineering issues that only runtime can reveal. There are dozens of minor but time-consuming changes that need to be made before a complete design, documentation, and tutorials are locked in.
The next goal in our sights is increasing reliability and ensuring that when something does go wrong, the user is notified and the machine halts. The c-channel architecture gives us a much simpler system to debug than what we had before.
Three variations of the machine now exist among the engineers at the bleeding edge of the hardware and software. That's certainly the first time there have been three instantiations of the same LEGO® sorting machine, and I think that's a massive achievement in itself.
Thank you to everyone in the basically Discord contributing ideas, knowledge, and elbow grease to make this machine a reality.
Thank you to Marc Neuhaus and Tobias Linkjendal for their feedback on this post and engineering research on this project.