Truly Autonomous Welding

We create manufacturing robots that autonomously scan, position and weld your parts without the need for skilled welders or robot programmers.

Path Robotics was started by brothers Andy and Alex Lonsberry in 2018 while working on their PhDs at Case Western Reserve University. Their goal is to reform the world of manufacturing by providing intelligent robots that make manufacturing infinitely flexible and infinitely scalable. This will reduce the need for skilled workers, such as welders, and propel the manufacturing industry into the future.

Reforming a whole industry is a monumental undertaking. The first piece that Path focused on is alieving the need for certified welders. While welding robots exist from many manufacturers today, none are as versatile as what Path has set out to build. By using artificial intelligence, machine learning, and computer vision systems, Path is creating robots that can be easily set up to handle a wide variety of tasks, that are also easy to operate.

time is money

As Path grew, and deadlines became even tighter, it became apparent how much time was lost due to developer inefficiencies. Whether it was getting a new software engineer’s system up to speed, running tests to verify functionality, or deploying code to a new robot cell, there was a lot that could be improved.

By pivoting to Buildkite, a flexible and scalable CI system was able to be created that could help alleviate some of the cost issues present. Each step of each job is able to be run on different sized machines, which gives more flexibility to run steps on cheaper machines where possible.

Buildkite also integrates very well with autoscaling groups. This means CI machines will only be running when there is a demand for them, which reduces costs even further. Another big benefit is the speed at which Buildkite runs the jobs. It is significantly faster than the previous CI system, which means less time waiting for builds to complete and more time getting work done.

consistency is key

While reworking the CI system, an opportunity opened up to address other inefficiencies that had been noticed. Developer machines could take multiple days to get set up, and everyone had their own way of running the software, running tests, and which libraries were installed. Building production machines could take quite a while as well, as all of the code was compiled on the production machine before it could be run.

By using Docker, getting a full system running became as simple as pulling and running a handful of Docker images. This also makes local development much more efficient, as the developer would only need to compile the project they are modifying, and can use the Docker images for all of the others.

Docker also has the added benefit of the production version of every needed library already being installed in the container. Going this route makes consistency between developer machines a much simpler task. However, developer convenience still needs to be taken into account. That is why we took the route of creating scripts in every repository to handle things like building, running tests, packaging, etc. Every repository has the same basic scripts, and they all follow the same pattern. This makes each repository much more predictable, regardless of which technologies are being used.

bring up / integration

One of our pairs was largely focused on the complexities of bringing up weld cells. This process involved lots of coordination with various engineering disciplines within Path. Our engineers were critical in solidifying the Bring Up process and making it faster and more repeatable. We took responsibility for high-level management of the entire process, from the initial imaging of the cell computer, to calibration of the various components of the cell, and finally to performing initial test welds with the cell. We coordinated our efforts with various groups within the Path organization, working across disciplines to ensure that cells were delivered on time and in great working condition.

When we began working on Bring Up, Path had a list of procedures for bringing up their smaller AW2 cells, which we helped refine over the deployment of multiple AW2s. Initially, AW2 Bring Up took around 6 weeks to complete from the time that the cell was fully assembled. Over a period of a few months, we refined the Bring Up process to the point that it could be completed in under 2 weeks. We led the AW2 Bring Up team, which doubled as an initial “training” team for engineers coming into the organization. We developed documentation and training materials which were used by Path to expose their engineers to the various concepts involved in robotic welding. Engineers who passed through the Bring Up team learned about the software architecture of Forge, but also learned a little bit of everything else, from the basic math behind calibration procedures to electrical troubleshooting procedures for cell components. We also aided in the daily support of live weld cells, communicating with engineers and technicians to keep the cells running smoothly.

As Path shifted their focus to the larger AW3 cells, Augustwenty engineers were called upon to develop new Bring Up procedures, adapting the various components and procedures of AW2 Bring Up to the new cell types. We updated documentation and created a Bring Up manual for the new AW3 cells, working closely with dedicated Bring Up engineers to ensure that they were capable of performing or overseeing every aspect of cell bring up. By the time our contract with Path was over, our engineers were some of the most knowledgeable people in the building about the Bring Up process, able to take a newly assembled cell from power on to weld with around 2-3 weeks of focused work. We ensured that the dedicated Bring Up teams on site were able to learn from us and handed off the responsibility of Bring Up to a very capable team.

sensors software team

As a part of the software team, augustwenty members worked on a wide range of initiatives. One of our first projects was increasing the performance of a computational analysis tool used in part recognition. By refactoring the code to enable parallelization and by leveraging our previous experience with cloud computing, we engineered a new highly scalable architecture that reduced the run-time from a few days to a few hours. Another need from Path Robotics was extending the codebase to support new sensor hardware. Our background in hardware and testing was a big help in integrating, benchmarking, and optimizing performance for a variety of specialized cameras. From this work, we were selected as embedded software developers, as part of the sensors team. For this initiative we lead the development of data collection tools and a variety of performance improvements. This required the development of new, easy to use, methods for orchestrating robot motion and gathering specialized sensor data. These tools were used to prove out new calibration methods, collect training sets for machine learning algorithms, and increase overall robustness of the sensing system.

data, data, data

As one might imagine, these welding cells generate a significant amount of data that could be used for machine learning, determining cell health, etc. But how does that data get uploaded, and where does it go? These questions were much harder to answer than initially thought. So let’s break them down.

The first problem to solve is how to get data off of each cell. Since these machines are installed on manufacturing plant floors, there is no guarantee that a broadband connection will be available. Sure, cells are being shipped with a 3G cellular connection, but pushing multiple gigabytes of data for each part run through a cellular network is unreliable at best. So we got creative.

First, we created a local stream of events that needed to be processed. Some of these events may contain files, photos, or whatever other data is needed to tell the whole story of what is happening on the cell. This on premises stream meant that processing of events could happen asynchronously of the cell actually running, which means the data offload would have no impact on cell performance.

Once this stream was set up, we needed to get all of these events off of the cell. So, we created a job that reads each event and sends it over the network to another event stream in the cloud for later consumption. If, for some reason, this offload failed, the next time the job starts up, it would read the same event from the stream and attempt to run it again.

Now, where is all of that data going? Quite simply, it is being stored in a combination of an S3 bucket and a Kafka event stream, both hosted on AWS. This allows different teams to consume events and data from production cell runs and use it to train machine learning algorithms, track down issues in the software, and whatever else they could think of.

the Path forward

Path Robotics is solving some extremely difficult problems, and changing the way that the world sees manufacturing. By taking autonomous robots to the next level, Path is solving the industry-wide skilled labor shortage through innovative solutions.

Today we’re focused on welding robotics, but that’s only the beginning. We’re making intelligent robots that make manufacturing infinitely flexible and infinitely scalable. Our mission is to enable robots to build, so humans can create. The future of manufacturing will be built by Path.