Full-stack Robotics and Growing an App Marketplace

15. Full-stack Robotics and Growing an App Marketplace, with Christian Fritz

2022-03-08 · 1:43:42

computer vision

dashboard

In this episode, Audrow Nash speaks to Christian Fritz, CEO and founder of Transitive Robotics. Transitive Robotics makes software for building full stack robotics applications. In this conversation, they talk about how Transitive Robotic's software works, their business model, sandboxing for security, creating a marketplace for robotics applications, and web tools, in general.

Comments

Outline

0:00:00 - Episode introduction
0:01:09 - Introducing Christian and Transitive Robotics
0:06:52 - Fleet management + networking challenges
0:17:15 - Problems in fleet management
0:21:23 - Business model
0:26:21 - Using MQQT for message passing
0:30:28 - Developing your own capabilities
0:35:35 - Testing capabilities
0:36:44 - Sending data: authentication and authorization
0:43:32 - Sandboxing for safety
0:56:10 - Discussing web technologies
1:01:03 - Open source business models
1:05:38 - Scaling, finding market fit, and taking investment
1:15:57 - Plans in starting a marketplace
1:20:01 - Plans to grow the team + remote work
1:29:36 - Web and robotics
1:33:08 - Web technologies on the backend
1:34:59 - Future of robotics

Transcript

The transcript is for informational purposes and is not guaranteed to be correct.

(0:00:03) Audrow Nash

This is a conversation with Christian Fritz, who is the CEO and founder of Transitive Robotics. Transitive Robotics makes software for building full stack robotics applications, meaning that it aims to make connecting your robot to a user interface easier. Some reasons you might want to do this are to remotely monitor the health of robot fleets. See what a robots camera sees, or to tele operate a robot? Transitive Robotics does this while solving the hard networking problem of robots potentially coming into and out of connectivity. I enjoyed talking to Christian. His perspective in forming Transitive Robotics seems to have been very pragmatic. And in my opinion, Transitive Robotics is building a tool that is very needed by the robotics community. It was also interesting to hear his thoughts on growing a robotics app marketplace, which may be in Transitive's future. This is the Sense Think Act Podcast. I'm Audrow Nash. Thank you to our founding sponsor, Open Robotics. And now here's my conversation with Christian. Christian, would you introduce yourself?

(0:01:13) Christian Fritz

Hi. I'm Christian Fritz. I'm the founder of Transitive Robotics. People may know a little bit from my career, where I'm coming from, I used to be the head of software at Savioke. And for those who don't know, Savio, said hope makes a really cute delivery robot for hotels and hospitals. And it was, it was a really fun ride. For me. Being there, I started when there were about five robots in the field. When I left there were over 100. And it was a really an eye opening experience. For me, my background is in robotics, I've done Robocop back in 2001, I've seen all sorts of versions of robotics, including before ROS, which was bearish. And then at Savioke, I learned about not just the robotics piece, but the full stack that went on top of that. So that's really kind of my background, I was leading the application development team there, which basically, I always described it to new candidates or employees as as follows. The application development team gets a robot that knows how to stay localized and not bump into anything, and turns it into value to the company. So what that meant was all of the HDRI was done by our team, anything that involves just a sense of ambition, right, like running a delivery, the notion of delivery, writing elevators, calling phones, notifying users, all of that was done by a team. And it was, it was a really interesting experience. Because I found out that while ROS is really great, there's, there's so much more that you need in order to deploy a successful robotics fleet in the real world. And so that's, that's how I came to start trying to

(0:02:58) Audrow Nash

know, what exactly are you doing at Transitive? Like, how are you solving this deployment problem and the problems that you kind of saw from your work, it's.

(0:03:09) Christian Fritz

So it's heavy, we spend a lot of time building, you know, those those full stack applications, data synchronization between robots and the cloud at the front end, visualizing elements of the robot, such as maps at laser scans, and sending data back and forth and doing all of that DevOps. And it was really interesting for me to find out that other people at other companies like fetch robotics and places that we spoke with, were basically building the exact same thing, right. So we, we felt that, that that's not a good idea. And granted, there are some solutions out there that help try to offer you the kind of a one stop shop for fleet management and DevOps. And some of them are actually done by friends of ours. And they approached us and said, We have to, to see whether we would want to use them. But the problem that we had with them was that they all are sinking, like standalone platforms. So really, they give you the choice of do I build my own fleet management? Or do I outsource that. And the issue that we had with that was that when you outsource that your hands are tied, if the thing is not perfect, you cannot extend? And if there's something that you need, you still have to build it separately. And then you have, well, first of all, some type of work. But also you're duplicating your data, landscape, right? Some data will live in the one side or the other in

(0:04:32) Audrow Nash

your domain in so software you're using for fleet management, and then whatever features you build custom yourself kind of outside of that. For your own. Yeah,

(0:04:42) Christian Fritz

that's exactly right. Yeah, exactly. Right. So you will have separate users on different accounts. You'll have different roles. You'll have complex some data about the robot. Yeah. And so what struck us was that what people really want is the ability to just take individual complaints and plug them into your existing web application. A good example of that is low latency video streaming, almost everybody wants to see what's the ability to see what the robot is currently seeing. And it's a complicated application or capability to implement. Because there's some really great technology like the one that we're using here right now, which is why Partisi, which is running in the background, it's very complex. And a lot of robotics companies don't want to get in the weeds don't want to become experts, they don't want to get into the weeds. So I tried to give were basically developing these things as individual components. That's the one thing that's different about us from from the existing offerings out there. And the other one is that we believe in open source. So we actually following an open core model, with a platform that we're developing will be open source, and anybody can use it, and we hope people will, and they will build cool things on top of that. And this is really kind of a philosophical thing for us. We think that ROS has done such a good job at uniting the robotics community by giving us a common platform that we can build packages on. And so we can share, right? So if you if you build a really awesome navigation functionality, and thinking of your last you can you can share that with the world and the world will be a better flex, right. And I think ROS has done such a tremendous job at establishing that framework or platform on based on which we can share it. And we would really love to do the same now for the for the full stack. If it's open if it's open source, and it's easy to implement new capabilities that we really think that people will start contributing back. And we can finally stop all reinventing the wheel and building the same.

(0:06:47) Audrow Nash

Yeah, for everyone who has a fleet of robots that needs to manage them in some way. So now one thing I'd like to do just kind of going more into detail, what does it mean to do fleet management? And what are some of the challenges with fleet management?

(0:07:04) Christian Fritz

Well, so I'd start perhaps a little bit lower and start with why why sleep management or anything to do with robotics is not just another react app, or something else where you can use common tools out there. And they don't just solve the problem. The big one is really that these robots as much as they seem to behave like servers are not really servers because they run around, they lose network connectivity, they gather data faster than anybody can process them. And so you have some unique requirements in creating a uniform picture of your fleet in the front end. And this is not very unlike what some of the cloud providers offer with their IoT

(0:07:51) Audrow Nash

when we say that you mean like a web browser or some other web browser?

(0:07:57) Christian Fritz

Yeah, it's um, yeah, I guess I should, I should say that I'm asking I'm a no, it's a it's a good point. Because in robotics, and especially in bras, a lot of Qt applications are still being fronted. We think that if you're dealing with a broad set of users who are distributed, have different backgrounds and so forth, using web technologies, really the way to come. Because everybody knows how to use them. Obviously, most of the software being developed these days, runs in some on some form of web technology. And it's just a very lively and flourishing ecosystem. So using web tools, I think it's the best approach for building these front ends. And so at that point, you have to create a link between your your robot gathering data and user sitting in front of a browser.

(0:08:52) Audrow Nash

Okay, so for fleet management, webs, web related tools are really good. Because they let you it's like it's better. There's really good tooling around there. There's a good ecosystem, this kind of thing, and I guess, getting into kind of the fleet. So and then actually, you were saying that a server, like you can't just treat it like a normal sir, a robot like a normal server. And so because of that, you have Transitive robotics, you're trying to make it so that you can, in a sense, treat a robot like a server while addressing some of those challenges.

(0:09:35) Christian Fritz

Yeah, that's exactly right. I think it kind of comes down to the core abilities that the platform gives you as a developer. And one of them. I think that's perhaps the most important one is the data model that it gives you. And what we're doing there is actually not very different from what some of the cloud providers offer in the IoT solutions at all on AWS, they call them IoT shadows. In a jury, they call them desired and reported state of a robot, the idea is always the same that you have some form of data model that tells the robot this is what I want you to be like, whatever that is configuration deployment. So as a robot to get into, basically. So it's, it's saying I want to think of it as you think of it as a state. Yeah. At the state can have all sorts of aspects to it, right? Like which software to run, what users to have, what configuration values to use, which cloud to connect to, and, and then the problem is your robot. Sometimes it's not just not online, right. So you have to make sure that you reliably synchronize that data to the robot, and also get the get the data back. On the coming back side, you have that same issue that you may want to monitor your robot while it is traversing through some areas where it has very poor connectivity. But you don't want the front end experience to be chopped up, right? You want the user to have a smooth experience and still see the robot, even if right now you can't get signal from it. And that's, that's why it is not a server, you can't just run a web server on it and have to reuse it connect to it directly.

(0:11:18) Audrow Nash

Is that is that kind of the biggest challenge in this? Would you say where it's, the robot comes in and out of connectivity? And it makes it so that you can't make a lot of the assumptions that people would make about, like web servers? In general?

(0:11:33) Christian Fritz

I think that's a good way of putting it. Yeah. So

(0:11:35) Audrow Nash

what do you what do you do in the case? How do you how do you make a smooth experience when a robot is popping in and out of connectivity?

(0:11:45) Christian Fritz

I think really, the key here is an intelligent data synchronization where the robot essentially updates the cloud, whenever it has connectivity. And then the cloud serves the serve the users front end, right, so the user always sees data, sometimes data will be a little bit delayed, because the robot hasn't gotten an update through to the cloud. But the cloud will be able to tell, hey, I haven't gotten a heartbeat from this robot in 10 seconds. So what you're seeing maybe maybe a little bit old, but from the user's perspective, pages, load fine. Everything will be there. And you will always see the latest data that you could possibly get independent of when you show data, some people think you could just run a web server on the robot itself, and then connect and then the problem is sometimes you try to build a patient that just doesn't know because your servers down or not connect you.

(0:12:41) Audrow Nash

You mean literally host the website from the robot.

(0:12:45) Christian Fritz

That's, that's a lead. So let's take an alternative. Some people are this into the robot harvest or like a non ROS users is a visualization tool for ROS. And it's it's an awesome tool. But it's, it's not really meant to be used remotely for for several reasons. One, it sends a humongous amount of data because it actually thinks that the connection is very good and fast and sending duplicate data is not a problem. And it also just sends a ton of data. So there's not a lot of filtering typically going on. Which means that remote experience with harvest can be very choppy, and the robot goes in and out of connectivity sometimes. So if you lose that you won't have a lot of disruptions, you're losing interest. So I think some kind of caching of the data in the cloud. That's one, reducing the amount of data that you send from the robot to the cloud is another Oh,

(0:13:37) Audrow Nash

yeah, that's an important point, reducing it so that you don't actually spend that many resources on kind of, I don't know, perhaps you can get by with less. And then you have less requirements of your connectivity to your network.

(0:13:51) Christian Fritz

Yep, that's exactly right. A good example, here is health monitoring. A lot of your your listeners may be familiar with how ROS solves the diagnostics problem where there is a nice hierarchy of message definitions that allow us to share diagnostic information about your robot such as set of values, battery stage, and so forth. But the way that ROS publishes status, here's an update, here's an update, here's an update, even if nothing changes, right. And that's fine with ROS, that's not ROS is designed on the robot. And that's, that's good. It's actually a good approach on the robot, but not for the cloud, because you don't want to repeat messages if they're literally the same as the previous one. So even just duplicating sequences of messages will already save you a ton of data.

(0:14:41) Audrow Nash

Yes. So how I'm understanding what it sounds like you're describing. So if you want some sort of way of monitoring your robot, your robot has information it's driving around, it may move in and out of networks. What you're doing is you're placing a cloud component so some computer somewhere else that's talking to the robot. This is basically it's keeping up the whole time. And it's displaying whatever the most relevant data is on there. And then I suppose, well, actually, and then you have the user who looks at whatever the cloud is doing. So the cloud has its own host, its own website is hosting. And the user can look at that and get to see the state of the robot. And then I assume on the robot, you have something that's saying, this is necessary information to send up to the cloud. So if it if it's overheated message that's being sent, you don't bother sending it again, because of limited bandwidth effectively, to try to send data to the cloud. Like we only want to prioritize and send the most important updates, probably, to the cloud. Yeah,

(0:15:48) Christian Fritz

that's exactly right. That's exactly right. The way that these decisions are made is that we believe in vertically integrated capabilities. So I've described so far is this very fundamental data synchronization layer, but then what you build on top of that, we think in terms of apps, right, so let's take a remote Tailor of capability. A lot of people need that on the robot. So that involves sending video from the robot to the to the front end, displaying the video on the front end, and sending back some control signals from the from the joystick. The Transitive is structured is that we have this concept, very strong concept of packages, similar to ROS. But what's special about Transitive is that inside a package, you don't just have components that run on the robot, or the code or the front end, you have all of them together. And what's great about that, is that you can you have an end to end exchange. And if you want to change the way that things are visualized on the front end, if you need, say, some new data that you didn't have in the previous version, it's fine, because you're going to publish another version of the code that runs on the robot and push us to the cloud as well. So this gives you some really nice. We think of this as cross device dependency management. Yeah, you don't have to worry about oh, well, we just upgraded our front end. So we now also need to upgrade our backend. It's all it's all taken care of.

(0:17:13) Audrow Nash

Yeah. Yeah. Interesting. Okay. So going back. So some of the challenges with fleet management, we have, basically the connectivity issue where it's going in and out of the network, we have, perhaps, the, the so you have the robot, it's sending data back and forth. The robot may or may not be connected, you have health monitoring, and things like this checking the status of the system, and you have updating it, which you've kind of just mentioned, you can ship things as components, and it's updated universally. Are those kind of the other additional challenges to fleet management, and network updates. And the second, but yes, those are there additional ones that are kind of critical and fleet management, health monitoring.

(0:18:08) Christian Fritz

Actually, if you don't mind, I'm going to share a kind of famous Greenbrier course. So this is a list that we've put together off things that we needed at one point or the other, in the past. And it's grouped by categories of kind of apps or capabilities that you might need to run a fleet successfully. So there's the category of DevOps and fleet management software, super modular uploads a video is Iraq, prospect view and health monitoring, and it goes observability is a big one. alerting, right. A lot of people like to integrate with pager duty and so forth. But then there's also things like application logic, right Task Entry to a queuing of tasks, user management, account management, and a lot of those things are really not that much fun. Yeah, so that and they're not really they're not differentiating to a robotics company, right? So we were we validated this with a lot of CEOs and CTOs of robotic startups. And they always said the same thing. There are certain things that we would like to focus on. Often, in the ml or computer vision space, we were talking with an apple picking robotics company, you can probably guess what that was. And they said, well, our our secret sauce is in our ability to identify grasping points from the computer vision, we would never want to outsource that. And that's where we want to differentiate ourselves. But there are so many things on your list like CI CD, like anomaly detection, that's not that's not important to us. We would love to outsource that. And that's how we think about Transitive a, a both a platform to develop those kinds of capabilities and then also a company that will that will offer them

(0:19:57) Audrow Nash

yes to you So where are you guys currently in this because the list of things, there must be like 40 items or some large number of things that all seem really important to shipping a robot application. Do you have all these implemented? Or is it like a set of them? Or we're yet?

(0:20:16) Christian Fritz

Yeah, no, not at all. This is the aspirational slide so to say. And it's also meant to, perhaps give people ideas of what they could develop and contribute. This is really the motivation to do all of that. And the way we're going about it is we want to develop the platform First, open sources, and then start building the ecosystem to develop all of them. Right now, if you go to our website, there's three capabilities that you can try out right away. And they are some of the ones that I've talked about. So far. The low latency video streaming, remote telehealth and, and health monitoring. Everything else?

(0:20:55) Audrow Nash

So TBD? Yeah. So it's, so you have this list, you kind of gathered this list, and I assume maybe it was somewhat iterative in the process. But I assume this really informed the data model that you're using, and the development of the system so that you could fit all these cases under your framework.

(0:21:18) Christian Fritz

So that's exactly how we're thinking about it. And

(0:21:22) Audrow Nash

that's really cool. So the, I'm kind of imagining this is, like, I'm mapping it to like web concepts, it's eventually going to be like the hosting service. For robotics applications, probably you have your specific logic running on your robot. If you're using the ROS ecosystem, you get a lot of things for free, that might be good enough for your applications, like navigation or move it for motion planning of arms, these kinds of things, and then you have this to make it so you can quickly build your web interface to monitor your application for the people that should make sure the robots are running or I don't know, whatever it is that's engaging and engaging with your robots, or whoever it is, yes, whatever they're doing.

(0:22:12) Christian Fritz

We're thinking about this in two different ways. One is to get people started more quickly. So they don't need to build these things. And then sometimes our investors ask, well, aren't you going to lose those people, once they grow to a certain scale? And they will, they will not care? Because they are now they now have 200 employees, and they will build it themselves? And my answer to that is they still not want to. And the reason is, like my counter example is slack. Yeah. Why do people use Slack? It's not impossible to do. In fact, it's pretty trivial. However, are you really going to bake it quite as well as slack? And that's all I do. Where, exactly, it's, it's the value of specialization, right. And in the end, you will use the best solution out there, startups in especially in robotics are actually not as price sensitive as you may think. And that's because the bulk cost of robots all of the operations is not that cheap. So if they have to shell out $20 a month for a capability, there's really well, who cares, they're spending more on the LTD Bill per robot. Right. So I actually think it this is something that I've felt with ROS, too, is that I think ROS would actually benefit from more entities having commercial a business plan behind them and commercial backing, so that the contributions that are being paid by those companies to ROS have have a longer a longer outlook, right? There's, there's some real money behind it, we can be certain that they will be maintained. And there's somebody on the hook for making sure that they that they do that they work well. Yeah, there was this really, I think I wrestled last year somebody presented this paper, I think it was called something like it takes a village, I forget the details, you remember that? I don't think I thought it was really interesting, because they did a study of ROS packages, and how many which are used, like how many how many people use them, and how well maintained they are. And it was really striking that there are some like the core modules that are they're all being used by almost everybody. But then the vast majority of packages, and of course, there's a ton of packages, they are not maintained very well. So that puts users in a difficult spot. And in deciding of can I really rely on this package? Or do I have to fork it if I want to if I want to use it. And I think that the JavaScript community does a very good job at that with their with the NPM package manager where with every package that you can find on their site, they will show you how about how well does it maintained me to how many commits Have there been made lately? How popular is it? How many people use it? And I think some other metric and I think I think that's very helpful quality, some sort of They bought the holiday

(0:25:00) Audrow Nash

trick. I don't, I don't know how to get that, but it's quite cool.

(0:25:04) Christian Fritz

I think it's very helpful. And when I choose libraries to use, that's definitely something that I look at. And Oh, for sure, knowing that there's others who use it is sometimes perhaps the most important factor. Because I know that if I run into issues, I will not be alone, there will be others who will be who are also invested

(0:25:22) Audrow Nash

in it. And you can feel a little more secure in that other people might pick up some of the slack, you can pick up some of the slack, but it's not entirely on you to maintain if the developer just goes silent, and maintaining it. Yep. Gotcha.

(0:25:39) Christian Fritz

And I think if we can stand something like that up here, we're obviously taking the perspective of the full stack. But I think some of those ideas translate into into other ROS packages as well. And one thing that we haven't touched on yet is you could have a rust package be part of one of these apps, right? You can, the way that we actually designed our deployment mechanism. These packages can contain whatever you want. Some people cringe when they hear whatever you want, because that sounds dangerous. And we can talk about that in a second. Yeah. Yeah, so we we've designed this from the bottom up as a framework that

(0:26:19) Audrow Nash

what are the components? So in any one of these packages? Or in any of these components? It has the robot arm? Or what are the parts of it that are involved? And how do they talk? And then sandboxing sounds very interesting to talk about, too.

(0:26:33) Christian Fritz

Okay, so let's, let's dive a little deeper up. Before we before we get into that, I think I should mention that we're using TGT as the underlying communication mechanism for just about everything. I think that will help our conversation here.

(0:26:48) Audrow Nash

I don't know much about that. I don't know anything about that.

(0:26:50) Christian Fritz

Okay, so MQ TT is a Pub Sub mechanism, where you have topics that are hierarchical, separated by slashes, just like a path in Unix,

(0:27:00) Audrow Nash

very similar to ROS topics, it seems like from the description so far, in a sense that it's good topics, and then it's hierarchical, like namespacing, and this kind of thing.

(0:27:12) Christian Fritz

That's right, I think the main difference rough topics is that they don't have this notion of a message definition. Any message in the end is just a buffer, or a string, like a character buffer. And then on the receiving end, where you will interpret

(0:27:26) Audrow Nash

offers nicely. So yeah.

(0:27:30) Christian Fritz

And other than that, I mean, it's a very well developed technology, it's actually underneath all of the IoT, cloud offerings like AWS, GCP, and Azure, all built on MQ TT. So it's sort of battle tested. And it's meant for IoT devices. So for low resource usage, very high throughput, communication. And unlike ROS, it was really meant to be cross device, like the typical IoT application, you have a large fleet of small devices that all send data to the cloud, and from there potentially onwards. So this seems like a very good technology to build this on. And then our packages, they are exactly like you suggested, they actually have three components, there's the code that will get installed on the robot, there's the code that will run in the cloud in a Docker container. And then the third piece is, are any sort of front end components. And there we are using this new technology called Web Components, it's not a very good name, because it's not very unique. But web components is a thing. And it's very nice, because it's front end framework agnostic, you can use it in React or Angular, or even without any of that. So it really just is like a custom tag in HTML. So you have lots you've loaded that component to that component, you can just type, you know, pointy brackets, the name of your component, and it will appear with where you want it to be. That's what we use for the front end. And then underneath, they all communicate through through MQ TT, in a in a namespace that is not just specific to the capability, but actually even to the version of the capability. And this is what allows us to create this cross device dependency management. This is this was a very big pain point that that I've faced at one point in my career where if you update the cloud, you may be forced to also update all of your robots, depending on what you've changed on the cloud. Now, guess what? Your robots if you have more than 100 robots, at no point in time, a lot of your robots be online at the same time. So when do you make the switch? Right? And so there's different ways to deal with it. Some people

(0:29:46) Audrow Nash

get both, and you just have them send their version messages. That's how we are solving it except super cool. And then you kind of delete it once they're all on board with the most recent version.

(0:29:58) Christian Fritz

Nobody has been talking to me be on that version for a month. So just got to shut off that Docker container.

(0:30:05) Audrow Nash

That's super cool. Okay, so you use MQ TT, this gives you that really nice version messaging behavior that makes updates really cool. And I really like the idea of kind of it trickles in as the robots become available. Okay.

(0:30:26) Christian Fritz

So that that tells you how the three components in the, say the three again, just explicitly, the robot, yep, the cloud and the UI. Okay.

(0:30:38) Audrow Nash

And so for these components, one thing, so are they all? You get them to talk? Like, so if I'm writing one of these components? How does it look? Like how can I test all of these? What do you call with the components within the component? Or how do you refer to the the web robots and cloud parts of component?

(0:31:03) Christian Fritz

We haven't, we should get that terminology. We don't have a good name for them yet.

(0:31:09) Audrow Nash

Gotcha. That component makes me think React components, which is kind of it's a, and then that makes me think just the web part of what your thing is. But

(0:31:21) Christian Fritz

we could call them modules. And well, actually, on right now we're referring to this whole thing as a capability capability. Okay. And then the three underneath are packages or modules. But okay.

(0:31:35) Audrow Nash

Gotcha. Okay. I like the word capability better for discussing it just so it's not as overloaded in my head. So how do you write a module? And how do you write a capability and test all these modules? How do they work from a developer's point of view?

(0:31:52) Christian Fritz

Some of this is still being developed right now, we have not yet made the open source release. And one thing that we want to get done well, is the SDK, which is kind of what you're asking about, right? So there will be tools that will allow you to create new capabilities, quickly in the sense that they will, I'm taking a lot of inspiration from again, how things like reactive office where you have like a CLI tool, that's where you might say, Transitive, create new capability, whenever it will, it will set up the directory structure and you know, the package json and the web, web pack, whatever you need, in order to compile all of those. Yeah, we do use I guess, I might have to say that we do use NPM exhaustedly, and for those of you who don't know, NPM is the node package manager. It's a very nice tool. A lot of people think like, it's only for node. But it turns out, you can put anything you want it to that package, it has a lot of advantages over say Debian packages. That was probably too much detail to go into, but I'll be

(0:33:04) Audrow Nash

talking about it just a bit later in the interview. Yeah, good.

(0:33:10) Christian Fritz

So once you have these NPM packages, there's, you know, scripts that you can have for NPM publish to publish those capab those those packages have your capability into a into a private registry or an Artifactory store. And from there, your robots will be able to pull them and and run them the connections that you were asking about for communication, where they will be set up through the further data synchronization. So from the from the developer's point of view, all you're manipulating is actually one big JSON object. And within that JSON object, you can decide which sub paths you want to subscribe to which ones you want to publish. But you will always be dealing with a JSON object as if it was just on your machine, you know,

(0:33:58) Audrow Nash

the thing that's being passed between the modules in the capability correct. So you're sending that JSON object around and that JSON object. So that's just a data structure for viewing everything. JavaScript Object Notation, or whatever it stands for.

(0:34:13) Christian Fritz

That's what it stands for. And data data data synchronization that I mentioned previously, basically just takes care of making sure that what the robot sees from that tracing is exactly the same as what what the capability in the front end sees, and you don't have to worry about it, you just manipulate it on the robot. And you will can see it like that on the on the front end. For those of your listeners who know how, you know, reactive web programming works is this is a reactive data source. So if something changes here, your React component will update. dynamically, you don't have to pull you don't have to worry about it. I simply will take care of the push. And in the moment there's a change on the robot. You will see it on the front end without ever folding.

(0:34:57) Audrow Nash

So what that means is at the second row About sends a new image from the camera is your component updates and shows that new image correct a web component.

(0:35:08) Christian Fritz

I wouldn't necessarily use images or an example here, okay, because that is more complex said for our web RTC and like with good compression. But the example still holds. If you if you could do that you could send an image over that channel. Another example would be like, let's say the battery charged, if your battery charged, that's probably a better example. It will show up right away on the front end.

(0:35:33) Audrow Nash

That's really cool. So how if I if I'm developing this, like if I if I'm writing my own capability, how do I test that all of the three modules are working well, for the capability? Is there any like, I don't know, the thing that makes sure that all of them are working well together, that data is being sent around that I can test my components, my q&a module for the web browser locally, these kinds of things, like a storyboards for the mind, all these things. Component,

(0:36:04) Christian Fritz

there's a lot of tooling, yet, so some of these automated checks that you're alluding to don't yet exist. But there's definitely the developer workflow and the documentation on how to run it locally in a development server. So that you can you can try this out. And I think that's a good way to get started, you can use a simulator to run you know, your, your, your robot, whenever we use turtle sim a lot, which honestly is enough for a lot of work we want to do, and then you open the local web page on your machine, and will you will be able to see whether or not things are working.

(0:36:41) Audrow Nash

Gotcha. That seems super cool. And what is the so in the cloud component? So there's a web, the cloud the robot, what does the cloud component do?

(0:36:53) Christian Fritz

So the cloud component is actually a very module. The Cloud Module, there's, there's obviously what you what you want the functionality to be there can be visualizations, and so forth. But before it can get there, what the what the Transitive wrapping for that, for that module does is twofold. One, and that's very important is authentication and authorization. Because if you want to embed this, this component in a third party web application, you need to get the appropriate permissions to actually show the data of the robot, right? I mean, not, you don't want the camera of your robot to be publicly available on the internet. And obfuscation is not enough, you want some really strong authentication, the way that we solve that is through JSON web tokens, which is a security technology, it's it basically allows you to take a JSON object and sign it with an asymmetric or symmetric key depending on what you choose. And we use that to basically get permission from the back end of your service, whatever you're embedding it in, to show certain things to the user. So you will basically give your user a signed JSON web token that says this user has permission to see this device, this capability for this and that long. And then it will be embedded in the in the webpage that your user goes to that webpage will talk to the transit server, whether you host it yourself or whether you use our transit products hosting. And it will let us know whether or not we are allowed to show the users that that kind of data. So that's our Yeah, what are they authorized to see that and that's that by itself. So it's a big pain point that a lot of people struggle with just this. For sure. It's complex. And we've seen some very successful companies offering authentication as a service like Okta. And for good reason. It's, it's not a lot of fun. And if you make a mistake, a lot of at stake, right, your company, you're sharing too much data than you then you wish you were.

(0:39:02) Audrow Nash

Yeah. And I think that's an area where it's like, oh, you need to go be an expert at to do well. And so it's nice to specialize there and have another company that just does this really well. But so you don't have to worry about doing this for your application. So the cloud component for any of these capabilities you're making is going to handle the authentication and authorization. I imagine that's kind of like baked in to what you're building. So they don't probably have to handle that when writing their application. Does it also handle is it on the robot that it's running? Like, I know that sounds silly, but is it the thing that sends the information up to the cloud? Or is it actually running on the cloud? It's actually,

(0:39:44) Christian Fritz

yeah, the human way the authentication is going to be processed,

(0:39:49) Audrow Nash

or I mean, I guess. So the authentic authentication. That's I guess, I'm just I'm a little confused, because so for that, I would think that that would be something that you would set up very well. And maybe all the code lives in the cloud component. And the person hardly who's the developer hardly touches the cloud one it just like, because I don't think like, if I want to use this to write capability, I don't probably want to do the authentication and authorization side. So I'm imagining that's probably generated or exists in something that's already being used, like my code is using.

(0:40:28) Christian Fritz

Yeah, that's part of the the essence of the framework. And it's actually a feature of the MQ TT brokers that we're using, where you can have custom authentication and authorization, which which we try to offer. So the way it works is that the the web component actually establishes a web a MQ TT connection over web over WebSockets. Okay. And in order to authenticate for that, for that connection, it will send its Simes JSON Web Token. The MQ TT broker will interpret that and say, first of all, yes, you are who you claimed you are, because this is a valid JSON, valid DWT. And also I've decoded that JSON web token. And in it, it says you have access to the following topics. And this can be read or write access. And that's all you need. Right? Because again, this is the beauty of relying on MPT for everything. Now, you know, that the broker knows which messages it is allowed to send to you, and which ones you are allowed to write. And then it kind of goes into the ether and and everybody connected to that. That's it. Yeah, it's, yeah,

(0:41:40) Audrow Nash

that's magic. That's so cool. I feel like it's taking such a painful problem and making it a lot less painful. So just so the cloud, if I'm a developer, using writing my own capability to cloud component, I will probably have the ability to use the default way of doing authentication and authorization. Or I can write a custom one, if I desire. And that's kind of all the cloud component does, or is there anything else?

(0:42:10) Christian Fritz

Well, I mean, the other thing that the cloud component does is, of course, the data synchronization piece, right? So that in the cloud component, you have immediately access to you can subscribe to a subset of the of the topics that you want, and they will enter data will magically appear on your doorstep. And then you can visualize it in whichever way you want. So that you can really focus on on just that, right? How do I, how do I present the data. So you know, I mentioned your little play, I like to think in terms of black boxes, if you're a web component, your black box that you receive, after all of the magic has happened, you receive a JSON object. And what you're responsible for is outputting, a nicely rendered HTML page or whatever or react whatever you want to use. You have visualize that data, right? Health Monitoring is a good example. Again, like you get a JSON object that represents the health of your fleet. And you decide to show that as a table with red and yellow and green and and what have you. Right? That's that's really the that's really what people want to use web components for. They don't want to spend too much time on the on the plumbing, as I call it. Yeah, they just want to visualize it. And then in the reverse the same right, so your, your joystick opponent says the user has been pressing the forward button, now you need to send that to the robot. So you will send the appropriate data into the onto on that topic where you know, the robot will be

(0:43:29) Audrow Nash

listening. Gotcha. That's really cool. What does it look like on the robot? How, like, how do you set it up and what's actually running on your robots when you actually are using this.

(0:43:44) Christian Fritz

So the the way to get started ended depends a little bit on whether you want to use the hosted solution that we offer or whether you want to sell photos. But in the hosted solution, you just go to our website and create an account and you will get a curl script that you can run on your robot, which will install a Transitive robotics agent. This is just a small little piece of software that runs on the robot. And it's primarily responsible for checking whether you are running whether which packages are installed, which packages should be installed, and then installing them and starting them. And then once it is told to install a certain capability, it will fetch that from the repository and install it and run it in a sandbox. The Sandbox is one of the other pieces that is really important to the way that we're thinking about this because we want to enable third parties to develop for you. We think that sandboxing is really important.

(0:44:38) Audrow Nash

Tell me tell me what sandboxing is. I know what it means, but just like describe it.

(0:44:44) Christian Fritz

So the issue is always that when you're buying software from a third party, you you may not want to trust it 100% So you want to reduce basically the damage it can do you want to reduce the permissions that it has on both iOS And Android has a very, very strong sandboxing model. So if you install an app on your phone, it won't be able to read the password from your from your other apps, right, which is kind of important. Yeah. And the same thing here, right. And in the ROS world, people are used to using sudo, to install ROS packages. And that's a very honorable thing to do, as opposed to give that much trust. But if you are dealing with a much larger ecosystem, you may want to be a little bit more careful about the trust that you give and not run everything as root. So a lot of people wouldn't even want to run it in the normal user space, because even the running user could have could have secrets and so forth. That's one thing. The other thing is you want to separate those the capabilities running on your robot from one another so that they cannot see each other's data. Otherwise, the authentication and authorization is kind of goes out of the window, because somebody could install everything. Yeah, and a malicious capability could just listen in on everybody else. So you're solving this. Through a number of technologies that all borrow from Docker, we do not use Docker on the robot, because we don't want to use require that as a as a as a requirement. But we use some of the same technologies, we use the Linux namespaces, using the unshare tool, to to isolate things. This allows us to do pretty cool things, honestly, without requiring sudo on the on the robot, for instance, we hide a lot of folders on the drive, we can hide the home folders. And then we're also using overlay Fs, which this technology exhaustively used by by Docker, to minimize the number of copies of things that you need on the system. So if a capability has a requirement for a ROS package, it will it will first check is that already installed. And if not, it will install it in an overlay on top of what's already there. This way, we don't have to install ROS in each and every component that we have, which would happen if we were running in Docker containers, right, there would be a lot of duplication, which we can, which we can elegantly avoid.

(0:47:23) Audrow Nash

That is really cool. So you see if you have it elsewhere. And then if you have it elsewhere, you use it from that location. If not you install it. That's really cool. So what about handling things? So that that handles? You mentioned a lot of things? And I don't I'm not that familiar with all those technologies. But it can you hide things like the environmental variables that one capability can see versus another one? Or it just like all of the different things you give it access to only a small part of the file system. Yeah. How does all this work? It sounds so cool.

(0:47:59) Christian Fritz

Right? Now we go with a one size fits all type sandbox, you don't actually customize it, we just we just reduce it down to what we think is all you need. If you don't see the environmental variables of your user, you you're either home folders or hidden certain sensitive folders in the in the file system such as var lib, or from you as much as possible, like the data, if you're, if you're running a database, it would live there and he wouldn't be able to see that. And you explicitly

(0:48:32) Audrow Nash

opt in to permissions with this, or is it implicit in that, like, oh, this app needs this? And then we'll give it that? I'm not sure it's explicit. So

(0:48:41) Christian Fritz

so right now we, we think actually, we have the permissions down to what most capabilities will will need we there could certainly be some people have asked us about things like user management on the robot, right? This is clearly something that would need administrative rights. And we don't currently support that. We are currently only supporting things. It's a what one way to think about this, especially for your audiences ROS and up if you a lot of capabilities run a ROS node, they're able to talk to the other ROS notes. And that's honestly all they need to do. Yeah, it's it's none of their business what I have on my on my desk, right? That's that's not what we're here to do. So, all of that accesses is going to be very, very limited. Other than say, you know, what you need for, for for ROS operations, such as the message definitions, right. But most of the file system will be hidden from

(0:49:36) Audrow Nash

good I saw I'm imagining if I had some node that so I have a module on my robot, and that's sending up video. And maybe I want to send some sort of thing down from the cloud, to say, hey, we're a bit bogged down right now. Reduce the video quality you're sending up or something like this. And maybe it's netstat and an environmental variable, like, could you give it access to that? Or maybe there's a better way to go about doing that kind of thing?

(0:50:08) Christian Fritz

I would have to think about it. If by setting an environmental variable, you mean one that would also be written, read by all of the other capabilities, like some sort of shared space? Yes, not currently possible, there is no shared drive space. So another piece of technology that we've taken a good look at is snaps on on Ubuntu. And they, they solve this very elegantly to where they have, of course, you know, containerized, or sandbox capabilities, but they also have some, some shared folders, right, in which you can collaborate if necessary. So that that certainly, that certainly exists. In the example of the video streaming, I would, I would argue that that's the capability itself, that then reduces that.

(0:50:54) Audrow Nash

But yeah, you probably wouldn't need to do it the way I described. Because yeah, the capability would probably just do it. And it'd be setting a variable inside the module, robot module. That would be probably the best way to do it.

(0:51:08) Christian Fritz

And actually, so we do have that video capability. And we use Web RTC, of course, and one of the beauties of web RTC is that it will actually do that automatically, right? That's so Turman, I can't get those frames through, we're going to reduce quality for a little while, and and it will adjust to that, which is very nice. And really one of the reasons also to use Web RTC

(0:51:32) Audrow Nash

for industry. Do you think that this idea of sandboxing will catch on more generally, in robotics? Like I mean, if I'm using a bunch of software from the internet, you never know if something has been maliciously included? So

(0:51:49) Christian Fritz

yep. Yeah, I, I think so. I mean, if you've been following what Ubuntu has been doing with their push for four snaps, for instance, they had a person that was also very active in the Rust community. And he was in charge of ROS and snaps on the canonical side. And he was making some very good points as to why snaps are a good solution for that because they are sandbox, like you say, right, they are snaps for, for those of your listeners who don't know, basically, or you can think of them as Docker containers that run apps on on Ubuntu now, people will yell at me for describing it like that. Because of course, in reality, it's more sophisticated, and it actually doesn't use Docker. But for that, for the event, who knows a little bit of Docker, that's roughly how it works. And so you get all of the beauty of isolation, and, you know, reliable requirements, like dependency, dependencies, and so forth. So I think it's useful. I'm very curious to see how this will evolve, and whether the sandboxing will get into the way of development, whether people will prefer to install their capabilities, quote, unquote, privileged. But I think it's the I think it's a, it's a requirement for more broader cooperation, like you said, if we want to enable third parties to run, and it's our fleet of robots, right. I mean, for it from the perspective of a business owner in robotics, they're very conservative about what gets to run on the robot. Because if you screw up, like, these are implications, there's a lot of implications for on the security side, but also, even just on the operational cost, if for some reason, your robots one morning, don't do it anymore, or, or you know, they dropped from the internet, you can't reach them, somebody is getting on a plane flying somewhere. Very expensive.

(0:53:45) Audrow Nash

Gosh, uh huh. One thing a little bit of a tangent, but one thing that I thought was really interesting, and I am hoping more things start to go this way. There's Dino, which is a TypeScript library or TypeScript runtime environment. And Dino, for us. It's kind of like Node, but better suited for TypeScript also runs JavaScript. But if you explicitly opt in to every permission that you want to use, you can say all if you want, but so you can say this should only be accessing these folders, this should only have access to this environmental variable. And all of the software that you use can have these permissions set, which is quite cool. Because I mean, if you're running software, there's the chance that it's like trying to access something you don't want it to use. And this would be a nice way to bet that hey, there was an error or tried to access some sensitive location. We denied it and the program exited.

(0:54:45) Christian Fritz

That's pretty cool. I had heard about the though I didn't know that they have that feature. That's uh, I'm actually gonna take a look at that. That's that sounds really useful.

(0:54:53) Audrow Nash

Yeah, I'm sponsoring site quite a few you know, projects cuz I really like the direction that they're going But the whole node ecosystem is really, really, it's just so much there, that it's hard to use the you know, for anything that you really want to build, like, I've just been doing it for, like, command line tools that helped make my job at open robotics easier to try them. And you know, but lately node is kind of thing.

(0:55:20) Christian Fritz

Gotcha. So it's not a replacement for Node js at this point.

(0:55:23) Audrow Nash

Not yet. But there are quite a few packages that are like, I mean, I don't know, there's like an express like thing for hosting web servers, and routing. But if you want to do like, really nice date time stuff, or I don't know, there's just a bunch of missing stuff. Or you can go look at the CDN serialization or whatever it is, I don't actually know what that does. But you can go some packages can be translated over to it, but it has a different import setup. So it doesn't work flawlessly with existing node things, which is a bit of a bummer. But the ecosystem is growing. And there seem to be a lot of really smart programmers doing stuff on it. And building tools.

(0:56:06) Christian Fritz

Yeah, I mean, that's really, I think, key to a framework platform. You name a working ecosystem of developers, right. And my favorite example there that the reason why Node js is so popular and works so well is because it's so popular and works so well, right? Like people use us developing more things. And because they develop more thing, it's the network effect, right? And then more things. So you can find a library for just about anything if you don't need to develop it, yourself. There's downsides, of course, and we've seen the news about some, you know, either hostile takeovers of packages, where people have have stopped maintaining it. Whereas sometimes even malicious changes that people made sometimes out of spite or break everything, yeah, yeah. And those issues are, of course, serious, and we need to take care of them, and it'd be worried about them. But it's a very cool technology to build on.

(0:57:06) Audrow Nash

Oh, definitely. Yeah, I find it. So I mean, working at Open Robotics, we use a lot of C++ and Python. And type like years and years of using Python. But I really like TypeScript, because defining the interfaces is really nice. And it helps me I feel like I'm much more productive in it. And so now I'm getting familiar with the node, or NPM, packaging, and just downloading libraries and software from it. And I'm very impressed. And I feel like it's a, it's a lot more capable, in my opinion, than a lot of the Python libraries. And there are obviously exceptions, like, like, pandas is a really nice Python library that I don't think has a good analogue in TypeScript or JavaScript. But just it's an interesting space.

(0:57:54) Christian Fritz

It absolutely is. And I like to play dog to that. Note, J S is actually a bit faster than Python. And that's because JavaScript is compiled just in time, it's not actually interpreted, it's just compiled on the fly, which makes the execution a lot faster. And then I can, you know, say a lot of positive things about NPM. As a package manager, it's, it has a lot of features. And it has a lot of capabilities that other package package managers have within the past leg. So for instance, one big one is having multiple versions of the same package in the repository, you would think that this is a trivial thing. But DVM, for instance, doesn't, doesn't really support that apt, you're not really supposed to have multiple versions of the same package in the in the repository. But it is important

(0:58:47) Audrow Nash

for your application where you're trying to wean robots off of version, when they're when you're updating them. This is, this would be very useful.

(0:58:58) Christian Fritz

Next time, it also for the for strict versioning. I think that strict versioning, of strict, strict semantic versioning is a real benefit. Where you in npm date, there's this concept of a lock file, where you will save I'm going to lock down my versions. And when I commit to get is exactly this, if you execute this, you will get the exact same result, no matter what any of the dependencies have done in the meantime, in terms of updating, you will get the exact same. And and this is really helpful when you're dealing with an ecosystem like NPM, where you have hierarchies of dependencies that can be very, very deep, right? You can super nest 2000 packages being installed as part of your of your somewhat simple application. And that's, that's a benefit, right? You don't want to reinvent all of those 2000. But you do want to be certain that if anything happens to either of them, maybe they introduce a bug in the new version, your system doesn't go down. So really locking down the versions and deciding Yes, I want to update or I don't want to update it. Is, is very powerful. And for that you need to be able to have multiple versions of the same package in the repository. The other one is, of course, all of the books like pre installed post install, pre uninstalled post, uninstall, pre publish all of those kinds of scripts that you may want to run as different types of the software lifecycle, they are very powerful they can really allow you to do I mean, us? They are, they are very powerful in Debian packages as well. But because NPM has them you can do, you can pretty much install anything through NPM packages that you have, because the payload is just a tarball. And then you run these scripts when when it gets installed. And at that point, you can, you could install things out of the tarball that say you Debian packages, or play system files if you have the permissions to do that. So it's very, it's very versatile tool. And I think it's, it's a real good technology to build on and share.

(1:01:00) Audrow Nash

Let's see. So now segwaying, a little bit. Tell me a bit about your open core model at Transitive.

(1:01:09) Christian Fritz

Yeah, this is still still in flux. But I am a big believer of open source businesses, I think that there are some very good examples that we've seen in the past. And so we, we really want to make this open source model work. And from everything that I've learned. There's, there's basically two things that work really well from, from an open source business model point of view, one is testing. So in our case, we are offering a hosted solution where the cloud will be taken care of by us, you can still, like I said, have the components and embed them in your own web applications, if even a web application is running somewhere completely different. But you don't have to worry about it, setting up the cloud, dealing with the maintenance and administration of that storage of data and whatever your capabilities want to do. That's the that's the one model. Some of our customers have asked about self hosted solution. So we are offering that as well. And this is still a work in progress. So that has not been released. And the business model in that case, is premium applications. So it's it's really similar, I guess, to Android, again, right? Where Android is open source, you can install it on any phone you want. But then the capability the apps in Android can also be free, or they can be they can be premium. And I think this is a good model, right? It allows people to first of all get started with it. They it provides developers with a marketplace where they can distribute their their their contributions, their work, they don't have to worry about, you know, advertisement and and billing and and all of that. And on the receiving end, you know, the the companies using those capabilities will have an ecosystem with writings with commercial support behind it that they can that they can rely on. So I think that this is a model that can that can really work.

(1:03:12) Audrow Nash

Gotcha. And so are you experimenting between those two models? Or your you'll think you'll kind of see what capabilities you have? And then possibly add? Actually, it seems like it makes sense to do the Android model for what you're talking about, where it's and then you're doing both in a sense, because you are providing the hosting, but you're also possibly going to have specific capabilities that people can opt into, by purchasing. Yeah, that's,

(1:03:41) Christian Fritz

yeah, that's exactly right. And both are evolving, we'll have to see which one will be more popular and how, for instance, what we are still keen to find out as to what extent will people prefer the hosted solution versus self hosting? There's definitely pros and cons with both. Some people really don't like the idea of relying on a third party, especially if it's a startup, right? Because it multiplies to whatever No. That's why the ability to self host is certainly desirable. Others really don't want to take care of the scaling of that infrastructure and would much rather outsource that. So this is mongos applet service, which I think is fantastic. If you if you just want to set up a database, you don't need to set it up yourself and manage it. But I Yeah, time will tell really. And we're curious to hear from from more people what they think. And also, on the premium app site, there's this additional persona of the third party developer, right. Are people interested in developing for this platform? I think so. I've spoken with a lot of people who have been working on specific capabilities, a lot of them in the ml or computer vision space that they want to market to robotics companies. And they like the idea to not having to do all of the legwork in terms of marketing it and figuring out deployment and so forth,

(1:04:58) Audrow Nash

having more of an app store third approach. Yeah, that would be super cool. I would love if we had that kind of thing in the robotics ecosystem. Just like ROS really solves a lot of problems, making it easier for people to build applications. But it's hard to get it outside of your robot, as you're saying, as we've kind of motivated with the whole first part of this conversation. And so if it was like, you just try to get you would just add different capabilities on through an app store like setting and you can use them elsewhere. That would be super cool. Yeah, that's it. Gotcha. How have you guys been funded so far? And like, Would you talk a bit more about the team and everything,

(1:05:43) Christian Fritz

the team is very small, you're looking at it. God's just, it's, I'm the only one fully committed right now and doing technical development, I have a short, I have a small list of advisors. First and foremost, my previous co founder, Bob Bauer, he was at Willow Garage, and he's still advising me. But he's not a developer. So there's not too much for him to do right now. And funding, it's, it's completely bootstrapped right now, where, where we're profitable in the sense that I'm doing consulting work for customers, helping them both doing custom development, and then helping them figure out how to use Transitive as well, which is a good model, it's, as you can imagine, you don't get rich doing that. But it's, it's, it keeps the lights on. And one thing that I've seen with robotics companies, one, one way that they have failed, was that once they take money, they have to spend it once you once you because your investors want to use that money to hire a bigger team and scale faster, which, which means that you are lacking in a certain certain product, a certain business model, and a certain market fit. And if the market fit is not great, then you're trying to scale a business that was not meant to be, then you're making you're you're digging yourself a hole. And I really want to be certain that we have absolutely nailed market fit that we have gotten adoption that we have validated that this is something that people want before we take on money. And so yeah, I consulting that actually solves two problems here. Because, number one, yes, there's some money coming into the bank. And number two, we are actually getting validation from our customers. So this, this really lends itself to an iterative process that will make sure that we will build the right product for the market. Yeah. And I think we would get into race, no problem. We've had conversations with investors, they, they like the idea that we are basically indexing on the robotics market. And what they mean by that is, rather than so they have the choice of which companies to invest in. And they know that in robotics, the differences are stark, right? One company may be doing apple picking the other one maybe doing drywall construction, another one may be layout printing, and another one is doing delivery on sidewalk, another one on the street, if they don't know what to invest in, they all know that robotics is going to go up. And there's plenty of studies by IFR and all of those API research that tells us it's going to go through the roof. It's it's it's a phenomenal technology. And it's only sort of at the start, but they all want to invest and they don't know where to invest. So what they like about platforms like this is that they know that if robotics will succeed this company,

(1:08:33) Audrow Nash

as well, gotcha. That's really cool. I really like bootstrapping, too, as a model. In general, I get it. Because one of the other things with if you take investment is you kind of commit yourself to a timeline that you will have some sort of liquidation event within some period of years, like typically less than 10, maybe closer to five years that the investor would like to see a return on their investment. And that's tough, because as you said, you have to like really commit to the current fit, and it lends itself to a certain type of product. Yeah, and that being said, like cobalt robotics, they're doing the investment route, and they're doing a phenomenal job as far as I can tell. Which is really interesting. If you position everything well. And it'll be cool to see kind of if you start accepting investment, and how that helps you scale. But once you found that really good market fit, that seems like a very good approach. So me.

(1:09:31) Christian Fritz

Yeah, I'm keen to get into that point. And I do have a concrete plan on how to use that money in the employee to to foster third party development. I think there's, there's there's some really interesting models that you can that you can follow. Yeah, I think that there are a lot of capability. developers out there and I love this idea of, of the marketplace because it has inherent network effect. So more capabilities We have of high quality, the more people would want to use it, the more people who come to our, to our app store to look for capabilities to what people want to develop for it. And so that's, you know, that's the classical network effect that can that can actually justify exponential growth. And investors always want to see exponential growth. And I always ask them, Well, based on what, right, it's not, it doesn't just happen, right? There needs to be some sort of mechanism behind that. And it's not bouncing a QR code on the Super Bowl. In Super Bowl x, right? That's, that's a lot of money. No, you have to have something where the classical Atlas one, right if the ad plus one user has a better experience than all of the end before and makes the experience all of the end users before that better. That's network effect. That's why you have these these conversions effects where everybody will use the same social network, right? If, if you're the owner, if you and I go on to a social and create a new social network, and we're the only users Well, you don't have to have great conversations, but but it's not as useful as if they're more friends of ours on that same thing, right. And so for me, one that we had, it gets better. And I think, you know, marketing marketplaces have that dynamic, inherently built in, they're also hard to pull off. That's where money can be really helpful. But I think first and foremost, you have to make sure that it that it goes about it the right way and openness. And I think it's really the the key to all of that.

(1:11:28) Audrow Nash

Hmm, tell me a bit more about that. That seems very interesting.

(1:11:31) Christian Fritz

Well, I I just think that if you if you want to be if you want to establish yourself as the framework that everybody develops, on, contributes toward contributes to your store, and I'll use the Android example. Right? Then then being open is really what you is really the best thing that you can do, because you're you're going to benefit in the long term from people being on your platform, if you will find ways to pay your bills like that. I like this quote from Eric Schmidt, when he was still the CEO of Google, they asked him back in the day they asked him, so Eric, how are you ever going to make money from Android? And he said, In five years, there's going to be 1.8 billion users using Android. We'll figure it out. I think was brilliant. And of course, he wasn't the first Microsoft obviously, famously gave away MS DOS for free at a time when others were charging for the operating systems. And we all know what that did, right? People started installing MS DOS on their phones, just like Android was free, right, and they installed Android. And now there's a big market for for Android applications. And so that can be that can be monetized. And that's, and I don't say monetize in the sense of, you know, really making as much money as possible. It's more about making enough money to do a good service and to keep running and to make sure that it is serving everybody involved in the best flip.

(1:13:02) Audrow Nash

Yeah, you can invest it back into it. And it's basically more ability to make a larger impact in the future. And then you just, I don't know, event like that, that seems Excellent. That is a good model, it's interesting to consider the network effect I had been previously thinking of, kind of like a zero replication cost as the way to get towards exponential growth, which is like, I don't know, coding is a good example. you code it once, and then you can use it anywhere. But network effects seems like a very good thing to think about, especially when thinking about like a marketplace, and this kind of thing, because as you get more products on there, it becomes more valuable. So the n plus one, as you're saying more valuable than all the previous people, venture

(1:13:49) Christian Fritz

capitalists, especially in the SAS world, look at one ratio more than any more than one software

(1:13:55) Audrow Nash

as a service, right? That Software as a Service, yes.

(1:13:59) Christian Fritz

They look at one ratio more more than anything else and that is the lifetime value of the customer over the customer acquisition cost. And they mostly because they know that the customer acquisition cost at first is tremendously high. They are totally fine or they almost expect you to spend three quarters of all of the money that they will invest in you on customer acquisition which sounds mind boggling at first, right? What you spent so much money just to get users why don't they get that at work? That's what Yeah, but it that's why these these network effects are so valuable from a growth perspective because it becomes cheaper and cheaper to acquire new users Facebook when you when you think back until not too long ago, they'd never advertised anything. It was all word of mouth and and of course it was because if I'm on Facebook, I will actively recruit my friends to come to Facebook because hey, I don't want to share my photos both in email. And then also on Facebook and also I want to know what's what's going on. Your Life, right? I would love to see that. And so friends, you know, are intrinsically motivated to recruit friends or it doesn't have to be friends, it can be developers, colleagues and whatnot, then there's a real good chance that things will grow. And so I think for that there's this concept of giving back in substances is important, right? If I'm a developer on Transitive, I will be recruiting people to use it right? I will advertise the fact that I've I published something called Transitive. Sure, the focus will be on what I've published. But in the process, I will still be advertising the platform as well. And then people may go, oh, yeah, I've been consuming capabilities through transit, CIF, and we have developed this cool, new, whatever it is map display map editing tool for for robotics, we could we could publish that back as well.

(1:15:55) Audrow Nash

What do you think will be so kind of going from where you are to starting a marketplace of different capabilities? What do you imagine? Like, how will you get from here to marketplace? Yeah, what are how are you thinking to proceed.

(1:16:10) Christian Fritz

So marketplace is, of course, the longer term vision and aspiration as you can, you can't even build a platform from from day one, you have to go vertical to horizontal, you have to have something that where your early users will get some real value out right away, before they even recognize that there's a platform and that they can do more things. So that's why we we will develop certain capabilities ourselves. And on our website, we already have three that you can people can use right away. And ease of getting started, I think it's really important there. So if people are totally within 30 seconds, have can have a remote video streaming capability, which they previously thought would take them months to build. That's a great experience. And I think that's something that we can market and start growing up. This is actually again, going back to Facebook, not not very different from the way that they got started. If you if you may remember, they were first just an application for students at Harvard, right. And then for a while they were just for college students. And then they brought out like that. And it's it's a nice model, because when you think about it, first, you basically conquer a small part. But you try to get to something like 90% users, like 90% of the people are in that pond use it. And of course, at that point, okay, you've convinced yourself that first of all, young people want that second of all, the network effect works. And these people have friends outside of Harvard, right? So they will talk to them, and they will, they will talk about Facebook, and people are like, well, I can't use it yet. But that so that creates some some, some sense of desire. And I think that's, that's really the model of vertical to horizontal, you want to start with something that is very small, where you get a lot of value for potentially a very small market at first. But I have absolutely absolutely no doubt about the fact that

(1:18:02) Audrow Nash

they are how great it is. Yeah. How do you how do you think you'll get your first Harvard or whatever, in the robotics community? Is it the video streaming app that people will be using? Or where do you? Or is it sunset of the ROS community? Or what do you think?

(1:18:18) Christian Fritz

So we definitely target the rust community right now. And especially specifically, we're actually targeting the rust one community, which may surprise some of your listeners. It's gonna ask you both want to rush through? Yeah. So right now we're focusing on rust one. And that's for a very simple reason. From us pyramids, everybody who has an actual fleet of robots out there that grows up using ROS 1, and I wish it was different, because I think ROS two has some has some really nice features. But until not too long ago, it wasn't necessarily perceived as really ready for primetime if we've seen all of those discussions on this course and elsewhere. So the vast majority of robots out there still using ROS 1. And so breaking into that would be sort of the first step. The platform that we built is not specific to ROS 2 or ROS 1 that the capabilities that you will build are. And then in terms of which capabilities to focus on. Yeah, I think low latency video streaming and remote tailor some very good ones to get started with, we know from from from some of the existing offerings, that's also some of the most popular features. In fact, there are now companies like Dr. Yu and Fenton auto, that offer specific remote control capabilities for originally self driving cars, but now they are doing a lot of business with auto delivery robots. So there is a there's an absolute need there. And so I think that's a that's a good way to get started. Mm hmm.

(1:19:56) Audrow Nash

See, is there Well, I guess, do you? How do you imagine your team will grow over time?

(1:20:09) Christian Fritz

I mean, this is, of course, a little bit of a chicken and egg question. But we have to first get some traction so we can hire and then we can get a team. But of course, in order to high end, people may also want to know about that strategy at 70 of my entire team was remote. Which, at first, I thought is not possible for a robotics company, because we're dealing with hardware, right? How can I do that remotely, but I learned there that it is absolutely possible. And it has some real big benefits, like on so many levels, like, for one, you can tap into a much broader pool of talent, right? Great developers all around the world, not just in Silicon Valley. They, it also solves another problem that we have here in Silicon Valley, there's housing is insanely expensive, because everybody had water, if we can work remotely. We don't need to make this housing market here. Any works? I know. And, and yeah, so I'm a big believer in hiring remotely. We have worked in the past with people. I had people on my team from Germany, France, Spain, Argentina, several places in the US, one of my employees actually was driving his RV, through through the country almost every minute started by asking where are you today? And sometimes he had to apologize, because there was not enough sun to use the solar panels to charge this batteries. But that happened very rarely. But it worked. And I thought it was it really added to the diversity of the kind of perspective of the team. So I want to follow that same model and focus on like, build a remote first kind of company.

(1:21:52) Audrow Nash

Yeah, that seems super cool. What are some of the because you, you seem to like you've been implementing everything. So I imagine, like, I'm wondering what what will the first people? What will their roles be? Do you think as you start to grow, or as you start to have more interest and investment, and then have the ability to hire some people? Where do you think you'll start, I think

(1:22:15) Christian Fritz

we will be hiring mostly on the engineering side. And I will be handing off more and more to my team and focus more on the on the leadership in sort of external facing requirements. I also before law, will hire a product manager. Because I think it is actually really important to to really feel customers out and understand what what pain points they have and how we are addressing them. And I'm also just going by things that I know myself, I'm not very good at. That's perhaps the best advice that ever got for hiring to try to hire somebody is when you can find somebody who can do that role better than you. Not before that. They're not after it's not it's sometimes people think of oh, I'm too overburdened, I should hire somebody to do these things. But if you then don't find somebody who you really trust to do it better than you, it's too early to hire because you will be questioning them and to have micromanaging that that will not make anybody happy. So a lot of it will have to do also with finding the right people at the right time it filling in until then then yourself which again is is fine. Well, you're bootstrapping. And then once we've once we've raised money, it will be there will be a slightly different question. But that will still to the to the extent possible people model

(1:23:33) Audrow Nash

chacha, I really like that model. It's interesting, because I mean, you think if you hire someone, and like it is to take weight off your shoulders, if you're trying to do everything. But then if you don't trust them to do the work well, then it's like, well, now you're micromanaging. And now you have that job still through micromanaging. In a sense,

(1:23:53) Christian Fritz

I think it goes back to the question of accountability versus reliable, being responsible. And I think at the end, what you need us, people who distribute on to whom you can distribute the accountability, people who you can rely on being accountable for something happening and having that attitude to say, like, well, maybe I wasn't supposed to be working on this, maybe it was somebody on my team, but it's not there, I'm going to fix it, right. That's kind of the attitude that we need. I've seen this in engineering teams a lot like sometimes the the, the amount of features that you need to implement, you just have too many features or too much code for the size of your team. There needs to be I always think of attempt with tentacles. That way if you have two or three temples, you can cover a lot of ground just by you know spending something over but some but at certain points you have to hold up the tent. You cannot with one temple cover a lot, a lot of area because they cannot look there or the explanation There's what the amount of code that you are responsible for, as a developer, it cannot be infinitely not a one developer can be responsible for 100,000 lines of code, a good rule of thumb that I have is between 10,020 1000 lines of code per developer is a good number. Beyond that, you will just not be very effective. Because if every time you switch tasks, you have to re familiarize yourself with the code that you're dabbling in, then you are in trouble. Right. And so having that getting that ratio down, is it's quite important, I

(1:25:34) Audrow Nash

think. Gotcha. Do you think that's kind of the way to proceed? Where you have people in a sense specialize on specific spots of the code. So 10 to 20,000 lines per person where they kind of like, divvy it up? Yeah, each person has like a little silo? In a sense.

(1:25:51) Christian Fritz

Yeah, I think so. And I think with our architecture, in particular, it lends itself to that, because we have the framework itself, which breaks down into the components for robot cloud front end. Yeah. But then we also have the capabilities which are super important, right? I mean, they aren't, and they are by design standalone. So you don't, in fact, it is a good thing, if you're not too familiar with what's going on in the platform, because you're supposed to treat it like a user, like the documentation says, I should be doing this. And that's what I done, and it doesn't work. Okay. Thanks, file a ticket, but you don't have to fix it, I will fix it. Right. And I think that's, that's how we can divide it up and also find interesting ways of working together, right. So you know, when you're working with a remote team, sometimes it's preferable to have contractors rather than employees, people may not want to commit full time completely, but only part of the time. And so having this actually a product, which is componentize, like that lends itself to offering all sorts of ways to work to get right. If somebody wants to work half time on this, and really just wants to develop a specific capability but wants to get paid for it, rather than selling it on the marketplace afterwards. That's great,

(1:27:04) Audrow Nash

we'd be we'd be open to that. That's super cool. It's very flexible, I haven't thought of that kind of model, where someone can be hired as a contractor just for a specific thing that they want to add. But it's maybe too large to take on. It's like a free project or this kind of thing. Very cool. Yeah, I

(1:27:22) Christian Fritz

think since the pandemic, we have seen more and more models for how to work remotely. And of course, they have been even before the pandemic, there have been things like, I think Upwork, and Zephyr and take these search kinds of tools that are platforms that allow you to outsource some work. But I think there's a spectrum of you know, from being a full time employee thing to being an hourly contractor for a short time, there's there's a lot to be explored in between. And only because you're a contractor, for instance, doesn't mean that you can't be treated like an employee. I mean, it's just, to me, that's just the burn Pratik aspect of what's, what are you call it on paper, but the relationship can still be that of an employee and location shouldn't matter for that at

(1:28:07) Audrow Nash

all? Yeah, for sure. Especially I feel like with, like with programming tasks, I mean, we work on GitHub, you do reviews and things like this, it works really well, asynchronously, is what I'm struck by. So far, being an Open Robotics,

(1:28:24) Christian Fritz

it does when you're set up for that. One thing that I've seen, of course, comparing those with a lot of my friends at other companies. One thing that I've seen, especially with some larger companies in the Bay Area that frown upon remote work, and I'm not going to mention their name. They, they have this problem that like 90% of the people until the pandemic were in the office. And so anybody who was remote felt left out, right, there were a lot of decisions that were being made in person meetings that were not documented, and so forth. And that was really hard for the remote team. But if you set up like a remote first company, and some people just happen to meet in the office, that's it's a completely different ballgame. Every decision will be made in a ticket, and everybody can chime in, everybody can see what the record was what led to it. And that has so many benefits, not just for inclusion of the remote team. Also just for refreshing your memory two years later is gonna

(1:29:17) Audrow Nash

say future you.

(1:29:22) Christian Fritz

I always think of it like that every time I've write documentation. I'm sure that I'm doing my future self a favor. Yes.

(1:29:30) Audrow Nash

For sure. Now, I would love to get your thought more thoughts more on web and robotics, kind of how you see actually starting it super broad. How do you think web and robotics kind of? I don't know, like what do you see is the relationship between the two like web tools and robotics?

(1:29:51) Christian Fritz

Yeah, I mean, obviously I'm a big believer in web tools. I actually have a another bootstrap company that is Based on web technology, it's for scientists, I've been running it since 2006. So I've gone through this whole process of web development and really learn to love it. What I'm struggling with in the robotics community is that there's that there's still a little bit of a divide there sort of a, I sometimes call it the group of believers, and those who who don't yet believe in web technology, the tools I love ROS, but some of the UIs like Qt, it's not, it's not up to snuff these days anymore. It's not, it's not developing as fast as web technologies, it's not as accessible. The benefits of web technology, the perhaps the biggest benefit of web technology is that everybody immediately has access, because they have a web browser on any device that they have, like the desktop portable, and Linux, Windows, Mac, iOS, some people, I think, still run always to whatever you want, right? I think I have it on your phone, you will have access, you don't need to run Linux to visualize something, for instance. So I think that by itself is perhaps one of the biggest benefits. And it kind of enables a broader group of users to write side adservio, we had a very important part of the company was field ops, because of course, it's 70, we were running robotics as a service. So we were on the hook for making sure that our robots work in the field. And if there was a problem, we wouldn't just, you know, it wasn't our customers problem was our problem, we would fix it, and suddenly turn into robots, triaging, and so forth. That was a that was a big part of what we did. But we didn't want to have engineers to have that because engineers were busy writing, you know, improving the software. So we have this role of field ops engineers. And they may not know much about ROS nor nor do you want to train them, because that would be a real big limiting factor for hiring. So being able to give them tools that they know how to use really enables them, it lowers your cost, makes makes everything easier. And so there's a lot of a lot of good reasons, I think, like that for for web technologies. And now I think what we need to do is collectively build the tools to make exactly that development easier. You and I meet on the on the ROS web tools are working group every two weeks, and there's a group of others, especially the folks on foxglove. We're very active on that. And I think it's great that there's all of these contributions being made. And I think that's how we fit in with Transitive as well, like being able to offer a piece of the puzzle that helps with with data synchronization across devices and remote, remote robots, hopefully will contribute to the to this open source, web technology ecosystem, that we can all kind of build the future.

(1:33:02) Audrow Nash

Do you this, this might be a crazy question. But do you ever see web technologies on the back end? Or robotic navigation? So like, maybe like a ROS client library and TypeScript or something like that? Do you think there's a place for this?

(1:33:15) Christian Fritz

Oh, absolutely. I guess I should mention that I'm one of the contributors of rational js, which is, you know, just like raw CPP, or ROS pi is a native binding for for ROS. So it speaks ROS, it just makes TCP connections to all of the other ROS nodes. But it's written in Node J. S. It's a it's a native implementation. And, yeah, I mean, I personally use it a lot, right? It's certainly not as fast as C++, if you have something that really requires high performance, like I wouldn't necessarily use it for point cloud transformation. But yeah, if you want to put something together quickly, it's similar. It really, I think scratches is similar as where you would use Python. Because you can write it very quickly. You can test it very easily because it has an interpreter. And yeah, so for sure. I mean, they are and there are others, right. There's ROS no Chase, which was originally started by Brendan Alexander and at Willow Garage. He later became the CEO of, of iron oxen. He was too busy to maintain it. I took it over at one point and around the same time, the folks that Rethink Robotics started to rewrite it. So the current version of ROS no chases based on on what Christmas, everything developed. And there's alternatives. There's similar libraries for ROS 2, as well. I don't know I don't think it's crazy at all. I think it's a it's a fine language to develop in. It's very quick to develop in that and it's very, it has this very nice ecosystem that allows you to share very quickly

(1:34:56) Audrow Nash

see, so, where do you think robotics We'll be more generally in like, where do you see us going as a robotics community in the next, say, two to five years?

(1:35:09) Christian Fritz

Now, that's an interesting question. I don't I don't spend too much time thinking about that. But I guess I can extrapolate a little bit from my, from my view of the robotics, the startups in the space right now. Which I looked at very carefully after, after, after leaving Savio, Goodwin, wondering what to do next. One thing that struck me, of course was, and this shouldn't be too surprising, but I still think it's worth mentioning the successful robotic startups are the ones that find a problem worth solving first, and then convince themselves that robotics is the best way to solve it. And that's, which is honestly not happy. That's not always been the case. Right? In the past. There were a lot of robotics companies that that were trying to solve that hammer nail problem of we have a robot, but can we use for what to do with it? And so I'm very excited about this new model. And I think that's actually what's behind it. Again, not too surprisingly, behind the success of so many new robotics companies in so many different spaces. I mean, even just, what is it like eight years ago, they were they were all that many applications of robotics, outside of, you know, car manufacturing. And then at the time, that was roughly the time when the Kiva acquisition happened. So we were aware of the warehouse robots, which still was sort of a novelty. Apart from the AGVs, that were just following, you know, simple trucks. And now you look around and you find so many startups in so many different spaces, act Tech is a particularly interesting space. If you ask me, there are so many problems there. That the and that's where I live, like you're the title of your podcast, sit in a sense, plan, act, or sense Think Act works better than the blanket approach, because that's really what a robot does, right? It senses it decides what to do. And then it acts and when you look at for instance, what Blue River does in appetite, right, they will go over a field and rather than applying pesticides everywhere, they will actually take a good look at the crop that is growing. And they will decide how to act like what to where to apply pesticides. And the amount of pesticides that you use as a result is of course, much lower, which which is fantastic, from an ecological point of view, but also is a very good business proposition. You're building you're growing better crops. And that's I, I really congratulate you on that on the choice of that of that name for the podcast, because it is so it is core for for what a robot does. And it's also describes the value very much right. But there's so many areas that we could explore with this mentality of where are we currently doing a blanket approach where it would be smarter to take you to look that aside and then act and of course, this is now being made possible by better software, better compute that allows us to implement algorithms that do service and that do think, right, that that wasn't necessarily possible before. And I think it's it's super exciting. There's one particular area that I'm very curious of, and that is this whole idea of semi sorry, mixed initiative, operation, or no, that means, so any sort of tele operation where you are not controlling the robot entirely, but only perhaps giving certain signals and then having the robot do other things, to kind of falls into that category. And I think that's a, it's a very interesting space to look at. Because another thing that robotics companies in mind have done wrong. And I'm saying that now, I would have made the same mistake until a few years ago, but they made the mistake of trying to automate everything from the get go. Whereas nowadays, you see a lot of very successful robotics companies start with fully manual approach remote controlled, and basically say, Let's own the problem. First, let's build the business problem. First, let's, let's build a customer base, and then automated more and more and more to reduce our cost. And I think that's a fantastic model. Because you will be learning if you will know what to automate in the process. And the most of the value may actually come from something that is relatively easy, right. So I'll give the examples of sidewalk delivery robots. I personally have to admit that I was laughing at starship when I first saw the robot, because I looked at it and go like you will never be autonomous. And they laughed back and said, We don't try to be fully autonomous because they they basically recognize that they have evolved a lot since then. But in the other day, Steve recognized that if they have a robot that can reliably drive forward without bumping into anything and noticing when there is an obstacle and just stop as opposed to doing all of the great you know, path planning, like the stuff that you've discussed with Steve last time, about you know, going on around obstacles dilating the obstacles and dealing with, with all sorts of situations, if you just focus on this one thing, then all of a sudden you can have one pilot control, whatever it is 10 different robots at the same time, because most of the time, they are actually driving by themselves. And then when they get in trouble that they will ask you questions that you just, you know, we're pretty quick without without which we humans, right, we see this, decide what to do which other robot what to do. And so that way, you can really kind of make a step function, a gradient, right. And of course, anybody in machine learning will tell you that that's the secret behind all learning neural networks as well, that if you have, yes, in the end, you may need a step function. But to learn it, you need to smooth it out. And by smoothing it out by giving a way to move along that spectrum between full automation and for the remote control really enables a lot of a lot of innovation. So I'm really curious to see what will come from that. From a kind of vision point of view, I like to I sometimes ask myself, whether it will be possible to make everybody in the world able to work remotely. And what I mean by that is, we we've we've seen that during the during the pandemic, right, they were the I would call us, the fortunate ones who were able to just work remotely and those whose job required them to go in and they had a big problem, either. They couldn't go in because it was shut down because we had lockdowns and they suffered economically. And that caused a lot of hardship on a lot of people, or they weren't able to go in, but they sometimes, you know, suffered and had to take the risk of getting affected more easily with COVID. And that's exactly what happened. So from almost from a fairness perspective, I asked myself, well, what would it take to automate all of them not automate, but make it possible for everybody to work remotely. And we've seen some, some very, perhaps eyebrow raising examples of that of humanoid robots being remote control to stock shelves in seven elevens in Japan, where, you know, somebody was remote controlling the arms to take cans out of out of a tray and opening the fridge and putting them in there. And people laughed at that, but actually think that's, it's, it's tremendous. It's, it's exactly how we should be thinking about it. And if you start by remote controlling that and then ask yourself, well, which of these things can actually automate? And which ones are the really hard ones? And just identifying the problem and frame phrasing it? Well, there will be actually no shortage of people who will be interested in solving that. Both of us have been in academia for long enough to know that, in academia, often the problem is finding the problem, like finding a real product that fits my solution, right? So there's, there's almost a thirst for problems. So if you if we as as sort of a, the ecosystem of companies in robotics can identify problems worth solving, and frame them really well. So that we can sort of hand them over to academia, academia would love us, and we would love them back for the for the solutions that they give us. And I think that's like building bridges like that, between academia and applied research and robotics in particular, is something really worth working towards. And I think it's, it's really exciting.

(1:43:25) Audrow Nash

Awesome. Well, I think we'll end it there. Thank you very much. Thank you, everyone. Thanks for listening to this conversation with Christian Fritz. Thank you again to our founding sponsor, open robotics. See you next time.