Four Years of the LumenPnP
Today marks four years since the beginning of the LumenPnP project. Four years ago, I posted a YouTube video announcing a project that would eventually dictate literally every aspect of my life.
Given that it’s an anniversary, it’s a great opportunity to look critically at how things have gone. What have we accomplished? What worked? What didn’t? Here’s some of the main things I think of looking back on the last four years.
YouTube worked great, and in so many ways. Posting videos was an incredible way to get some eyeballs on the project and bring in smart folks that were excited to work with me to make the project better. It built a huge community of people that are excited about the mission, and what eventually would become an early adopter market for the kit we’d soon sell.
After that, YouTube started working differently. It was critical in the early days of the project, but as certain R&D decisions became more established, the base of people that were subscribed for engineering videos were bound to be disappointed. The work shifts from design to logistics pretty damn quick when you start shipping.
I’ve been struggling to find a new voice as the company has taken so much of my time. It’s not about building a pick and place anymore. It’s about building a pick and place company, and that’s an entirely different thing, for a mostly different audience.
Should I go back to random one-off videos circa 2019? Switching the channel to being more company-focused? I really love making videos, but they have to benefit the project and the company in some way for me to choose to invest time in them, at least for now. This is a large consideration for me this year.
Wow, what an incredible boon. The LumenPnP Discord server is now 4k people strong, and they have become such an incredible driving force behind design decisions, UX improvements, and engineering solutions.
One of the corrections from the community that I’m most grateful for is about my focus for the project in 2021. I had gotten into an iron-clad cadence of making a new, entertaining video about R&D every two weeks. After a certain point, the body of work that really needs to be done is validation and lifetime testing. The community gave me really excellent feedback that I should probably be shifting my focus to these challenges, and they were completely correct.
More recently, the community has been instrumental in making updates to the LumenPnP’s motherboard. Last year we tried a new format of review for PCB designs that’s been working really well that I’m excited to continue using into the future.
There’s also been really incredible efforts to design and document mods for the machine. A handful of other feeder designs have already been adapted to the LumenPnP, and one is even in the works that supports our communication protocol, Photon.
We’ve taken a pretty aggressive stance on our management of source material. Every bit of source is tracked in Github. PCBs, 3D models, even wire harness designs are stored in the repository.
But git is designed for text. Merging a KiCAD schematic file from a divergent branch is effectively impossible. Your only real recourse is to choose one and overwrite.
We manage things a little differently. Using Git LFS, we can “lock” a file, ideally preventing anyone else from editing it while it is locked. In practice, it’s not quite so perfect, but it is a universal way of marking a non-mergable file as “checked out” so collaboration becomes easier. With this tweak, we’ve been using Github to manage our design source happily for the past few years.
Because of Github’s excellent CI/CD tool, we can even do things like automatically export BOMs for the machine, generate gerbers, or even render images of all the FreeCAD models. (Example in this release.)
This single source of truth has been fantastic for sharing the design and tracking versions.
Kit vs Assembled
For the initial kit version of the LumenPnP, a customer had to solder dozens of through hole components, 3D print tons of separate plastic parts, and engage in a tedious build spanning many hours. It was one hell of an ask. I am grateful so many people came along with us for the journey that early in Opulo’s lifetime.
Feedback from customer support was a clear indicator that we needed to own more of the process. Many problems that folks were having with the machine stemmed from bad print quality, incomplete THT soldering, or damaged SMT connections. We ended up solving this with semi-assembled machines where the customer is only plugging in some cables and bolting together subassemblies.
If the customer is building the machine, then every machine is built by someone doing it for the first time. They don’t get to leverage the experience we have for common assembly gotchas, or optimal ways of doing things. Taking most of the assembly in-house greatly reduced the number of issues, and resulted in happier customers.
Other Open Source Projects
The LumenPnP is built on the back of dozens of other open source projects, and it is better for it. Some of these projects are clean, isolated black boxes of utility that grease the wheels of development. But some require a bit more consideration, particularly Marlin and OpenPnP.
These projects are true behemoths with years of legacy and design decisions. Making edits to something so large and complex is hard. I think this is just the nature of large software projects, particularly ones that are designed to support many types of hardware.
We’ve made significant edits and patches to both projects since the beginning of the LumenPnP project, particularly around supporting the LumenPnP feeders. It’s been such a cool experience to see how other projects manage contributions. I spend most of my time working within the structure of the LumenPnP project, so to dive into how other folks operate an open source project is a great opportunity to challenge my own methods and see if I could be doing things better.
One of the most important things I’ve learned in the past four years is the importance of user feedback. Understanding what users of your product are experiencing and reacting directly to that information is such a crucial part of making something great.
In college, I worked on a muscle-controlled prosthetic hand. I designed a joystick driven menu system for selecting different grip strengths, and was pretty proud of my feature. When I showed this to the amputee I was working with, he said, “I will literally never use this. If I have a free hand to change a setting, why wouldn’t I just use that hand to pick up what I want to pick up?”
I was floored. In retrospect, it’s so obvious that that feature would never be used, but because I was not the target user, I was missing critical context about what using the product would be like.
At Opulo we use the LumenPnP every day to build boards, so we’re effectively our own user. This certainly helps us keep the right context, but there’s no replacement for listening to your users.
I have been unbalanced these past four years. I have effectively shut off every aspect of my life besides Opulo and the LumenPnP. I have gone to an extreme.
To be totally fair, it has worked. Opulo is a successful, profitable company, making tools that do useful work for people all around the world. But the way I’ve managed it has been unsustainable for myself. I need to find a better way of operating, because I’m sure as hell not going to slow down.
The problem is that I love it. I absolutely love working on this project and this company, and there are always a million things to do. Making the conscious decision to not is incredibly hard for me, even if it’s in my own best interest.
A few months ago, I started putting some things in place that help me continue to be the most effective that I can without losing my mind. Having a group of other founders to talk to has been unspeakably good for maintaining sanity. Also, taking an evening every once in a while to truly not think about work is surprisingly effective. Picross and Dungeons and Daddies have been my saving grace. It’s incredible how much taking some time off will make you more effective when you are working later. It’s not about the hours, it’s about the effectiveness.
I love running Opulo and the LumenPnP project more than anything, and I want to do it the best that I possibly can.
Next Four Years
We’ve hit some pretty excellent milestones since the project’s inception, but there’s still a lot of work to do. The midscale operation still has some gaps.
One of the most difficult things for folks starting out is having the right information. There’s a ton of resources out there for engaging in midscale manufacturing, so we recently started Midscale.io to help share these resources to others trying to get started. The OHM Podcast that we started last year also aims to accomplish that goal.
The LumenPnP’s UX can also see improvement. OpenPnP runs well, but can be difficult for new users to learn. Calibration is very thorough, but many parts could be automated. Also, job setup (mounting feeders, PCB panels, and strip feeders) is quick but could be quicker.
There are also other parts of the midscale SMT line that need work. I experimented with the idea of making a reflow oven, but there are really excellent machines that already exist. The same goes for stencil jigs. Some of these problems are not engineering issues, but availability issues. Importing and distributing these things would be the most pragmatic way to fill these gaps, and not by reinventing the wheel.
The management side of a midscale operation is also slated to improve. The already excellent Inventree which helps keep inventory, builds, and purchasing in order is constantly getting better. Standardizing BOM structure and sharability, hardware releases via Github CI, and git-based collaboration for ECAD and MCAD are things I’m working on in the coming months.
What We’ve Accomplished
I’m truly proud of what we’ve been able to do in four years. It’s been dozens of creative, intelligent, passionate people working together to develop a platform that helps folks manufacture their products. People have started companies, shipped products, performed research, and changed the world for the better with the hardware we’ve built.
In four years, we have:
- developed a pick and place system from scratch that is completely open source, and self-buildable with off the shelf components
- developed multiple updates and revisions to that pick and place system, improving speed, rigidity, and reliablility
- developed pick and place feeders that support the vast majority of components
- developed standardized feeder firmware and a custom protocol supporting feeder discovery and loaded part tracking, plus integrating this protocol into Marlin and OpenPnP
- written thorough, annotated user documentation and assembly instructions
- raised money to enable the first batch of material purchases and office space
- developed custom testing software and production jigs to allow for these machines to be assembled and tested
- built and shipped thousands of units to every corner of the world
- started a podcast and developed resources for folks diving into midscale manufacturing
I am so incredibly grateful to anyone and everyone that has contributed to this project in some way. If it wasn’t for all the folks that helped craft it into what it is, it’d still just be me in my Somerville apartment, tinkering away. Thank you.