William Santoso is an undergrad at the University of Sheffield, and heavily modified a LumenPnP as part of his internship at Phlux.
During his time there, he was challenged with fully automating the test procedure of Phlux’s devices. So he decided to take advantage of the open source nature of the LumenPnP and modify it to automate device handling completely.
In order to accomplish this, William developed a new toolhead that can grip components from the side as opposed to with vacuum, and custom control software that was built using the LumenPnP control API, Leash.
Tell us a bit about yourself and what you make.
Hello! My name is William Nathanael Santoso, and I'm an incoming final-year undergraduate at the University of Sheffield, studying Mechatronic and Robotic Engineering (BEng with a Year in Industry).
Outside of my coursework, I’ve been involved in a variety of student engineering projects at the university, from developing avionics systems for high-powered rockets to helping design a small-scale bioreactor. I’m very passionate about engineering and really enjoy applying my skills across different disciplines. Currently, I’m working as an Undergraduate Research Assistant in the Robotics & Autonomous Manufacturing Systems (RAMS) Lab within my department.
I recently completed a year-long internship at Phlux Technology, an award-winning startup in Sheffield developing novel infrared sensors for high-performance sensing, communication systems, and various other applications.
During my time there, I was part of the Automation team within the Engineering group, where I helped develop automated systems for Phlux’s production processes. Since the company was still in its early scale-up phase, the team was quite small — I was actually one of only two members in Automation — which meant I had a lot of responsibility and direct impact, even just as an intern.
My main project throughout the duration of my internship involved developing an automated system for loading and unloading batches of devices between different carriers. The primary goal of this project was to help streamline the device testing process, a fairly significant bottleneck for the company's production.
What are you doing with your LumenPnP?
We’re using our LumenPnP — dubbed the AutoLoader — for this exact purpose, to automate device loading and unloading. More specifically, the machine handles the picking and placing of Phlux’s APD devices (which come primarily in SMD and TO-46 packages) between the waffle packs they arrive in and our custom device carriers used throughout our testing workflows.
The AutoLoader serves as both the entry and exit point for our envisioned fully autonomous device testing pipeline. Currently, it's only being used with Phlux’s flagship Aura line of APD devices. However, thanks to the way the machine's been set up, only minimal modifications would be needed to adapt it for the company’s upcoming APD product lines.
Why did you choose the LumenPnP for this unique use case?
The core problem we aimed to solve was automated device loading and unloading. Early on in my internship, during the initial concept phase for the AutoLoader, I explored several types of robotic manipulators to address this challenge. I was considering everything from small 6-DOF robot arms to SCARA and Delta-style mechanisms. Ultimately, I decided on a gantry-style system, as I believed it offered the simplest and most flexible solution. It also helped that it aligned with what I generally saw in industry, as most pick-and-place machines use this kind of system.
I eventually chose the LumenPnP to act as the foundation for the AutoLoader. This decision was primarily driven by its open-source nature (very customizable!), a strong track record with professional clients, and the supportive community behind the project. On a personal note, it also helped that I had been a fan of Opulo's work for quite some time!
What kind of modification did you make to your LumenPnP?
I made several hardware modifications and designed custom attachments and mounts for my stock LumenPnP, alongside developing custom control software in Python and ROS2. I also built a fully functional GUI to interface with the machine.
How did you modify or adapt the machine to make it work for your use case?
Hardware:
To accommodate for our specific use case, I made a series of hardware modifications to expand the LumenPnP’s capabilities and improve usability. Initially, I added two extra staging plates to increase the working area, but this still didn’t provide sufficient space for our large device carriers and waffle packs. To further extend the machine’s reach, I replaced the stock legs with AlanaCat’s Wide Body legs, which I modified to also increase the overall height. This additional height gave the tool head more clearance to maneuver around the tall device carriers. As part of this modification, I adjusted the homing fiducial mount to match the new height. I also reworked the X-axis by replacing the stock extrusion and linear rail with longer ones to maximize the tool-head's X & Y travel, given the wider legs.
However, the increased height created a new challenge: the bottom camera could no longer focus properly on the devices. To resolve this, I built a new mount that repositioned both the bottom camera and bottom light above the staging plate rather than underneath it. I then calibrated the focus to align with the top camera's focal plane, restoring the vision system’s accuracy. I also designed and 3D printed custom mounts for the device carriers and waffle packs, which could be easily attached to the staging plates with standard nuts and screws.
The most significant hardware modification I made was definitely a custom-designed micro-servo gripper attachment for the tool head. This was created to address the difficulty of picking up TO-46 packaged devices, which were seated in through-hole slots on the device carriers and required more force/grip than vacuum suction could reliably deliver.
After extensive prototyping with different materials and mechanisms, I finalized a design inspired by the AR4 servo gripper by Annin Robotics. I essentially just created a scaled-down version for use with a micro-servo and redesigned the gripper fingers to better grip our specific devices. With this modification, the machine now had two dedicated tool heads: one for picking up SMD devices using vacuum suction, and another for handling TO-46 or other through-hole (THT) devices using the gripper.
In addition to these functional upgrades, I also implemented several quality-of-life improvements. I integrated separate X and Y drag chains from the most recent LumenPnP V4 to replace the combined drag chain system of the older V3.2.2 unit, which I had unfortunately ordered just days before the V4 was announced.
Software:
I built a more complete version of the LEASH control API originally developed by Opulo. While the base API was a great way to learn the fundamentals of interfacing with the machine, I found its feature set too limited for what I needed. My version expands on it with:
- Enhanced motion control (with ability to target the left head, right head, or top camera)
- Improved position tracking relative to the active head (especially useful for calibration and capturing coordinates)
- Rudimentary runout and backlash compensation routines
- Built-in methods for offset and orientation detection (tailored to Phlux’s devices, but adaptable for other devices as well)
- Modular framework for integrating different actuators, such as my custom gripper attachment
Beyond the control API, I developed custom ROS2 packages and nodes to handle higher-level system control. These manage tasks such as:
- System State Management
- Homing (Both Mechanical & Visual) & Idle Routines
- Picking & Placing Routines
- Offset & Orientation Correction (Devices + Fiducials / Markers)
- Carrier Skew Correction
- Landmark (Carriers, Fiducials, Devices) Coordinate Tracking
- Running the GUI
I chose ROS2 as the backbone of the system architecture to ensure easier integration with other automated systems in our workflow, since they also run on ROS2. While the AutoLoader currently operates independently, it’s designed for seamless integration when the time comes for it. ROS2 also simplified concurrency management, which was another factor in the decision-making process.
Finally, I created a few small utility scripts: a C++ script (using OpenPnP-Capture) to automatically adjust camera settings at program startup, and a Bash script to generate a desktop shortcut so operators can launch the entire program without having to use the command line.
What aspects of the LumenPnP helped you create and implement your modification?
Both the readily available CAD files and Opulo's Leash API were invaluable, especially at the beginning of the development process. When I first began the project, I had little to no knowledge of the hardware and software stack behind a pick-and-place machine like the LumenPnP, so these resources provided a solid foundation for my modifications.
The open-source community behind the LumenPnP was also incredibly helpful, not only as a source of inspiration for potential improvements, but also for answering my own questions as I continued to develop the AutoLoader. I should also mention that the extensive OHAI documentation was really helpful in improving my understanding of the machine’s inner workings.
How has the LumenPnP overall impacted your workflow, productivity, or capabilities?
The AutoLoader has only recently been introduced into production, but it’s already making a noticeable impact. It’s taken over the manual loading and unloading of our device testing carriers, a task our Operations team used to handle, freeing up their time and attention for more important work.
Even at this early stage, the machine has provided tangible benefits to the company. Thanks to its modular and extensible design, there’s plenty of room to add features and continue building out the automated device testing pipeline. I’m really excited to see how far the next generation of the Automation team can push it from here.
Looking back on your experience, what feature of the LumenPnP do you value most, and what was the most enjoyable part of creating your modification?
Looking back, the feature I value most is definitely the open-source nature of the LumenPnP and the incredibly active community behind it. I don’t think I could’ve delivered the machine within my given time frame without the extensive resources and support from both the Opulo team and the broader community.
The most enjoyable part of the development process for me was diving into all the intricacies and complexities of building a pick-and-place machine. It really is a lot harder than it looks! It was a great learning experience, and being able to apply that knowledge to create a practical solution to a real-world problem was something I found really rewarding. I just hope the work I’ve done can be helpful to other makers as well — even if it helps just a few people, that would mean a lot to me.
What challenges did you face while making it work, and how did you overcome them?
Some of the most challenging aspects of the development were areas where there wasn’t much existing work to reference, at least not within the LumenPnP or broader open-source pick-and-place community. One key example was the custom gripper attachment I designed. As far as I could tell, no one had done something like this before, so it very much felt like I was venturing into uncharted territory.
The same was true for the custom software API I built. While most users rely on OpenPnP or Leash to control their machines, our use case required specific features and deeper integration with other systems (such as our ROS2 network), so we decided it would be best to develop our own software stack for the machine.
To overcome these challenges, I spent a lot of time researching and learning from a variety of sources. For the gripper, I looked into open-source robotic arm projects to understand existing gripper designs and adapted those ideas for the AutoLoader. For the API, I reached out to the OpenPnP community and spoke with developers to gather insights that could help inform our own implementations.
I also reached out to Stephen himself on many occasions to get his perspective and ideas on what I was working on. There was a lot of trial and error, but it was ultimately a rewarding process that significantly expanded my understanding and technical skills.
What advice would you give to others who are considering modifying their LumenPnP?
Take the time to thoroughly understand how your LumenPnP works before making any modifications. Look into why specific components are designed the way they are and how they come together to form the complete system.
This also applies if you're planning to write custom software — whether it be OpenPnP, Leash, or even something like the software I've written for the AutoLoader — try to study these existing implementations first.
Gaining even a baseline understanding of how the software controls the machine and what’s happening under the hood will make the whole process run a lot smoother. In my experience, knowing what you’re changing before you try to change it is really important.
Keep up-to-date with Phlux:
Website
LinkedIn
Keep up to date with William Santoso:
GitHub
LinkedIn.
The AutoLoader (CAD & Software)
GitHub
