Making hardware a little less hard
A technical look at Electroloom’s switch to a GUI system
This is the first piece in a two part technical series about Electroloom.
Stay tuned for the next post which will detail some of our pump iterations.
Building and iterating our hardware over the last year has been a complicated process—one with lots of changes and realizations. We wanted to provide a bit more of a technical view of some of the progress we’ve made this year, and catch you up on what our interfaces have looked like along the way.
In the beginning…there was nothing.
The initial interface will likely be unsurprising—there wasn’t one. Our first experiments were just that: hacked together parts with little structure or forethought. We just wanted to see if we could get something to work. With some cheap parts and a vague idea of how to make it work, we just went for it. (A bit more detail on the metal chopsticks in our first blog post). Turns out, it worked. Well, it worked well enough to convince us we could make some progress.
Automate it!
The process was admittedly rough around the edges. Our whole “system” was still a largely manual proof-of-concept.
As a software guy, I saw it as ripe for automation. We took an Arduino and a couple motors and made the parts move without our intervention.
Gaining some control
The small amount of automation was great step forward. It helped to fine-tune what we were able to produce and allowed us to begin to focus on how to improve our early system. One of the problems with our first automation step was that it was just hard-coded “control” (if something moved too fast, we had to flash some new code on our Arduino, which was time-consuming and repetitive).
We grabbed some analog sliders (slide potentiometers) and hooked them up as speed controls for our two motors. This worked great for a simple interface and allowed us to make small (though imprecise) adjustments to the motors after they’d started moving. These imprecisions were caused by the analog nature of the sliders. They directly change a supplied voltage based on where the slider is physically located in its range (about 3 inches). The location often ends up between two “states” and can bounce between them, making it hard to specify our parameters.
Structure
With these additions, we were outgrowing our open-air breadboard setup. The whole thing became clunky to move around and prone to grabbing a wire and disconnecting something. We built up a box to contain all the intricacies and mounted the components to a single panel, making it a little nicer to work with (we no longer had to hold the sliders in place in order for them to work).
Refining and Optimizing
As with every step of our development, we constantly see things we missed in the design and ways we want to make it better. Sometimes it becomes hard to focus on using the current model because those problems become distracting. We’ve been driven to iterate our models quickly because we know how we can improve them. After we built “The Magic Box”, our next step was to consolidate the separate pieces into a more cohesive unit.
As we started our next iteration, we wanted to address some issues we had with our interface. The sliders we had been using were analog, meaning they changed the amount of voltage being read as they were adjusted. This worked fine early on, and was definitely an easy way to get started (which is why we picked it). But we had become more interested in further precision, and couldn’t live with the bouncing around that the analog controls introduced.
We moved to digital rotary encoders (like a car stereo) instead. These let us count the amount of movement and calculate new values. Once everything was digital, precision was no longer a problem. We could easily adjust granularity, there was no risk of bottoming out like we did on the sliders, and there was no more “bouncing” between values due to analog controls.
Thinking about the future
I’d like to say we realized this earlier, but we didn’t—our approach of fixing the problems we saw in each iteration of the hardware interface wasn’t very scalable. In fact, it was beginning to hinder our development time on the software side. Separate code bases for each model and iteration seemed like a nightmare, and I like my code to run everywhere (i.e. multiple models and iterations). So rather than copying an entire code base and making the minor edits to reflect the latest hardware change (e.g. switch to a bigger pump), I added some new code on top, allowing a quick toggle between whichever happened to be running at the moment.
Initially it was manageable, but it got to be too complicated after we had encoders instead of sliders. The math was different, the pinouts were different—it just didn’t make sense. So I thought, alright, we’ll ditch the old hardware and push forward with this new stuff. But then what would happen the next time we (inevitably) changed the hardware controls? Seemed like there had to be a better solution.
How about eliminating the hardware interface altogether (something other 3D printers have adopted as their strategy)? Given this array of examples of the “right” way, it might surprise you we started (and ended up) where we did. Each interface was the result of small, iterative steps that accumulated over time—each step was the quickest (or cheapest) way to get to from where we were to where we wanted to be. Though this strategy is common (even at large companies) and makes a lot of sense while developing, it lacks foresight, and I’d mostly recommend against it—it can complicate switching to better solutions later, and ends up clouding what the “best” solution to a problem really is.
So that’s what we did—threw out the hardware interface iterations and built a software interface instead. We started with Tkinter and Python to build up a GUI that communicated with the Electroloom’s hardware.
We’re fortunate to still be small and agile in our design and build processes. We can afford to throw everything out because we’re early (even if we weren’t early, I think that throwing it all out is often the best solution to solving lots of small problems). To that end, after throwing out our physical hardware controls, we saw the true advantages of a software interface. The software allows us to swap in and out different machines on our laptops and have the same control we need. It has much more room to grow, now that it’s moved to a proper computer. We can even add more powerful features, and not worry about being limited by the size of the machine (and additionally, we can shrink down the machine since a lot can happen on the computer now).
Overall our software has gotten a lot more powerful, and begun to add to the Electroloom’s capabilities. This will undoubtedly bring us to a more refined version in the coming months as we move toward a consumer-ready device.
