00:00:00.000
the optimal pick speed is infinity. So, that's a simple answer. But It depends on what kind of object it is. So if you would want to pick eggs, infinity would probably destroy them pretty well. but it, comes like it's, it's grocery or it's a, I don't know, ball that cannot be broken? But mostly I would say the speed is still limited by the dexterity of the robot. Viktor, when I say the phrase fleet management, what does that mean to you? fleet management, what mean to you? It means that, uh, I need to deal with that CD, and I, I don't wanna run away. Meaning you're probably managing a bunch of EC2 or similar type instances, and you're having to my case, I, I, I thought that CD in terms of fleet of Kubernetes Oh, fleet recruit. Exactly. we're used to dealing with it from a software and a deployment perspective, but we don't deal with the physical side of things. On today's show we have deep breath, let's see if I even get it close. Tomasz Kowalczewski. Am I close, Yes, I think you're, you're, you're pretty close. Yes. It's, it's Okay, but I'm wrong. I'm Ah, it's just, just, just slightly, slightly. Yeah. Okay. Uh, he's with Brightpick. He's the CTO, and they do robotics, like legitimate robotics, like warehousing robotics, right? Yes, that's right. Yeah. It's not those types of robots that, uh, you can put into your home and then somebody controls it, telematically, no? No, no. These, these are, these are proper, fully autonomous robots. They, they really do the job. So they're really going around and, uh, do the job, without someone really needing to control them. Yeah. when I said fleet management to Viktor, he said SED. What does fleet management m-mean to you in the physical world? Yeah, ex- ex- exactly. That's, that's for me it means very different thing. Yeah, so, of course I understand also for the software part, but for me it's mostly really physically managing the fleet of robots and in the physical space, like wherever each robot is, whatever it needs to do, and, uh, basically commanding them around. At the end of the day, it's basically same. Uh, yeah, so we have more orders, you need to have more robots, uh, doing the job like moving them around. for me it's, it's more about the, I would say the algorithms and also the infrastructure that keeps the warehouse going. What does an algorithm look like? I guess to me, an obvious one, not having worked in that space ever, is there's gotta be vision in there, making sure I'm not running into each other. I guess vision, making sure I'm not running into the racks. so basically exactly right. So it depends, uh, what kind of, automation it is. for example, for our auto pickers, uh, they are full aware of their surroundings, so they use, uh, lidar navigation. And, we have, uh, algorithms for, navigating around based on the surrounding, based on how the, warehouse actually looks. that's just one thing. The, the second thing, of course, is to understand whenever robot is around, so we need to go around them. the third thing is, it's a very different space from the software perspective. Like you need to have several layers how, how would the robots react. So the first one is, of course, like everything works like supposed to, then every of these robots, knows its parts and when everyone else is. But, uh, have different layers, and this is not always true. Sometimes you have, network disconnections and so on, so it means that robots need to be totally independent. It needs to do decisions on its own. that is so say a very, very important part of the story as well. So the robots are able to really function when connected, but also whenever they are, working, uh, just on their own. So they need to make a decision if something bad happens. You know, before we started recording, I had to leave and said I'm back in two minutes. There were two reasons for that. One is to fetch my headphones. The other reason was to turn off my Roomba that keeps hitting the chair over and over and over again, So I kind of… I cannot make one of them work without, colliding with something all the time. I don't know how you do it for a fleet, man. it's pretty funny and, uh, it goes to things, little things like network connection, which is something that was for me before we started doing robotics and fleet of robots. It was like, okay, so with Wi-Fi does work. It's simply technology that was there forever and it's, simply working. Was, I was never having a problem with that. But when you have hundreds of robots inside a huge warehouse full of metallic s- uh, bit of metallic stuff and you're working around then even things you take for granted are not that easy anymore. so we need to develop a lot of things how to be sure that, the robots stay connected actually. So yeah, it have its challenges, yeah, sure. But uh, at the other ha- other hand I would say it's, satisfying when you see something physical is, uh, moving around and is happening. That's I would say it gives you a, a feeling that whatever you do is, is it just have really that kind of, impact to the real world. So you said Wi-Fi, sure. is that where you started? can Wi-Fi support up to, you know, like five or 10 robots okay without saturating the access points and… Or is it just, uh, because of the infrastructure of the buildings themselves, it's like, "Eh, it doesn't really work out"? I would say it's, uh, it's a combination. you need to really ensure that you have, we'll say, dedicated channels, for the robots and that they are not overlapping But for example, of course we are always working with the customer, so the customer needs the Wi-Fi too. So we need to agree of which channels, and how we, how we split them. the same time then you have, roaming because like when you are sitting around, you're typically connected to just one IP and, uh, it's pretty okay. But as soon as, you, you move around, you roam a lot and, whenever you roam you have just small disconnections. And, we want to like, really wanted to minimalize that and, ideally get rid of disconnections at all because every little disconnections means that the system is not totally working, to its potential because some-someone has delayed information I would say, that's something which is a little bit harder with robotics. It's not only about the, let's say the payload or the, the load balancing as system as, thing of scale, but also the latency is important, uh, that things really happen at the time it should because, like, things depend on each other and, uh, and so on. And every-- But basically, in a warehouse, you have a lot of robots, and basically everyone depends on each other, who is the fastest to go to the crossroad and, is the exit order they are going, through it, and if it's efficient enough and so on. mostly focused on warehouses, right? how does the, let's call it training work in terms that do you give them some information related to a specific warehouse where they're living, or it's all generic and kind of I can put it anywhere type of situation? the robots themselves, they are pretty generic. So, you can actually work in almost any environment. But, Because they're interacting with the physical world, so you have totes, they basically have an items for the customer. Uh, you need to know where the totes are in the customer system and then, of course, when these places are in the real world. So yeah, you need to have some kind of map, that maps the digital space to the real space and also, like, in that map, wherever is our, we, we call them storage position or tote positions. So where these are located, and then we have of, of course, a database, where we, uh, we remember wherever and in which quantity, of each items, there is. You mentioned the database. Do robots themselves also update it? Kind of, "Oh, I just picked up this package," or whatever they're doing, kind of like there is none left, things like that? that's a good question. Yes. So of course they do. So the, the system, the whole system is basically connected, so th- their internal, like i- individual layers. So the robots are the, really the end node. Then of course they are connected to a server system that is running on edge on the, customer side. it basically keep tracks of everything. It communicates with the customer, the WMS, which is a warehouse management system. whenever we pick an object, by the way, for that we are using, trained trained neural networks, but they are pretty, general, so they are able to recognize, uh, different kinds of objects. we of course track the number of items that is left, sometimes really happen that someone, for example, make an, m- make a mistake, and, there is not, uh, enough of the items. So yeah, the AI can recognize that a bin is empty, and, then we need to take care of that. So my question here is, obviously there's a lot of telemetry going on. You're saying databases are being updated. I'll revisit databases in a few minutes. You've got a basic training in there. You said it was general training, right? what happens when you need to update the robots? Like when you-- let's say you need to push a vision model update to the robot itself. Is there downtime on that? Can you do it live? Is it canary, blue-green? What's it like? that's a great question. Yes, we can do it live, most of the time. So sometimes there are updates that you need to stop everything. Like for example, when you are changing the layout, like adding something or, or something like that, these things are not backward compatible, so you need to stop the fleet. But, for most of the things we are able to do a rollout that is basically ongoing. And yes, typically we are doing, whole bunch of testing on our premise and our testing facilities. And after that, the feature is, for example, solving some kind of problems with configuration difference, we typically do a kind of retesting and slow rollout. So if anything happen, we can act fast. And because like the fleet of robots, like there are multiple of them, so whenever there's no a single point of failure in that. so if there is something wrong, for example, with the update, typically the rollback is not that a big of a problem on the robot side. Are decisions made inside machines or some kind of communication to some server that kind of like, oh, you know, here's the input, I receive output, and then I do this? does that work? much is decision-making inside of the device as opposed to elsewhere? so the, the robots themselves, they are pretty smart. when you have a fleet of, normal cars with people in them, what would be perfect if, some central logic can control the whole traffic, which is almost impossible in the real world right now. That would be means that there will be like, a small amount of congestions and so on. So yes, this is the optimal part. if the system is able to do all the work, and this is what we typically wants to do. But, once in a while, things like, okay, someone's slower than it should be, or something is on the ground and the robot needs to react, and you, basically cannot rely the servers, that they will act. Yeah. So, so you need to basically override the action of the system. So the smallest part that is nearest to the real world have always have to have, uh, the highest levels of, control. So we have, a- actually in the robot, there, there even two layers. One is the software layer. they decide, let's say high level logic that is able to do things slowly and, with, good amount of time before. And then there is another PLC, which is basically a safety gate. So if something gets really near the, the robot needs to stop, the hard way. that's actually these really the, the several layers. So one, the master system, then the, the robot software part, and then there's the safety at the end. What's the size of them? Is that kind of Roomba size, small ones, big ones? I would say they are about, Like, do do you know what's these, totes, uh, the in centimeters like 60 times 40 centimeters totes. Like this is pretty standard in logistic that's used. So the robot have like two of, two of them. So it's say it's, it's about half of the pallet typically. Uh, so, that, that's the footprint and of course they are tall. So we have three meters, uh, tall as I would say is a standard. And we have also, uh, some we call giraffes that can reach up to the six meters. but they are, they are telescopic, so they're able to basically extend the, pillar. one thing I'm curious, can I walk that warehouse or is it kind of like no humans allowed or, or how does that work? the robots themself, they do have the sensorics, to work. Like I am totally okay working around the warehouse and, uh, the robots will simply slow down and stop. So it is totally okay. But of course the warehouse are designed to be operated by machines. because whenever someone is involved, it's slows thing down. And, I would say the collaborative robotic is fine whenever there is a reason for it. but, typically whenever it's not a reason, it's, typically slows things down. And it of course depends on what is kind of application. For example, we do have a new product, uh, a grid picker, and that's designed a little bit differently. For example, in, d- in that system, uh, they're absolutely separated from humans. What happens when you've tested everything out in your local environment? So you've got probably, I'm guessing, three or four robots in a scaled-down environment. Like, you maybe have one aisle or an aisle to the landing spot modeled physically in your spot, and you test it out, and it's great. And you start rolling it out canary in the actual warehouse, and it's so-so. It's going okay, but then you cross over, say, 70% canary, and then things go completely sideways because scale, right? Typically, with normal software, you don't see problems when it's small. but once you get it to scale, there's a problem. How do you roll back? 'Cause it seems like, okay, I've, I've already, you plowed out all this software. Now I've gotta roll it back. Do I-- Do you roll forward? Do you roll back? K- What does that look like? we actually do have a process for that. So whenever something is wrong, we simply roll back to the last, good configuration. So it's, it's not automatic. Of course, it needs to be decided by the support. but, it typically doesn't happen like in real world, when you have the robots, like they are distributed system was but of course, these things can happen. But, it typically is not a Pandemic or epidemic, that you just cross something and something happens, too much. I would say sometimes there are subtle things that, we did, uh, for example, we, did fix, some problem and then, we see on the statistics or long-term statistics that things are a few percent worse than we expected, like, uh, I don't know, uh, the cycle time and so on. uh, this can be also the reason, for example, to go back because, like, that's exactly the things we don't want to do. So, uh, it doesn't necessarily need to be like some, ep- epidemic. Typically, it's hard to do because, like, if you're really going one after another and, of course, when you have a small number of, robots You cannot be 100% assured that everything works great. But, on the larger scale you can see, uh, there's a lot of interactions whenever you start to see some patterns, some problems, they're typically one of, I don't know, hundreds, thousands. So, they are typically not that, rapid, not that extreme or something like that happen. But of, of course, like, when there is a really reason to roll back, we, we do roll back. How do you manage logs, metrics, traces? Do those even exist Sure, sure. Yeah, yeah. A lot… Actually, quite a lot because, like, whenever you don't measure something you don't understand. there's a Prometheus server that is basically scraping, metrics from each individual robot. so that's, also one thing. the other thing is, the robots have something we call panics. So whenever there is something unnatural or some kind of anomaly, they're able to record kind of everything that they was able to see in the last couple of minutes or something like that. we have actually, a system how these are automatically processed and uploaded and, uh, within our, our, our engineers are able to Access them and replay really part of, what, what was happening, how the robot interacted with other robots, uh, what was happening with the sensor and can go pretty low on the level of, okay, what is the individual angle of some servos and, uh, and things, things like that. So we can go really, really deep into understanding what is happening. So that's, also more investigative tool, and the, the Prometheus and then Grafana is more like, okay, statistics. you have a fleet of robots and you… I would say a little bit different with the software probably is than when you have a different kind of, for example, Kubernetes nodes. when you scale a system, they are typically very similar and, can do a similar job. Of course, like if you have, a certain, let's say CPUs, maybe some of them are different a little bit. but on robotics, if, for example, something wears off, you want to see an anomalies between different, uh, robots, and that's I would say more, even more important maybe, to look for them. What's powering their brains? Is that kind of traditional machine learning? Is that the LLMs visions? What's behind it? Without revealing probably, you know, So yeah, so de- depends what part, yeah. So, for the picking, yes, there are, there are neural networks, involved of course. for, I would say, the classical navigation and so on, the- these are more classical algorithms. So they can be like proven, they can be tested. I would say like we are now really trying to use, uh, AI and LLMs for everything, but for the robots, like once you've solved, I don't know, a Dijkstra, and when you solve an A* and things like that, it's basically an optimal solution. so for some of the problems, there's no need for AI. But of course, like, I would say that's the main part. So When we're picking, yeah, that's an AI. When we're traveling around, that's I would say old school algorithm. is that conceptually similar to what cars are doing, like Waymo and things like that? Uh, in terms of making decisions, you know, move forward, go back, speed up, things like that. I, would say yes. similar. for some, points of view, uh, we are interacting with other, agents, basically other AMRs of our own fleet. So we have liberty to know exactly what they want. So I'd say that's, that's kind of, the easier part. it's very similar problem, but yes, we know whatever they want, so we can, they can agree. I honestly don't understand, and I, I did see a lot of videos, for example, like say with Waymo, many times like you are on the crossroad and you see the other guy in the other car and he's just like doing something with his eyes and you say, "Okay, I understand. I should go," or he, he's going to go. the robots are simply not there and and you don't want to do a decision like that based on, I don't know, uh, some unnatural Wink, wink. Yes, exactly. So yeah. So from this point of view, our robots can make, I would say, calculated decisions based on real data. What is your tech stack? I mean, based on what I'm hearing, it sounds like there's some SRE on-call type place that's probably co-located with your test facility. Is that right from that perspective, or am I off on that? the individual robots, they do run basically, some operating system and, communicate with a central node. We call, we call them Intuition, the application layer, but actually a server that's running Kubernetes pods. And, uh, that's that's on our sites. It's uh, al- always on edge. Like the the main reason, we can run on the cloud. That's, is not a problem. the problem is that we want to have a very tight synchronization and latency as, as, as I told before. each individual robot and also the Intuition, they are synced to the same, clock. they really have like, I would say almost millisecond, different, they drift between, between the timestamps and that's, that's really, really important for what they're doing, for the efficiency. But, uh, we do have a centralized cloud, uh, that is running on a GCP. that one is basically, orchestrating, each individual part. So, the individual nodes when they're running, then they're using, CP to do, do basically a Gi- GitHub. So, so we have, Git that's, that's, uh, that's basically a layer s- of truth. So this is the, the source of truth. whenever we change something in the instance, then, the, individual on- on-site servers, they, check for differences and updates themselves. let's break that down. What's the language of choice for the robots, and what's the language of choice for the software running in the local Kubernetes stuff? I'm assuming it'll be the same with the cloud Kubernetes as well. probably analysis. It's 50/50. May-maybe, maybe it's more on the Python side. But, I would say that the backend is mostly in Python. in the robots themself, they're mostly in C++ because of the speed, and I would say, the momentum of, uh, robotics is mostly probably still in C++ and things like that. And I would say when, when you build big clouds, then yeah, now we have uh, more options, but, uh, Python is still pretty, pretty popular. So I would say that. Yeah, of course, like even, even on the, on the side of fleet management, there are that are optimized and, uh, they're running, uh, running on C++, so compiled. Let me ask one question about maybe one of those algorithms. Let's say you have congestion start building up. When I think congestion, I think about that Waymo video to where all the cars gathered in one place and couldn't get out. Uh, what happens if you have a robot stall? Let's just say the rubber fell off the wheel. I'm assuming there's probably rubber on the wheels. Like, just something happened to cause the robot to not be optimal. How do we keep that from cascading through the fleet and potentially causing a deadlock? it depends. Like there are two options. If something is, is off but robot is still able to move, and also that's, that's mostly, the case. So in that case, we're trying to ge-get the robot out of the system, and uh, most of the time that's possible. And if the robot is not able to do that by himself, we have, remote support that is able to basically… Like similar to Waymo. So it's ab-able to connect the robot and is able to solve the problem remotely and, take the robot to a maintenance position. in case something would happen that, that I don't know, as, as you said, the wheel will fall, fall off, then, the robot would be stuck there and, uh, uh, it then depends on the situation. One, if, it's of course in a really bad place, then something need to physically go there and help the situation or, there are cases in which we can, for example, leave the lo- robot there And the things can go around him. for example, in, in case of the Grid Picker new product, the great thing is with something of that, I, I don't know if you are familiar with the products that we have. but, Gri- Grid Pi-Picker that we, s- unveiled on the Modex and the LogiMAT, the robots are basically on top of a, of a warehouse, on top of the shelves. And, uh, whenever that robot will be, for example, broken, something like that, there is a lot of, uh, workarounds around him. So he will simply be there and can be there for ages basically until, some maintenance will, will clear that position up. But, many cases, it can just go around and the system will just work with almost no, change in the performance. But it, it of course depends on the situation. I was half hoping that you would describe something like a robot ambulance, that you have a specialized robot that comes, picks it up, kind of like sends it, sends it to, to repair shop or something. Actually, we was, was thinking about that, like, or, or some drones that can, do something like that. maybe in the future. But yes, it's still a little bit hard to prepare for everything. And yeah, sometimes it's, i- is good to have people around that can help. You were saying all the robots are able to talk to each other. They're also talking to that warehouse cluster. The warehouse cluster is talking to the cloud cluster. just staying inside the warehouse for a minute, it feels like mesh networking at its finest. Am I incorrect in that thought? Although it, it would be a mesh if, uh, the robots itself, they, they would say they would, act as an APs or something like that. So, uh, the robots themselves, they are, jumping between each, AP. But of course it's, because it's, it's standard, the, the warehouse, uh, need… It's, it's physical infrastructure. Of course, it's better to run cables between the APs. let me, restate the question then. It's not so much a, the not mesh network, but it's a mesh network of robots because they are talking to each other. Forget about all the, the wiring of it, right? So, because I wasn't being clear. So since they're all talking to each other, and let's say we have that one robot go into one of those, low cell areas of the warehouse, right? There's, there's that one dead spot in every warehouse, at least one dead spot. And we lose contact for five seconds for whatever reason. once it comes back online, quote-unquote, back online, every- it's seen again, is it dumping that five seconds of lost data back on the line so we know what was going on, or is it just lost? So it-- the, the robot itself, it's half-- it's internal storage. So, nothing is really lost that, purpose. But, we don't want to dump all of the information because like most of the things like where I am, in most of the time, it's not that important whatever he was doing the last five seconds. I want to know wherever you are now. that's the most important part. So actually at the beginning, we had problems that we, ha- we had the network stack designed in a way that after the reconnection, everything was sent, was every k- every, every message. And then the problem was that, okay, whenever there was, as, as you said, it was like five seconds off, then it have so much to say, basically silence, was for several more seconds, until he was saying everything he wants to say. So, currently most of the sensory data is typically trying to transmit the most recent part. Yeah. The rest is, is not important, and it's recorded on the robot itself. So whenever, I don't know, you would need it, at least some history is always there. What do you do in the situation to where a robot feels off? as a human, every once in a while we'll get up, we have-- just wake up one morning and it's like, "I just feel off. I'm fine, but I'm off." but there's no errors happening, right? Just off. We could sort of classify that as, I guess, as a flaky test. How do you deal with things that become flakes? that's actually a good thing because like this is where the statistics come in handy. So uh, when you see individual robot, you're not able to say something is off. but if you are seeing them comparing to each other and one is acting differently and is doing something wrong, and to-- you already have a good statistical, let's say, sample, of the population, you can, "Okay, this guy something is off with him." So for this purpose, it's, I would say it's, it's some kind of soft error. depends whenever the, the maintenance is coming because of course it's a robotic system. Every physical system needs to check up, needs maintenance. So then the robot is planned for maintenance until… if it's really bad, sometimes it's not crazy. So okay, works and we, we know that the robot can perform and, uh, it can wait, and really do the job. Or sometimes it's better to, get the robot out of the fleet, park it into a maintenance position and, and wait for a service, to come and check. If you were to pull one robot out and you had 100 running, that means you have 99. Yes Do you try to speed up the fleet to make up for that one missing? You typically don't lose one whole percent because, like when you have a lot more, more robots, of course, like every other robot you, have more traffic around. So, typically, yeah, you want to have some surplus the performance around if that's possible. But, yeah, when, it's obvious it's really hard to really get, the other part of the fleet to take the place. So yeah, and go … Other, other robots, like they, can maybe go a little bit faster, but if they would be able to do like we would probably like have them faster anyway if you can have them go faster, why not go faster. All the time? Not exactly, yeah. Well, because you may not have enough product in the warehouse for it to fill, then you're gonna be down, so there's probably some management of what is optimal-- what is the optimal pick speed, I guess, and how does it go from there? if you have … Like if there are, there are like less, less work, of course the, the robots no need to necessarily work all the time or some of them do, some of them are not working. Then I would say like you still want to go the full speed ideally, if you finish the work sooner then the better. Yeah, sometimes you like, even for the customer, like they typically do have, busy hours and busy parts of the year. Uh, where for example, they're doing three shifts and, some parts of the year they are doing just two, one shift. So it's I would say, more managed in this way and, typically better than like- Making robots, deliberately slower. Uh, sometimes, for example, when we do have two shift, three shifts, and, there is a shift when we are not working, we, do something we call a good night mode, where the robots are moving around, and basically waiting for the next shift. because we don't have a charger for every robot, so there would be like too many places. even there they need to go around and charge. and then they are going slower. at least for that. Yeah. What is your ratio of chargers to robots? Basically similar to what's the charging current So I would say it depends legislations. For example, in, some of the US places we have a little bit, we say slower charges. sometimes… De- depends what is the, the power grid can, can handle. But in some cases it's eight to one, some cases a little bit less, around that So people just get in line and wait. It's sort of like back in the '70s in the States when there was the fuel crisis, and cars just lined up at the gas stations and slept overnight waiting to get the next tank of gas. It's sort of like that, right? a little bit different because, like, we know when the other guy will leave, so we send the, next robot whenever the slot is ready. So he knows even when he's at the other side of the warehouse. But uh, basically similar, but a little more or-organized in this way. Do you have to worry about split brain at all? For people that aren't familiar with split brain, this is where you have two things working together, and all of a sudden there's a network partition between the two, and eventually they come back, and there has to be some sort of merge conflict resolution or some variation. Is that something you have to deal with? sometimes you have, yeah. for example, when you, window picking, yeah? So you, I would say the, sacred part, what you do is when you move physical things around. when you do digital things, you can roll them back. But when you, I don't know, you pull something out of the tote, it's gone. So, you want to have the digital world really, copying the physical world. So sometimes, I don't know, when there is disconnection during these kind of actions, you need to get that information after, okay, uh, really find out what has happened. I would say in that kind, these kind of things, okay, robots know something, the server does know something, and yeah, in the worst case of scenarios when both systems are doing something wrong, then you need to decide, uh, even on, on the human side, but that's happening basically almost never. You said warehouses that are doing this are designed for robots and not for robot-human interaction, at least from an optimal perspective, there are places like we do human picking stations. So sometimes, we have applications where the robots are doing something we call a G2P, like goods to robots. When we take basically what is I would say unique on, our machines that they are carrying around I would say the basket, so the, the order of the customer, and also the storage tote. So whenever there is an object when we do not, we do not know how to pick because the robotic, arms, vision, the AI, they are able to pick most of the stuff. I would say the problem is not in AI, the problem is typically the fingers, like the human dexterity is extremely b- extremely good. And so there are simply things that we're not able to pick and, this is okay. for them, where we go to human and, he basically can interact and can pick, we have a tablet on each robot and, uh, he knows, okay, I want to pick three of these items and it's a very simple ergonomic operation because he just, move things around from one bin to another. So the robots can be lined up and he can work really, really efficiently in that way. So this way, it's, it's, very collaborative, but of course like from the way they move around the warehouse, it's separated. Like the warehouse are typically built, okay, this is an automated part, and this is the part designed for humans. So they are typically separated places. How do we get to lights out, like true full lights out fulfillment? Because to me, at this point, we can't do true lights out because we need humans today to be the distributors into the warehouse, and then the robots could pick off from there. there is a lot of, a things happening and a lot of companies trying to solve also some individual parts of that equation. So you have, obviously the picking. I would say we're very close to, Full automated picking. so that's, that- that's one thing. Of course, like we need to pack and then, send things around. we have also the inbound. I would say each individual parts is solvable. Some I would say are far away, but I would say s- still several years. even with the automation, it's sometimes you, you need to pick the, battles, Yeah. So which, problems are actually pretty efficient, with, people, which problems are, are really tiresome and, and complicated and expensive based on the, I would say, one pick, one item. What is the optimal pick speed? I guess it depends on size of product, robot, everything else. is there an optimal? Is it just, it always depends? the optimal pick speed is infinity. So, that's a simple answer. But It depends on what kind of object it is. So if you would want to pick eggs, infinity would probably destroy them pretty well. but it, comes like it's, it's grocery or it's a, I don't know, a rock, ball that cannot be broken? But mostly I would say the speed is still limited by the dexterity of the robot. So that's, I would say that's still the most limiting factor, so it can be faster. But at the end of the day, I would say the traveling is still, uh, the biggest side of the problem. So actually this is something that we are solving in a little bit different way We don't want to necessarily be fastest in every single thing we do, but we want to be smart about things, or that we do in with AutoPicker and GridPicker. we don't want to move around because like typical automation in the warehouse logistics, what they, they do is they go from, edge of the warehouse, where, for example, the human picking station is. They go into the warehouse, they pick some storage tote, and they go back all the way, and then one thing, two things are picked from there. And they go back and, et cetera. So it means that there are fire hose places then create congestion. And so what we try to do is we try to take the picking inside the warehouse, so, so it is distributed around that. So the robots go and, pick on one place, the second place, and then we can optimize things like traveling salesman, things like that. So we don't need to travel a lot, and, and that's the key. So we travel smallest amount of distance as possible. And then, of course, we don't need to be a race car in terms of picking, because, like, we can do it parallelly in the whole part of the warehouse, there can be thousand of robots picking at the same time, and that's, that's great about that. So I would say that the biggest bottleneck of the typical system is the congestion. It's not typically the action itself, it's the getting around. So it's the getting around is what really makes your SLOs make sense. Because if you were having to home run every run, like if everybody started from the same place and had to come back to roughly the same place. nowhere near as good. is it all these robots kind of doing the whole trip, or do you use also conveyor belts and things like that? Kind of, oh, I put it here and then it travels the rest or something like that? we interact with the conveyor. So because, like, in many, customers have different kind of processes, so they… Many customers do have conveyors, so sometimes the conveyors are the input to our systems. Uh, either if these are storage totes or sometimes, uh, they are basically totes with a customer order that already have a part of the order picked, and it goes to our system when we pick other part of the order, and then it goes out potentially to other part of the system. So tend to be conveyors at the end and in the beginning of the system, but we don't use conveyors that much. So we are, trying to be as flexible as possible. So I would say, yeah, we are interacting with conveyors, but not, uh, typically using by ourself. We know that AI is considered to be, at least from the software development side, a great enhancer. Some people will argue that point, but I'm gonna stick with that for now. I will say that right now I am writing a program that-- And it's, I've been working on it for probably eight clock hours. There is a 0% chance, if I could have a negative 0% chance, it would be that, that I could have done that in that amount of time, in a language that I don't know, on a platform that I don't understand. But it's doing what I want it to do. So I feel like as a software developer, I feel like I'm empowered to do even more. I think in a warehouse, it might be backwards because people are concerned about from the blue collar… excuse me, from the white collar jobs losing their jobs to AI And we get all up in hands about that. But what about the people that have worked warehouse jobs their past 35, 40 years, and now robots are coming in? What have you seen happen when you show up and it's " like, Hey, we're the robot guys." Are you fearful for your life in about 20 minutes? the, funny thing is that it typically do not happen because, what we typically found out is that most of the pl- most of the places, there are, missing picker jobs. So in US, in many cases, what I think was like hundreds of thousands of people missing in the position. And the job is not… It's, it's, it's pretty crazy. If you think about, it, like you, you really do a lot of, miles per day in a warehouse, it's not an easy job. So of course, like it's, it's not easy and of course, like y- you have a lot of it, so you want to optimize it. So it's not the best paid job to… So I would say this combination makes like the job is not very attractive. so there was always a vac- vacuum that we, we filled. So we, helped the customer rise and uh, the problem that he was not able to get enough people. So I would say that's, that's more of the case. To the future, I would say, and hope that automation will bring more opportunities and it's, it's a, a little bit, I would say that's for perhaps for into a different discussion. But at the end of the day The job is done. I would say the value is delivered. So I would say the value should not vanish, so the people should be able to get part of the value, out of it in the end. the software community-- Because you said you're more focused hardware. Uh, what do you wish the software community would do to make your life easier? sometimes I am, as me as a person, I'm more of a guy that, uh, have a lot of drive, and I try to move really fast. And sometimes, I see a lot of people are focusing more on the way they do things as the end result. So I, for example, am more motivated by, okay, what I'm trying to achieve, and what is the shortest way to achieve that, of course. Like, when things go in scale, it, it means that things need to be clean and so on. I would say I would like most of the people to think about not only how they do things like coding and so on, but what is the product perspective. Because what I found is, the hardest, and I would say this is the hardest thing for the people or the, programmers now, because, like, the, craft is getting eaten by the AI, as you said. But what is … Now what hap- what, what really matters is how well you're able to connect the dots or think about the product, how think about the business value that it brings, and how you are able to navigate in that space. This is really what matters. Because if you are just about the craft, then, i- it's going to be really hard. What's a prediction for this year, for 2026, physical AI? You know, what, what's the equivalent of, like, a production-grade Kubernetes milestone for warehouse robotics? I would say I see a lot of, a lot of that happening, a lot of great things. I'm looking forward for it. I would say it would still be hard. when you, for example, take your hand and close your eyes and, put your hand, I don't know, a bag, and you are searching for the keys, you're typically able to find them pretty quickly even if you don't see anything. it's about the touch, about the tactile, like, the, the dexterity of your hand, like, moving around the bag, and this is so natural for the people. I would say this, will be probably a little bit harder than the intelligence. I would say the intelligence will be there sooner, which was something that people they think the other way around. I would say the intelligence would… there'll be sooner than the ability of, I would say, dexterity of the machines to do the general kind of job. We'll see more and more of, generalized machines. They are able to do 90% of the things. But I would say there are… we're still several years from, I would say, full automation. But for, I would say for warehousing, I'm looking forward for humanoids working around everywhere doing cool stuff. But for something like when you want to buy a pasta and the pasta, we will not, never probably see a humanoid making pasta, May- maybe some hu-homemade, right? It will, There will be factories because like, the factories, they're, they're doing it really good in scale. And uh, I would say in logistics, it's these are factories for shipping things out. there will be machines that are dedicated for that, not only because of the intelligence, but because of it does have sense because of the scale, to have something that is specialized. And then we have a lot of intelligent robots that that are generalists, like, like we are humans are general, creatures that can do a lot of things. And we'll see them, I think, on the places where they can do a lot of things that they will bring the, the biggest kind of value. What's one thing that your team has built that the wider software world should steal? Like, what's that one thing that you feel like, "You know what? If everybody would just do this one thing, then my life and everybody else's life would be easy"? I would say it's a combination of things. But I would say that like the, maybe the drive that we try to have. when we see that in the people around us, how motivated they are, how, can they do things. and, that's something that if really everyone have people that can do things with that kind of passion, I would say that will make a lot of things easier. But that's, that's not a software part. That's, that's something, I would say, hard as steel. But It's it's, it's something you want to grow. Well, if everybody could steal it, then it would be no fun, I guess. Well, you can find out more about Brightpick at brightpick.ai. So you were early on in the .ai. Did you used to be something else before you were .ai? we started as a company doing 3D cameras, and, we're called Photoneo. we sell the Photoneo to Zebra. So, we were basically Photoneo.com before, that's, was the founding team. And now, they're probably in new home in Zebra, so it was a really, really great achievement. check it out at brightpick.ai. And all of-- I'm gonna try it again, Tomasz. Am I closer this time? it's uh, yeah, Tomasz is good. Yes, that's very… very That's very nice. Yeah. it one good time for everybody to hear? Like Tomas, but I, I, I, always say Thomas. That's, that's a… Sorry. I was trying not to do that. I was trying to be cool, but obviously my cool was j- it was just crashing out every time. All of his contact information will be down in the episode description. Thanks for being with us today. Thank you for having me.