Waiting for the relational database of robotics

2012/11/01 by Leave a comment

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!

Filed under Economics, System Development

“Ask me anything: The answer is a robot! …I’m a roboticist.” -Dr. Rodney Brooks

2012/10/15 by Leave a comment

On Friday, I had the pleasure of attending Rodney Brooks’ first public talk on the Baxter robot, “A New Class of Industrial Robots.”  Although, there wasn’t a great deal of new technical information available beyond what the barrage of press exclusives has already announced, it was a fascinating look at the thought process that went into building the Baxter.  I’ll attempt to share some of the ideas that he shared at Carnegie Mellon to best of my deficient note taking abilities.  You can can also watch the video here.

My general impression is that the Baxter is a real product.  That’s really exciting to see in robotics!  We don’t get true products all that often.  I mean this robot can be used by people who cannot code and don’t know how to do math.  You can use a Baxter at a basic level just by pressing some buttons and moving the Baxter’s arms.  A ‘power user’ might use the menu system to enable (or more likely disable) features that make the Baxter so easy to use.  A forthcoming software development kit will let the robotics engineers tinker if they like.  The overall impression I got however is that the Baxter is a not a fundamental breakthrough so much as a breakthrough product.  It is designed around a specific set of user needs, responds to their preferences, and doesn’t attempt to do everything.  I could see how it might delight people who need a box packed or something sorted.

Another interesting aspect of the Baxter is how it takes an alternative design approach to current industrial robots.  The Baxter focuses on tasks that have some degree of compliance.  Most industrial robots are focused on precision.  It will be interesting to see how these two classes of robots end up interacting, competing, and complementing one another.

ReThink has an ambition to bring back a lot of manufacturing value to the United States.  The idea that much of the drudgery in a factory can be completed at an all in cost of $3/hr definitely puts the economic rationale for taking production offshore into question.  We all know that there are tremendous efficiencies achieve from having production close the large markets and design centers, this will make it possible to further substitute capital for the lowest skill labor and create many more valuable manufacturing jobs in the United States.

“Advanced Manufacturing doesn’t mean manufacturing advanced stuff.”  Dr. Brooks pointed out that although employment in manufacturing has remained stable or declined over the last several decades, the output of American manufacturing has been on a nearly uninterrupted increase.  This has been driven, in part, by a march up the value chain into business to business and complex products.  Dr. Brooks hope that the Baxter will let us look at having

Why isn’t Baxter mobile?  First, Baxter doesn’t need to be mobile to fulfill its intended function and adding mobility probably would add cost and complexity that the customers don’t require.  Baxter can be moved on casters easily by a worker, but it doesn’t need to move on its own for most applications.  Second, Dr. Brooks’ non-compete agreement with iRobot prevented him from working on mobile robotics until recently.  Maybe, we’ll see a mobile Baxter soon.

Finally, I’m really curious to see how the end effector strategy plays out.  ReThink  is going to publish an interface that includes mechanical, electrical, and software specifications.  Currently they provide an end effector that appears to be only a two finger gripper that can be customized for size to some degree.  I’m curious if there will be a lot of end effectors that come out and to what extent the Baxter and ROS become a platform for further innovation in robotics.

The Baxter was designed in conscious analogy to the PC.  Will it usher in a new age of robotics the way the PC did?  From a business perspective will Baxter-type platforms become commoditized and can ReThink retain its edge?   Dr. Brooks was refreshingly humble about the future, but it was clear that he is optimistic and willing to learn more from the market for this disruptive product.

If you’re going to RoboBusiness have fun at the public unveiling of the robot!

Filed under Start-ups, System Development Tagged with , , , , , , , , , , , , , , ,

We need horizontal migration for robotics

2012/10/11 by Leave a comment

Despite the tremendous potential for robotics to transform people’s lives, robotics is not nearly as widespread as information technology.   Traditionally this has been ascribed to the high capital costs of starting a robotics company, but this explanation does not bear scrutiny[i].  More realistic explanations for the lack of proliferation of robotics are that management in most robotics companies cannot effectively match customer development and product development cycles, and robotic solutions are not easily ported from one industry to another.

The lack of synchronization between product and customer development leads to a much slower and more expensive development cycle than in software based businesses. This is not an inherent problem of robotics, but a product of the management practices employed in robotics versus software businesses.  Better management is already leading to falling iteration cycle times.  Many of the leading robotics firms on the West Coast have cycle times that are within a factor of 2 or 3 of software best practice.

The more fundamental problem in robotics is that robotic solutions are not easily ported from one industry to another.  Solutions tend not to be universal but rather quite tailored to specific industries.  As a result, successful robotics firms tend to think of themselves as serving specific industries and being participants in that industry rather than having a core technological competence.

Take the example of Automated Healthcare, one of the first substantial out-of-factory robotics acquisitions.  In the 1990s, it developed a solution for automating pharmacy operations at hospitals to reduce labor and more importantly theft and errors in the pharmacy.  Although, their solutions was loosely based on handling of computer tape media, they did not view themselves as a material handling and storage provider, they came to view themselves as providers of drug distribution solutions—while this is certainly a valid business direction—the acquisition by McKesson ensured that their great success in drug distribution would likely stay in that industry.  I’m not suggesting that McKesson took a technology that was ready to jump industries and didn’t take it across industries.  However, once a technology finds a home in a giant healthcare company it is going to developed to serve the interests of the parent company, not the interests of the robotics community at large.

Contrast this with solution providers for information technology.  Ten years prior to the start of Automated Healthcare, Oracle was being started as a relational database company.  Oracle did not stay fixed on any particular industrial niche, but rather became a database solutions provider to practically every industry that uses databases.  This portability allowed Oracle to grow to a thousand times the size of Automated Healthcare, even though material handling probably generates as much revenue as do relational databases.   The sad part is that the acquisition of Kiva Systems by Amazon indicates that this trend robotics material handling solutions being aligned to particular industries is likely to continue.

ReThink’s Baxter may point at a broadening of robotics to serve several sub-segments of manufacturing.  I hope that Baxter can also become the mail clerk in an office and serve lunch in the cafeteria.  Once we get to that point, our industry will really start to take off.  My suspicion is that there are enabling technologies and infrastructure that we haven’t developed yet to do this.  A truly universal dispatching system and some other key enabling technologies are likely to have to fall in place before this happens.  I hope to devote a future post to what those key enabling technologies and infrastructure pieces are.

Filed under Commentary, Public Companies, Start-ups, System Development

DARPA is about to show the Navy’s shipbuilding plan is bull****

2012/08/16 by 2 Comments

What is a powerful enough word to describe how the Navy’s shipbuilding plan is wasting thousands of man years and hundreds of billions of dollars on prejudices, untested assumptions, and bureaucratic inertia?

Luckily, DARPA is doing exactly what Congress created them to do way back in the Sputnik era: they are creating and protecting against technological surprise.  It would be fantastic if the Navy would jump on board and run phase 7 of this recently awarded DARPA contract.

Source: DARPA

For those of you who do not come from defense, here is my take on the conflict between how the traditional Navy looks at ships and how DARPA and the embattled progressive minority in the Navy look at naval platforms including unmanned naval vessels.

The big, traditional Navy believes–and they have some experiences that gives rise to this belief–that naval ships ought to be flexible, broadly capable, and completely independent assets.  Take a modern Arliegh Burke class destroyer (DDG-51 class), the backbone of the U.S. fleet, as prime example.  It can deploy itself to the theater of operations, maneuver tactically, sense targets, make engagement decisions, engage the target, and retrograde tactically and strategically from the operation.  Moreover these ships can do almost every mission that they might be called on to do.  They are among the most capable ships at anti-air, surface, and anti-submarine warfare.  Additionally, they respond to things like pirates, search and rescue, and humanitarian relief operations.  Sounds pretty cool, right?  And it is.

However, being able to do everything comes with two main drawbacks.  First the ‘jack of all trades, master of none’ phenomenon is far more likely to be true because of design compromises in engineered systems than it is in people.  Second, adding all this capability costs a lot of money.  These destroyers are about $2B a copy and on the order of $1M/day to operate if you add in everything.  This means that we can only have so many and they cannot be everywhere.

DARPA and the progressive faction within the Navy believe that there is a fundamental change at hand in naval warfare.  Looking at how the Army/Air Force team conducts operations and the improvements in automation and communication technologies at sea, the progressives believe that the tradition of having big capital ships that do everything is outdated.

In contrast to the completely capable Navy platforms, Army units often only do one or two things.   Almost no Army units have strategic mobility.  Most can only do one or two things.  Intelligence units often only have the ability to sense. Artillery units only have the ability to do tactical maneuver and fire, but cannot sense.  Transport units move other units and equipment but cannot fire or sense; sometime they cannot even maneuver tactically.  The Army has huge staff units that do nothing but process information and make decisions to keep all these specialist pieces working in coordinated fashion on the battlefield.

DARPA and the naval progressives believe that a similar future is in store for the next globally dominant navy.  Which we hope will be, but does not have to be from the Unites States.  They envision swarms of inexpensive specialist vessels such as the one DARPA is building running around coordinated by a few manned ships.  The components of these fleets would be optimized to do a couple things well, be relatively–we’re talking about defense here–cheap, and be deployed in large numbers.

The reason that this is an urgent argument is that there is wide consensus within the U.S. Navy, across both the traditionalists and the progressives, that the Navy will not be able to meet its strategic obligations to our allies and American political leadership in a decade or two.  This is a ways off, but still within the service life of all the ships commissioned in the last decade.  The traditionalist seem to hope for a larger budget and the chance to ditch some missions (the Obama administration just took steps in this direction in their last budget), while the progressives say that if the Navy is receiving half of global naval spending it should be able to keep all its obligations by changing the way the Navy is organized.

The problem is that the traditionalists point out, correctly, that the progressives have not proved their scheme will work.  Then they say that they cannot cut even one ship or submarine which would build about a hundred of these future systems so that this alternate path can be tested.  It sounds to me like someone’s rice bowl is about to be overturned, and deep down they know it.

This is why DARPA’s ACTUV program is so important.  It puts at least one of these vessels out on the water so that people can see with their own eyes that they work.  They will be able to see the SAIC team turning around the vessel in record time and the ship controlled remotely and also sailing autonomously.  They will get to see that anti-submarine warfare works when done with a robot instead of hundreds of men on ships.  DARPA will start smashing the traditionalists reality, or at least put some big cracks in it.

Three cheers to DARPA for their continued work pushing the United States forward whether we all want to go or not!

Filed under Policy, System Development Tagged with , , , , , , , , , , , , , , , ,

Before we can even have a bubble in robotics…

2012/06/29 by Leave a comment

Our industry needs a better methodology for managing robotics development.

I just a had a great entrepreneurship conversation.  My entrepreneur friend opened my eyes to the possibilities for robotics in an industry, platform space, and application that I had pretty much written off.  The application was using robots to collect data–the simplest and earliest task for any class of robots.  He had taken a fresh look at an industry he knew intimately and seen that there was an opportunity to do something extraordinary and make some money.

This friend is not a robotics expert, but he’s been awakened to the potential in the robotics field.  His big concern and great hesitancy to  jumping into this business is establishing a workable business model.  He sees the potential in the opportunity with the vividness of an insider, but when it comes to the robotics he could use, he sees the immature, expensive junk of an outsider’s eye.  He’s vividly aware of the danger he might not structure the business or implement the technology in such a way as to be the guy who becomes profitable and grows first.  He saw that it would take a lot of money and time just to prove out the concept and that it might take much longer to figure out the right business model.  Meanwhile, his fledgling robotics company would be burning cash at the combined rate of a software, hardware, and an operations company with a direct sales force–not a very pretty proposition.

I didn’t really have anything to say to him on that front other than hackneyed cliches about iterating, pivoting, and the value of moving early.  It really occurs to me that my friend is already following what little we know about how to build a robotics company.  Be a great whatever-you-are first (medical device, logistics solution, toy, etc.) then have it be a robot.   Don’t market the thing as a robot; market it as a new technology solution to a real problem that is worth money to solve.  Be willing it iterate (fail on first attempts).  Go to market with the least capability that you can get paid any money at all for.   All great principles, but it seems like we’re still missing the kind of prescriptions that have developed for software.

The Lean Start-up movement, combined with movements like Agile Development have brought much more rigor to how software development in early stage companies is managed.  More traditional software and engineer models are still applicable to projects where the desired outcome is well known.  In most of my conversations with engineers, it seems like robotics engineering has not reached a similar stage of maturity.  It is difficult for robotics engineers to communicate to business leaders when they will know something that allows for opportunities in business decision making, let alone accurately forecast the true cost of a development job.

The most successful robotics companies do a great job managing development.  However, when you talk to their founders or engineering leads, they are often at a loss to explain what they did differently from failed efforts.  They might explain how they avoided some basic pitfalls–like outsourcing design work–but they often have a very difficult time offering an affirmative description of what they did, why it worked, and how they kept the engineering process and the business on track towards the correct goal.  If robotics is ever going to be the semi-conductors of the 80’s, web of the 90’s, or social and mobile of today, our industry will need to develop a compelling description of how to stay on track towards successful technology and business outcomes.

Filed under Commentary, Start-ups, System Development Tagged with , , , , , , , , , , , , , , ,

Robotics Implementation Manifesto

2012/06/03 by Leave a comment

My prior article in Unmanned Systems, kindly hosted by Deloitte, lays out some of my formative experiences with robotics that give rise to my thoughts about implementation of robotic systems.  I am firmly convinced that we as a robotics community are perpetually tempted to make the same mistakes.  I’d like to propose a draft of an Agile Manifesto style creed for implementing robotics.

My commitment is to help bring about a better world enabled by robotic technology.  From experience using robotic systems, these principles have shown their value.

Redesigning processes and organizations over using the latest technology

Early fielding over continued analysis

Managing risk as a part of operations over engineering out risk

Changing the world and making money  over elegant design

Giving the end customer exactly what they want over maximizing autonomy


Filed under System Development Tagged with , , , , , ,