"Smarter" robots

[Garlan Garner]

anyone know how long it takes to program the robots on assembly lines, on average?

There really isn't any programing anymore. You move the arm to where you want it (through AI ) and have it weld and then return to rest position or have it change tips and again "physically" or through AI move it to another position and have it do something. Then it can repeat your action. All of 10 min if you know what you are doing.

 

[HankLloydRight]

There really isn't any programing anymore. You move the arm to where you want it (through AI ) and have it weld and then return to rest position or have it change tips and again "physically" or through AI move it to another position and have it do something. Then it can repeat your action. All of 10 min if you know what you are doing.

Not true at all. On the factory tours, driving past each assembly robot, you could clearly see code running on the control panels directing the robots... and as a coder myself, it was pretty identifiable as running code, with standard code structures and a code running environment. What you say is generally true for the welding and glueing robots, but that's by far not the majority of them, there is still significant real coding required.

 

[182RG]

There really isn't any programing anymore. You move the arm to where you want it (through AI ) and have it weld and then return to rest position or have it change tips and again "physically" or through AI move it to another position and have it do something. Then it can repeat your action. All of 10 min if you know what you are doing.

Um, No. Take it from someone who manages teams that programs industrial robotic equipment. Of course, if you listen to EM, you have a machine that builds and trains other machines....sure....

 

[SageBrush]

Um, No. Take it from someone who manages teams that programs industrial robotic equipment. Of course, if you listen to EM, you have a machine that builds and trains other machines....sure....

If Musk had said that, you would almost have a point.

 

[electracity]

Um, No. Take it from someone who manages teams that programs industrial robotic equipment. Of course, if you listen to EM, you have a machine that builds and trains other machines....sure....

You will be replaced by the machine that manages the machine that builds the machine that builds the car. In a couple of Years Tesla will be just Musk and a laptop. Or so I hear. Manufacturing is easy and just needed the right guy to get it organized.

 

[Model 3]

If Musk had said that, you would almost have a point.

He has been talking about the machine that builds the machine. He was just taking it one more step - to the machine that builds the machine that builds the machine

 

[Garlan Garner]

One last post concerning the robot assembly lines I write python libraries for.

This one was extremely exciting to me.

A company purchased 32 robot arms to produce a product. 16 robots on each side. The first robot on the line was to be fed a chassis that was about 6 feet by 9 feet from a mobile robot that took the chassis from a press about 19 feet away. Anywhoo, the chassis weighed 79 pounds. We initiated hand-in-glove learning down the entire line. Robot #1 was to take the chassis from the mobile robot vertically with the chassis facing the robotic arm and then turn it horizontal and rotate itself 90 degrees and place it down on the preformatted assembly line. At the end of the assembly line there was a fully formed aluminum frame ( 30 individual aluminum parts of the press and 612 cold welds )ready for paint. The initial assembly line was running at a pace of 0.5 frames per minute. Fully repeatable within .0001% precision rate. Almost absolute perfection.

We watched as the robots were networked and the arms learned new efficiencies on their own and suggested to us after 3 hours that they could actually run at 1 frame per minute with no change in power / heat / nor noise due to their newly learned and implemented efficiencies. We clicked on robot #6 which made the suggestion and it propagated our response to all 32 robots and they acclimated themselves to the new schedule.

Robot #1's original routine was to 1. pick up a counter weight and place it on the back of its own arm to counter balance the 97lb chassis it took from the mobile transport robot. Then #2 place the chassis down on the assembly line...and then #3 perform 6 cold welds with a different attachment.
To our shock....once we accepted the newly suggested routine from Robot #6......Robot #1 no longer needed the counter balance....because....it used another library package called centripetal / centrifugal spin. Robot #1 took the chassis from the mobile robot and spun this huge chassis at a rate of 1 revolution per 1.3 seconds and used the centripetal force to lighten the weight of the chassis therefore eliminating the need for the counter balance weights to place the chassis down on the assembly line. Robot #1 removed an entire step in the process by using the calculations of the options in its own library. AND it no longer performed the welds. Robot #4 performed the cold welds that Robot #1 was performing as it welded in frame part #12. It was suggested by the robots that the frame was more rigid that way. It was amazing to see the adjustments by the Robots.

We then increased the completion rate to 2 fully formed frames per minute and the Robots ran for another 3 hours and determined that of the 32 robots @ at completion rate of 2 fully formed frames per minute that Robot # 21 was not necessary.....Robots 20 and 22 started doing the job or Robot #21 and it was eliminated from the line automatically. The company we sold the assembly line to was more than happy to get a $612k reduction in costs. One good thing about robots in this scenario as opposed to humans....there was no disgruntlement by Robot 21 that lost its job. There was no loss of pride, ego. There was no HR fight nor meetings needed. It just happily shut itself down at the agreed efficiency of the entire assembly line.

There is no central intelligence unit in our lineups. Each robot can be the chief steward which can be manually selected or automatically selected in our self healing design. This company essentially had 32 central computers each capable of handling the entire line. All we do is SSH to the default IP address of the line and find out who the robot leader is if we want to interface with it. Otherwise we all check our email boxes and/or texts on our cell phones as to different snmp trap decisions by the entire network of robots.

Ok....I've bored you enough. Its just soo cool. I can't wait to get to work in the morning and write some more libraries. BTW we sell efficiency libraries to our clients to improve their processes....that's one of the primary products that we offer. That centripetal library was written for another client 2.5 years ago by my partner DH. Kinda sounds like a company named Tesla that sends out updates ( maybe assembly language or something ) autonomously to its robots......I mean our cars. lol

 

[Gen3Joe]

One last post concerning the robot assembly lines I write python libraries for.

This one was extremely exciting to me.

A company purchased 32 robot arms to produce a product. 16 robots on each side. The first robot on the line was to be fed a chassis that was about 6 feet by 9 feet from a mobile robot that took the chassis from a press about 19 feet away. Anywhoo, the chassis weighed 79 pounds. We initiated hand-in-glove learning down the entire line. Robot #1 was to take the chassis from the mobile robot vertically with the chassis facing the robotic arm and then turn it horizontal and rotate itself 90 degrees and place it down on the preformatted assembly line. At the end of the assembly line there was a fully formed aluminum frame ( 30 individual aluminum parts of the press and 612 cold welds )ready for paint. The initial assembly line was running at a pace of 0.5 frames per minute. Fully repeatable within .0001% precision rate. Almost absolute perfection.

We watched as the robots were networked and the arms learned new efficiencies on their own and suggested to us after 3 hours that they could actually run at 1 frame per minute with no change in power / heat / nor noise due to their newly learned and implemented efficiencies. We clicked on robot #6 which made the suggestion and it propagated our response to all 32 robots and they acclimated themselves to the new schedule.

Robot #1's original routine was to 1. pick up a counter weight and place it on the back of its own arm to counter balance the 97lb chassis it took from the mobile transport robot. Then #2 place the chassis down on the assembly line...and then #3 perform 6 cold welds with a different attachment.
To our shock....once we accepted the newly suggested routine from Robot #6......Robot #1 no longer needed the counter balance....because....it used another library package called centripetal / centrifugal spin. Robot #1 took the chassis from the mobile robot and spun this huge chassis at a rate of 1 revolution per 1.3 seconds and used the centripetal force to lighten the weight of the chassis therefore eliminating the need for the counter balance weights to place the chassis down on the assembly line. Robot #1 removed an entire step in the process by using the calculations of the options in its own library. AND it no longer performed the welds. Robot #4 performed the cold welds that Robot #1 was performing as it welded in frame part #12. It was suggested by the robots that the frame was more rigid that way. It was amazing to see the adjustments by the Robots.

We then increased the completion rate to 2 fully formed frames per minute and the Robots ran for another 3 hours and determined that of the 32 robots @ at completion rate of 2 fully formed frames per minute that Robot # 21 was not necessary.....Robots 20 and 22 started doing the job or Robot #21 and it was eliminated from the line automatically. The company we sold the assembly line to was more than happy to get a $612k reduction in costs. One good thing about robots in this scenario as opposed to humans....there was no disgruntlement by Robot 21 that lost its job. There was no loss of pride, ego. There was no HR fight nor meetings needed. It just happily shut itself down at the agreed efficiency of the entire assembly line.

There is no central intelligence unit in our lineups. Each robot can be the chief steward which can be manually selected or automatically selected in our self healing design. This company essentially had 32 central computers each capable of handling the entire line. All we do is SSH to the default IP address of the line and find out who the robot leader is if we want to interface with it. Otherwise we all check our email boxes and/or texts on our cell phones as to different snmp trap decisions by the entire network of robots.

Ok....I've bored you enough. Its just soo cool. I can't wait to get to work in the morning and write some more libraries. BTW we sell efficiency libraries to our clients to improve their processes....that's one of the primary products that we offer. That centripetal library was written for another client 2.5 years ago by my partner DH. Kinda sounds like a company named Tesla that sends out updates ( maybe assembly language or something ) autonomously to its robots......I mean our cars. lol

Thank you for the post. This stuff is very interesting to me.

 

[animorph]

Thanks for the posts Garlan. Way more advanced than I was imagining!

 

[sandpiper]

One last post concerning the robot assembly lines I write python libraries for.

This one was extremely exciting to me.

A company purchased 32 robot arms to produce a product. 16 robots on each side. The first robot on the line was to be fed a chassis that was about 6 feet by 9 feet from a mobile robot that took the chassis from a press about 19 feet away. Anywhoo, the chassis weighed 79 pounds. We initiated hand-in-glove learning down the entire line. Robot #1 was to take the chassis from the mobile robot vertically with the chassis facing the robotic arm and then turn it horizontal and rotate itself 90 degrees and place it down on the preformatted assembly line. At the end of the assembly line there was a fully formed aluminum frame ( 30 individual aluminum parts of the press and 612 cold welds )ready for paint. The initial assembly line was running at a pace of 0.5 frames per minute. Fully repeatable within .0001% precision rate. Almost absolute perfection.

We watched as the robots were networked and the arms learned new efficiencies on their own and suggested to us after 3 hours that they could actually run at 1 frame per minute with no change in power / heat / nor noise due to their newly learned and implemented efficiencies. We clicked on robot #6 which made the suggestion and it propagated our response to all 32 robots and they acclimated themselves to the new schedule.

Robot #1's original routine was to 1. pick up a counter weight and place it on the back of its own arm to counter balance the 97lb chassis it took from the mobile transport robot. Then #2 place the chassis down on the assembly line...and then #3 perform 6 cold welds with a different attachment.
To our shock....once we accepted the newly suggested routine from Robot #6......Robot #1 no longer needed the counter balance....because....it used another library package called centripetal / centrifugal spin. Robot #1 took the chassis from the mobile robot and spun this huge chassis at a rate of 1 revolution per 1.3 seconds and used the centripetal force to lighten the weight of the chassis therefore eliminating the need for the counter balance weights to place the chassis down on the assembly line. Robot #1 removed an entire step in the process by using the calculations of the options in its own library. AND it no longer performed the welds. Robot #4 performed the cold welds that Robot #1 was performing as it welded in frame part #12. It was suggested by the robots that the frame was more rigid that way. It was amazing to see the adjustments by the Robots.

We then increased the completion rate to 2 fully formed frames per minute and the Robots ran for another 3 hours and determined that of the 32 robots @ at completion rate of 2 fully formed frames per minute that Robot # 21 was not necessary.....Robots 20 and 22 started doing the job or Robot #21 and it was eliminated from the line automatically. The company we sold the assembly line to was more than happy to get a $612k reduction in costs. One good thing about robots in this scenario as opposed to humans....there was no disgruntlement by Robot 21 that lost its job. There was no loss of pride, ego. There was no HR fight nor meetings needed. It just happily shut itself down at the agreed efficiency of the entire assembly line.

There is no central intelligence unit in our lineups. Each robot can be the chief steward which can be manually selected or automatically selected in our self healing design. This company essentially had 32 central computers each capable of handling the entire line. All we do is SSH to the default IP address of the line and find out who the robot leader is if we want to interface with it. Otherwise we all check our email boxes and/or texts on our cell phones as to different snmp trap decisions by the entire network of robots.

Ok....I've bored you enough. Its just soo cool. I can't wait to get to work in the morning and write some more libraries. BTW we sell efficiency libraries to our clients to improve their processes....that's one of the primary products that we offer. That centripetal library was written for another client 2.5 years ago by my partner DH. Kinda sounds like a company named Tesla that sends out updates ( maybe assembly language or something ) autonomously to its robots......I mean our cars. lol

Hi Garlan

Is this being done in an academic environment? I've done quite a lot with industrial robots, including a limited amount with Kuka, and have never seen a system where robots are collaboratively self optimized in this way. What software is being used to do this? I'm not aware of any Kuka software that does this.

I'm also don't quite follow the the counterweight / spinning comment. Obviously spinning a part doesn't make it lighter. Could you explain?

 

[Garlan Garner]

Hi Garlan

Is this being done in an academic environment? I've done quite a lot with industrial robots, including a limited amount with Kuka, and have never seen a system where robots are collaboratively self optimized in this way. What software is being used to do this? I'm not aware of any Kuka software that does this.

I'm also don't quite follow the the counterweight / spinning comment. Obviously spinning a part doesn't make it lighter. Could you explain?

We use Kuka robots and our own Python controlled library driven propriety interfaces. That's why we can sell what no one else can. Kuka doesn't make this software.....we do. That way we can use any robots with our libraries and extremely simple interfaces.

Indeed a spinning part changes the needed torque ratios for raising and lowering a part. Any imbalances imposed by the weight of an object as it moves through time and space forces the perceived weight of the object to remain constant at the point of lift. That's why a gyroscope'd object weighs the same from every vantage point while it is spinning. If an object is 100 pounds and you pick it up anywhere off of dead center the torque required to lift that object is more than 100lbs and exponentially increases the more off center you are. Now spin that object at its saturation point and it will only ever weigh 100lbs no matter what. Robots were picking up the frame off dead center because of how the frame was made. Then the program decided that picking up the frame off dead center however rotating it from dead center reduced the need for counter weights to lift 180 pounds.

In other words...... If the dead center of your body weight existed in the center of your chest....then if I picked you up at your knee...I would need about twice to 3 times the weight of your body to pick you up.......however.......if I picked you up at your knee and my elbow was at the center of your chest at that point ( just let it be true for a min ) THEN......if I were to spin you around at the axis of my elbow then the only weight I would have to lift is your body weight. That's what the robots did. They found the axis point of the frame ( which was off center on the x-y axis ) and placed on of its elbows at that balanced point and spun the frame around to lift the frame from that point reducing the required "Frame weight" ( counter weight = 0 ) it took to lift the frame from the mobile robot and place it on the line.

 

[sandpiper]

We use Kuka robots and our own Python controlled library driven propriety interfaces. That's why we can sell what no one else can. Kuka doesn't make this software.....we do. That way we can use any robots with our libraries and extremely simple interfaces.

Indeed a spinning part changes the needed torque ratios for raising and lowering a part. Any imbalances imposed by the weight of an object as it moves through time and space forces the perceived weight of the object to remain constant at the point of lift. That's why a gyroscope'd object weighs the same from every vantage point while it is spinning. If an object is 100 pounds and you pick it up anywhere off of dead center the torque required to lift that object is more than 100lbs and exponentially increases the more off center you are. Now spin that object at its saturation point and it will only ever weigh 100lbs no matter what. Robots were picking up the frame off dead center because of how the frame was made. Then the program decided that picking up the frame off dead center however rotating it from dead center reduced the need for counter weights to lift 180 pounds.

In other words...... If the dead center of your body weight existed in the center of your chest....then if I picked you up at your knee...I would need about twice to 3 times the weight of your body to pick you up.......however.......if I picked you up at your knee and my elbow was at the center of your chest at that point ( just let it be true for a min ) THEN......if I were to spin you around at the axis of my elbow then the only weight I would have to lift is your body weight. That's what the robots did. They found the axis point of the frame ( which was off center on the x-y axis ) and placed on of its elbows at that balanced point and spun the frame around to lift the frame from that point reducing the required "Frame weight" ( counter weight = 0 ) it took to lift the frame from the mobile robot and place it on the line.

Hi Garlan

Interesting. PM me. Is this a commercial product or an in-house development for internal use? I'm slightly familiar with Octopuz, which is a brand agnostic programming environment. It sounds like you've done something similar?

Re: physics. Your language is a little fuzzy, but it sounds like you were picking it up off of CG, causing an increased moment / torque load on the affected joints? And then you moved closer to on-CG, which doesn't change the weight of course, but can definitely reduce the moment load on the joints. It's interesting that the robot software was able to auto tune this. I've never heard of something like this being done in a working environment.

 

[Garlan Garner]

Mod note - Garlan's fascinating description of robot controls started to sound a bit like an advertisement.

I think it is "all good" for the moment, but do be careful not to use this forum as a way to sell a product or service without discussing it first with the forum owners.


Personally, it made me ponder if the robot control software has a full 3D idea of the objects they were manipulating... (?) My very limited understanding of all this starts with the thought that the biggest worry with custom robot programming is that you don't ever want the robot to damage itself ($$$) and the biggest risk there is having it collide with another robot arm or something it is carrying. If they are taking to spinning parts and changing choreographed movements, how much safety is baked in to prevent robot damage?

I vaguely recall a story from the early days of Tesla factory set-up where a programming goof with the paint shop robots caused two arms to collide causing expensive damage.

Really?

I didn't mention names of individuals nor a company or anything. Name the company I'm advertising for.......no one. I didn't mention any companies. Really?

Am I PMing anyone about my posts? No. You can see my PM's also.

I'm truly surprised and offended. Wow.

 

[brianman]

I'm truly surprised and offended. Wow.

I think TEG worded his post well. I don't see why you would be offended. Nonetheless, moving on...

Regarding "spinning parts and ... choreographed movements", I'd like to see a new AI built to analyze the patterns of movement and recommend (and synchronize) background music for the factory tour.

 

[Garlan Garner]

I think TEG worded his post well. I don't see why you would be offended. Nonetheless, moving on...

Regarding "spinning parts and ... choreographed movements", I'd like to see a new AI built to analyze the patterns of movement and recommend (and synchronize) background music for the factory tour.

The only time ever took and opportunity to speak about what I do for a living while carefully wording all of my posts to avoid such accusations. And now.... to no avail.

 

[gregincal]

The only time ever took and opportunity to speak about what I do for a living while carefully wording all of my posts to avoid such accusations. And now.... to no avail.

I think you misunderstood his post. He explicitly said what you did was fine, he was warning others not to take what you did further and cross the line.

 

[Garlan Garner]

I think you misunderstood his post. He explicitly said what you did was fine, he was warning others not to take what you did further and cross the line.

thanks.

maybe I can hire people like this guy.

Chicago Tesla Research Study - $450

 

[EValuatED]

The only time ever took and opportunity to speak about what I do for a living while carefully wording all of my posts to avoid such accusations. And now.... to no avail.

I've thoroughly enjoyed your recent posts. I understand where the mod was coming from in general, but personally didn't see you crossing the line, imho. I work for a company that provides, among other things, design, modeling & simulation, and manufacturing control software. So I've occasionally shared some perspectives in this and other forums about modern manufacturing and driving right into production, exponential ramp up from partial hand assembly to full automated, et al (which is also being done in the Gigafactory to supply our future M3s). I'll ask you here to keep sharing -- I'm sure I'm not alone in enjoying your real world, hands-on perspectives -- thanks!

 

[TEG]

thanks.
maybe I can hire people like this guy:
(Study research link removed)

Thanks for pointing that out. I reported the study solicitation post to the admins. They are particular about that kind of thing.

 

[drewfaulk]

We use Kuka robots and our own Python controlled library driven propriety interfaces. That's why we can sell what no one else can. Kuka doesn't make this software.....we do. That way we can use any robots with our libraries and extremely simple interfaces.

Indeed a spinning part changes the needed torque ratios for raising and lowering a part. Any imbalances imposed by the weight of an object as it moves through time and space forces the perceived weight of the object to remain constant at the point of lift. That's why a gyroscope'd object weighs the same from every vantage point while it is spinning. If an object is 100 pounds and you pick it up anywhere off of dead center the torque required to lift that object is more than 100lbs and exponentially increases the more off center you are. Now spin that object at its saturation point and it will only ever weigh 100lbs no matter what. Robots were picking up the frame off dead center because of how the frame was made. Then the program decided that picking up the frame off dead center however rotating it from dead center reduced the need for counter weights to lift 180 pounds.

In other words...... If the dead center of your body weight existed in the center of your chest....then if I picked you up at your knee...I would need about twice to 3 times the weight of your body to pick you up.......however.......if I picked you up at your knee and my elbow was at the center of your chest at that point ( just let it be true for a min ) THEN......if I were to spin you around at the axis of my elbow then the only weight I would have to lift is your body weight. That's what the robots did. They found the axis point of the frame ( which was off center on the x-y axis ) and placed on of its elbows at that balanced point and spun the frame around to lift the frame from that point reducing the required "Frame weight" ( counter weight = 0 ) it took to lift the frame from the mobile robot and place it on the line.

Loved the informative post. Don't know what all the fuss is about. I thought it was a thoughtful, well-written, informative, post within which he makes complicated material understandable to the layman and cannot contain his exuberance for what he does for a living (frankly, I'm jealous). It sounds like he's a really bright guy with a cool job that he thought the rest of us early adopters would appreciate hearing about.