[Benjie Holson] is an experienced roboticist and wrote an interesting article published on IEEE Spectrum about how the idea most people have of non-roboticists is a myth, and efforts to target this group with simplified robotic frameworks tend to be doomed.
Now, let’s make a couple things absolutely clear right up front: He is not saying robots shouldn’t be easier to program, nor is he saying that non-roboticists literally do not exist (of course they do.) The issues he’s highlighting really come down to product design.
[Benjie] points out that programming robots is super hard, but it’s also hard in more than one way and for more than one reason. And when people try to create a product to make it easier, they tend to commit two big product design no-no’s: they focus on the wrong hard parts, and they design their product for a vaguely-defined audience that doesn’t really exist. That group is the mythical non-roboticist.
These are actually very solid points to make in terms of product design in general. Designing a product that solves the wrong problems for a poorly-defined group isn’t exactly a recipe for success. [Benjie]’s advice on making a truly effective and useful API framework that genuinely lowers the bar of complexity in a useful way is similarly applicable to product design in general.
His first piece of advice is not to design for poorly-defined amorphous groups. Your product should serve actual needs of actual users. If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.
The second is to design as though your users are just as smart as you are, just less tolerant of problems stemming from rough edges like compatibility and configuration issues. Remove those so that your users can get useful work done without having to re-invent the wheel, or resort to workarounds.
Robotic frameworks like ROS are useful and extensible, but whenever someone attempts to focus on creating a simplified framework, [Benjie] says they tend to step on the same rakes. It’s a mistake [Benjie] has committed himself, and see repeated by others. We think his advice is good product design advice in general, whether for designing APIs or something else.
That article makes a lot of good points. The section on BS complexity hits particularly hard. Anyone who’s worked on robotics shares this pain. I’ll work for 10 hours straight on a 3D transformation and mapping algorithm *and enjoy it*. But omfg, the hours of troubleshooting Linux drivers and library compatibility to get to the point where your inputs and outputs work are unbearable.
As a person who has never done anything robots related, what kind of robots is this addressing? In my mind there’s industrial robots, tech demos and toys, and it at least seems that industrial robots of the assembly line kind have been figured out.
This.
They need an intro definition.
> industrial robots of the assembly line kind have been figured out.
They’re now making “co-bots” which are industrial robots designed to work alongside humans rather than being closed off inside wire mesh cages and behind laser curtains etc. Humans are very good at fine manipulation and dexterity, while the robot is very good at doing repetitive tasks like turning screws to exact torque limits, so the combination of both would increase productivity.
The challenge is that the robot is very powerful, extremely fast, heavy, and totally dumb and blind. By the time it senses a mild increase in torque in one of its joints, it has already driven the screwdriver it was holding through the back of your hand. They now need to figure out how to make it safe for people to interact with industrial robots other than from behind a plexiglass shield.
They’ve got that figured out.
The robot has to be stopable/pushbackable by a weak person.
Alternatively the machine needs to be grandfathered and have a limited spindle RPM. The person has to posses self preservation.
Yes, that is one of the solutions – make the machine feeble and slow so it can’t hurt anybody. If a person is within the guard boundary, the machine slows down to the point that a person who’s passed out would not get hurt by accident.
That however isn’t the solution they want, because it’s terrible for productivity.
To illustrate the issue, consider a PLC that has a cycle time of 1 milliseconds. It controls a robot arm that can move at 1 m/s. Between two measurements of any variable, such as detecting an increase in torque of the driving motor, the arm can advance 1 mm.
As they say, two points make a line, three points make a trend. In order to detect a collision, it takes as much as 2 ms or 2 mm of motion at least to confirm that something is happening, which means the screwdriver that the robot is holding is already punching through your skin. The time it takes for the robot to decelerate and stop takes another few milliseconds, which means you end up with a puncture wound and broken bones – and that’s not acceptable.
The difficulty is that the robot isn’t a tool like a drill press, where you know to not put your fingers in the way of the drill bit – it’s a tool that’s supposed to perform multiple different trajectories in 3D space, and if you’re not aware of what it’s supposed to be doing then you’re liable to put yourself in harm’s way.
Let’s just create an AI assistant to handle this, it looks a nice thing to do right?
“If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.”
The author does not understand how EU funding programs work. It’s free money, without doing anything useful to anyone. Hell, what you make does not even have to work. Taxpayers money at its finest.
I can assure you that US government funding programs are just as idiotic as the EU ones.
Where do you think we learned from…
>Hell, what you make does not even have to work.
That’s called basic research. The EU funding mechanisms support projects that build organizations which have the resources and the know-how to perform something meaningful. These “do-nothing” projects either serve as training cases to build up expertise, or they serve to test some idea that might yield further research for actual application.
Of course they can be abused to just do nothing, but then your organization will have a hard time publishing any results and they lose credibility in applying for the funding. After all, you need to beat hundreds or thousands of other applications to get the funding.
Robotics is not difficult compared to a vast number of other subjects eg astro physics, brain science, solving climate change etc. etc. Just expect to deal with terrible incompatibility issues which will destroy desk top computers etc on a regular basis. Recently lost my boot system thanks to a Nvidia Jetpack install :{