Waiting for the relational database of robotics

If I were smarter and technically inclined, I would be working on a generalized solution to the problem of material handling.  Intuitively, it sounds really simple.  The basic task is to move objects in accordance with a larger process from one work or storage point to another.  Humans hate it, it is boring, sometimes dangerous, and doesn’t use much of the human’s ability most of the time.  Even more, it satisfies my test of a great robotics application (the Morris Test?):  By having the robot perform steps in a process can you favorably reorganize the larger process to change its key constraints?

Material Handling Robot at a Solar Cell Plant
Image Credit: Energy.gov

Why does it feel like we’re stuck in the 70’s compared to computing?!  What’s going on?  Material handling is to robotics what databases are to computers.  Certainly material handling is not the only application of robotics, but it is definitely one of the leading business applications of robotics, just like data bases in computing.  The need has all kinds of variation and tons of different degrees of depth and similar sorts of need across a huge variety of industries.  However, unlike the relational database, robotic material handling does not transfer to across industrial verticals.

The database industry was like this before the relational database.  Back in before the 80’s, every industry and often specific companies had their own database structure.  The organization was hierarchical and specific to the company or industry (i.e. arbitrary from a programmer’s perspective).   In order to build code or run queries it required elaborate local knowledge of how the data was arranged.  This prevented the transfer of technology between industries and made it difficult to build large software companies since work was largely non-transferable between clients.  The relational database changed all this.  It made it possible to transfer code and innovations between industries, allowed the deployment of programmers across industry lines, and built large dedicated software companies who were not system integrators.

All of the big industrial robotics manufacturers have a stake in material handling for manufacturing applications.  Additionally, there are many systems that we do not call robots by convention, such as optical sorting lines, which truly are robots in this space.  Beyond those solutions, several of the emerging manufacturers have stakes in material handling.  For example, Kiva Systems (Amazon), Seegrid, and Adept all have material handling solutions.  These manufacturers have solutions that serve what is essentially a single industrial niche.  If your environment or the need is different than the original application you’re out of luck.  Unfortunately, robotics manufacturers are not service businesses, a single vertical focus is a bad thing.

My initial take on this problem is that there are three problems that are closely related that all need to get solved jointly.  However, there may be value in solving the problems individually even before we realize the full benefit of the integrated solution.

First, is the problem of sensing, processing, and reacting to the environment to recognize the correct material and move it to the correct place.  My personal take is that this problem is close to solved as a stand alone problem, but that there is still some issues in integration with current solutions to the other problems.

Second, is the problem of interfacing with the larger process.  Robots that are unsupervised are notoriously difficult to synchronize with the larger processes.  I believe teleoperation in medical and field robotics is popular, not because autonomy cannot be programmed to complete the task at hand, but because the autonomy cannot be synchronized with the larger process.  This may have to do more with irrational flesh sacks running the larger process than any fault of the machine, but nonetheless, in integrated processes synchronization is key.  Note that the main differentiation between the robotic material handling systems discussed above is the method that they use to communicate with the larger process.

Third, we have not solved the mechanical generalization issue.  This will be the tough.  There are some things that require a forklift and some things that you cannot get a forklift too.  A forklift operator can get out and walk, but humanoid robots are not the answer.  Beyond revulsion with robotic anthropomorphism, there is no way that the human water bag is optimally configured for just about anything, let alone moving stuff around.  I was pretty unhappy carrying half my body weight in the Army, but for a machine that just pathetic.  Even if this problem could be generalized into a few basic types, that would go allowing the first two kinds of solutions to control the hardware.  The market as much as engineering may help solve this problem.  It will take deep pocketed speculators and market organizers to get this to happen though.

I don’t have a brilliant technical idea.  Further, this market probably will not have the same degree of network effects that power the database market (however there will be more winners).  That said, it seems like this problem has to be able to be generalized in a way that has previously eluded us.   When it does, hallelujah, we will finally have a piece of robotics technology infrastructure that will serve widespread adoption of a host of robotic applications.   The Jetsons will finally start to look backward!