Компания Inbolt внедряет AI-платформу для автоматизации электроники и обслуживания дата-центров

Automotive plants have had robots for 40 years and integrators on retainer. Many electronics teams don't have that depth yet, and they're being asked to automate more and at a faster pace. Q&A with Griffin Gillespie | Inbolt Tell us about yourself and your role with Inbolt. I currently lead our electronics manufacturing and data center infrastructure segment at Inbolt. Before this, I helped open Inbolt’s US office and operations, mostly working with automotive customers to improve their existing robot processes or install new automation workflows. Inbolt builds a control platform for industrial and collaborative robots. There are three parts: CAD-based robot programming, an edge-computed vision model, and real-time robot control. It can run on every major robot brand, and it's installed on more than 200 robot arms in over 100 factories. Last year, our solution powered more than 40 million robot cycles. While automotive manufacturing has historically been the primary user of vision-guided robotics, our technology is now expanding into electronics assembly and the maintenance of data center infrastructure. Electronics manufacturing has been automated for decades, but mostly around PCB placement and inspection. Why is there renewed interest in robotics for electronics assembly at the chassis, module and rack level right now? PCB assembly was automated early for a good reason. The process is standardized, the parts arrive from feeders in a known orientation, and the machine never has to ask where anything is. Placement machines are extraordinary at that. But everything above the board, so the chassis, the enclosure, the rack, is a different world. Parts arrive in dunnage or on racks, positions vary, the assemblies are large and awkward, and the product changes constantly. So that work stayed manual, and for decades the volumes didn't justify solving it. AI infrastructure changed the volumes. Contract manufacturers are building AI server racks at a rate nobody was planning for 3 years ago. I’ve heard reports that one CM is producing around 1,000 racks a week. These systems are denser and far more complex than what came before, crammed with liquid cooling manifolds, heavy busbars, and dense connectors. Once fully loaded, these racks can weigh thousands of pounds, making manual handling and integration a massive ergonomic headache. Layered on top of that is a growing high-voltage safety hazard. As racks transition to 400V and 800V DC architectures to meet extreme power demands, routine assembly operations and live testing introduce real arc flash risks. So the question on the floor has become “how do you assemble and service this equipment fast enough, and safely enough, when human operators physically shouldn't be exposed to the manual strain or the electrical risk?” In chassis and rack assembly, robots have historically handled maybe 20 to 30% of the work, performing mostly basic pick-and-place or simple screw-driving operations. Everything else, from routing stiff cables to seating dense connectors, stayed manual. Getting from that 20% baseline up to 90% is where the whole industry opportunity sits today. Automotive parts are far larger and heavier than electronic components. So why are electronics components often more challenging for robotics? Payload was never the hard part. A few things make electronics more difficult to automate, and only one of them is about accuracy. Let’s start with tolerance relative to feature size. A body panel is huge and its tolerances are generous relative to its size. A fastener going into a threaded hole in a server chassis has no such margin. You're asking the robot to have sub-millimeter precision on an assembly that may not be sitting where the program assumes. Next, when things do go wrong, there's less room to recover. Automotive scraps parts too, but there's usually a repair path, and the failure shows up before much value has been built into the part. In electronics, a screw driven slightly off-axis can strip a thread on a chassis that's already populated with boards and cabling. There's often no fix and no room to retrofit a repair in this case. Torque monitoring catches it, but by then it's scrap. That's why precision here is a quality argument before it's a productivity argument. There’s also the history of each industry’s robot programming culture. Automotive plants have had robots for 40 years and integrators on retainer. Many electronics teams don't have that depth yet, and they're being asked to automate more and at a faster pace. Finally, we face a structural problem. A contract manufacturer builds someone else's hardware. So the classic automation move, redesigning the part slightly so it presents nicely to the fixture, isn't available to them. They have to take the part as the customer designed it, and absorb every revision the customer makes. Precision robotics has traditionally depended on fixtures and mechanical indexing to hold a part in a known position. What happens to that approach when the product generation turns over every 12 months, and what replaces it? A fixture is a mechanical answer to an information problem. You don't know where the part is, so you constrain it until you do. That works beautifully when the part stays the same for years; however, the math stops working when you have a part or line that frequently changes. A fixture package has to be designed, quoted, built, installed and validated, and all of that sits on the critical path before you can prove the station works. Then the customer revises the design mid-program, which they always do, and you rebuild from there. Amortize that over 5 years of a stable part and it's fine. Amortize it over 12 to 18 months and it isn't. This is really a new product introduction problem, which is the term this industry actually lives by. NPI teams get judged on two things: how fast they get from design freeze to a qualified line, and whether the first batch is good enough to ship. Fixture-based automation answers both poorly. It arrives behind the ramp rather than with it, and while the process settles you’re forced to scrap parts. What replaces it is moving the tolerance out of the mechanics and into the perception. Instead of forcing the part into a known position, you locate it where it actually is and correct the robot's path in real time. The practical consequence is that the program exists as soon as the CAD does. We train a new part from its CAD model in about 5 minutes, on site, and a station goes in over days rather than weeks. One of our controllers can store over 100 different part numbers on the same station. An NPI engineer would save a huge amount of time loading new CAD instead of designing, building, and testing new fixtures after every product revision. You've pointed out that electronics engineering teams often have less deployment experience than their automotive equivalents. How should that change what an automation solution looks like for them? It should change the product, not just the training plan. And I'd argue this constrains what actually gets deployed more than accuracy does. The input has to be something that the teams already have. Every electronics manufacturer has CAD models of what they build. Almost none of them have labeled image datasets of their parts in every orientation and lighting condition, and asking a production team to go and create one is asking them to become a vision team. Model training has to run locally on their machine, with no outside network connection required. This sounds like a small detail, but it can often make or break a project. Plenty of plants run closed networks where a vendor simply cannot reach in. I know of a vision project at a large manufacturer that died for exactly this reason. Every model change had to be sent to the vendor's engineers and came back a day or two later, and on a closed network that became unworkable. This dependency on sending proprietary information outside of a secure network ultimately shut the project down. For engineers to understand and troubleshoot a technology, its output has to be readable. Our platform generates Python that their engineers can open, understand and change. If the automation is a sealed box, the first time it needs adjusting they're blocked, and the plant learns not to trust it. The vendor also needs to be out of the loop for routine work. If adding a part number requires a support ticket, the system will be worked around within a quarter. None of this is about making things simple for people who aren't capable. These are strong engineers. They just shouldn't have to become vision specialists to use a robot. Data center operations are emerging as a robotics frontier, with mobile robots moving through server halls to swap drives, handle transceivers and take material samples. What's actually blocking that today? The obvious blocker is landing accuracy. Navigation is largely solved. A mobile robot will reliably get to the right aisle and the right rack. But docking repeatability is measured in centimeters, and seating a drive or a transceiver needs a fraction of a millimeter. So the robot arrives in roughly the right place and then has to work out the last few millimeters for itself. That's a last-leg perception and control problem, not a primary navigation one. The less obvious blocker is that nobody owns the whole mission. A useful data center robot needs navigation, arm motion, perception, task dispatch alongside the other fleets already on that floor, control of doors, lifts and chargers, and telemetry back to the operator's own site system. Buy those as separate pieces and every site becomes a bespoke integration project. Our view is that the control layer has to run the base and the arm together, in one loop with the perception, and interoperate with whatever fleet management the operator already has rather than replacing it. We build on ROS 2 and Open-RMF for exactly that reason. The last blocker is that the hardware wasn't designed to be serviced by a robot. On flagship AI racks, the customer-replaceable set is genuinely small, and a drive swap can require powering down a tray and rebuilding a RAID array. Rack form factors have barely changed in 50 years and they aren't standardized, so any approach that needs fiducials, brackets or a standardization program is not going to get deployed. That's why the Open Compute Project matters here. Serviceability is a design decision, and OCP is where it gets made. Robots operating data centers isn't theoretical. Alibaba runs autonomous disk replacement across several data centers at around 4 minutes a disk. AWS has robots working on decommissioning. Google has talked publicly at OCP events about testing robots for rack servicing. Microsoft Research publishes on manipulating optical transceivers in cluttered cable environments. The direction is set. The near-term realistic set of tasks is handling drives, transceivers, cable re-seating, material sampling, asset audit and teardown. Where does vision-guided robotics genuinely not apply in electronics, and how should an engineering team decide whether a given task is a good candidate? Vision-guided robotics is the wrong tool for PCB component placement, die attach, wire bonding and wafer handling. Those operate at tens of microns, on parts already presented perfectly by the machine, and they're solved by placement machines and fab equipment. Adding a robot to that equation makes no sense. I’m a fan of the old “if it ain’t broke, don’t fix it” saying. If your part is already perfectly fixtured, the fixture is paid for, and the product isn't changing, leave it alone. Don't buy perception to solve a problem you don't have. For deciding whether a task is a candidate, I'd work through six questions. How often does the part change, and how many variants share the station? The more it changes, the worse fixtures look and the better perception looks. Does the part's position vary when it reaches the robot? If it's perfectly presented every time, you don't need guidance. What tolerance do you need at the tool, and how large is the feature? Go below one tenth of a millimeter, and you're in placement-machine territory. What happens when it goes wrong? Rework or scrap? A task where a single mis-positioned operation destroys a high-value assembly justifies guidance almost immediately. Would a fixture need rebuilding at the next product generation? If yes, count that cost properly because it recurs. And last: who maintains this after the integrator leaves? If the answer is "we call the vendor", you've bought a dependency rather than a capability. That question disqualifies more projects than any of the technical ones. Griffin Gillespie leads the electronics manufacturing & data center infrastructure division at Inbolt, an AI robotics company. Griffin helped establish Inbolt’s U.S. operations and now works to bring precise and flexible automation to next-generation data center maintenance and electronics assembly. The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow Palladyne IQ is a closed-loop autonomy software that uses artificial intelligence (AI) and machine learning (ML) technologies to provide human-like reasoning capabilities for industrial robots and collaborative robots (cobots). By enabling robots to perceive variations or changes in the real-world environment and adapt to them dynamically, Palladyne IQ helps make robots smarter today and ready to handle jobs that have historically been too complex to automate.