[HN Gopher] State of Industrial Robotics: Emerging Tech, Challen...
       ___________________________________________________________________
        
       State of Industrial Robotics: Emerging Tech, Challenges, Key
       Research Directions [pdf]
        
       Author : contingencies
       Score  : 37 points
       Date   : 2021-01-06 17:14 UTC (5 hours ago)
        
 (HTM) web link (workofthefuture.mit.edu)
 (TXT) w3m dump (workofthefuture.mit.edu)
        
       | Animats wrote:
       | Strange. That reads like a pitch for Rethink Robotics, a MIT
       | spinoff, from 10 years ago. They were going to make robots that
       | could work alongside humans and do so cheaply. "Baxter" was their
       | first product. It was a flop. The robot was not precise enough
       | for assembly, using it to move things from one place to another
       | wasn't cost effective, and the "learning" wasn't that helpful.
       | 
       | This paper should have examined that critically and discussed
       | what has to be fixed for the next try at this.
        
       | LeifCarrotson wrote:
       | Reading this as a controls engineer who frequently deals with
       | industrial robotics, it looks like there are three main points
       | being made:
       | 
       | 1. Industry 4.0/Cyber-physical systems: Basically, the process of
       | getting a database server to speak Ethercat/Profinet/EthernetIP
       | and upload tag values from all the PLCs in the plant. Then you
       | run some statistics and flag trends or anomalies and have a
       | process engineer squint at the most promising graphs. This is a
       | lot easier to do than of keeping track of cycle time, average
       | sensor values, faults etc. on a whiteboard or clipboard (and
       | don't expect vendors of traditional HMIs to make this easy to do
       | on individual screens...HMIs are one of the most regressive parts
       | of the industry). It's not as complicated as the
       | C-level/government sales pitch makes it sound, but not a bad
       | idea.
       | 
       | 2. Safety around collaborative robots is hard. You want the robot
       | to be able to accelerate heavy objects fast, but also to not hurt
       | the squishy human in the same volume. Part of this can be fixed
       | by improved electronics that can detect ever-smaller torque
       | anomalies so that your 1kg payload robot detects a force more
       | like a 2kg payload and comes to a halt after gently shoving the
       | operator. But there's a fundamental limit where no matter the
       | sensor resolution or how fast you can stop, contact between your
       | 100kg, 2000mm/s cast steel robot arm and somebody's skull is
       | going to hurt the human.
       | 
       | 3. Anyone familiar with natural-language programming, voice
       | interfaces, or domain-specific languages will probably see the
       | hazard they run into with the second point:
       | 
       | > _Improved programming and communication interfaces can enable
       | humans with little programming experience to control robots to
       | perform a variety of tasks,while communication interfaces enable
       | robots to communicate with other hardware and software._
       | 
       | Yes, robotics manufacturers are improving their software - your
       | teach pendant is probably a color touchscreen now, instead of a
       | 480x320 monochrome display with a few softkeys. But solving hard
       | problems is always hard, and it's probably always going to take a
       | programmer (whether that's part of their job title or not) who
       | understands the solution to the problem to express that in a
       | precise way so the software can understand it. Otherwise you've
       | just made a more complicated system that usually solves the
       | problem, and dropping back to a level that actually fully
       | expresses the decision tree leaves you with more complicated
       | interfaces. There's certainly a lot of room to make the interface
       | easier to use, but it's always going to take some programming.
       | Doubly so if you're trying to integrate vision or additional
       | analog axes. Stick with digital sensors, open/close grippers, and
       | highly tolerant processes if you want it to be easy enough for an
       | operator to pick up a pendant and do useful work.
       | 
       | My company, unlike some of our competitors, typically does not
       | lock our customers out of their teach pendants to keep their
       | warranty intact. It does sometimes mean that I need to come back
       | and touch up a point where the operator saw that the robot
       | sometimes failed to make the target and had their technician move
       | it a little too far, so now the parts at the other side of the
       | tolerance range don't fit anymore, but typically both sides are
       | acting in good faith and we work through that.
       | 
       | I think it's going to take some third-party robot software like
       | RoboDK to make this more intuitive. Right now,
       | Yaskawa/Fanuc/Kuka/ABB/Epson/Denso etc. are burdened with:
       | 
       | A) Customer bases who are productive with their legacy teach
       | pendants and Pascal-like programming languages, and have a
       | significant familiarity with their 2000-page manuals.
       | 
       | B) Robot operating systems that work. It's hard to justify
       | starting fresh, so you have to leave the quirks and complexities
       | of old systems.
       | 
       | C) Simulator/IDE software departments that are their own
       | cost/profit center in the automation company. Sure, the company
       | manufactures hardware, but mostly you have to program it with the
       | pendant (which might itself be a line item), the offline IDE is
       | an optional line item that costs several thousand dollars. The
       | offline simulator is extra, vision programming is extra, CAM
       | toolpath generation is extra, each new network interface is
       | extra...
       | 
       | Because of these factors, existing players will have a hard time
       | making things intuitive.
       | 
       | Side note: Figure 2, the 2-position dial table with the light
       | curtains, is a frequently-seen design but IMO a dangerous/bad
       | one. I really hope that blue button is a latch reset, but given
       | that the process is typically to replace the completed assembly
       | in the nest with new unassembled parts, and carry the assembly to
       | pack-out (so your hands are full), everyone involved really wants
       | to make this system self-resetting so the table indexes when the
       | light curtains are restored. Operators and maintenance techs
       | (like, I assume, this guy with the giant wrench) will frequently
       | be tempted to step over the knee wall and into those two small
       | voids adjacent to the dial to reach stuff at the back of the
       | table, or put a knee up on the table to reach something. If they
       | take their other foot out of the horizontal light curtain, fix
       | whatever's broken or interrupt whatever sensor was blocking the
       | condition that prevented the dial table from rotating, they're
       | going for a ride, which is really, really bad. That kneewall
       | should fill the space around the dial so you can't step in the
       | corners, and there should be a floor scanner just above the table
       | (it can also perform the function of the vertical light curtain)
       | to stop the machine when someone's anywhere in the entire volume.
        
       | spieswl wrote:
       | Disclosure: Previously worked for an industrial automation
       | integrator and currently work for a robotics startup.
       | 
       | Weird paper. Reads like a survey of the state of the art from a
       | decade+ ago. Many of the things mentioned are already mature
       | areas of focus for startups and major players in the industrial
       | robotics space. Many startups are working on the portability,
       | ease-of-integration, and ease-of-use problems [0][1]. Cloud-
       | oriented tools tailored to robot, line, and facility level
       | health-and-status monitoring (even beyond the capabilities
       | typically provided by SCADA systems) have been available to buy
       | from major players for a long time [2]. I know Big 3 automakers
       | have been toying around with integrating collaborative robots for
       | years (and another OP already mentioned Rethink). Simulation
       | tools run a pretty wide range of usefulness and market
       | penetration, from first-party tools like ABB's RobotStudio or
       | Fanuc's ROBOGUIDE to tools in the ROS stack to Nvidia's ISAAC
       | simulator [3].
       | 
       | To be fair, I only scanned it but I did not detect the hints of
       | anything useful except for those who are entirely unfamiliar with
       | the industrial manufacturing and robotics space.
       | 
       | [0] https://www.ready-robotics.com/
       | 
       | [1] https://www.olisrobotics.com/
       | 
       | [2] https://www.rockwellautomation.com/en-
       | us/products/software/f...
       | 
       | [3] https://www.nvidia.com/en-us/deep-learning-
       | ai/industries/rob...
        
       ___________________________________________________________________
       (page generated 2021-01-06 23:01 UTC)