Or: How a Fun Weekend Project Revealed Everything Wrong With Modern Technology
Part 1 of a series on astromech droids, universal design, and the technologies we’ve lost and/or failed to develop.
I’m sitting in my workshop come sitting room with an NVIDIA Jetson Nano, a tangle of cables, and an increasingly uncomfortable question: Why doesn’t R2-D2 exist?
Not the little beeping astromech from Star Wars—though that’s the inspiration. I mean the concept. The idea of a small, curious helper that can talk to any machine, understand what it’s trying to tell you, and translate that mess of error codes and blinking lights into something a human can actually use.
We have smart homes where devices won’t acknowledge each other’s existence. Factory floors running equipment that speaks Modbus, SNMP, proprietary REST APIs, and ancient serial protocols—often simultaneously. Office networks where a single connectivity issue requires physical access to three different closets on different floors. And when something breaks? You’re on your own, frantically correlating timestamps across incompatible logging systems, or paying a specialist who charges €150/hour because they alone understand the vendor’s particular dialect of “standard” protocols.
So I’m building an R2 unit.
The Vision: A Universal Translator for Machines
Picture this: You walk into any building—your home, your office, a factory, a data center. You have a small device, about the size of a lunchbox. It rolls around (or sits on your desk, or clips to your belt—modularity is key). Within minutes, it has:
- Discovered every networked device
- Identified what each one is and what it does
- Checked their status and health
- Translated all that technical noise into plain English
- Made cute R2-D2 sounds while doing it
Happy beeps for “everything’s nominal.”
Concerned wobbles for “that switch is running hot.”
Urgent whistles for “your router is about to die.”
It doesn’t need special software from each vendor. It doesn’t care if you have Cisco switches, TP-Link routers, Raspberry Pis, industrial PLCs, or a mix of everything. It speaks their languages—SNMP, HTTP, Modbus, mDNS, all of them—and translates back to you.
It’s your personal astromech droid. Your machine whisperer. Your helper.
The “Aha” Moment
It has ocurred to me many times, but particularly struck me during a routine network troubleshooting session. I was three terminals deep, switching between different vendor management interfaces, each with its own password I’d reset twice, trying to figure out why traffic was dropping.
One device requires a hard connection and have no indicators of their state.
Another required SSH with arcane commands I had to look up.
A third had an SNMP interface but only if you knew the right community string.
The fourth just… blinked unhelpfully.
All these machines were trying to tell me something. They had status information. Error logs. Performance metrics. Somewhere. But getting it required speaking four different languages, remembering vendor-specific quirks, and maintaining a mental model of how all these systems interrelated.
I thought: “Where is R2-D2 when you need him.”
When R2 rolls up to a new spaceship, he doesn’t care if it’s a Corellian freighter or an Imperial Star Destroyer. He plugs in his scomp link, has a quick electronic conversation, and boom—he knows what’s going on. Then he translates that into beeps and whistles that Luke or Leia can understand, or he just fixes it himself.
Why don’t we have that?
The Missing Service Layer: A Hole in Our Technology Stack
Here’s what struck me after that troubleshooting session: we’re missing an entire class of technology.
Think about the layers we do have:
Physical Layer: The hardware itself. Switches, routers, sensors, PLCs, motors, controllers. We make these increasingly sophisticated, increasingly powerful, increasingly complex.
Application Layer: The software that runs on them. Web interfaces, mobile apps, dashboards, SCADA systems. We make these increasingly feature-rich, increasingly data-heavy, increasingly specialized.
But what sits between them and us?
Nothing. We expect humans to bridge that gap directly. We expect network administrators to simultaneously understand Cisco IOS, Ubiquiti UniFi, TP-Link web interfaces, and raw SNMP queries. We expect factory technicians to read Modbus registers, interpret PLC ladder logic, and diagnose motor controller faults. We expect building managers to navigate BACnet, interpret HVAC sequences, and correlate events across incompatible systems.
This is insane.
The Cognitive Load Crisis
Every technology vendor adds to your cognitive burden:
- Another interface to learn
- Another set of credentials to manage
- Another mental model to maintain
- Another troubleshooting methodology to master
There’s no translation layer. No intermediary that speaks all these dialects and translates them into something humans can actually work with. You’re expected to hold dozens of incompatible systems in your head simultaneously and correlate their behaviors in real-time.
And it’s getting worse.
The average office network in 2000 might have had 20 networked devices. Today? Easily 200+. The average home in 2010 had maybe 3 connected devices. Today? 15-25, all speaking different protocols, all requiring different apps, none talking to each other.
We keep adding complexity at both ends—more sophisticated hardware, more feature-rich software—while completely ignoring the growing gap between what systems can do and what humans can comprehend.
What Should Exist: The Translation Service Layer
Imagine if we had a standard service layer that sat between complex systems and humans. Not a monitoring system (those exist, and they’re part of the problem—just more complexity). Not a dashboard (which still requires you to understand what you’re looking at).
A genuine translation and intermediary layer that:
- Speaks every dialect natively – SNMP, Modbus, BACnet, HTTP APIs, MQTT, CoAP, you name it
- Maintains continuous awareness – Always listening, always correlating, always present
- Understands context – Knows what “normal” looks like for your specific infrastructure
- Translates to human language – “Port 24 is overheating and will fail within 48 hours” not “Temp sensor OID 1.3.6.1.4.1… reading 67C”
- Acts as your proxy – Can be physically present in multiple locations simultaneously
- Reduces cognitive load – You don’t need to understand the underlying protocols, just what’s actually wrong
This isn’t a product. This is an entire missing technology category.
It’s like discovering we built a telecommunications network without inventing the telephone switchboard operator, or built the internet without inventing DNS. There’s a fundamental service layer that should exist but doesn’t.
Why Doesn’t This Exist?
The absence isn’t technical—we have all the components. It’s economic and structural:
Vendor Lock-In Benefits from Complexity When you need specialized knowledge to work with equipment, vendors can charge for:
- Proprietary diagnostic tools
- Certification programs
- Support contracts that should be unnecessary
- “Professional services” to interpret their own devices
Monitoring Companies Profit from Fragmentation Every incompatible protocol means another software license. Every vendor-specific interface means another integration module to sell. Complexity is the product.
No Individual Company Can Build It A universal translation layer requires cooperation across competing vendors. It requires open standards and interoperability. It requires sacrificing the profitable complexity that keeps customers locked in.
Market forces actively prevent this technology class from emerging, even though the need is desperate and growing.
The R2 Solution
This is why the R2 concept is so powerful. Helper droids are the physical manifestation of the missing service layer.
They would:
- Embody the translation function (protocols → human language)
- Provide the spatial presence needed for distributed infrastructure (multiple locations simultaneously through a fleet)
- Maintain continuous awareness (always listening, always correlating)
- Reduce cognitive load (you interact with the droid, not with 47 different vendor interfaces)
- Break vendor lock-in (standardized SCOMP interface works with everything)
An R2 unit isn’t just a diagnostic tool. It’s the first implementation of an entire technology category that should have existed decades ago but couldn’t emerge because market incentives pushed against it.
The Broader Implications
Once you see this gap, you can’t unsee it. The missing service layer appears everywhere:
In healthcare: Medical devices that can’t talk to each other. Monitors, pumps, diagnostic equipment—all siloed, all requiring specialized interpretation, all adding to clinician cognitive load.
In industrial automation: Factory floors with dozens of incompatible control systems. Operators juggling multiple screens, multiple interfaces, multiple mental models.
In smart buildings: HVAC, lighting, security, fire systems—all separate, all requiring different expertise, all failing to coordinate during emergencies.
In agriculture: Sensor networks, irrigation controllers, weather stations—all producing data, none speaking to each other, farmers manually correlating everything.
In transportation: Vehicle diagnostics, traffic systems, logistics networks—all generating information, all requiring specialized knowledge to interpret.
The pattern repeats everywhere humans interact with complex technical systems. We keep adding sophistication at the device level and features at the application level while completely ignoring the human in the middle who’s drowning in cognitive load.
We need the service layer. We need the translators. We need the helper droids.
Not because they’re cute or nostalgic or fun to build (though they are all those things). But because there’s a genuine, critical gap in our technology infrastructure that’s making systems less maintainable, less reliable, and less safe.
The R2 project is an attempt to demonstrate that this missing layer is buildable, practical, and necessary. And maybe, just maybe, if we build it well enough and document it openly enough, we can create the pressure needed to make universal translation interfaces a standard part of infrastructure design.
Because the alternative—continuing to pile complexity on complexity while expecting humans to bridge an ever-widening gap—is unsustainable.
This is the cognitive load crisis. This is the missing service layer. This is why we need helper droids.
Why This Matters (Beyond the Fun)
Here’s where the fun project gets serious.
We live in an age of unprecedented technological complexity. The average household has 10-15 networked devices. Offices have hundreds. Industrial facilities have thousands. And almost none of them talk to each other in meaningful ways.
This isn’t because it’s technically impossible. We have the protocols. We have the standards. The engineering challenge of building a universal diagnostic device is completely solvable.
But it doesn’t exist. And I think I know why.
There’s no business model for it.
Vendor lock-in is profitable. If your Cisco switch only speaks Cisco’s language optimally, you need Cisco tools, Cisco training, Cisco support contracts. If your industrial PLC requires proprietary software, you’re locked into that vendor’s ecosystem.
Simplicity doesn’t scale revenue. A device that just works, that you can diagnose yourself, that tells you plainly what’s wrong—that’s terrible for support contract sales.
Gatekeeping creates artificial scarcity. When only certified technicians can understand your equipment, those technicians can charge premium rates. When only specialists understand the protocols, those specialists are valuable.
Security is a notorious area for this problem. We know that open source is more secure in general. Devices though spend almost no effort on making it easy to access their stste, what they think is happening in their world. Which is a large percentage of troubleshooting connections. But there is no real monetary incentive to make things more secure by opening them to a troubleshooting layer such as R2 devices.
None of this serves users. It serves vendors and creates a professional class around unnecessary complexity.
The Archaeological Parallel
I come from archaeology, and this reminds me of something we see in historical research all the time: technologies get lost not because they stop working, but because the economic incentives change.
Roman concrete lasted millennia. Medieval blacksmiths made steel we can barely replicate. Ancient navigation techniques worked perfectly well. But the knowledge of how to do these things vanished because the social and economic structures that preserved them collapsed.
We’re watching this happen in real-time with modular, maintainable technology.
Industrial Automaton, the fictional company that built R2-D2, had a brilliant design philosophy:
- Standardized interfaces that any droid could use
- Modular components you could swap out
- Devices that exposed their internal state clearly
- An open ecosystem where third-party modifications thrived
That philosophy used to exist in computing. Early Unix systems were built on interchangeable tools. The internet itself was designed for interoperability. Open standards were the foundation.
But increasingly, that’s not the world we live in. We have walled gardens. Proprietary protocols. Devices that actively prevent third-party repair or diagnostics. Complexity as a feature, not a bug.
So I’m Building a Droid
This project is partly a technical exercise. I’m genuinely curious whether I can build something that discovers devices, speaks their protocols, and translates their status into human language—all on a Jetson Nano small enough to carry around.
But it’s also a statement. A proof that we could have helper droids if we wanted them. That the technology isn’t what’s missing—it’s the will to build for users instead of against them.
Over this series, I’ll share:
- The technical journey (how you actually build this thing)
- The design philosophy (why Industrial Automaton got it right)
- The economics (why modern incentives push the other direction)
- The accessibility angle (Universal Maintenance Design as an extension of Universal Design)
- The path forward (how we might get from here to there)
What’s Next
In the next post, I’ll dig into the history: how did we get from the modular, maintainable design philosophy of early computing to the vendor-locked nightmare we have today? What can Industrial Automaton’s fictional history teach us about real-world technology choices?
For now, I’m going to keep teaching my Jetson Nano to speak SNMP and make happy beeps when it finds a working device.
Because somewhere, in a workshop far, far away, a little astromech droid is rolling toward a broken hyperdrive with nothing but curiosity, determination, and a scomp link.
And I think we need more of that energy in the world.
Next in series: Part 2 – The Death of the Helper Droid: How We Got Here
Want to follow along with the build? The project will soon be open source: [GitHub link]. Have thoughts on modular design, vendor lock-in, or why your smart home makes you want to scream? Let me know in the comments.
About the author: I’m an archaeologist and AI researcher who codes in Python and curses at recalcitrant macnines. This seems like a natural career progression.
An interesting history of Industrial Automaton in the Star Wars universe.
Creating a Scomp link