Since I’ve spent far too much time on klust3r already, I’ll probably focus on other projects instead of further perfecting the candy sorter. But it could do with several improvements, some of which are listed here.
A lot of effort has been put into making surfaces as smooth and sloped as possible. But M&Ms still get stuck sometimes, either clogging the hopper, or getting stuck on their way to the dispenser, or even jamming the conveyor. While the Lego format isn’t especially well suited for the containment and transportation of granular material, I believe there’s lots of room for improvement in this area.
The current design allows the hatch hinge to bend both ways. While either direction can open and close the hatch, one of the options is preferable because it’s more stable in the horizontal (‘closed’) position. And the provided software assumes that klust3r has been calibrated to the better of the two starting positions. The design should allow only a single, optimal way to assemble things.
Because of the PC (USB) port’s position, the EV3 brick must be (temporarily) extracted from the robot when using a wired PC connection, which is inconvenient. Alternatively one could choose to pass the USB cable through klust3r’s innards, putting it perilously close to conveyor-related gears. Although one can simply make these problems go away by using a wireless (e.g. Bluetooth) connection, it’d still be nice if the PC port were better accessible when klust3r is fully assembled.
The sorting mechanism currently assumes that each iteration presents a single M&M to the color sensor for inspection. But sometimes the conveyor picks up two candies at the same time, which are then dropped into the same wheel segment. And when the pegs fail to grab a candy, the wheel is needlessly rotated to sort the absent M&M, usually into the ‘brown’ bin. I’d like for the mechanism to (better) ensure that candies are picked up one at a time, and to detect (e.g. using the IR or ultrasound sensor) when an M&M arrives at the color sensor. This would also allow klust3r to stop running when no more candy arrives.
Apart from not being able to tell brown M&Ms from absent M&Ms, the color sensor does not discriminate between red and orange candies, causing them to be sorted together. And yellow M&Ms are sometimes identified as white, making these end up in a separate bin. While a simple software change could resolve the latter problem, I’m not sure how to address the inability to tell similar real-world colors apart. It seems like MindCub3r must be doing some new-and-improved color detection, but I haven’t looked into this.
Thinking even bigger, I’d like to give klust3r the ability to feed sorted M&Ms back into the system. It seems like my Lego toolbox has enough spare parts for such an expansion. And it would be pretty cool to turn klust3r into an entry-level great ball contraption of sorts.
Finally, some details need polishing in the building instructions:
- Rotate icons are sometimes absent because I couldn’t get them properly positioned.
- The annotation texts for some part types are superfluous or even misleading.
- Annotations for axles should be rendered in a circle instead of in an oval.
- Apart from in the part lists, beam and axle lengths should also be displayed in the model images.
- Model orientation (camera position) could be improved in several cases.