The Sim-First Approach to Automation

In today's economic climate, manufacturing industries are under increasing pressure to maximize productivity, cut costs, and deliver quality products faster. This is where robotic automation steps in, revolutionizing the way we manufacture. Robots solve the much-discussed skills gap, and enhance production by providing speed, precision, and 24/7 operation. They're the key to ramping up productivity, reducing errors, and fostering safer work environments. Additionally, they offer the ability to rapidly scale operations to respond to market demands, a critical factor in today's fast-paced economy.

Amidst the evolution into the era of Industry 4.0 (some would say we are already in 5.0), the adoption of robotic automation is not just an advantage, it's a necessity for businesses to remain competitive, foster innovation, and facilitate sustainable growth. However, the complexity of robotic automation brings challenges, especially as manufacturing continues to transition into a just-in-time, high-mix low-volume endeavor.

In the article series linked above, I've talked previously about one of these key complexities, specifically the difficulty of programming industrial robots and how to manage the fragmented robot and peripheral landscape through common software platforms, like our own ForgeOS. However there are a lot of nuts and bolts (so to speak) that go into a robotic cell, and with the fastest programming experience in the world, these are still a challenge.

The Status Quo

Below I've tried to paint a picture of everything that goes into a robotic cell - not just the robot and hardware, but the effort that goes into it - the design, validation, analysis, and ultimate deployment into production. I've broken these efforts down by the tool that is traditionally used to perform them, and where that effort takes place.?

You will notice that many of these activities are performed in CAD, which has been transformative to mechanical design since its invention. Unfortunately, this tool starts to show some weaknesses when we start to throw robotic design tasks its way. When it comes to designing the custom mechanisms needed for a robot cell - custom fixtures, part presentation, gripper fingers - CAD excels. However, when we get into subsequent activities, such as work cell analysis, we start to see some cracks.

Take for example reach analysis, the simple step to make sure an equipped robot can actually reach and grab what it needs to perform its task. Because of how most CAD packages model articulated bodies like robots (typically with mates), it can be highly clunky to even stretch a robot out to see how far it can reach. Furthermore, when we look at activities like the placement of safety sensors, we end up drafting lots of cones and spheres to "represent" the field of view of these sensors. It's just not something CAD was really designed for.

Another pattern we see in the above automation workflow is just how much work is done, not in software, but in the physical world. When building a robotic cell, most of the programming and subsequent validation of this program is performed on real hardware. In the case of an integrator building the cell, this is done at their facility, and in the case of a manufacturer building their own cell, it is done on-site (and hopefully in an area not critical path to production, although cells are often built and programmed in place). This means that the part of the deployment with the most risk to success - the programming and validation of the actual process - is happening once things are bolted to the floor.?

It is a problem when our best opportunity to find issues in a robotic cell is when it is already installed, and hardest to change

Robotic automation is a fussy business - a metal-on-metal business, and that means that small things like materials, friction, and tight tolerances can have lasting effects on the success and reliability (or lack thereof) of a robotic cell. So traditionally, this prove-out once things have been installed makes sense - that is where you will find the 20% you missed during design (and also spend 80% of the time debugging). But the fact remains that this programming and analysis is happening in the most expensive place possible, in the real world (or more wallet-burning, in production). It is a problem when our best opportunity to find issues in a robotic cell is when it is already installed, and hardest to change, especially when it comes to safety analysis, which I could write a whole separate article on.

A Move to Sim-First

So then what is sim-first? Well, it's a strategy to alleviate the situation, both the fact that we have a tool, CAD, which is non-optimal for a lot of robotic automation activities, and also the fact that much of our programming and validation of these systems (especially safety analysis, which is another expensive endeavor) is done once everything is purchased, bolted down, and in some cases installed.

Below I've taken the same activities that we see in the above figure, but I've introduced a new tool - simulation. Let's look at how these activities stack up now, especially when we look at where these activities are occurring:

Simulating manufacturing processes is nothing new, but I hope this illustrates just how transformative this tool can be. Firstly, we are using CAD for what it is perfect for - designing the mechanical assets needed for the cell. The other activities it was sub-optimal for, like quickly arranging layouts, modeling how robots really move, and modeling safety hardware like cameras and sensors, we now do in a simulation tool designed specifically for these efforts.

...we can now program the cell in simulation too, before even buying hardware.

With READY's ForgeOS, which can now work in a desktop setting alongside simulation tools, we can now program the cell in simulation too, analyzing the performance of the process and the motions of the robot, looking at part flow, making tweaks, and revising things, all in the comfort of our own computer - and far away from the eye-watering cost of the factory floor. We can even perform risk assessments in simulation too, which is its own huge benefit, as anyone who has performed a robotic risk assessment on-site with a tape measure can attest. Finding distances between robots and other hardware, measuring gaps in guarding, and finding possible ingress points are all simple in simulation.

Just look at how little time we are spending in the lab and on the factory floor, and imagine the cost savings.

Now there are some prerequisites. For many of these activities, the simulation needs to be very high fidelity, especially in the situation where we want to validate a task with lots of mechanical contacts, physical interactions, etc. Fortunately, there are simulation tools like NVIDIA's Omniverse Isaac Sim that provide physical fidelity which allows us to model many of these metal-on-metal interactions to the point that we are very confident they will work in the real world. It also takes time and effort to build the simulation, but as I mentioned in a previous post, there is a growing ecosystem of vendors who can help with that too. And finally, simulation tools are continuing to get easier to use.

Simple in Sim

So taking another look at our automation deployment process with simulation as a major tool, we see a lot of benefits. We are using the right tool for the job (I've been using Solidworks since 2003, so don't think I'm biased against CAD), and we are only installing a system in the real world once we know it works. There will always be those last-inch tweaks that are necessary until our simulations are millimeter perfect, but that is a small price to pay versus finding a major process issue or safety challenge once we have everything installed.

We also have embraced the iterative approach to automation (one of our favorites at READY) where we can now test and improve our automation cell in simulation in an iterative loop, with no cost but time - time that is much less expensive than at the factory.

Additionally, by embracing this workflow, especially with programming tools like ForgeOS tied in, deploying and maintaining the work cell is a breeze. We already wrote the program for the cell in simulation, so we can just transfer it to the real cell once it is built (see READY's recent Forge Edge announcement). When we need to make a tweak to the process, or even change it significantly, we can do all of that work in simulation while the existing cell remains happily in production, and then push our changes to the real cell when we are ready to change over - with almost no downtime.

Conclusion

Simulation provides us with a real chance at keeping up with the speed of automation deployment required by manufacturing today. We don't have time to make mistakes in the real world where they cost the most - instead, we can make lots of mistakes, and lots of improvements to speed and robustness - in simulation.

Be sure to follow on LinkedIn for more updates and news on this front. We have some exciting things in the works, all with the goal of making robotic automation faster and easier to build and deploy, whether in the sim or in the factory, by anyone.

Kel Guerin, Ph.D. - Co-Founder and Chief Innovation Officer, READY Robotics

I build technology that enables everyone to use robotics and AI, and I write about the transformative powers these technologies have for our society.