The Origin of Robot Arm Programming Languages | Hacker News Reader

The Origin of Robot Arm Programming Languages

rodneybrooks.com

74 pointsnabla919 comments

It's frustrating how little progress robot manipulation has made in the last half century. Most robotics is still positional programming, maybe with some visual fine tuning for final alignment. Brooks tried to move things into force space, which seemed promising. But his Rethink Robotics robots were not successful. Most of the things you could teach them to do could be done cheaper by other means. Mostly picking up stuff and putting it down somewhere else, in approximately the right place.

Amazon had a competition for bin-picking robots, but never got anything that could replace a few hundred thousand pickers in their fulfillment centers. There's a demand for this, but still few usable products.

SAIL at the D.C. Power Lab (D. C. Power was a Stanford donor) was impressive in its day. They were way ahead in the 1960s and way behind by the end in the 1980s. They had their own custom everything - their own operating system for DEC 36-bit machines, their own compilers, their own networks, their own displays and keyboards, their own video distribution system - and were stuck in their own niche too long.

I used to keep a horse at the barn next to the lab, but by then most of the activity had moved back to the main campus.

Amazon will use bin pickers when minimum wages and collective bargaining hits a deep enough nerve

Wouldn’t a robot with the adaptability and trainablility of a human be, in effect a human? I say this only partially in jest. At one time I drove an old jalopy that developed a broken throttle cable, being poor i contrived a fix by splicing the two ends together with a nut and bolt. I joke to a friend the operation required three hands, one to hold the cable together, one to hold the bolt and one to turn the nut. I often reflect on what would be required to “program” a machine to perform such an operation; under the dash where the steering column transited the floor board, no less.

Of course robots aren’t expected to do such tasks, that’s just an example of a complex task that seems impossible to implement. And there are an infinite number of such tasks in the human repertoire.

I work in robotics, and yes we still do a lot of positional programming although that is starting to change. A couple of outstanding issues exist. (1) Robotics is expensive. Even Chinese manufacturers tend to price robotics grade motors at $500 a piece. (2) Iteration time is long. Our simulation environments are hard to use (poor integration with CAD) and slow (this is changing). Theres also a gap between simulation and reality (which is growing smaller, but still not small enough for everyday use) (3) People's expectations are unrealistic. Its easy to program a robot that can move in a flat non-crowded environment. Its still out of our grasp to be able to get robots to move in a crowded dynamic environment. Similarly, its easy to grasp certain types of objects but handling dynamics of other objects is much harder. (4) A lot of academia tends to focus on rewards, competitions, buzzwords (Deep Learning and RL) and smaller problems that can get them publications. Yet there is little interest in real world problems. There are exceptions to this, but the norm is professors will select low risk projects which use deeplearning to solve a very narrow constrained problem.

What is the difference between standard motors and robotics grade motors?

I would imagine robots like very high torque low speed motors with no backlash. Built in high precision position sensing is also probably nice.

Yep and they will be brushless motors which means a controller that costs at least $85 per axis (though a $500 motor may have that integrated already).

It's application dependent.

If you're making a robot fitting car doors, you want precision and high torque - but you also want high enough speed to keep your cycle times down.

And of course you'll want a magnetic brake that can stop your heaviest payload at top speed, in case there's a power cut or the control software crashes.

But you don't engage the brakes every time you're stationary. So the robot can stay in one place, you'll need enough cooling that you can apply full torque with a stationary motor indefinitely without any heat worries.

And if your robot is industrial? No air holes or fans for you. Gotta find that cooling entirely passively.

Oh, and if it wears out after 2 years of 24/7 operation your users will consider that unreliable. They'll do scheduled maintenance - but they'll still be running robots from the floppy disk era.

What is the problem with cheaper motors? Would a sufficiently smart controller work with a cheaper motor?

Yes, in some low torque, high speed applications, we could design motor controllers that are smarter even for DC brushed motors. Its probably even possible to do force control on them. But these motors will wear out VERY quickly, in the end you will spend more on replacing the motors than if you had started out with a brushless, high precision, lo w backlash, high torque motor. Furthermore, if you need a decent amount of torque most cheap motors can't handle them.

> Amazon had a competition for bin-picking robots, but never got anything that could replace a few hundred thousand pickers in their fulfillment centers. There's a demand for this, but still few usable products.

I was going to say “what did they end up doing with Kiva?”, but the latest marketing [1] suggests “picking is hard, so we use the robots to carry stuff from A => B on a grid”.

What’s your sense on assembly robots at the high end? (E.g., for cars).

[1] https://www.aboutamazon.com/news/operations/new-robots-new-j...

There's a few spin-off companies [0][1] and probably others from that competition. It's coming, but slowly. Humans are simply too good at manipulation and robots too expensive in comparison.

[0] https://fizyr.com/ [1] https://lyro.io/

Rodney,

I worked at Unimation when Vic Scheinman came to demonstrate his robot to myself, Maury Dunne, and Bill Perzley.

Vic set up the robot and the computer. The robot started, typed some words, and typed a command to stop itself. I took an 8mm video of his visit. I sent it to him about a year before he died. (I wonder who has it now).

Vic's arm failed while he was there. One of the motors died. He sent me out for some wire. Then he built a new motor from scratch on the Bridgeport in our lab. I was completely impressed.

Vic was later hired to design the Puma. His desk was next to mine.

I got the VAL language from Vic and Bruce Shimano. I modified and extended it to drive our Unimate from a PDP-11/03. It also drove the 2 arm robot for Ford.

Richard (Lou) Paul was at SRI using a Unimate. He taught myself and Bill Perzley how to use DH-Matrices and the Jacobian for robots. I extended VAL to use some of that math.

Later, at IBM Research (with Russ Taylor and others), we worked on AML, the robot used to drive the IBM robot. I worked on the vision subsystem (Gold Filling) and a multi-address space linking loader. I also added networking to link it to the Boca robot. Ralph Hollis left the group and all of that robot work went with him to Carnegie Mellon. I worked at CMU and visited Ralph often.

I researched a "design-to-buid system". The idea is to start with a CAD drawing of an assembly and automatically construct a robot plan to build it. This was used to assemble a flashlight, driven from AML.

Later still, I worked with Scott Fahlman on Robot-Human cooperation to change a car tire. We used a mashup of Scone (Scott's Knowledge base), a modified version of Forgy's RETE algorithm for rules, a modified form of Alice's natural language, machine learning (to recognize lug nuts), and a custom feedback system to dynamically learn new rules and knowledge from interacting with the human.

These days all of my robot work is in ROS.

Tim

New VAL code is still being written today. The programming language for Omron robots, eV+ (acquired through acquisition of a splinter company off Unimation called Adept) is basically VAL II with some minor syntax changes and new keywords. It's had amazing longevity.

Surprised to see eV+ mentioned on HN... V+, sure, but eV+, interesting... :) The robot world is so much smaller than I thought it was before becoming a part of it.

I was the person who got the VAL language from Victor Scheinman and Bruce Shimano at Unimation.

I wonder what version you are running. I made several modifications to the original code.

I find this super inspiring and equally frustrating. We've made very little progress since these breakthroughs.

I'm working on 3d printed Robotics trained with ultra low data RL, but it just doesn't work well.

Traditional control is too rigid and modern "AI" too unpredictable

Are you using any simulation or when you say “ultra low data” do you mean you collect all data in the physical world?

Do read the footnotes if you read the article.

Reply on news.ycombinator.com