Ep. 5: Erik Schluntz
Taking Elevators, Robot Body Language, and Advice for Startups
Erik Schluntz is a co-founder and the CTO of Cobalt Robotics, which makes a security guard robot.
- Download the episode
- Cobalt's website
- Erik's website
- Video introducing the Cobalt robot
- Video of the Cobalt robot using an elevator
The transcript is for informational purposes and is not guaranteed to be correct.
Audrow Nash (A.N.) (0:03)
Hi, everyone. Welcome to the Sense Think Act Podcast. I'm the host Audrow Nash. And in this episode, I'm talking to Erik Schluntz, co founder and CTO of Cobalt Robotics, which makes indoor security guard robots. Erik and I talked about having the Cobalt robot take elevators, how Cobalt has humans help their robots make decisions, robot body language, advice for entrepreneurs and several other things. It was great to talk to Erik, I enjoyed learning about how cobalt uses humans and robots in their systems, which each play to their strengths. It was also a great seeing how cobalt robotics has navigated getting investors and funding. As always a big thank you to our founding sponsor, Open Robotics, and I hope you enjoy.
All right. Hi, Eric, would you introduce yourself?
Erik Schluntz (E.S.) (0:54)
Hello, I'm Eric Schluntz. I'm the co founder and CTO of Cobalt Robotics.
Would you tell me a bit about Cobalt?
Absolutely. So Cobalt builds indoor security guard robots. So these are robots that will patrol around an office building, looking for anything out of the ordinary. We work with human operators to help support the robots. So if the robot comes across anything, it doesn't know how to respond to it switches over controls are humans. And then our humans can escalate exactly like a human guard on site would, whether that's calling the customer or calling police, or having a friendly video chat, instead of asking how someone's doing just like a security guard.
Nice. And so for the people listening? Would you describe what your robot looks like? And how do we refer to it? What do you just Is it the cobalt robot
or just a cobalt robot, we actually we decided we didn't want a separate product name from company name. That can be hard to to brand both of us. So it's just a cobalt robot. And I'll describe this actually, while playing a video for people that are watching. Sure, we'll get this going here. So the cobalt robot is about five feet tall. And it'll control around it has wheels, two main drive wheels. And then for supporting casters, it's designed to navigate around through an interoffice space, looking for anything ordinary, that can include doors or windows that have been left open, the body is actually coated in fabric. So it's a little bit soft and squishy. And this was actually a big part of our industrial design was that we wanted the robot to be friendly. The job of a security guard is to keep people and employees feeling safe and comfortable. And so if the robot is scary, you know, it really hasn't done its job, right. There's also a touchscreen on the front of the robot that we use for being able to interact with anyone around the robot, where one of our human operators can video call and talk to a person on site. We also have a lot of sensors, cameras that are 360 degrees around so no one can sneak up on the robot. And then a ton of sensors that you find in a self driving car like LIDAR and depth cameras, and I am Yes.
So how I'm thinking of it. It's like a telepresence robot that has a lot of sensors that makes it more sophisticated. And then you have the whole like person in the loop thing, which makes it a good bit more sophisticated. But is that a like a squishy, a basically a telepresence robot with a kind of cylindrical fabric body?
Yeah, yeah. And I'd say that's what our design is basically that it's telepresence five or 10% of the time. And I'll tell you this 90% of the time.
Okay. Now, and the one behind you has a little arm.
Yes, yeah. So this is one of our add ons for some of our customers. For our security patrols, we want to be able to patrol through multiple different floors. And so to do that, we need to ride elevators. Now in the past, we've done elevator integrations that are wireless. Those take a long time, elevator companies are often very slow. And so actually what we do now at a lot of customer sites is just physically press the button. So we added a one degree of freedom actuator, swing up and press elevator buttons. And we use the cameras and computer vision to detect the buttons know where we should press. And we actually have this rolled out at a bunch of customer sites now. And it is a lot faster to roll out in a wireless integration and it works pretty well. So yeah, I'll show a video of that for people at all kind of narrate that. So the robot first starts and presses the button on the outside of an elevator. waits for the door to open, navigates inside. elevators are very technically challenging thing to do. We find tons of things like elevator thresholds that are actually out of spec that would cause a lot of problems for people in wheelchairs.
What do you mean? Is that like a big bump getting into it?
Exactly, you know, we find elevators where it's a two inch gap, you know, between the elevator car and the floor or you know, one inch vertical, but once the robot gets inside, it uses computer vision to see the paddle and know which button it should press, flex the correct button drives forward, depress it. And as I mentioned earlier, this arm that we add is only a single degree of freedom. So we actually use the robots drive train to steer the robot left and right. And to move forward and backwards, the arm only moves up and down. Yep. And we use the robot for the rest of the degrees of freedom.
You may I think you mentioned so it has to the cobalt robot has differential drive or something so you can turn it's not Omni drive, so it doesn't move side to side.
It's it's differential drives, we have two main drive wheels and four support casters.
Okay, is that tricky to get lined up with the button?
Yes, so we definitely put a lot of work into sort of that motion control and planning to be able to nicely line up and press a button. Especially because elevators often have very tight space, we don't have a lot of a lot of room just sort of back up by 10 feet and approach it nicely. It's, yeah, we have to kind of operate in these very tight spaces.
Gotcha. I wonder, do you have ever the situation where the elevator is so tight that you have to raise the arm and then kind of swing into it?
We haven't hit that yet. And luckily, there are rules around elevators, for people with wheelchairs. So we can actually just follow a lot of those same design specs to know what the robot hardware needs to be capable of gotcha.
And is it difficult when you go into a new elevator? To find the buttons? Like I imagine that this is fairly custom, depending on the use case, depending on how you're detecting things?
Yeah, so we have a sort of a proprietary system that we've set up where one of our sales engineers can go on to new customer site with the robot, and very quickly calibrate the robot for that site. So we don't need a ton of training data or anything new like that. We can kind of just bring the robot through the elevator once, and then after that, it's able to use the elevator by itself.
That's awesome. You kind of... Can I guess that what it is?
So do you use the depth camera at all in this for figuring out how far away you are. And
Yes, we mainly use the LIDAR for that. One of the other interesting challenges is that elevators are very reflective surfaces, a lot of times you have sort of a polished metal. And time of flight depth, the cameras can do very poorly with that, because
they're shooting out infrared and trying to see that but then it bounces off. So you don't get any good depth information, maybe very noisy information,
you get very noisy, but the LIDAR at the bottom of the robot is pretty good. And we know that in an elevator, it's a fairly structured environment where we see the walls is usually in line. Why is LIDAR
more reliable? intuitively, that doesn't make much sense to me. So for the depth cameras, are they structured lighting, where they're projecting something out? And then trying to observe what that is, with the pattern and the deformation in it? Or?
That's a great question. So the one we use is not structured light, it's time of flight. Oh, and I don't think there's any inherent reason that a time of flight depth camera is is worse than a LIDAR, which typically, what we see is that LIDAR is are a lot more powerful, and just put a lot more into those be able to get a much better signal response.
Gotcha. And the LIDAR of this robot is at the it's like, on the base, right?
Yes, at the very bottom of the robot, and you can see around 270 degrees around the robot. So that gives us kind of a good sort of footprint of what the the room that said, Yeah, and then we use the optical camera on the front of the robot, and can get very good sort of optical readings, write up the buttons and see where they are.
Yep. And then how do you control the press for this, I'm imagining like, you draw, you basically raise that to the correct height that you imagined the thing is, and then you just drive forward until you hit some sort of drive
forward. And we have a set Oh, very tip here to know whether we've made contact cool little forest, what are the eggs? Initially, we had a force sensor, and then for reliability, we just switched it to a, you know, a switch. That's, that's calibrated. Yeah, one of the interesting things is sort of, you can we can tell that we've hit something, but you don't necessarily know whether you engage a button or the or that you know, the rim of the button and maybe didn't engage it. So there's some interesting things we can do to you know, to sense whether we'd hit that one of the first things we thought of is oh, you know, we can tell whether the light, the light turned on in the button, but you'll actually find plenty of elevators that don't light up. And so actually what we do now, is we have an accelerometer of the acceleration of the elevator.
So can you feel it moving?
Exactly that's kind of you know, the sort of that's like the the ultimate end goal is we feel like the elevators not moving. We know that we've correctly told the elevator what to do.
Now is there ever the case where the robot is in the elevator pushes the button, but Miss This so that it didn't actually click the button and then someone calls the elevator from a different floor, and it sees it.
Absolutely. And so I think what you brought up is that one of the really interesting challenges of this is that when we are in an elevator, in the worst case, we're inside a Faraday cage. And so this has to be often this has to be 100%. I'll
speak about it in a cage for just a little bit. Yeah,
absolutely. So a Faraday cage is a closed metal structure that no radio waves or electromagnetic waves can get in or out of. And so that means that for some elevators, when we're in them, we don't have Wi Fi or cellular. And that means that we can't rely on our human operators that generally we use for ourselves.
That's hard, because it's like one of the more difficult situations. Exactly, exactly. They're in a Faraday box. That's crazy.
Yeah, so it's very funny but And generally, what we say cobalt is that one of our sort of really fun advantages for our engineering team over say, working at a self driving car company, is that we just have a lot of inherent safety and stability that we move slowly through indoor spaces. If anything happens, we can just stop and call a human operator, you can't do that on a freeway. And so that means that we can basically solve for the 99% case, and we don't need to worry about solving the last percent bring anything in the elevator, except in the elevator. That's where we need to get 100% You mean safety
instability? For this yet safety and stability and stability?
Yeah, you know, we're not trying to balance on two wheels, it is always a safe situation for the robot to stop. And so we can take a lot of advantage of that, and basically, handle covering a lot of edge cases with that safety behavior of I stopped the robot and wait for a human operator, except in the elevator, then they realize
it. It's two interviews that this has occurred. So I have to figure out how to turn that off.
Okay, yeah, I'll need to be careful not to save the G word over here, but my phone. Yeah, so And basically, we need to make sure that because we're in this Faraday cage, where we can't call for help from an operator, that this robot is going to get itself out of the elevator come hell or high water. And there's all sorts of really funny situations you can get into. Like you mentioned that, you know, perfect timing, you can miss the button, but someone else calls the elevator at the same time. So it thinks that it succeeded. And we have really robust state machines that we've built around these behaviors. So the robot knows what state it's in and knows how to retry from pretty much any state and knows that these kinds of things happen. That even though it's it's felt the motion, it knows there's a chance that maybe this is just a coincidence. And if it doesn't go to the right floor, hey, I might need to retry.
Ah, okay. Yeah, cuz what I was getting at with that is I'm curious about the mapping problem. So how you split up different maps, I suppose it like maybe Each floor has its own map. And then you try to once you enter a new floor, try to figure out where exactly you are in it. So that which Am I in for one or three? This kind of thing?
Yeah, so there's a I think two interesting things that one is sort of knowing what floor we're on. And the other is, is knowing where we are sort of inside the floors. For the know, in the foreground, we actually use the accelerometer to the
robot. So you need to know the accelerations to try to we do what did you? And I suppose you decided not to use like a barometer or something like that. Was it too noisy, or I mean, not accurate enough.
So we explored a bunch of different sensors, including including barometers. One of the things that we found there is that indoors, pressures terminal lot more by the H vac system, oh, that's an actual altitude. So you can go on one floor and the pressure can actually be lower, even though it's higher, because the air conditioning settings are different. So it wasn't a really good sensor for the Tirpitz. Wild. where we are. Yeah, we did a lot of really interesting sort of looking at different sensory modalities for this. Now the accelerometer, you're absolutely right, we're double integrating Yep, and double integrating is a scary thing. If you do it forever, you're going to either end up going to the earth's core or going to the moon. And so one of the things there is that we can actually apply a lot of structure and constraints that we know about how elevator systems work, in order to basically constrain that and add a lot of these checks that keeps the robot from going to the moon, or the floor. So an interesting one there is that you know, that basically, floors are basically integer divisions. So if you stop, and you're kind of Oh, I think I'm at floor 1.1. You can actually snap that down. Yeah, for what, an elevator never stops at sort of one and a half floors. And similarly,
if it's working still
exactly what's working. And similarly, there's a lot of these other constraints that we found out well researching and testing on elevator systems that they follow very consistent acceleration profiles and speed profiles. And we can use a lot of those things to basically add these constraints. So it doesn't become an unbounded double integration, it becomes sort of a much more constrained problem that we're fitting to. Yeah. And we didn't tell what floor we're on pretty accurate.
Gotcha. So you integrate your acceleration results, and I guess, probably, so integrate, get velocity integrate, again, get position. And then you look at the position of the robot, how it's changed, because it's moving. And then you get some sort of rough approximation of how much you've moved. And then you use that. So it's like weighted information. So you say, Oh, it's probably about this.
Exactly. And we can use this extra information of, you know, when we know that we've stopped, we can basically clamp it to zero until we see more than a certain amount of acceleration. Because we know that when the doors are open when we stopped, you know, we might be reading a little bit of acceleration, but we know that elevators don't actually jiggle around. You know, if it's mostly stopped, it's a terrifying elevator. Yes. it lessens the terrifying Okay, exactly. So basically, we found a lot of these hidden constraints that let us do this very accurately, and filter it no before.
Interesting. What if you have to go up 20 floors or something like this? Like it's a skyscraper, say 50? floors?
There's, there's definitely a point at which breaks down. I assume I'm actually not sure where that is. But we have not yet hit a we've not yet hit a building where it does not work. trouble. Yeah. It. We've been in some high rises in the San Francisco area.
And it still works fine. That's awesome. Yeah. So if you want to go around that, yeah. If you want to go to like the 32nd floor, or what's the how large are these high rises?
We've done jumps of 20 floors with good accuracy. And I've never tested above
That's awesome, though. Hell yeah. I mean, I'm impressed. It works to that level, which is awesome.
Us as well, we were initially much more optimistic about the barometer, than the accelerometer, and we were actually very pleasantly surprised that it works out. And again, you can do nice things like right before you get on the accelerometer, right? Before you get on the elevator, you can pause for five seconds and zero out your IMU calibration, because you know, hey, I'm, unless there's an earthquake going on right now. I know that I'm not accelerating. Let me save that as gravity. And then, you know, for for a five minute elevator trip. You know, that stays pretty good in that over that short period of time.
And then how do you? How do you store your maps? Is it like, so I'm wondering if it's a so say you have two floors? Is it one map that includes both floors? Or is it two separate maps? One for each floor? Or each each? Like? I don't know, Consett? consecutive space are contiguous. I don't know, continuous space contiguous space.
So that's another really interesting question that we had at the beginning while working on this. And it's also an interesting question to ties into our hdri of how our operators and how our customers interact with a robot. Because this isn't just a robot operating in a vacuum. This is the operators and customers want to see where it is on the map, they want to see the alerts coming from the robot. And actually, what we found what they liked, most was not needing to switch between maps and only being able to see one floor at a time. But seeing all their floors laid out side by side, just like you would on a floor plan. And so actually, what we do is we just have them on one giant map in different locations. And so a robot switching floors is implemented as just teleporting to kind of a new island in this map that work and go between.
Interesting. And the elevator is like the portal between all of these different floors. Exactly, yeah. Okay, now. So getting into the robot a little bit more.
So it has a bunch of sensors. Would you just talk a bit more about the sensors that are on it?
Yeah, absolutely. So there's, I'd say two categories here. The bottom half of the robot is like an indoor self driving car. And basically, its job is mobility and safety, to bring the robot around through a customer space and get the robot anywhere it needs to be. And the top half of the robot is all about providing the security service that we provide to our customers and providing that value. And basically, it's a mobile sensor package that can be brought anywhere. And there's a couple of high level goals there. The primary thing that we do for our customers is detecting people. You know, if we're trolling around the warehouse at three in the morning, you want to know if there's a person, you know, they're in the warehouse. Yeah. And a lot of times, you know, they are supposed to be there, but we get an alert to our operators, and they video call in and say, Hey, excuse me, can I see your badge? Why are you here after hours, just like a security guard on site. saying, you know that they can authenticate that and make sure they're allowed to be there. The other big category of things that we do is facilities inspection, going and taking pictures of sensitive things, whether that's an expensive piece of equipment, either using our optical cameras or a thermal camera, or checking doors, sort of sensitive things like that. And also environmental checks. So we have temperature sensors, humidity sensors, carbon dioxide, and carbon monoxide sensors in the robot. And what's really great is being able to move these sensors, this sensor package around at a tire building, and not just get sort of a single point measurement like you would from an air quality sensor. But being able to generate a map of air quality, and being able to say, hey, not just what's the carbon dioxide in my office, but get that map and say, Wow, the carbon dioxide is all coming from this corner here, we must have a broken bet. And be basically taking that promise of what like IoT sensors trying to do, and bring in 1000 sensors bring it everywhere, and to localize that data on a map. And so we've helped customers catch really interesting things. Whether that's broken h vac systems that could possibly pose danger, we actually found h back issues where the with temperature, where we show that one half of the building was like five or 10 degrees colder than another. And they said, Oh, man, we've had employees complaining about this. For months, we didn't believe them. But now that we see the data from the robot, and so really what the robot is, is, we want to bring sort of superhuman sensing to what the guard could do. And the things that a guard could notice, while looking around and that that can be security or facilities.
Did you Do you guys ever so you have this arm now. And I feel like that's a relatively new thing to push elevator buttons. You ever, like try doors to see if it's a hinge door to see if it's locked or interact in the environment, interact with the environment in any way with it.
So we have some interesting things coming out for doors in the next year. I can't talk too much about Okay,
stay tuned, stay tuned.
So, and I will say with this, we can press handicap up and Stoker doors.
Ah, that's awesome. Let's see. So with these sensors, now I noticed is with all the air quality ones, I basically how did you select the air quality sensors? So you have like carbon monoxide, carbon dioxide smoke? I don't know what else? How did you select the sensor packages that you had humidity and temperature? How did you select these ones? For as opposed to anything else?
Yep, exactly. So at the beginning, sort of when we we did a lot of customer discovery asked our existing customers, what are the kinds of things you're worried about in your hair? What are the kinds of things you you want to know about your space that you don't have right now, and sort of took a lot of that input and then looked at what was feasible, we actually have a radiation sensor on one of our robots from one of our customers. So that's not a standard option. But you know, we could add other sensors as needed for special cases.
Gotcha. I was gonna ask about customization next. So you are customizing a little bit I imagine. So with the body of the robot being kind of a big cylinder covered by fabric, it seems like you can probably have pretty large sensor payloads, and you can swap them out fairly easily. So you mentioned the radiation. One, but do you do Is there a good amount of customization that occurs or
only for very large customer deals, we really try to stay away from as much customization as possible, the sensor package is one thing that's a little bit easier for us to do. But it's sort of right now it's tied to sort of large new deals that we do with customers, I would say that the majority of what we do that's custom, I would consider more configuration than customization. So we can configure the robot with actually different color fabrics to match the customers. And a lot of the robots of behaviors actually are very different between customer sites. And one of the ways we think about this is that security is basically a big human configuration of if this than that, if you see a person that doesn't have the badge, call this person, if you see a door left open, do this. And it's these are sort of the instructions that are given to human guards and sort of human security teams, but how they should respond to all these different situations. And so our robots are very highly configurable for different customers. So for one customer, you know, seeing a person might be just oh noted in the daily security report. And for another customer it might be immediately called the police. And so you know, there's these very, very divergent actions based on what the robots attacks. Yeah. And we build systems that let us very easily configure that, so that the robot can be to basically do exactly What your guard was doing?
Yeah? How so how does that work? So for you to customize the robot's behavior? How, like, are you using our Do you have users use like a block programming language? Or is it just YouTube and a bunch of values? How does this work? Or use maybe select from a drop down? If this occurs, then do this? How do you set this up? Yeah.
So we'd like to make things as easy as possible for our customers and our customers. They just want security that works in they don't want to think about the robot or programming anything. Yeah, so typically, one of our account managers who's an expert insecurity, and also now an expert in our robot system, they will work with a customer and look at their existing instructions for their guards, and basically translate it into our configuration for the robot. So the customer just has to give us their instructions as if we're a security guard, which they love it. And then basically, we turn it in, on our side, this configuration for what the robot does.
So it's a fairly one off thing done by an expert, is what I am hearing for this. And so
Exactly, yeah. And this is sort of pretty standard for how the security industry works, that every new every sort of new building, or company, when they get security guards, they have an account manager that basically helps set what the what are the instructions? What should they be doing on the site?
how detailed is it? Like, how many things to configure? Is it? Is it like a huge list? Or is it a few? Simple If This Then That statement? I guess it may vary? Yeah,
it varies, I'd say there's some customers that sort of are very new, and, you know, young customers that are expanding have their first few buildings. And we actually usually help them define sort of what their procedure should be. Because we've seen a lot of much more secure much more mature security programs, and help them sort of know, hey, well, what happens if this person doesn't answer the phone, like, you know, you don't want you don't want something to just stop. And so if it's a bigger company, we'll know, here's the whole call tree of how you escalate things. If someone isn't available, and for younger companies, sort of we help them define a lot of that same security program with the same rigor, so that we can help them get
to that level. Gotcha. That's cool. That's interesting. You guys are becoming security experts through this problem.
Exactly. And sort of, for us, we have a big robotics team. And we also have a security operations team. And they're the people that are interacting with customers and using the robots and using our control interfaces, to configure them and to respond to alerts and help keep the customer safe. Yeah.
So have you guys ever had kind of a silly question? But have you ever had a like, where a security guard would like, maybe try to physically stop? If physically stop a person from doing something so you there's like a thief or something? And they would like tase the person? Like, is there any like, would you put a taser on the robot or like on the little arm that comes up?
So there's, there's no taser on the robot. And I'm actually really happy. You asked that. One of the little known facts in security is that a security guard will never touch a person, it's a huge liability issue. All they do is call the police, you'll actually see a lot of security guards that either have fake guns or unloaded guns through that it's entirely for deterrence. Whoa. Because imagine sort of the the liability if a guard misjudges. And a person was actually an employee, they thought they were you know, up to no good and tackle someone that hurts them, you know, be this huge liability issue. And so it's very funny when we started off, this was one of our big assumptions as well. And this actually kind of gets to how we started cobalt of when me and my co founder, Travis style started cobalt, we actually didn't know what we were going to work on. We had both started companies in the past, we both been through Y Combinator. And that's where we met each other. And we've seen a lot of people come up with a startup idea, and then really get overly attached to it, despite it not really being needed by anyone. And so we decided that we were going to take the opposite approach. We were going to find a real customer and a real problem, and then work backwards to the idea. And so you know, he quit Google, I turned down a return offer to SpaceX with no idea what we were going to do. Both of our families thought we were pretty crazy, but we're like, No, no, no, no. startup idea is crazy. This is better. And so we spent the first few months interviewing people from different industries, anyone that we didn't really know what their job actually entailed. We wanted to talk to them and just asked, hey, what are your problems day to day like what what would you pay money to solve? And luckily, one of these people we talked to was a director of security and he started complaining about his guards, sort of how unreliable nightshift you know work can be why his cameras weren't enough. Yeah, and we kind of the first thing we said is can we build these smart security cameras. And he actually said, No, like, I already have smart security cameras. But someone, someone comes in wearing a hat, and you can't see the face. It doesn't matter how smart the cameras, you either can do nothing, or you can call the police. And that's why people still have guards, they still have guards to, to follow up and investigate as something's happening is happening, and understand to collect more information. And that's when we realized, Hey, this is the perfect job for a mobile robot. It's kind of that blend between a guard and a smart camera where it's not just about detecting a person, it's about once you detect them being able to follow up and gather more information, go up to the person and say, hey, how can I help you? And then you can make the call of, you know, what do I need to ask? Or not? Exactly, it's kind of like this, you need this third option of following up and getting more information before making a final decision. And so actually, now that's a big direction that our product is going is that everyone now has tons of smart cameras and smart sensors. And all of these smart devices, for enterprise security, create work, they create alerts, they create alarms. Yeah. And actually, a lot of our customers that we've talked to have had to hire more security guards, because they have all these things, that's fun as they need to go investigate them, they need to go deal with false positives. And our strategy is that all this other security infrastructure is creating alarms. And our robots are actually reducing work. Yeah. And the robot automatically gets dispatched to go investigate these things, and say, Hey, this door for this door force alarm was actually a false positive, the door looks fine. And then it gets this batch to the next alarm. And so basically, there's kind of these two sides of security, there's the detection, and then there's the resolving. And we actually want to be much more on the resolving side. So the robot is not just a moving security camera. It's much more than that. It's the ability to follow up and resolve things, which is what a guard does, not what a camera does.
Interesting. I feel like you've said a lot of very interesting things just now.
No, thanks. Yeah, it's a, it's a really fascinating space, I think it's very cool seeing how more people and enterprise security are building sort of these, they're trying to build these much more autonomous systems. And he's much more sort of systems for handling physical security without needing a lot of human input. But also, you know, one of our customers quoted general patents us and said, fixed infrastructure is a monument to man's stupidity. It's a quote from World War Two. And this is sort of why no one builds castles and fortresses anymore, is that anything for infrastructure, you have anything that static, is at some point, either going to be broken and not replaced, or someone's going to find a way around it. And that's the difference between cameras and sort of fixed sensors, and robots and guards is that we're infinitely adaptable. A customer can call one day and say, Hey, our left door alarm broke, can you change the robots patrol to stay in that area? And we're like, yep, we can do that. Just like a guard, you know, you can just call us. And we'll immediately responds to whatever that is. And that's why we don't want the customer to need to go through some interface. We don't want us. We don't want cobalt to be a static system. It was a flexible and responsive system. Yeah, that's why they have
I'm saying, so the way that I'm thinking of cobalt now, is you guys are almost like, but you guys are a security company. And your personnel is your robots. Exactly. Which is very interesting. It's an interesting model. It's almost like I don't know you've you've taken all it's just it's interesting, because you're not selling the robot, which is what I first thought it was. You're selling the service around the robot.
Exactly. Yeah. And I think that's, you know, as we scale, we're exploring, sort of splitting that off. So cobalt can stay more of a technology company and work with guard partners with the with the operators is
splitting exactly what off the
work with an outside partner for sort of those security to operators to be the security part, the cobalt can stay more of a technology. I see. But I think in the beginning, it's a really, really good strategy. Very, very,
I see seems to trigger Siri, when I say see God's sorry, what did you say?
That basically, you know, there's this balance of us being a technology company and us being a security company. And at the beginning, it's really powerful that we can be both of those things. Yes, you can do that. So we get vertical, we get vertical integration. And that means that you know, our engineers are sitting alongside our security operators and seeing what the deficiencies of the robot are and seeing what the pain points are for the customers and They're talking to security end users. And if we were just selling the robots, and someone else was implementing security with them, we wouldn't get any of those learnings. And so we want to be a place where we are a technology company. But that's very, very integrated with the security and very product focused, and really sort of end user focused
gadget that is very interesting. Yeah, initially, all the questions about configuration and things, I was assuming that you just sell your robot, they buy it, the customer buys it, and then they figure out how to use it in their space. When really you're saying, okay, our robot is going to be like an employee. And every time you want to update it, you call us we make the changes. And then you present them do so you present their security manager or something like this with the data, or whoever's relevant with the data that the robot captures this kind of thing. Yeah,
exactly. And that's sort of the way that we provide the end service, you know, the service isn't the robot, it's the data that we collect and provide to them. And there's a couple things a couple of ways we do that. One is, you know, if there's ever any urgent incident, we just call them Yep. And then the customers have a interface on a web dashboard, or they can live see what the robot is saying. And they can dispatch the robot to go see something. So we might call them and say, hey, there's a break in, in progress at this office, you know, pull up the dashboard, and you can watch while we resolve it. And we've actually, we've stopped a few break ins, oh, congratulations. Thank you, it's, it's actually much more boring than you would think, you know, modern Moto, you're just going
up to them. And you're like, stop, and they're like, Oh, no, and then they run out.
Modern criminals are not in ski masks, you know, breaking into Windows, they are social engineering delays, and office buildings. And so
what do you mean social engineering there? What is that
they're there pretending to be an employee that forgot their badge, but they're actually not, they're well dressed. They're, they're trying to blend in, they're trying to blend in, around other people, and sort of. So we had a customer where one of their door locks, stopped working at a door swung open to the streets of San Francisco. And fairly soon after that, our robot detected a person in the site. We approached them because our operators didn't recognize the person. And we video chat and said, Hey, excuse me, can I see your badge? And the person was the video like, Oh, I'm lost? Like, I didn't know I wasn't supposed to be here. It's funny. I was like, I have to in the office building? Sure, yeah, you're just so you know, here. You know, we call it the customer and call the police, and then escorted the person out the door. And then the robot was able to stay century at that door that was open for the rest of the night. And so that's the kind of flexibility and responsiveness that we want is that as an emergency happens, we don't want to just be on a fixed rail, like a camera, yeah, we're going to be doing what a garden would be doing. And that's, you know, making value calls as we go and deciding what is the best way we can provide value to this customer?
So how do you code in all that behavior and the flexibility I'm imagining like, something like behavior, trees, or whatever they do in video games, where it's like, you can have fairly complex layered behavior where I go, I try this, and that doesn't work. So I'm going to try this other thing. And you can keep moving from limb to limb of the tree. Is that how do you encode your behavior? Basically?
Yeah, so that's a really good question. We use a hierarchical state machines for most of our behaviors. But actually, I'd say a layer above that. And I think that it would be misleading to say that our state machines resolve that case, we keep our high level decision making done by our human operators. And so they are able to on the fly, say, Hey, don't patrol tonight, stay century here. And basically giving them thinking that for operators, it's more like them playing Starcraft, they can tell the robot what to do. And we provide a really good interface for them to be able to tell the robot to do different things. And that might be go patrol this floor that might be stay here that might be go recharge, okay, and that high level decision making, we will have to be made by our human operators who are very highly trained, and know our customers. And then our state machines that we build are basically these primitives for the robot to be able to do these block size to actions. But it's the human that's deciding sort of which of these should be done.
Interesting. So the human at a very high level, it's almost like picking the mode of whatever the robot will do. You do. It's like a delegation effectively, exactly. And then the robot will go and it will execute this fairly. This this decided behavior and you have all those primitives, those smaller action, control loop things go around this desk, go look in that unexplored territory. These kinds of things. Yeah, Yeah,
yeah. And so we want to build the system that I think it's, it's, we really consider our system. It's the combination of human and the robot human operators. Yeah. And that's really it's those put together that allow us, allow us to provide a great service for our customers, I think, you know, we've seen self driving cars being worked on for 10 years now. And they're just barely starting to actually give, you know, get out into the market, and give taxi rides to people. And for us, what really attracted me and my co founder to this idea was that we could use this combination of humans and robots to immediately get into the market and start providing value, like right away. Yeah, right away, even though pieces of the robotic technology weren't there yet. And now, as all this technology gets better, what it does is it increases our ratio of how many robots each one of our operators can manage.
Gotcha. So tell me a bit more about the human in the loop kind of thing. So how does that work? They're on a computer somewhere logged into some web application that you have,
like, how does it work? Yeah, great question. So we have a lot of operators, and they work from our offices or satellite offices. And they have a sort of this big three monitors set up. Each of them for AI, basically, they can zoom in to one robot, and they have a fleet management view, and they have sort of a communications view. And so they are
management, a little bit slower for that. So fleet management, if they're using many robots in the same environment, or
Exactly, so they're looking at sort of the health of all of their robot, okay, sort of how we have it work is there's, you know, five to 10 of them on shift at a time. And they split up the fleet of robots of who's responsible for which robots, you know, plus some overlap. And so dynamic changes. And they're saying, Hey, I'm watching my robots, and the robots are telling them, Hey, I think I saw something or Hey, I need help, I got stuck. And they are zooming into these robots kind of one at a time, as events are popping up that they need to go resolve. So then they switch to that robot specific view and can go take action, whether that's video chatting with a person to, you know, talk to them, or ask, ask to see their security badge. Or maybe it's changing a patrol route to go around, you know, a new obstacle or something that's causing issues for the robot. And then if anything is needed, they can go communicate with the customer, they can escalate something to the robot sees into the customers dashboard, so that they can
see Ah, so they have, they have their setup where they see many robots, they have a view into one robot, and then maybe they have a good way of accessing commands or something with it for escalating the situation. Is this one robot specific, I guess? Or is it? I guess you don't have multiple robots coordinating? Or maybe you do? I don't know.
Yeah, so for most of our customer sites, there's one or just a few robots. But individual customers have many robots across their different buildings. And that's one of the other things we really see is that a customer that has this one place really likes to expand to all of their different offices and satellite offices. Yeah. So that they can get this consistent data and reporting evenly across sort of their their whole site, or their whole collection of sites. And so they you know, there might be a call tree that applies for these 10 robots that are all from the same customer.
Gotcha. Interesting. Okay. Yeah. Yeah. And then so when the robot is stuck, or anything they the person takes over gives them high level guidance, do you have to do anything where the person will do? So you mentioned, like, pick another route? Or something like this? They won't do like map editing, or something? Like, will they correct any sensor errors, or say, This region is actually a spot you shouldn't go?
They have some annotations that they can add like that on the fly. But if there's anything bigger, like if, if they come in one night, and realize that the customer has totally rearranged the furniture, you know, they'll basically they can create a ticket for us to go with remap. And we can do all that remotely. And it's kind of like the next day, you know, we would go look in and see what,
so you're working with an existing map, it makes sense for this kind of thing. So you can localize
and that's exactly and that's something where when we first go to a new customer, that sales engineer goes on site for a day with the robot shows that the building shows that the elevators shows that any sort of you know, doors are handicap delicate, it needs to know about and then we have that map that we can navigate against, is it some and we're using, you know, right now some pretty we're using Ross and we're using, you know, a heavily modified version of move base, and then a half stack NaCl. So a lot of that kind of standard standard, but improved. Ross systems. Yep.
So you forked specific things, and I've improved them internally. Exactly. Which, which Ross are using are using Ross one are using Ross two.
Yeah, so we're using Ross one. We haven't yet seen a lot of other people switch to Ross two for, you know, live deploy the customer sites, applications yet we're seeing a lot of interesting traction there and sort of new things getting started with Ross two, but we haven't yet seen all the level of limit that we'd like to see before switching would make a move.
Gotcha. How? How has it been working with Ross stack for you? Like, what are your? I don't know, just how, what are your impressions of yeltsin?
Yeah, I mean, I I really like Ross, I think the just the general messaging architecture is a really, really good way to design systems that it sort of forces that microservices architecture, in the robot, and really good separation of concerns, definitely, to be able to work on a lot of different pieces, and just know what the interfaces are. So I really love Ross conceptually, there's, you know, a couple downsides. And there's a couple of rough edges, especially of Ross pi, the Python implementation, but you know, the things that we work around, and I think, I mean, what I love most is just the community and the ecosystem that any sensor we find, it's like, oh, there's a Ross node already made for it. Like, we can just, you know, install it, and we're ready to go. And, you know, I really love that. And, you know, I want to find more things in the future where cobalt can contribute back into open source. And I think that's something that I want to do as we get more libraries and things built that might be a little more general, outside of just us,
because so for the, like your fork of NAB two, or any of these other raw libraries that are built on top of Ross, what was the decision? Are they public? Or what was the decision to fork for this kind of thing? Yeah, they're not public
yet. But it's something we've thought about. One of the, I'd say two of the major areas there that we've that we've added is one kind of just overhauling a lot of the innards of move base to make things more reliable.
Base very well.
Yeah, yeah. So move base is one of the big packages in the bra snap stack that's responsible for getting a robot from point A to point B. And it's kind of the the nice high level interface, where you can say, hey, send a nav goal here. And move base is a open source Ross package that implements how to do that gotcha, you give it some configurations about where to find your map, where to find your cost map and sensors, to not hit obstacles, and how to talk to your motors, and then it can go. So that's kind of the starting point of what we've, you know what we've very heavily modified. One of the interesting things that we've had to change it actually, is the ability to send intermediate goals.
So we as opposed to just the actions, abstraction, as opposed
to just work, we send an action that has two goals, sort of the final goal, and I think, a waypoint along and it will actually start moving towards the waypoint, even if we can't reach the final goal.
Now is that the why is that better than just sending to actions, so an action just to be give some background for those who are not familiar. So you send something, it's a high level thing that you'd like the robot to do. And then it will send feedback throughout the time that it's completing it, which you can do something with, you could say, I'll cancel nevermind, or just monitor it in some way. But why? So why is the two actions within one action? Why is that different than just sending one action, and then another action, I guess it takes both into account.
It's lower latency, and what we care about here, and the motivation for this was actually getting into elevators quickly. A lot of times, when you press the button at the outset of elevators, you have three seconds until the door starts closing. And if it's across the elevator lobby, we actually have to move pretty fast to get in there. And one of the things that we've seen is that if you send just one Ross action of go, Oh, so basically, the one of the things here is that if the elevator door has not yet opened, if you send a nap goal into the elevator, it will sit there and wait until the door opens and then start because I can't plant a calf there. And so basically what we wanted to do is hey, we're trying to get into that elevator. Even though the door hasn't opened yet. We should start moving over this get lined up in front of it. And basically doing both of these sort of within move base. Lets us seamlessly transition into that second goal as the door opens really quickly, rather than stopping and lining up with that intermediate goal. And then send the Second action to go inside, it's much faster for us to actually switch that goal. Without even stopping the robot. As soon as it sees that the second goal is viable, yeah, it's switched over. And the local controller just keeps on going. Also know, for any listeners that aren't familiar, of move based on the nav stack, sort of as a two level system, there's a global planner, that is sort of like, think about as you're a star, you're Google Maps of, I'm here, I'm trying to get there, plot a route around my obstacles that I know about and get there. And then the local controller takes in that path, and is simulating its wheels trajectories to figure out how it should follow that path most quickly. Get to the point.
Okay. And then the interest in eventually open sourcing things. I mean, so I get, so from the company perspective, it's not quite your interest to maintain a, like an open source, library or anything. But why why do you feel like you'd like to open source things? I mean, I'm at an open source company. So clearly, I like it. But yeah,
I think for me, it's a sense of giving back and like paying it forward. cobalt was very heavily dependent on open source at the beginning, we actually launched our, our first product and deployed the customer sites, with myself and a single other robotics engineer, wow. And we would not have been able to do that, then, you know, plus some web engineers and hardware. But we would not have been able to do that without really heavily standing on the shoulders of giants and using these open source packages, and building layers on top of them. And I just found that really exciting that, you know, two people were able to build a, you know, a production ready robotics system, by using a lot of these open source packages. And I just really, really enjoyed that. And I think I want to make sure that, you know, problems that we solve just sort of first humanity, I don't want, you know, engineers everywhere to need to, you know, solve the same problem over and over again, I love it. Now, of course, a lot of the things that we built are very sort of specific, customized to our robot. But you know, we're always looking for things that could be a good thing to open source.
Now, so, two people, you had a production ready robot, how large Are you guys now?
Yeah, we're about 115 people right now.
And so that's a lot of the people that are doing the security related thing.
Exactly. Yeah, about half of that is actually our human operators to supervise the robots, control the robots. Our engineering team is still very small, it's about 23 people. And that split again, across robotics, web and hardware. So it's a really great place where you know, the teams are very small, each person can have a really big impact, and solve a lot of interesting problems and have really good ownership
over the code. Totally. What's the so going from two, you had a production ready robot, now you have 20 engineers, or so what are the additional 20 ish people, like you said, or what are the additional 18 people or so doing? Yeah,
we had two engineers to get to the point where we can have one or two robots roll around. Now with a much bigger fleet. There's all sorts of other, you know, other things we have going on. And also for this first production ready robots, that means that each one of our we had one operator at the time. So if he's only looking at two or three robots, the robots can be a lot more needy. And so really, now everything is about scalability, and saying how many robots can each one of our operators handle and that means the robots being able to, you know, not get stuck as frequently, being able to unstick themselves if they do get stuck, you know, navigation area, building a lot more features out for our customers, better data reporting better information that we can send them and do that more reliably and more quickly. So I'd say it's, it's really about adding a lot of like meat to the bones of what our product services and increasing reliability and making these robots, you know, really rock solid so that we can scale scale out the fleet. Yeah.
Can you tell me a little bit about manufacturing your robot or just in general making them and deploying because you have how many? How many robots out in the world now.
We have over 100 robots deployed very exciting. So we actually manufacture all of our own robots in house at our right now our office in San Mateo in the Bay Area of California. So we've really liked having manufacturing in house because it lets us have a very, very fast iteration cycle between engineering and hardware. So we can solve issues as they come up and roll them back into the design and be have engineering right there to solve any issues that happen. So now as we're scaling up manufacturing, you know everything is getting a lot more locked down and as volumes Going up, you know, you start to see 1%, you know, 1% errors where if you're buying, you know, you know, SSDs, you know, it's a 1% chance that they come out of the box debt or something like that. I don't know about that particular component, but
some arbitrary about some widget. Yeah,
widget, you know, when you're building in five or 10, robots, you don't really need to care about that. But when you're building a lot of robots, you're going to have anything that can fail. Exactly. And so that means you need to build in a lot more, you know, basically unit tests for each component that goes into the robot, everything gets tested before it gets put in, they get put into sub assemblies, those sub assemblies get tested, before they get put in, and trying to catch any of these errors sort of as early as possible. And then every, every robot that gets finished, goes through two days of battle tested at our office before they go to battle testing. Yes, exactly. And so it's a basically, the robot goes back and forth across like, a simulated office environment with very rough and bumpy floors for two days to try to shake itself apart. And it goes through basically making sure that it can do all the different kinds of tasks that it will be required to at the customer sites, we can catch any errors or manufacturing defects before it gets shipped to a customer.
How is it? So where so you're doing your assembly in house, I assume you're buying a good number of components to put together? Exactly, yeah, how has it been sourcing those components? Like the process of doing that is very interesting to me,
this has been a very challenging year with a global CIO like that. And so you know, a lot of the components are either off the shelf sensors or compute pieces. And we do design our own custom PCBs that go into the robot. And I'd say the most of the most of the off the shelf pieces, it's, it's fairly easy. You know, we do research online, we test different components and make sure we go with vendors that are sort of more industrial, or they say, Hey, we're going to guarantee that we're going to keep making this part for at least another three or four years. Oh, interesting. There are, you know, in the early days, there were more consumer components in the robot and things like that are dangerous that, you know, it works great. But you know, the next year, it's not available on Amazon. You know, in the in the first version of a robot, there were definitely a couple of components, you know, purchased off Amazon. And it's a it's a great supplier until they disappeared.
That's so funny. Yeah.
And, and now with the chip shortage, one of the big challenges that has been that, you know, so many people are, are ramping up production, for different things that even very simple components, like inductors, that go on a PCB will go out of stock. And there's been a couple times where if you don't have those stock piles, you know, you have to change a PCB design to use a different a different partner different value, because you can't get, you know, whatever component that goes on it. And so things like STM microcontrollers are very hard to come by now. And even surpasses our Yeah, it can be difficult to find gotcha. passives, like resistors. Exactly. resistors, capacitors inductors.
Wow, that's really interesting.
So it's been a really crazy year for supply chain management, inventory. But we've done a good job. And there's been a lot of heroic lifts from the engineering team here to redesign with available five days is redesigned components around, redesigned boards around what's missing, and find other options.
Let's see. Now another thing, I'd like to talk about the human robot interaction of your robot, so it's covered in fabric, just tell me some of your human robot interaction considerations in designing the kobalt robot.
Absolutely. So this was one of our really, really big sort of goals when we started this, because when we, again, going back to set up that that customer driven approach that we wanted to take, when we first talked to customers, about you know, whether they would like this product, whether they wouldn't, a lot of their biggest fear wasn't that the robot wouldn't work, it was that their employees would be scared of the robot, and that they would like something like this. And so we put a lot of effort into trying to dispel that fear, and making the robot as friendly as possible. And so that's why we we actually contracted a design firm that's very well known, called fuse project, and worked with a world famous designer in the heart. He actually helped design the Herman Miller office chairs. And kind of the sense that we wanted to go for it was not Terminator, Robocop, but we wanted to feel like a high end piece of furniture. That's something that's natural to be in the office that's helpful and useful, but isn't sort of isn't as much of like a intelligent thing that you know you're going to fight with. And so that's why we went with sort of the fabric basis that it was, it's nice and sunny. And it's actually we've seen it like crazy it's we go when we went to early customers, and would you an onboarding, for them to bring the robots there and basically tell the employees what it was and how it was going to work. A lot of people were initially very scared about the idea of a security robot. They were picturing picturing Terminator or Robocop with a taser. But you know, as soon as they came to the, you know, the all hands or the lunch and learn that we were host, and they saw the robot, and they touched the robot and realized that it was soft. And they talked to one of our operators, they realized, Oh, this is just like a security guard that just happens to be remote. And that just getting people to come touch the robot and interact with the robot. And see what it is really, really helps with that. Yeah, but Hollywood, sort of, Oh, yeah. Hollywood's depiction of robots is, you know, definitely not good for us. And, you know, we're trying to stay far away from that.
Very interesting, that's crazy to me that people were afraid. I mean, I guess I've been involved in robotics for so long and not talking to customers. So that
exactly, this is something that's, you know, challenging, and that would why we wanted to make sure that we were very close to customers is that for us as roboticists, it's very easy to say, oh, who doesn't love robots? Yeah, so a lot of people don't. And so it's something that we want to be really, really careful of, and really just take, you know, very good consideration. And so actually, that goes in not just to the industrial design of the robot, but also into a lot of what we call the body language of the robot, and the software and behaviors. And so there's some interesting things there, if you know, we have an issue in the past, where if they, if the robot got stuck, and was waiting for a human operator to you know, help it proceed, if it was stuck near a person, the person would think, why did the robot stop and just stare at me for 10 seconds, you know, and then continue on. And actually, it was that the robot was just stuck, staring at that it just happened to get stuck near that assumed and a person that doesn't know that assumes there's attention. So now we do things, like if the robot gets stuck, it's something displays on the screen that says, you know, oops, I've gotten stuck, I'll be on my way shortly. And make sure that people understand what the intention of the robot is. And that's made people a lot more comfortable around.
What other so that's really funny about the body language of the same phrasing it as the body language of the robot. And so I see so you'll see someone who's watching the robot or sees the robot come up, and they assume a sort of intention behind whatever the robots doing. And so then you have to so you're making this explicit message of Oops, I'm actually stuck. I'm not just like staring at you, or something like this. How do you find those? Is it is it case by case where someone will be like, This made me uncomfortable of what the robot did? Or how do you? How do you go about designing robot body language? And I would love to hear other examples of robot body language.
Yeah, so I think the one of the best ways that we do it is that we have our own offices patrolled by cobalt robots, for our security. And so that just means, you know, we're dogfooding we're trying our own products, and dogfooding, for anyone that hasn't heard of it as a term of basically, if you're a company that makes dog food, you should eat your own dog food to make sure it actually tastes good and is high quality. That's, if you want to express your own product. If you don't use your own product, like how can you expect customers to use it. So that's something that's really important to us. And so that, as we're working in the office, you know, to feel what it's like to have a robot go go past you, or someone to come up and ask to see your badge with a robot. And so doing that is really, really important just to get that sense of what it's like. We also have engineers that will go on site to customers, with customers and walk around the robot and see, you know, see how people interact with it. And we just really try to get as much exposure as possible for our engineers to be with end customers, and also to be with our operators. Because a lot of times our operators see or they're seeing everything that goes on around the robot, and they're talking to people out there, they'll hear complaints, or they'll, they'll hear sort of people being delighted that they're talking to someone through a robot. And we're just trying to keep engineers not just looking at code, but involved with the end product and seeing the pain points is really important to us.
That's very interesting. Have you. So there's a growing space of research, rather human interaction space. Has any of that research been useful to you guys? Or like, have you been leveraging it or it's all things that you've been finding kind of organically.
I'd say it's a mix and one of our advisors, Laila Akiyama, she's an expert in HR II, and so we brainstorm with her. And I say that's a mix of things that There's a lot of things that once you hear them feel like common sense. But there's also really good things that are, you know, very non intuitive that are very cool. One of the things that we had heard and learned from HR AI experts, and some of this research is that being completely stationary, for humans is actually a very aggressive and sort of assertive behavior. It's like, I am rock solid, and medicine. And for a robot, though, because like, by default, a human doesn't stay Stockstill, they fidget. And a robot by default stays stuck. And it's the one of the ideas that we've had is that if we're, if the robot is idle, instead of being stocked still, it should fit. You know, when kids turn back and forth a little bit. You know, that's one of the things we're thinking about implementing now. But kind of going back to that body language is that being stationary is actually like, more aggressive than moving sometimes. And so there's a lot of interesting things like that, that we've learned about
interesting. And see. So
yeah, I think those are often called keep alive movements keep alive show that the robots Yeah, show that the robot is still active, it's still doing something, even if it can't make progress towards its goal.
Yep. Yeah, I'm always a little disappointed as someone working on robots that almost all the time or robots are off. And so it's like, almost all of the robots are just completely still for almost all the time around robots, which maybe it will change at some point in the near future.
Yeah, yeah. And I think for us that that's actually an interesting segue that some of our future plans is making our robots a lot more general purpose. And our thoughts there is that security guards actually do a lot at, you know, at employers, they're making sure nothing bad happens at night. But during the day, they're doing visitor management, they're checking people in, a lot of times, they're almost acting like a secretary, or sort of a receptionist. And so one of our goals is that, while the robots are doing security at night, during the day, they can be a Virtual Receptionist, and check someone in just like envoy but then actually lead the person to the conference room, you know where they're supposed to be. And the idea is that, you know, once you have a robot on site somewhere, I just want to use it any functionality that you can do with our software updates, it's you have the hardware there, it's already paid for by security, because that's sort of a big cost, you know, the big cost, and you can start adding all these other applications. And we've already started doing that with some of that facilities monitoring that I talked about. But one of the next ones we're looking at is more daytime applications. Robots, you know, more active, and so people will be able to see them moving around and interact with them during the day.
Let's see, maybe a bit more of a controversial check. Question. But so how does this relate to jobs for security guards and things like this? Because it is, in a sense, automating the job and maybe in the end automating receptionist so our inspection people? How do you look at this? Yeah,
that's a really good question. And definitely one that we take very seriously. What we found is actually that robots replace tasks, not jobs, and really sort of change how jobs are done. And what we've seen is, you know, we've never had a security guard laid off. Because of a customer getting robots, what we typically see is that customers can't find enough security guards that watch work. Or they'll work night shift, but as soon as they have any other job opportunity, they're switching to something else. Exactly. And so we've redeployed customers and they can take their good nightshift guards, and let them work day shift now. Or have that the guards focus on more interesting things like interacting with people, while the robot is doing the much more monotonous, sort of patrolling around go like and checking all these alarms, and checking for doors and windows being close to what's really sort of changed how people do security. And the other thing is that his customers are adding these in places where they didn't previously have guards. Because guards are quite expensive, especially, you know, if you want to guard 20 473 65, it can be very expensive, you can actually need three or four security guards to cover that amount of time. Yeah. And so what we see is that companies had guards for receptionists at their main office, but none of their satellite offices. And now because the robots are much cheaper, they can put the robot at all the satellite offices where they never had security presence before, and basically get that additional coverage.
Gotcha. That's awesome. I really like framing it in the robots replace tasks, not jobs way. And I'm hearing this pattern in the last several interviews that I've done, where it's like, it's the same thing you're saying, which is that we're having trouble finding the workers for this kind of thing. So like I'm thinking of the interview I did with Melanie wise who in factories settings like there's a tremendous shortage of workers. And so it's interesting to hear the same kind of thing here. But there's a shortage of security guards.
Yep, exactly. Yeah. And I think comes from the fact that robots and humans are good at such different things. You know, humans are amazing at making good decisions, hands like guantes interacting with people, and they're terrible at anything monotonous, or something that requires Long, long focus. And the robot has no trouble at all for, you know, eight hours, never blinking. And checking, you know, checking whether that doors open with just as much sort of sincerity and, you know, carefulness as the the 100th time they did it as the first time they did it. So it's something where, you know, you can create a much better solution using both of those. And that's, you know, it's at several levels. That's, that's why we have our human operators that are handling the interesting parts of security while the robots are doing the monotonous parts. And we've seen the same thing with our customers, is they can take the monotonous parts of their security program, and do them with robots, and re designate their security guards to be working during the day shift, much more round people responding to things.
Yeah, gotcha. I'm also I'm hearing another echo in this interview, where it's that we have humans in the loop in some way, augmenting the tasks. And yeah, I mean, you've spoken about how the humans are doing the things humans are good at, and the robots are doing things that the robots are good at. So long attention, grueling, mundane work. Can you just talk about this model within robotics? A little bit? Because I think it's a big one? And it seems like we're at a good time for this?
Yeah, absolutely. So human in the loop is definitely a really, really big wave in robotics, where I think this kind of comes back to my point that it's let us get into the market, and ship a product when in an area where the robotic technology was not good enough by itself to do the whole, to do the whole job. But because we're able to kind of augment these two things together of what the humans good at what the robots good at, we can provide the value from day one. And it lets us both focus the engineering work on the pieces that are easy for robots, and save, you know, you know, it'll be very hard to automate something like how do you respond to a person that says they're an employee, but doesn't have their badge? Like, that's a crazy hard situation to be to handle. And, you know, it will take engineers a lot of time to write something is correct. And if there is a case, there isn't a correct, you know, it depends probably for each customer, how they would want to do it. And, you know, some would say, Oh, just don't want them in some would say, call this number and verify whether they're there. And you know, that's something that having a human do that they can respond with a lot more nuance. And I think there's a couple different archetypes of human in the loop, that sort of different levels of shared autonomy. And we use a couple of these different levels, I'd say the, on one extreme, this is sort of complete autonomy. And that, you know, you can see with factory robots where a person doesn't need to be involved at all. On the other extreme, you have complete Telly off, it's a person directly controlling a robot, you know, one for one, and exactly specify what it should do. And a couple of the layers in between there is back to the sort of the autonomy side, there's autonomy with supervision. So the robot is still doing an autonomous thing, but a person is supervising it, and they can hit the stop button, or they can hit the correct button. One more step towards human is sort of human review, which is the robot is explicitly saying, Hey, I'm about to make this decision. Can you approve it? And that's great for something like, Hey, I am you know, 90% sure this, this door is open, can you approve this. And that's great for things that are, you know, something where we want to remove false positives, we don't want to integrate our customers with false positives of this door was left open, or you know, this, we saw this person. So anything like that, we always go through human review first. And it's something the robot can do by itself, but we want to make sure a human reviews then kind of one step more towards human, I would say there is
I don't actually have a great term for this maybe robot accelerated or robot assisted human decisions, okay. And what that might mean is, let's say, we don't have any software to check, maybe a new customer feature, go check whether all of our fire extinguishers are there. Maybe we don't have code for that yet to classify whether we see a fire extinguisher in the correct spot. There. robot could still go and collect all the pictures of the 10 places they're supposed to be, and then show the human them all at once. Yeah, that way the human, the human can batch their work. And we don't actually have to automate the work, we just have to automate walking between the worker where a security guard would take 45 minutes to go walk around and check all these fire extinguishers, the robot can do that 45 minutes of walking, and then our human operator can go review them in 30 seconds. So basically batching and assisting work to let a human give just a little bit of input that makes the work. Basically, it's automating 95% of a task, and letting the human do it. And then kind of the, we get back, that's sort of the the far end, and then maybe you just have complete human control on the other end. So we have things that are sort of all along the spectrum. And as we automate more things, we try to move things further to the right, to make them more automated and take less human time. And that's a lot of the interesting things that our engineering team is working on now is, hey, how can we take something that right now we're just showing a person? And how can we have the robot make a decision and just have the human review and said, Yeah, cuz that's a lot easier, for sure. And the really cool thing about this model of having these different collections of kinds of human in the loop is that our humans basically act as a buffer for engineering work, where if there's a new feature that a customer requests, start a call, where it's done fully manually. And what that does is there can be a crazy new request from a customer. And normally, you'd have to say, ah, like, do we do this, it's this big product decision, you can try it and then see if you try it, and see if they actually use it and see if other if other people actually like it. Yep. And then if everyone does start using this feature, great, like, let's automate it. But if you know, no one is using it, if it's kind of a one off, you can either leave it manual or quietly deprecated. So it lets us kind of dip our toes in the water with a lot of features, and then automate them as needed later. So we spend a lot less time implementing features that no one needs, and a lot more time implementing a feature. Once we have amazing training data for an example. Yes. Because then when we go and do what automate it, we have, you know, two months of humans doing it manually with all that data recorded. Yeah.
So for many of the things that you're inspecting, and where you get the data, and then you try to do it in an automatic way. Are you using any machine learning on this? Or what what kind of tasks are you using machine learning for?
Yep, yeah, so we use a combination of classical methods and machine learning for a lot of these different things that we're inspecting or checking. And kind of one of the ways that we refer to this is auditing the physical world for our customers. So we Yeah, exactly. You know, you want to be able to audit that everyone in your organization has, you know, two factor authentication turned on, the robot lets you audit the physical world in a very reliable and trustable way. That you know, before you couldn't really trust the Oh, your guard says, Yeah, all the doors are closed. And we've had plenty of times where someone says that and then we sent the robot two doors to your robot to his
employee. That's like really diligent. That example. Yeah, other workers really dislike said it was done.
Humans are not exactly humans aren't good at that kind of deal. Don't worry, but robots are. Yeah, um, but so basically. Sorry, what was your question? I got the
what do you do with what is machine learning? Yeah, yeah. On your platform? Like, what kinds of tasks are you learning?
So generally, I would say that machine learning should be a last approach when it's just, you know,
data. But and so I love that I associated it with it. I know you don't, you can use classical methods with the training data to just see if it kind of lines up. But
yeah, yeah, exactly. So I would say, you know, we, we usually start for something new that we're doing, trying to use classical methods and trying to like, Hey, can we write an explicit solution for this? And then if not, if it's something that's challenging, We'll train a neural network, you know, based on some of the data. But it's actually really interesting that we've gotten very far using some even classical computer vision techniques and looking for diffs. Really. So an example is because our robot has very good localization, we can go take a picture of the same thing from exactly the same spot each time. And we can just look at a diff and say, Hey, this looks different than last time bow. And then suddenly, you have a way to inspect, you know, anything new, even if it's a, you know, whatever the arbitrary scene is, yeah, wherever the arbitrary scene is, we have now a way to flag this up to an operator of Hey, I don't know whether there's a fire extinguisher here. But it looks different than the last time I saw. Yeah. Yeah, that actually was no
semantic understanding. But you're still like, I ran a diff on the old image and the new image, I looked at the difference. And I saw that there was this many pixels different, or some measure of entropy or whatever it might be. And yeah,
and we found some very interesting pre processing techniques to do the diff in a non pixel space. Oh, that lets us signal much more area, much more invariant to lighting conditions, and things like that.
Hmm, that's awesome. can speak on that a little bit? Or is, yeah,
one, one example is that you can do things like edge, detect the image, and then do gifts at the edge detected images. And that that lets you see that something's sort of with heart outlines has moved in the scene. But an overall lighting change is very, not very picked out. Yeah. doesn't doesn't trigger that. And so we have sort of things like that, that we can do to very easily notice changes. It's
cool to use these like incredibly simple operations. So if you want to get an edge detection, you just multiply plus like a plus one and a minus one over the convolve it over the whole image, and then you get your edges from the resulting image. It's and it's so crazy that you can use that and that will be useful and fairly invariant, which is very nice to different lighting conditions. And
yeah, yeah, we're we're really big fans of keeping things very simple in the design. And if something feels sort of overly complicated, it's probably going to be fragile. When it actually gets working in the real. This, we see lots of things, you know, from research, like oh, like, did they need to do that? Like, was that something in a research paper just to make it more publishable?
Totally, how phony now so we're running out of time, I'd like to talk a little bit. So your experience in startups in this startup, and I you said you previously were starting companies or have started companies. And talk to me just a little bit about this time, like right now for being a robotics startup, and maybe just the landscape as you see it?
Yeah, yeah. So it's a really interesting time for robotics companies. And maybe I'll actually kind of backup Sure, maybe kind of my history of how I got here is, I started my first company called pulse metrics. In college with a friend, we dropped out of Harvard for a year went through Y Combinator. And that company eventually got acquired while I went back to school to finish my degree. Oh, congrats. That's awesome. Thank you. That's actually where I met my current co founder, Travis style. He also had a startup at the time that he was working on, we became pretty good friends chatting about robotics, even though neither of us at the time were doing robotics. And we just kind of stayed in touch. We're always bouncing startup ideas off of each other. And I think the really cool thing is of being a second time founder, was it just felt like we knew what we should be doing. You know, looking back to the first startup, it's crazy that we got anywhere, because we didn't know what we were doing. It's like, oh, maybe we should try marketing today. Maybe we should try to build features. Yeah, we didn't know what the goalposts were. And I think that's the really great time without her The really great thing about doing something the second time is, we know, what are the goals that we need to hit. And I think that a lot of the ways that I think about startups is progressive de risking, and look at what are the experiments you can be running each week that reduced the risk of your business as much as possible. And think about what is that next milestone we need to hit? And what are the kind of waterfall things that we need to do to get there. And a lot of times for early stage startups, that's different funding rounds, and sort of think, Okay, well, they get this, I need to probably have this much revenue. That means I need to get this many customers, that means I need to get this many features as an adult. And so you can kind of work backwards to what you need. And that helps decide what you actually need to be focused on. As a founder of what games your engineering team to be focused on, to decide, you know, really what's, what's going to be a feature that works and is important, and, you know, helps the company versus something that's just nice to have.
So how do you so is this? Can you speak a bit more about picking a problem?
Yeah, sure. So when when Travis and I started looking at ideas, we had a couple of constraints. We wanted to find something that we could see ourselves loving and doing for 10 years. And you know, cobalt is an amazing fit for that pelea. You know, secure security just feels like this amazing first use for robots. And it's really good opportunity to get robots out into the physical world and get around people, not just in factories where no one's going to see them, but in office buildings where they're going to be around people all day. And it was something that could be too could be done with today's technology, sort of really like the other sort of constraint that we had her. We wanted to find something that we could immediately get it to market with, you know, no research and development. That was another really good thing about cobalt is we could go and we could use human in the loop to fill in the deficiencies. And we didn't want to do something that would take, you know, a lot of r&d or had very high technical risk. Yep, we wanted to find something that we could use today's technology, and that will just get better over time. And in our last constraint, believe it or not, was no hardware totally failed on and we were actually looking at a lot of non robotics ideas at the time, but this one, actually we, we kind of found that it was such, we found such a strong demand from this first customer we talked to, and then he put us in touch with all of his other friends in the security industry. And we just got such a positive response, like, wow, yeah, you know, it's gonna be a lot harder to do a hardware startup, but like, we do have the background for it. And you know, we do have, you know, it seems like it's a really good, good problem and space to tackle. But we were basically looking for, for customers, and where they said they had a problem, and they would pay money to solve it. And that they would give us a handshake deal that, once this is ready, I will pay for it at this price. And we got a couple people to get to that point do that those handshake deals. And that was enough for us to go raise our first funding round of, Hey, this is our idea. Don't believe us go talk to these customers that have done these handshake deals with us, and said, Let them tell you how excited they are for this product, and how they would use it.
Okay, so a few things here. Very interesting to me the first, can you just tell me a bit about a bit more in detail about how you did your initial market research, when you were talking to people and seeing what they would pay for in this kind of thing? Like, how does someone do that kind of thing? How do you just, I don't know, like, how do you go about meeting these people? And what kind of questions and like, what's the heuristic when doing that kind of thing? Yeah.
So what we were looking for was talking to anyone that we didn't know what their job actually entailed. And it's funny, but it's, it's not that hard to do, you just kind of have to go and start doing it. And whether that's talking to strangers at Starbucks, which actually isn't that effective. But really, what we found most effective was going through our network, and really going in like asking, I asked every single one of my friends, what are your parents do? What are your aunts and uncles do? And you know what, to people that I knew, like, just asking them what their friends did and like,
I made this like kind of List of everyone I knew and went through them. And like, tell me about like everyone that you're, like, close enough to that you could ask for a favor and like, tell me like, what is your uncle do? What is your aunt do? And we kind of wrote out like, Oh, actually, I don't know what being a pharmacist is like, like, yeah, go talk to that person. I don't know what the security director is like, let's go talk to that person. I don't know what being a lawyer is like, let's go talk to that person. And then once we were talking to those, those people, you know, in our, in the back of our minds, we had a couple broad theses that we cared about, and that things that we were looking for, they were mainly around enterprise, and finding ways that we could use software or AI to make some process better or more efficient, or cheaper. And so that was kind of a lens that we were looking at these interviews through, but a lot of it was trying to be very open ended, like, tell me what you actually do day to day. But if there's one problem that you could solve, or like pay money to solve at work, what would it be, and trying to really focus on the problem, because a lot of times people will come up with an idea that they want you to do what it's kind of like people asking for the faster horse. But you have to kind of keep going back and really understanding what is the pain point that they have? Like, what would it actually mean solving. And a lot of times from someone saying an idea that they have, you can kind of work back to what is that actual pain?
What is the pain point? Yeah,
come up with an even better idea.
Gotcha. What an interesting thing. Okay. And then the other thing that I'm really curious, so you can you talk a little bit about kind of the way that you have been funded at cobalt?
Yeah, absolutely. So we have great financial backers. Bloomberg beta, did our seed round in 2016. So they're really good fund focus on the future of work kind of designing, you know, their, their main LP is Michael Bloomberg. So they really care about helping invent what his work is going to be like in the future. Then for our series, a we raised from Alfred Lind at Sequoia, he was sort of, Oh, yeah. Yeah. So Sequoia has a really, really amazing duster. And Alfred Lin was actually the top of our list of who we wanted to, to go with for our series. Wow. You know, he is a he's a really, really incredible individual. He was the CEO of Zappos, and actually was helped bring Kiva robotics into Amazon after Zappos got acquired by Amazon, and so he's very familiar with robotics. He was most importantly to us. He is an operator. He's been in startups and feels the pain And you know, knows what it's like, you know, with the time pressure and like everything on fire. And we really wanted people like that people that had been through this themselves and could sort of know what Travis and I were going through, rather than someone that was kind of just a financial analysts that had never been in it themselves and was making a bet on us. And then we raised a Series B from cotu. Later, and we raised about, we've raised around 16 million total, from our series A's and B's. cotu was another great investor, our partner there is Chris Fredrickson. He was very early in luxury, and actually did a lot of really hard work around deliveries and logistics. And that's something that's very hard for us as we're moving hardware around around the country. And actually, across different continents. We actually have customers in Australia and Japan. Oh, wow. The UK. So Oh, yeah. You know, logistics are very hard for moving five foot tall robot around on. So yeah. So we've been very, very happy with our investors at some of the best companies in Silicon Valley.
Yeah. That's, yeah, I mean, you guys are very promising. So it's wonderful to see Great Investors supporting you, as well. Can you can you? So for someone who wants advice on how to approach investors? Or how to look for the I just any advice on getting funding? I suppose that you have?
Yeah, yeah. I would say to put your mind, put yourself in the mind of the investor. And what they're looking for is, how is this going to fail? And they're looking for the startup idea, that's, they're looking for a startup where they look at it, like, Oh, I don't see any possible way this could fail. And so sort of think, put yourself in that mindset and think, why would an investor say no to me, and then start working on fixing those things. And that might be they, they think, oh, I don't think this technology is possible, then go build a prototype, they might say, I don't think, you know, people are going to actually want this go get customers, or, you know, I don't think people are going to pay for this show that people will pay a high price for it. It's a really, you know, think about what the objections are going to be. And then your work as an early stage founder is, is doing things and collecting evidence to show that this is working. Yeah, and a lot of that evidence looks like building an early stage business of getting customers building a prototype. But really sort of it, you know, in the first year of a business are yours to the revenue isn't actually important, it's it's just an indicator that you will get more revenue in the future. And so you need to be thinking about it in terms of what is an investor need to see, to show that this is a great idea, and that people are going to want this and that we're the correct team to build it.
Yeah. So one thing that I have seen many times is people or companies accepting funding, and the funding comes with terms and things that eventually suffocate the company. Can you talk a little bit about avoiding things like this, or just how do you make sure you don't accept bad investment or whatever it might be? Yeah.
So it's, that's definitely sort of a negotiation game. And you just need to make sure that you're in a strong enough point where, even if someone is offering more money, if there are those bad terms in there, you should probably take someone else's money. And being just knowledgeable about it, really reading through the docs and understanding sort of what's you know, what's happening, and cut, some of the things to worry about are sort of guaranteed returns, or sort of any sort of overhangs where someone can get sort of more than they otherwise would, if your valuation is lower. But one of the best things there is to get, you know, a really, really good investor on your cap table to start. And then, you know, with us having Sequoia and Bloomberg and cotu, no investor is going to try that. Yeah, they don't want Sequoia to get mad at them. And so having really, really good partners, helps you negotiate because you know, that new investor you're talking to, you know, your existing investors are on your side, and that, that when you're talking to so getting really good partners, and really well known people where they care about that reputation, a no name investor might give you money, but if they don't have a reputation to lose, if something comes up, they might try to squeeze you for any penny of your work. Whereas a really well known and sort of prominent investor like Sequoia, they care more about their reputation with other founders and sort of showing that they're gonna do right by people. They care more about that than making a few extra dollars got any deal.
Alright, so wrapping up. What advice do you have for say, like a 20 year old version of yourself? I guess in now or in back then. Let's just how would you do the same thing I Then a little better, or what would you wish you better know? Yeah, advice for young,
I would say the most important thing is just always keep talking to customers and sort of always stay skeptical. You know, make sure you're always going to figure out what the pain point is and, and never sort of stop and think that you've, you've solved something. Because definitely for us, you know, from that first robot, to sort of where we are now, so many things have changed not just about the robot, but how we're delivering the value to the customer. And those iterations have led us really grow and scale and provide way better value. So I'd say just really stay focused on the customer. The technology and the product is just a means to an end. It's not an end in itself, you need to stay focused on the customer and their pain points. Awesome.
So wrapping up, do you have any links or social media or anything you'd like to share with our listeners?
Yeah, absolutely. I can put in a couple links to some YouTube videos of our robot using elevators, with its elevator arm. some links to sort of our hiring page, and we are looking for robotics engineers and web engineers. Pretty much everything right now we have a really strong or a lot of really strong customer growth. And we're trying to keep up the engineering team with it to help deliver that value.
Yeah, awesome. So I'll put links in the video description and podcast description. That sounds good. Thank you. It's been a pleasure.
Thank you so much, everyone.
That's all we have for you today. I hope you enjoyed the episode. I was surprised during the interview that the cobalt robot is going to be trying receptionist work during the day. What other applications could you think of a robot like Cobalts robot? Let me know in the comments on sensing act calm. Thank you again to our founding sponsor open robotics. Goodbye, everyone.