When I was a child, my father would come home from work and give me the extra computerized punch cards that were used that day - it was my first exposure to the world of computers. Later, I became an active participant in the personal computer revolution, both at school (which let students program on Apple II systems) and at home (my father purchased an early IBM PC system).
Because PCs were so new, most people who used them needed to learn how to program them, and in my case it was figuring out the BASIC language. After a while, my interests changed from programming to writing, but I had friends who stayed interested in programming. They discovered how much more they could do when they programmed on top of libraries that gave them higher functions. Similarly, in the early days of the commercial Internet, I was reading books on HTML so I could create my own web pages. I then also learned how to configure and manage early wireless networks (ah, the joys of 802.11b!).
Technology developments like these often follow the same path - a new technology emerges and gains momentum, but then others begin creating tools that let additional people participate in the process from a different starting point. For example, in the world of the web, you can now build a website by using templates and tools from WordPress or Squarespace, and download thousands of widgets that run different parts of the site, such as creating an online store.
Pick any area of technology and you’ll see the same pattern. Network management software -- first there were code-based tools, then software packages for individual network components, then came software systems that could manage multiple systems. Mobile phone apps - you can use developer tools to create your own mobile app … sometimes without any programming. Video creation -- you can use your phone not only to shoot the video, but you can edit it right on your phone. Yes, other more complicated tools and apps allow for more professional task developments, but all of them provide easier building blocks for the end result rather than forcing everyone to write code from scratch.
In the robotics space, we’re finally at a point where similar things are happening. Instead of building a new robot from scratch, you can take different components and put them together to create your system. Rover Robotics, for example, does a great job of providing rugged robotics components to developers. So does HEBI Robotics, a spinoff company created by Carnegie Mellon University Robotics professor Howie Choset. He once told me that he sees robotics becoming more and more democratized to a point where more people can create and operate their own robots, rather than relying on someone with a Ph.D.. We saw it in the computer industry, the Internet/Web, and mobile phone app development space, so the road map is there.
This also applies to robotics software. The ROS community is very active in providing updates to the core operating system, and InOrbit’s own robot operations platform provides many higher level functions for robot developers. We’ve discovered that a large majority of robotics operation tasks, no matter the robot, can be modularized, managed and monitored via a cloud-based platform.
For robotics companies, it makes more economic sense to utilize a platform and tools that are already available - whether this is a new lidar component, computer vision sensors, an operating system, or a cloud-based software platform.
There’s another reason why this is important: building things yourself also requires that you maintain and monitor that software yourself. I understand the appeal of building something on your own, whether it’s a website, a mobile application, or a hobby such as building a go-kart or knitting a blanket. I love baking cookies occasionally, but I don’t like the idea of opening a bakery and having the grueling task of providing uninterrupted cookie output in order to keep up with demand.
Sometimes in the excitement of building something, we often forget about the effort required to keep things running in the long term. That’s a big reason why technology tools and platforms are created - this lets other systems and software take care of the nitty gritty. Robotics operations are no exception.
For example, here’s a quick list of different hidden costs and complexities that might pop up during a build-it-yourself scenario:
Often, growing companies often end up “cobbling together some tools” to perform the same functions as everyone else, but this doesn’t scale well in the long term either. Maybe Joe is the person who initially built the tools, but he left and nobody else knows how the code works.
Several years ago, a publishing company I worked for utilized a home-built content management system to manage all of the articles created for its website, and then the person who built and managed the system left the company. It took lots of money and energy for the company to create a new CMS and guess what? They chose an established platform that was cloud-based, because it was easier to customize something via existing and well-trusted tools.
At InOrbit, we are obsessed and focused solely on building, operating and maintaining tools for robot operations. We set out to build a “bakery” that could keep up with the output of robots for companies to meet the growing demands of their customers. Instead of requiring that robot companies “do it all”, we are looking to partner with companies to help them keep their focus on solving the unique challenges for their customers - we’ll take care of the nitty gritty details.
Learn more about the InOrbit platform, and also check out the Robot Operations Group (ROG), a coalition of individuals and companies looking to share best practices to accelerate the adoption of robotics. The group recently posted its Robot Operations Manifesto, a discussion of the operation at scale of large, autonomous robot fleets.