The original version of this post by Benjie Holson was published on Substack here, and includes Benjie’s original comics as part of his series on robots and startups.

The Misconception

The notion goes something like this: Programming robots is hard, and it seems to require people with arcane skills and expensive PhDs. Wouldn’t it be great if we could do robotics without them? Imagine if everyone could program robots—surely, that would be fantastic. Let’s create a software framework so non-roboticists can program robots.

This idea is close to being correct, making it tricky to understand why it doesn’t work. On the surface, it’s not wrong: Making robot programming more accessible would be beneficial. The problem is that we lack a solid recipe for building functional robots, so we can’t simplify something we don’t fully understand. In the quest to make things simple, crucial elements are often removed because no one knows for sure what’s absolutely required. It’s like wanting to invent an invisibility cloak using materials from Home Depot. Sure, that would be nice, but if the cloak required mercury and neodymium, would you discard the recipe?

The Two Kinds of Complexity

Robotics programming is hard for two main reasons. Firstly, robots interact with the real world, which is inherently complex. The world is imperfectly sensed and imperfectly actuated, making the entire physical world a global mutable state that we can only observe unreliably. This intrinsic complexity means that getting robotics to work requires flexibility and the ability to employ various heuristics for specific problems.

Secondly, there is the challenge of incidental complexity—what I call “stupid BS complexity.” Robots are asynchronous, distributed, real-time systems with unusual hardware, leading to many configuration challenges for trivial reasons. For instance, getting drivers to work in a specific Linux flavor for real-time controls can be surprisingly difficult. Before tackling the intrinsic complexities of 3D rotation, moving reference frames, and time synchronization, one must wade through a sea of incidental complexities.

Designing for Real Users

A common mistake is designing frameworks for an amorphous group of “non-roboticists.” If you can’t name three real people for whom your API is intended, you’re designing for an abstract group, which leads to unusable APIs. Simplifying APIs to make them more accessible often results in oversimplification, which fails to cover the complexity of real-world problems. For example, an API call like “grasp_object” might look nice in a demo but fall apart under real-world conditions due to incorrect assumptions about “grasp” and “object.”

Respecting Users’ Intelligence

Assuming that users are less savvy than the framework creators is a pervasive issue. This feeling of superiority leads designers to resist adding necessary complexities, forcing users to devise workarounds for the oversimplified APIs. The goal should be to create powerful APIs with the least amount of incidental complexity, providing maximum flexibility with sensible defaults. This approach, which I refer to as Holson’s Law of Tolerable API Design, respects the intelligence and capability of the users.

Conclusion

While the dream of making robot programming accessible to everyone is appealing, it is important to acknowledge and address both the intrinsic and incidental complexities involved. Instead of oversimplifying and designing for vague user groups, we should focus on creating flexible, powerful tools that minimize unnecessary complications. By doing so, we can make progress in making robotics more accessible without sacrificing the effectiveness and performance required for real-world applications.