Everyone building robots right now is playing with the same Lego pieces. Same compute modules, same software stack, same ROS dependencies pulling in other dependencies pulling in other dependencies until your system needs hardware it would never need if you'd written your own stack. We call it dependency hell. The robotics industry is living in it.
The reason for this is understandable. Someone decided they needed to ship fast. They looked at what already existed. They used it. Then the next team did the same. And now you have a generation of humanoid robots that are basically thin clients — beautifully designed shells that call a cloud server for everything that matters.
We decided not to do that. Here's what that decision actually cost us.
The hardware got more expensive. When your robot is a thin client, your compute requirements are trivial. You need enough processing power to make a network call and interpret a response. When your robot has to run inference on-device — actually run the models, locally, with no external help — the hardware requirements change completely. We built EPIA specifically because the off-the-shelf options weren't efficient enough for what we needed. Building a custom instruction set architecture is not how most robotics companies spend their time. It is, however, what you have to do when you refuse to outsource the intelligence to someone else's server.
Updates got harder. With a cloud-dependent robot, rolling an update means deploying to your server infrastructure. Every robot in the world gets the update simultaneously, automatically, invisibly. With an offline robot, the update process is physical. You take the SD card out of the robot. You connect it to your computer. You burn the new image. You put the card back. It's not complicated — we designed a marketplace that makes this about three clicks — but it requires you to actually do it. We think this is fine. The people who care enough about privacy to buy an offline robot are the same people who understand why this tradeoff exists.
We can't help you remotely. This one is real. If something breaks on your Synthia, we cannot log into her to see what's wrong. There is no remote access. There is no diagnostic connection. There is literally no wireless hardware for such a connection to traverse. If you have a hardware problem, you ship us the board. That's the support model. Some people will read that as a limitation. We read it as the proof of the promise. Any company can claim they don't access your device. We can't access your device. Not because we chose not to — because the hardware doesn't permit it. You can open her up and verify this yourself.
The companies using the Lego pieces can't say any of this. Not because they're dishonest. Because the architecture doesn't allow it.
Top comments (0)