One post tagged with "robot fleet management"

It is an exciting time! You have successfully completed several customer pilots and are deploying your next batch of five to ten robots to the field. This is the moment of truth you have been working towards, through all the hardship of starting a robotics company. The moment where you can see market fit and start to grow. From here it will be all downhill, right? Not so fast! The difference between building and deploying a small number of prototypes and scaling to tens, hundreds, and thousands of fielded robots is vast. The name of the game in Robotics-as-a-Service and related vertically integrated business models is "operational excellence". You need to be able to deploy, monitor, and manage that fleet as it grows and your cost must not grow proportionately. You and your team need to get ever more efficient at operating that fleet, just like the mean time between failure of your hardware needs to increase.

Of course, as with virtually any challenge in robotics, we can call technology to the rescue. Software to be exact. Putting the right software tooling in place will allow you to more efficiently perform all tasks of fleet management, enable non-roboticists to triage and resolve issues, and reduce the number of times engineers are called to the scene (literally or remotely). This is key in reducing your cost and allows you to tap more resources. Furthermore, software is what will allow you to visualize to your customers the value you generate for them, providing them dashboards and reports that answer the question: "what have those robots done for us lately?" This is important, not only before contract renewal, but also every time a stakeholder at your customer changes or you want to increase the number of robots deployed at your customers.

The only problem: building a fleet management system from scratch is hard!

Make vs. Buy​

It is hence natural, and prudent, to consider using a third party fleet management solution rather than building your own. Why reinvent the wheel if someone has already done it? As it turns out, neither buy nor make are good options.

Buy​

There are a number of third party fleet management systems specifically for robotics available, see, e.g., this list, giving you the option of buying instead of making your own. But there is catch: they force you to make that decision, i.e., you cannot do both, and these systems will not meet your needs 100%. Before robot fleet management systems were created, management systems already existed for other types of fleets like vehicles, repair crews, and, of course, IoT devices. But these systems were not a good fit for robotics. Robots have different properties and requirements, which motivated the creation of fleet management systems specifically for robots.

But as it turns out, once you've seen one robot, you've seen one robot. Almost no two robots are alike. And why would they? Robotics, as a logical, intelligent extension of automation, is not focused on one application alone. Unlike vehicles which typically have four wheels, travel on roads, and (usually) have a driver, robots have very little in common. Some are small, some are big. Some fly, some swim, some dive, some travel on roads, others on sidewalks, and yet others indoors only. Some even perform surgery! And now there are dogs, too, and humanoids! And just like their forms and operating environments differ, so do their applications. Operating a fleet of strawberry picking robots is very different from operating outdoor delivery robots, dry-wall finishing robots, truck-unloading robots, or underwater surveillance robots. So it is not surprising that their fleet management requirements differ, too, and it would be foolish to believe that one size could fit all!

Hence for the same reason IoT management solutions were not sufficient for robotics, any one fleet management system "specifically for robotics" is unlikely to be sufficient for most robotics companies. I have seen this first-hand myself and we have heard this confirmed by dozens of CEOs and CTOs of robotics companies of varying sizes and stages of maturity.

But if these solutions only provide 80% of what you need, what are you going to do about the rest? What's worse, as you grow and want to increase your reliability from 95% to 99% and then from 99% to 99.9%, your needs become even more specialized, meaning the degree to which they are met by a "generic" robotic fleet management solution further decreases. Furthermore, you'll also need more and more customer facing UIs and dashboards as well, and you want them to be consistent with your branding and the rest of your user's experience. Your fleet management system, "operations center", or "robot web portal" will become very central and critical to your operation and bottom line, but building a secondary system of your own to supplement the shortcomings of the third party solution is not a good option either: There will be a lot of redundancy and hence cost involved, it will break up your data landscape, and it will break the user experience when users need to switch between different systems for different tasks. Some systems provide APIs or allow you to write plugins or extensions, but these don't tend to give you all the access you need.

In the early days it is tempting to just use a system like that, because on day one it gives you almost everything you need and in comparison you haven't yet built much yourself in-house. But over time you are likely to outgrow that system and be faced with the challenge of not only building everything you already had from the third party again in-house plus what you need on top, you also need to bear the switching costs, which should not be underestimated.

Make​

Building your own fleet management system, robot cloud portal, mission control center, or whatever you like to call it, is not easy either. For one, it's a lot of work and takes a lot of time and money. This is because the list of features you need is long and it gets longer every year. It includes deployment management, configuration management, remote monitoring tools including low-latency video streaming and tele-op, map display and management, missions and mission histories, health monitoring, remote access, file sync, log ingest, ... the list goes on.

Secondly, finding the right people for the job is not trivial. In the typical robotics startup, early engineers are roboticists, MEs, EEs, and firmware engineers who write software in C, C++, Python, or Rust, not HTML and JavaScript. And they don't usually know much about web servers, cloud architectures, Docker, or Kubernetes either. On the other hand, hiring web developers and cloud engineers comes with its own challenges: there are very few such engineers who have experience with robots. If they don't, they often struggle to grasp the difference between a robot and a web server, something they know very well and "looks" similar at first, but turns out to be very different. In addition they still need to learn about robotic concepts and ROS.

Building your own is also error prone. There are several technical challenges and pitfalls somewhat unique to robotics that are costly to fall into and recover from. This is especially true when your team is already spread thin attending to all the other complexities of developing something as innovative as a robot that addresses a new application.

Neither Make nor Buy are great options and this creates a real dilemma for robotics companies of all stages of growth.

An Alternative Approach​

With Transitive, we are addressing this dilemma by creating an alternative to the strictly binary choice of make vs. buy. We provide a middle-ground between these two options by making it much easier to build your own web-based fleet management system. This is accomplished by two means which can be used together or separately:

• an open-source framework that solves some of the hardest challenges in building such a distributed system of robots, on-prem servers, cloud, and web front-ends, and
• a growing list of commercially supported full-stack components, each adding a complete, new feature to your system, e.g., remote video streaming to the web.

These components, which we call capabilities, can be integrated into your fleet management system whether you used our open-source framework to build it or not. So there is no switching cost if you have already built parts of your fleet management system.

An open-source framework for full-stack robotic software​

Transitive solves many of the issues you would encounter if you were to build your own fleet management system.

• Live-data sync Transitive provides a reliable, real-time data synchronization protocol that operates on top of MQTT, called MQTTSync. MQTTSync seamlessly synchronizes stateful data between robot, cloud, and web, instead of just passing messages. Using MQTTSync you can reactively re-render web pages when data on your robots changes, live and without polling and because all data is persisted in the cloud, your web UIs will be accessible even when your robots are offline.

• Full-stack packages ("capabilities") Transitive defines the notion of full-stack packages, "capabilities", that implement encapsulation and versioning of software components for all three systems (robot, cloud, and web). Capabilities use MQTTSync's name-spaced data model to reliably communicate and operate, even when different robots run different versions of the package. Transitive sandboxes capabilities run on the robot and in the cloud to isolate them from the rest of the system, just like Android and iOS do, and the web components can be embedded in any web page including existing robot cloud portals.

• Authentication and authorization Transitive secures all communications using SSL for transport-level security, client certificates and JSON Web Tokens for authentication, and authorization based on MQTT topics.

The documentation of the Transitive SDK shows how this looks in action, e.g., in the browser. For a more in-depth explanation including examples, see What is Transitive?.

Full-stack robotic software capabilities​

Capabilities written for the Transitive framework can be shared and, like mobile apps, can be either free or cost a monthly premium per robot. By providing a way for capability authors to commercialize their work, we make it much easier to create high quality components with long-term support and that is also Transitive Robotics' own business model. The list of capabilities we have already created include webrtc-based low-latency video streaming, remote tele-operation, configuration management, remote access without VPN, and health monitoring. Our capabilities have been used in production by several robotics companies on over 50 devices for more than two years. It goes without saying that you only pay for what you use. If you only need one or two capabilities, then that's all you'll pay for, rather than paying for a full suite of features you may or may not use.

Benefits​

This approach has several benefits compared to building your own from scratch or using a third-party solution:

You remain in control! Since you control the overall system and architecture you remain in full control and nothing prevents you from meeting all your needs now and in the future, no matter how specialized they may be. Using the Transitive SDK, you have access to 100% of your data in real-time. This is true whether you self-host or use our hosted offering. And because your data-access is real-time, you can use and integrate it with other production applications. You also fully control the access, appearance, and branding of your system, making it possible to use the same system to serve your customers (e.g., dashboards, reporting, mission assignment) and your internal teams (e.g., health monitoring, configuration management, remote monitoring, logging, alerting).

Reduced effort and risk. As illustrated by the size of the dark blue areas in the figure, your overall effort to build your own fleet management system or robot cloud portal is much reduced compared to starting from scratch. This means your team will not stretch itself even thinner and can instead rely on tools and components used, tested, and trusted by other robotics companies. So rather than rediscovering some of the pitfalls in building such systems for robots, you can focus on what sets your company apart in the market you operate in and only build the tools that are unique to your operation.

You help the industry and yourself. By using Transitive you help seed a marketplace for capabilities with the usual network effect of marketplaces: the more people who use Transitive, the more developers will be motivated to develop capabilities for it, which, in turn, motivates more people to use Transitive – a virtuous cycle. This leads to a future where more and more of your needs can be met by existing Transitive capabilities, just like Apple's original iPhone ad "There is an app for that", and likewise helps the industry as a whole in the same way ROS did.

Getting Started​

To start exploring this new alternative to the make vs. buy delimma, you can follow our Getting Started Guide to create an account on our hosted solution where you can try all our existing capabilities on your robots for free. If you want to build or extend your own fleet management system with Transitive, the open-source framework, we recommend you read about self-hosting, which is also what you would use for local development. Lastly if you have any questions or would like our help with development, please join our community Slack or email us.