Bringing real software engineering to the factory floor

World-class robotics, held back by the software around it

The client's robots are extraordinary. They can sand a helicopter blade, polish an airplane fuselage, and finish a motorcycle helmet, each with precision that exceeds what human operators can achieve. The core robotics software, the motion planning and force control that makes this possible, was built by a talented internal team.

But as their customer base grew, the systems surrounding that core - configuration management, operator interfaces, deployment tooling - became the bottleneck. Every robot installation was essentially custom-built software. Settings for collision avoidance, force calibration, and environmental parameters lived in scattered files across deployed systems. There was no centralized visibility. No versioning. No way to migrate configurations when the software was updated.

The consequences were real: in one case, a misconfigured force setting resulted in a robot puncturing an airplane wing. The configuration complexity was growing linearly with the fleet, which meant every new deployment required another body on-site to manually configure it. This was a clear software engineering problem, and the internal team responsible for these systems was junior and under resourced.

The client's frontier was clear: they needed to build the software infrastructure that would let their robotics scale. They had the domain expertise. What they didn't have was the engineering capacity and software maturity to do it without pulling focus from their core product.

‍

Enterprise software thinking, applied to industrial robots

Configuration management: taming the settings sprawl

Every robot deployment involves hundreds of parameters: collision avoidance meshes that define the 3D space around a robot arm, force calibration settings for different materials and parts, environmental configurations unique to each factory cell. Previously, these settings lived in scattered files across deployed systems, with no central repository, no version control, andno validation. An application engineer would manually adjust a JSON file to set collision boundaries, and there was no way to know whether the value was correct until something went wrong.

We built a centralized configuration management system from scratch. The key architectural decision: the configuration schema is generated directly from their robotics source code, which means every setting is automatically validated against the actual software version. If the code changes, the schema updates. If a configuration doesn't match the schema, the system catches it before deployment, and (thankfully) not after a robot puts a hole in a wing.

The system includes full versioning, migration tools that let operators move configurations from one software release to the next with a visual diff of what changed, and rollback capability for when an update doesn't go as planned. It also introduced role-based access control, replacing a previous state where anyone with robot access could change anything, protected only by a password stored in an environment variable.

Human-machine interface: from C++ constraints to web-speed iteration

The operator interface is a touchscreen control panel that factory workers use to interact with the robot; it was built in C++ and was becoming a bottleneck. It was hard to maintain, difficult to extend, and couldn't keep pace with the features Gray Matter's customers were requesting. Adding new capabilities to the old interface was a weeks-long effort that often introduced bugs.

Our team replaced it with a modern web-based HMI built on React and Babylon.js for 3D visualization, connected to the robot's ROS layer through a FastAPI bridge. The architecture unlocked a fundamentally different pace of development. A new inspection feature allowed operators to select points on a 3D point cloud for the robot to measure paint thickness, and it was built in less than a day. A 3D collision sphere editor, letting engineers visually define collision avoidance boundaries instead of hand-editing JSON files, was built in half a day. These are examples of the normal speed of iteration when the underlying platform is built right.

The new HMI also unified two previously duplicative applications into a single interface with proper role separation: admin users get full access to the 3D interface and configuration panel, while operators see only what they need to run the robot safely.

Cloud + edge architecture: built for the factory floor

Factory environments are unforgiving. Network connectivity is inconsistent, and operations can't stop because a cloud service is unreachable. We designed the system with a dual architecture: a cloud-hosted API for fleet-wide visibility and management, and a local API running on the PC connected to each robot. Configurations are replicated and synchronized between both, so operators can manage their systems with or without an internet connection. This same architectural pattern is now being applied by Andes Path on other engagements in similar industrial environments.

‍

Real software engineering, not just more hands

The client's challenge is a pattern we see across robotics companies. The team that builds the core robot intelligence is often brilliant at motion planning, computer vision, and control theory. But when the product needs to scale, the surrounding infrastructure — the deployment tooling, the operator interfaces, the configuration systems — requires a different kind of engineering expertise. Enterprise software thinking. Git workflows. Schema validation. Role-based access. Version migration. These aren't exotic concepts, but they're rarely in the DNA of a robotics-first team.

That's the specific gap our pod filled. We didn't arrive to learn their domain from scratch. Our engineers already understood industrial robotics architectures, and the constraints of factory-floor environments. What we brought was the discipline and craft of production-grade software engineering, applied to problems that their internal team didn't have the bandwidth or the experience to solve.

The collision editor is another small-but-telling example. Previously, an application engineer would hand-edit a JSON file to define 3D collision boundaries. It was a tedious, error-prone process with no visual feedback. Our team built a web-based 3D editor in half a day. Not because the task was trivial, but because the right technology choices and the right architecture made it a half-day task instead of a weeks-long problem.

‍