The original version of this post by Benjie Holson was posted here on Substack and includes: This is Benjie’s original comic, part of a series about robots and startups.
I worked on this idea for months before deciding it was a mistake. The second I heard someone mention it I thought, ‘That’s weird. These two groups had the same idea. “Maybe we should tell them it didn’t work for us.” The third and fourth time I just rolled my eyes and ignored it. The fifth time I heard about a group struggling with this mistake, I decided it was worth a blog post on its own. I call this idea the “mythical non-robotics.”
mistake
Here’s the idea: Robot programming is difficult. And then there are people with really arcane skills and PhDs that are really expensive and for some reason seem to be absolutely necessary. Wouldn’t it be nice if we could do robotics without them?
One What if everyone could do robotics? Wouldn’t it be great? Even if you’re not a roboticist, you need to create a software framework so you can program robots.
This idea is so close to the right idea that it’s hard to explain why it wouldn’t work. On the surface, it doesn’t.
wrong: All other things being equal, it would be nice if programming robots were more accessible. The problem is that there is no good way to build a working robot. So we don’t know how to make that recipe easier to follow. To keep things simple, people end up getting rid of things they might need. Because no one knows for sure what is absolutely necessary. It’s like saying you want to invent an invisibility cloak and be able to make it from materials you can buy at Home Depot. Sure, that would be nice, but if you invented an invisibility cloak that required some mercury and neodymium to make, would you throw away the recipe?
These mistakes in robotics are based on very real and practical observations. robot programming
is It’s very difficult. It is famous for being difficult. It would be great if programming robots became easier. The problem is that there are two different kinds of hard parts to programming robots.
Robots are difficult because the world is complex.
Moore Studios/Getty Images
The first difficult part is that we are dealing with a real world where robots sense imperfectly and act imperfectly. Globally mutable state is bad programming style because it’s really hard to deal with, but for robotics software the entire physical world is globally mutable, so you can unreliably observe it and hope the operation is similar to what you’re trying to achieve. Making robotics work often pushes the limits of an individual’s ability to reason and requires the flexibility to use whatever heuristics work for a particular problem. this
essential Complexity of the problem: Robots live in a complex world, for every working solution there are millions of solutions that do not work, finding the right solution is difficult and often highly dependent on the task, robot, sensors and environment.
People look at the challenge, see that it’s very difficult, and decide that of course some cool roboticist might be able to solve it in that particular scenario. But what about “normal” people? “We need to make this possible for non-roboticians,” they say. I call these users “mythical non-robotics.” Because once they program the robot, they feel like:
become Robotic engineer. Aren’t people who program robots for a purpose a roboticist? Stop gatekeeping.
Don’t design for amorphous groups
I also call them “mythical.” Because “non-robotics,” as it is commonly implied, is a vague and amorphous group. Don’t design for amorphous groups. If you can’t name three real people (people you talk to) that your API is intended for, then you’re designing for an amorphous group, and only amorphous people will like your API.
And with this nebulous group of users in mind (and seeing how difficult it all is), people think, “Wouldn’t handling these things with a simple API make this easier for everyone else?”
no. I can’t do that. stop it.
Simple APIs cannot ignore their inherent complexity.
A simple API cannot handle the complexity of the problem.. Inevitably, you’ll end up with a beautiful-looking API with calls like “grasp_object” and “approach_person”, which we demonstrate brilliantly in the hackathon kickoff. But for someone actually trying to complete the task, it lasts about 15 minutes. It turns out that for certain applications, “grasp_object()” makes 3 or 4 incorrect assumptions about “grasp”. and It’s an “object” and doesn’t work at all.
Your users are as smart as you are.
The situation is made even worse by the widespread assumption that these people are less intelligent (read: less intelligent) than the people who created this magical framework.
2 This sense of superiority makes designers desperately cling to the beautiful and simple “grasp_object()” and refuse to add the handles and arguments needed to handle more use cases and customize it to what the user wants.
Ironically, this creates a lot of complexity for users of the poor API, who have to find clever workarounds to make the API work properly.
Moore Studios/Getty Images
The sad, salty, bitter icing on this cake of frustration is that, even when done really well, the goal of these kinds of frameworks is to expand the group of people who can get the work done. And achieving this requires sacrificing some performance that can only be gained by highly specializing the solution to the problem. If you live in a world where a professional roboticist can program a robot that works really well, but the demand for robots is so high that people don’t have enough time to do all the programming, this would be a great solution.
three
What’s clear is that even hard-core, card-carrying roboticists who do their best work (except in truly constrained environments like manufacturing cells) struggle to come close to the level of performance that builds their robots. Despite the long timeline and massive financing, it is commercially viable.
4 we don’t have any Headroom that allows you to sacrifice power and efficiency for ease.
What problem are we solving?
So should we give up on making it easier? Is robotics development only a small, elite group of people with outstanding PhDs?
5 Neither! I have worked with numerous undergraduate interns who are fully capable of robotics engineering.6 I myself have mostly taught myself robot programming.7 There are a lot of inherent complexities in making robots work, but I don’t think there are any more than video game development.
In robotics, as in everything, experience helps, some things can be taught, and once you master many areas you will see things start to connect together. These technologies are not magical or limited to robotics. We are not as special as we think.
But what about making robot programming easier? Remember when I said at the beginning of the post that there are two different kinds of hard parts? One is the inherent complexity of the problem, and it’s going to be difficult no matter what.
8 But the second is collateral complexity, or as I like to call it, stupid BS complexity.
Stupid Bachelor Complexity
Robots are asynchronous, distributed, real-time systems with strange hardware. It’s going to be hard to configure everything for some stupid BS reason. That driver will have to work on whatever weird flavor of Linux you want for real-time control, and getting it all set up will be difficult for some stupid BS reason. You’re abusing Wi-Fi to ensure smooth, uninterrupted roaming, but Wi-Fi in Linux doesn’t want that. The log files are large and need to be uploaded somewhere to avoid filling up the robot. You need to integrate with the cloud and deal with some stupid BS.
9
Moore Studios/Getty Images
There’s a ton of work to be done before we even get to the complexities of handling 3D rotation, reference frame translation, time synchronization, and messaging protocols. These things have both inherent complexity (you have to think about when something is observed and how to reason about it as other things move) and stupid BS complexity (someone multiplied two transformation matrices in the wrong order, so there’s a weird bug and now Does this mean that in some protocols you will get an error message saying that the quaternion is not normalized?)
10
One of the biggest challenges in robot programming is navigating the sea of silly BS you have to wrestle with while programming.
start We are working on interesting and challenging robotics problems.
So here’s a simple heuristic for creating a good API:
Design your API for people who are as smart as you but less tolerant of stupid BS.
It’s a universal enough feeling that I’m tempted to call it
Holson’s Rules of Acceptable API Design.
When you use a tool you made, you know it well enough to know the rough edges and how to avoid them.
However, the rough part is something that should be kept in the programmer’s memory while the programmer is using the system. If you insist on creating a robot framework
11, we should try to make it as powerful as possible with the least amount of stupid BS. Eliminate collateral complexity wherever possible. I want to create an API that maximizes flexibility but still has good defaults. I like Python’s default argument syntax. Because it means you can write an API that can be used like this:
It is possible to make easy things simple
and Allow for complexity. And please, please, don’t make an arrogant API. thank you!
1. Ironically, the people who suggest this are often PhDs with expensive, arcane knowledge.
2. Why always a framework?
3. Exceptions that can prove the rule are things like traditional manufacturing cell automation. This is where solutions exist, but the limitation to scale is the cost of setup. I am not an expert in this field, but I worry that physical installation and safety compliance may still dwarf the cost of software programming.
4. I know this from personal experience.
5. Or, for that matter, earned a PhD that you don’t really like?
6. I think many smart high school students could do that. But there are no good examples because Google tends not to hire them.
7. My school was in mechanical engineering and I never got a PhD. However, the ME class included some programming fundamentals.
8. Unless we create effective general-purpose AI. It feels strange to have to add that caveat, but the reality is that the possibility of robotics appearing in my lifetime is now much more likely than it was two years ago.
9. And if you’re unlucky, that API was designed by someone who thinks they’re smarter than their customers.
10. This special feature of BS complexity is why I wrote posetree.py. If you do robotics, definitely check it out.
11. Judging by the trail of dead robot framework companies, this is a difficult task.
From your site article
Related articles on the web
