Background: This is the second time I've had the chance to talk to the Caja Robotics leadership team. For this interview, I sat down with Guy Glass and Reuven Della-Torre to learn more about the current state of the software and hardware technology that makes up Caja Robotics.
You can learn more about Caja Robotics and the warehouse automation market in our recently released Warehouse Solutions Buyers Guide, where Caja Robotics was awarded an "Innovative Solution" award for their simulation feature.
Editor's Note: This interview has been edited and paraphrased for clarity and length. The content represents the intent of the speakers interviewed.
Mobile Robot Guide (MRG): Hi guys, can you tell us a little bit about your background and how the company got to this point in its history?
Guy Glass (Founder & President): I’ve been a software engineer for the last 20 years, primarily in the e-commerce area. I was one of the first pioneers of the e-commerce industry here in Israel. The company that I founded before Caja Robotics was one of the first and one the biggest e-commerce fashion companies in Israel, something similar to Gilt (luxury designer label).
We founded that company in 2009 and then we sold most of our shares in the company to the biggest media company here in Israel in 2012. There, I was responsible for the technology and operations. In 2012, I tried to find some kind of (warehouse automation) solution for that company. We were looking for something very flexible and scalable similar to what Caja Robotics is today. I brought the concept to the biggest shareholders and the board of that company, but because it was a very small company, and because we had sold the company, they didn’t want to invest in the concept. This was good for me, because in the middle of 2014, I formally quit the company, joined with some other founders, including Ilan Cohen, and started Caja Robotics.
That first year, we didn't raise money. We didn't hire any employees. We just sketched out the ideas, and only after a year did we start to raise money and recruit employees. So basically it took us five years to pull everything together to where we are today.
Reuven Della-Torre (Co-founder & CTO): My background is I have an MSC in mathematics and computer science. For the last 20 years, I was CTO and VP R&D of several companies here in Israel. Some of them were mid-sized, and some were startups. I started in the telecommunication arena with a company that at the time that was public on the NASDAQ. From there I moved to another company that went public as well. In 2008, I went into computer vision, and streaming on the net and worked for a company that was later acquired by Yahoo.
After it was acquired, I was introduced to Guy through the chairman of that company. I joined as the CTO of Caja Robotics and my goal was to build a long term architecture that became what we have today.
MRG: So neither of you came to this from the robotics side, right? You had the e-commerce background and enterprise software experience, but robotics was new?
Reuven: Right. I had an electronics background and a little on the mechanical side. That was the challenge in the beginning. To learn how to close the gaps on this subject.
Guy: Yeah, but I think one of the strengths of our concept is that everything is built on the cloud and with the software. One of our core beliefs is in the flexibility of software. We try to do as much as possible in software. This is, I think, one of the things that is really unique in our solution and probably because of our backgrounds. But it’s something we really believe in.
Reuven: It's a good question about what is our forte and what we really believe is the right solution. The software is dynamic, it’s easy to change and very flexible.
The idea was to build the architecture in the way that whatever can be done in high level software, will be done by the software. And I think that the main differentiator is that our robots are not communicating directly with the working environment. The robots know only about themselves.
The idea of our solution is that everything is managed by the back-end. The cloud system manages everything around the robot and the robot just does the specific task that it is given. The robots do not know if there are other robots in the environment.
When you think about the speed of the robots, we can run our solution much faster because the robots are not aware of anything in the environment. The supervisory system calculates the movement of everything in the warehouse and then gives each robot a path to follow. We architected the system from the start to put the decision making at the highest levels of the system. This leaves the robots and the hardware to do what they do best, which is to pull and push bins and to drive quickly from point A to point B.
MRG: The way I understand your solution now, gives me some background behind your decisions from an architecture perspective. So, you operate the robots in an environment free from humans. Humans aren't in the same workspace collaboratively with the robots in your design right now? Why do the robots need to run without humans around?
Guy: Yeah, you're completely right. We believe that if someone buys a robotic automation system, he needs to get the maximum performance out of this system. In terms of safety regulations, you are very limited to how fast you can drive the robots with people present in the workspace. So if you want to get very high throughput then we believe that the floor-space needs to be free of humans or other traffic. In that way we can drive the robots faster.
We include the functionality and flexibility in the software so that you can decide to close down specific areas of warehouse to robot traffic. After an area is restricted, then humans can enter into this area and do things like pick manually, do cycle counts, etc. Once they are finished, the area can be reopened to robot traffic. This is the most flexible way to operate with the automation in the warehouse.
We tried to make it very intuitive for our users to run Caja robots in any existing warehouse without modifications to the shelving, aisles and floor layout. This preserves the ability to fall back to manual processes at any time, if it’s ever needed. If a customer needs to cover fulfillment spikes with human labor that’s easy enough to convert some sections of the warehouse to manual while covering other sections with automation.
MRG: So, Reuven, you're using a method of fiducials on the floor to localize the robots? As the robots move on a path from the pickup to the drop-off, they are following a predefined path of fiducial waypoints to get there?
Reuven: The instruction given to the robots includes not just the route between two points, but also a time schedule. Robots have to drive a specific path between two points while sticking to a prescribed schedule. This means that they get a very specific path with a very specific time that they have to be at each point in this path. Once they get on this path, they can be sure that if they follow the order of this path, there will not be any obstacles in the way. Of course, we have lidars onboard and we have other sensors to avoid collisions.
In general we can go very fast because there are no people and no other robots to cross the path. We do all of the path calculations ahead of time such that everything is predicted. This also means that we can run simulations that are identical to reality. To run a simulation, we get the layout of the warehouse, the SKU and we get a real order queue from the customer. This enables us to run the simulation and get calculated outcomes.
MRG: This is an AHA moment for me. Simulation has always been difficult to get right. With autonomous navigation, anything can happen. A fork truck can stop the robot in its path for an indeterminate amount of time or the AMR can be forced to replan and take another path to get to where it needs to go. So now I see how your solution solves that problem.
Guy: We do a lot of optimization through our simulation. And the robots can run faster, because when the robot gets a path it knows it can drive safely at its fastest speed. The robot doesn’t need to worry that other robots will be in its way.
We currently use simulation as a presale tool, and as a service tool. Our customers are growing their throughput at 30% to 40% a year. When they need to grow the warehouse, they need to add more robots. But how many? We can run a simulation for them and we tell them exactly what improvements they can expect and how many additional robots are needed to produce the desired outcome.
However, this is a very powerful algorithm that requires a lot of computing power. This is the reason why we run it in the cloud where we have access to powerful and scalable computing infrastructure.
Reuven: Not only can the system tell you when a certain order will be ready, it can tell you how long it will take to move that order around. Plus, we can be sure that these routes are the fastest path that the robot can take at the time of allocation.
MRG: What are you doing in the area of optimization of the warehouse and in restocking? I would assume that you are able to see the orders for popular SKUs, and stage them closer to the pack-out stations when they're needed to prepare for a day's order?
Reuven: Yes, correct. First of all, we can work with totes and boxes as they come off the truck. No need to transfer individual items to different totes or bins just to put them away. This helps to speed up put-away tasks.
For picking optimization, we have two kinds of optimization algorithms. One optimization algorithm looks at statistical trends, and optimizes the location of things in the warehouse. We will put items that are hotter, closer to the picking stations and visa versa.
The Caja solution uses two different types of robots, the taller picking robot and the smaller shuttle robot. There will be times when the picking robot is busy moving inventory around between shelves as it optimizes the location of things and it’s not assigned to pull a specific customer order. Meanwhile, the smaller shuttle is always busy moving items between pack out and the inventory aisles. The small robot makes all of the long moves in the warehouse.
Reuven: Another kind of optimization is: “How do we sort the order queue in a way that we minimize the movement of bulk inventory. In other words, we try to bring one box of product to pack out that will fill as many orders as we can.” In this case, we are doing more to understand and to predict what will happen from the orders perspective, looking at the similarity of the orders. We work to optimize the order fulfillment while ensuring that all of the delivery commitments are made for expedited orders and the cut-off times for logistics out the back door.
We also use deep learning algorithms to guide the robot as it picks up a box on a shelf. Since we don’t constrain the system to using a uniform storage box or bin, we need this to help the system learn what it is moving around.
MRG: So, for customers who already have a warehouse management system that's taking and queuing orders, you're gonna take that order stream, and optimize it? Where do you integrate then in the systems that are tracking orders?
Guy: Regarding WMS, we don’t replace the WMS. We try to persuade the customer to keep his capabilities in terms of WMS and picking support tools. It's connected to what I told you before regarding that, we want the customer to keep this capability, in terms of redundancy to help in terms of spikes.
We add a layer of additional optimization on top of that, and we are not replacing the WMS because it has a lot of capabilities on top of just doing the picking.
Reuven: Perfectly right. We leave the WMS to do what the WMS has to do and that leaves Caja managing the warehouse area itself along with the goods in the warehouse to get the best fulfillment performance. For integration between systems, we have a RESTful interface that is documented. It’s much easier to integrate enterprise systems today than it was 10-15 years ago.
Guy: For WMS integration, we offer two way integration. We also report back to the WMS every time the robot takes a box, we report to the WMS: robot number X holding box number Y for a specific SKU. So as the robot moves a box from one place to another, we're reporting it in real time to the WMS.
We also report statistical data from every pick or any errors. We have a full API that gives a customer access to every parameter in the robot including the inventory history. We believe in being very transparent with this data.
MRG: What can you share with us about your future roadmap? What do you see today and where are you going?
Guy: First of all, regarding the robots, we can currently reach boxes up to 3.5 meters (11.48 ft) high with the tall robot. We're working on a new robot that can go up to 5 meters (15.4 ft). We’ve also started to talk about potential partnerships that will bring additional robots under control of the system. Our vision is to be able to quickly add/integrate new mechanisms to the system by defining the parameters of the robots and connecting the communications. Since our system pre-plans the motions and avoids collisions of individual robots, it will be simple to bring third party robots into the system and have them all collectively operate together.
We are also working on improving the algorithm and the optimization of the order flow. Even if we do a small optimization that improves the fulfillment by 1%, we can deploy it to the customer over the cloud. And as we drive faster, things move faster in the warehouse and customers see an
immediate ROI improvement.
Reuven: I would say in general we have a lot of things in mind, in my mind the main thing is optimization, system throughput and algorithms.
We are all the time working to find ways to get better throughput, better optimization and using faster and more clever algorithms. The other thing is the simulation. We are trying to make the simulation as easy to use as possible because we leverage simulation at every stage of working with customers. We can take a customer's order history, look at what happened on any given day and then look for ways to improve the throughput of the system. We can run different simulations and vary the number and type of robots to see what happens.
It’s also attractive for our R&D team because they can change the parameters of the robots in the simulation and get predictions about how that impacts the performance of the solutions. This leads to better decision making for our engineering investments.
Guy: I want to make the simulation tool very friendly so that a customer can run a simulation. They will not need us in order to run the simulation. And at the end, they can click a button and order whatever they like. I think it's a very strong tool when they can run simulation on their own. Our current simulation tool is all our intellectual property and entirely our design. Everything is web based. We just need to make it a bit more user friendly before we release it to customers.