Any startup (or, really, any company) will tell you that one of the most important things you can do prior to launching a new product is testing, testing, and more testing. This process involves internal stress testing of subsystems, external beta testing of prototype hardware, and continual abuse of new hardware and software builds. In advance of shipping our first Shaper Origin out the door, we want to understand and address any hardware and software feedback from beta testing as well as our internal stress testing procedures. Before I go into details about some of the tests we’re running on our Origin prototypes (stay tuned for future posts!), I want to talk about an oft-ignored part of the testing process — documentation and tracking. Allow me to introduce our solution to the the dilemma of effectively tracking beta test data: The Shaper Basket.
Our tongue-in-cheek name for this contraption comes from Alec (Shaper’s Computer Vision co-founder), who remarked upon it’s completion, “We’re really putting all our eggs in one basket!” Indeed, the basket is the home for ALL of our lovingly hand-built beta Origin devices.
The need for the Basket and associated tracking software arose from our desire to individually track performance of each unit. We use GitHub Issues for tracking systemic bugs or design improvements. However, when you’re beta testing with a bunch of hand-built units, each device can have its own quirks that need to be tracked and understood to determine if they represent a design issue, an assembly problem, or something else. The Basket allows us to track our device inventory, check units in or out, and note issues. State logging allows us to easily view the complete history of a device, and more importantly, to be able to reproduce issues.
The Basket check-in/out interface and logging details can be accessed via a touch screen mounted to the left side of the shelving, or from any computer or smartphone on our network (mmmm Responsive Design). The Basket keeps the control electronics for each unit powered and connected to the network; this enables our automatic build scripts to load the latest software onto all the units each night, so we can ensure we are always stress-testing the latest builds.
In standard Shaper fashion, we designed the Basket from scratch, built it with Shaper Origin, and designed our own control electronics and software stack. Here, you can see Sam using Shaper Origin to cut out openings for the outlet boxes on the basket:
We also used our Origin Prototypes to engrave some lovely labels for each cubby:
In addition to tracking device status in the software interface, we also wanted to be able to tell at a quick glance which units were ready to use. Before implementing the basket, we were constantly scrambling to figure out which units were in working order whenever we wanted to build something or give a demo. A side effect of having just a few hand-built beta devices is that they are generally all in the midst of some of kind of test or modification. We chose to equip the basket cubbies with ambient lights that would quickly and obviously identify which units were in working order, and which were in the middle of being worked on. This had an immediate and dramatic impact on our testing efficiency. Plus… having all those LEDs means the Basket is great for parties!
But, back to business. Here’s how we actually use the Basket in our day-to-day work... 1. Pick an available working unit. The overview screen shows the status of each unit at a glance:
2. Tap your unit, enter your name, and check it out. The state will update and the light in the cubby will turn off, indicating that it’s okay to take the unit:
3. Do your business. In my case, that usually means working on the prototype electronics within the unit, or using it to build something.
4. Encounter something that needs to be fixed? No worries! That will get logged by the Basket. As an example, in our early testing, it has become very clear that we need to carefully design the handle buttons to prevent sawdust from getting in and jamming them (sawdust ingress). Our current buttons have a tendency to get jammed. By tracking this across several units with the basket, it became clear that this was a systemic issue, and we are now making design improvements to fix this issue.
5. Two important things need to happen when an issue like this is encountered. First, it needs to be documented. Second, if it can’t be fixed right away, I need to make sure I let the next person know that the button doesn’t work. That prevents them from wasting time to discover the same thing again. The basket takes care of both of these needs. Here, I’m using the mobile interface to check the unit back in with a problem report:
As I mentioned earlier, the basket is a #ShaperMade original. Ilan designed it, Noah and Sam did the construction and AC wiring, and then I took over to do the electronics and software. Rob wrapped it up with the auto-build/updater software.
Mounted behind the basket is an Ethernet switch (with cables going to each cubby), power outlets for each cubby, a Raspberry Pi microcomputer, a bunch of RGB LED strips, and a simple LED Driver board that I designed to be mounted atop the Raspberry Pi computer. Since the basket is a side project, I kept it cheap by having OSHPark fab the PCBs with a slow turnaround. The PCB design job was quick as well. The controller uses 3 I2C LED drivers to handle the 36 total channels that need to be controlled (12 Tri-color strips).
All the software is written in Python (with some sprinklings of Javascript, HTML, CSS, and Bash scripting). I used Flask to create a simple webserver that serves up the responsive webpage as well as an API that allows our auto-updater to autonomously adjust machine state (Lights turn blue while an update is being applied, and the update is logged). I leveraged Bootstrap to make the interface templates.
That’s the Basket! I hope this peek at how we’re tracking our beta units at Shaper has been an interesting read.
~Jeremy, Shaper Electrical Engineering Lead