Sure, sure, now you have a robot. How much did it cost you? How much did you have to renovate to install it? How much did you change your material handling? Your part design? Your vehicle design? Your assembly design?

Robots also only really work in stop stations, not on moving vehicles (with a few notable exceptions like paint shop).

Does all of this cost more than hiring a person? More than twice as much?

How often does your automation fail? Is it more than 1 out of 1000 cycles? You have over 10,000 automation steps. That would leave 10 errors per vehicle. When automation fails, it often stays down for a while for investigation and repair. Any station down will stop all stations both before and after it (eventually)

With 10,000 automation steps, and a run rate of 1 vehicle per minute, how often can you lose a robot?

----

Disclaimer, I work for GM; any opinions are solely my own.

I think a lot of people see "automation" as this end-all solution. When in reality it's expensive, unflexible and unstable. Most producing companies don't have good enough preventative maintenance for it to work at all. When you have recurring problems that your own technicians can't solve you're in deep water. It's easy to hire and (unfortunately) fire workers, but a bot you're stuck with.

I see robots/automation as a solution to a problem. That problem is safety. Either repetitive work that slowly breaks down the human, or "this is not good for you"-work that's directly dangerous.

I like that question from the sensei in that goldratt book: "did the robots make you more productive?".

Trying to invest your problems away is a waste of time and money if you don't know, and continously work with your processes. Or what they call kaizen in the article.

Thank you! That’s exactly what a guy from Volkswagen plant told me. They don’t need a 99,9% working robot, because it’s not enough when manufacturing one car each minute. The robot might be cheaper to buy, but they cannot afford to stop the line for such errors.

It is just a matter of time before better, more precise and accurate robots will be created.

Precision is not the biggest issue here. There are very precise robots out there.

The big issue is improvement of standardized work. If you automate early you get tethered by subpar standards. This is natural when you have workers: you iterate work instructions and what tools to use together as a group. This is basically how Toyota is so good at producing: every worker know what to do and when to do it. They haven't always been like this; they have slowly iterated into what they are today.

Improving on work instructions for a robot is tideaus at best, and really, really costly as a worst case: you either re-program, or you're forced to reinvest if the robot isn't capable of the new movements/steps.

Yes, but you still have the problem of bringing this process into your production line and finding out how it makes you more efficient or better.

Musk also had to learn some lessons Toyota learned years ago, because he trusted a bit too much in automation.

If you want to automate something, you need to know exactly all the corner cases, every step of what the human is doing to make it work. The robots are precise enough, but it's often not that easy to describe the tasks to them.

How are these robots programmed? Just a sequence of position movements and affector actions depending on few digital inputs of light curtains or sensors?

In the most simple cases, yes. Parametric programming is popular, where you can define an item and then scale it in a number of factors and only need one program for thousands of possible premutations of that item.

Think about a company that produces screws, they don't have a program for every possible screw they make. Same goes for a more complicated item like a metal box with a door on it.

I work on the automation for some car lines.

The robotics are fine. The problem is, in the off chance that an error happens, the results are absolutely disastrous. The biggest problem being that there are too many potential things that can go wrong and it's very difficult to program the machine to be ready for every possibility.

Some known potential errors are checked for, but a problem is that when the machine detects an error, the line has to shut down so that someone can run over and resolve it. If they have a human doing the job in the first place, the issue can be resolved immediately.

For the most part, automation is just used for major error detection every step of the way (errors being things like cracks in the engine), but a human assembles everything and checks for any errors that the machine can't detect.

Exactly. Thus we see ultra-high automation levels in stamping, painting, and welding, where deviations are minimal. But once in final assembly/trim etc. there is a deviation every few cars! The headliner flops around and won't snap in correctly, the line jerks to a halt just as a nut driver engages, etc. COULD you automate for all these case? Yup. But why would you, when you can have ultra-flexible humans. This was always my question about Tesla's automation quest (now apparently dropped): assume maybe 7 hours in final assembly, say $70 an hour labor fully loaded, call it $500. Put in $100 million in extra automation cut the 7 to 3, how long before THAT pays off? Maybe you CAN do it, but it verges on Juicero: did you really need to automate squeezing a bag of veggie pulp?

I'm not sure of the numbers, but.

Cut 7 to 3, cut 500$ to 200$ say by rounding. Save 300$ per car.

How many cars do you need to recoup the 100 million$? 100m/300= 300k cars. Just one year of model3 production.

I think the bigger problem is in sensor precision, particularly those sensors responsible for reporting what state the arm in (i.e. so the computers onboard can calculate the position of the arm relative to the object it needs to pick up). Sensors with low tolerances are extremely expensive and those particular robot manufacturers may have opted for less accurate sensors to save on costs. They may work perfectly fine for moving things like doors and frames; but the differences make themselves known as soon as you try to interact with bolts and etc.

When I did robotics we had a perfectly capable Linux box running PID loops several hundred times a second; but our robot still sucked b/c our on board motion sensors were simply not precise enough to give us accurate data to feed the algorithms. As usual, it's all about the data.

As someone who works with modern industrial robots, like you'd find in a car factory, the sensors they're using for the arm positioning are unbelievably precise. I can have the robot stopped, with the brakes on, and push on the end of the arm with my fingers and see the joints registering the deviation (and not by 1 or 2 counts, but many more), while I don't perceive any significant movement of the robot.

Forgive me for perhaps being naively optimistic, but I'd probably give industrial robot design engineers applying optimal control methods to solve performance robustness issues the benefit of the doubt that their error budget would properly account for and derate any critical sensor.

Did you remember to low-pass filter the derivative gain? Properly accounting for sensor noise is just as important as getting low-noise sensors.

The vision systems aren't very good in practice.

The interest level in achieving the best result (and the required associated time, patience, planning, skill, and potentially cost) is likely the more limiting factor. I"m saying this as someone that works with vision systems for industrial settings. Often I see garbage images with garbage logic and they complain about garbage output. Then the camera is removed because "it doesn't work".