Today I’m happy to announce four new members have joined the InOrbit Board of Advisors, representing outstanding expertise in the field of robotics, cloud technology, supply chain management and venture funding. Our advisors help InOrbit accelerate our vision to help companies scale their robotic fleets through our cloud-based robot operations (RobOps) platform.

The four new advisors represent a wealth of experience across different fields:

Martin Hitch, one of the co-founders of BossaNova Robotics, who helped the company pivot from consumer products to service robotics. During his tenure at Bossa Nova, he raised more than $40 million in venture investment.


Patricio Echague, co-founder and CTO at Split.io, is an entrepreneur and engineer passionate about data and high-performance systems. At Split Software, he’s changing the way software companies release features and add value to their customers. He was also part of the engineering founding team at RelateIQ, which was acquired by Salesforce.

Developing modern information technology solutions of any reasonable complexity will require that you integrate existing technologies at some point during the system creation process. Whether you’re just starting out or you’re looking to scale, you will face the decision of using an existing piece of software or building your own. The level of sophistication needed today can only be attained by building on top of other components, such as libraries, platforms or services. Just like in the old Western, experiences with these services can be good, bad, or ugly, depending on the providers you choose.

Even as InOrbit is building a platform to make it easier for robotics companies to focus on their own secret sauce, our software engineers have faced these decisions. In the course of our development, we have chosen services and components along the way. By choosing this path, we’ve also been able to add our own expertise, allowing us to augment those services to create a better platform for our customers.

Along the way, we’ve also had some mixed results that we’d like to share with you. We hope this lets you avoid some of the mistakes we made, as a way to help you speed up your own development process. 

And should you choose to use the InOrbit platform yourself, we expect to be held to the highest standard.

The end of October brings out spooky and scary creatures of the night during Halloween festivities, but here at InOrbit we deal with ghosts, zombies and vampires almost every day. The different fantasy creatures give us a quick shorthand to the different artifact types we have available in our fleet simulation, the first of its kind.

In fact, these creatures are affectionately known as the “Hooli Robotics Horror Story Demo Fleet”, which operate as part of our fictional company, Hooli Robotics. Aside from the playful (scary?) names, there’s a deeper technical reason for all of this. There are many options, both open source and proprietary, for simulating an individual robot operating in a given environment. There are also solutions of creating variations, known as domain randomization, often used to accelerate reinforcement learning. However, what we found was missing was a way to simulate large fleets of robots, and to do that in a way that is both scalable and sustainable.

Most of our customers have enjoyed the Hooli fleet. While customers can’t directly interact with our spooky subjects (yet, but let us know if you want to meet them), in the spirit of the upcoming holiday, we'd like to give you a peek behind the curtain of our internal technology. Read on, if you dare, to learn more about the different types of spookiness that roams the hallways of Hooli…

Detecting insights from 3.8 million hours of robot monitoring data is elementary

For the last several years, we’ve all heard the quotes about data and information - it’s “the new oil”, it’s “the new science”, and that Big Data “holds all the answers.” Others have famously stated that “every company will eventually be in the data business,” or the real goal is to “turn data into information, and information into insight.”

But one of the best comments about data comes from our favorite fictional detective, Sherlock Holmes, who said (via Arthur Conan Doyle), “Never theorize before you have data. Invariably, you end up twisting facts to suit theories instead of theories to suit facts.”

As the world continues to battle the COVID-19 pandemic with varying degrees of success, the way we shop for groceries, clothes and other items has changed dramatically. Even as brick-and-mortar stores re-open for foot traffic, shoppers continue to buy items online, or shift their pickup to “buy online, pick up in store” and contact-free, curbside delivery.

For example, at a local Target near us, they’ve replaced the snack bar area with rows of shelves to store these pickup-in-store orders, but unfortunately the speed and efficiency of receiving your orders is not an improvement versus just walking through the store yourself and grabbing what you need on your “Target run.”

The problem lies in the method that physical stores are taking in filling orders - it’s the same that many distribution centers and warehouses employed when they didn’t have robots (or those warehouses that have yet to deploy them). A store receives an order, sending an associate out into the store to fill the order with a cart. The associate then returns to the front, where the items are placed on a shelf waiting for the customer to arrive.

At InOrbit, we’ve partnered with many robotics companies to advance the software tools and processes that have helped them scale to hundreds of robots, and eventually to thousands of robots.

Robots and Humans are Alike - We All Fail

At InOrbit, our mission is to accelerate the adoption of robotics at scale. After talking to 100+ robotics companies, from startups to companies with billions of dollars in revenue, with all types of autonomous robots, we’ve reached an inescapable conclusion: they will all fail.

We’re not saying the companies will go out of business (although, sadly, many have in recent years). Rather, every robot will experience failures, in some cases multiple times per day or per hour. While a few of these failures may be catastrophic (and occasionally hilarious), like steering into a pond, getting stuck next to a trash can, or suddenly catching on fire, many errors are recoverable. The most frequent failures are what we call autonomy exceptions, where a robot finds itself in a situation that falls just outside its operating parameters.

The term manifesto is usually reserved for political or artistic declarations around the intentions, motives or views of an individual or group, but in recent years the technology world has seen its share of manifestos from various groups.

Explanation of a new technology, term, or the goals of such a group are seen in manifestos such as the GNU Manifesto (1985), The Hacker Manifesto (1986), The Third Manifesto (1995), and The Agile Manifesto (2001), which fundamentally changed how software is built.

It is in that spirit that we founded the Robot Operations Group (ROG - pronounced “rogue”) with a group of robotics leaders and have just released the Robot Operations Manifesto. The ROG’s mission is to further the creation of best practices for robot operations at scale. We felt that, while there are already many places to learn about how to build a robot, when it comes to the challenges that emerge when growing from 50 to 5,000 robots, there just wasn’t a venue for discussion and learning.

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.

Today, InOrbit announced our latest funding news, with $2.6 million in seed round funding to help us on our goal to support 1 million robots that will positively impact the lives of 1 billion people.

We started InOrbit more than 2 years ago to help accelerate the adoption of robotics at scale. At the time, there were no good platforms to manage fleets of robots in the field, and most companies had to cobble together tools that were hard to maintain, and often didn’t work as their fleet grew.