Is anyone surprised the FAA is delaying UAS test site selection indefinitely?

I have to agree completely with the sentiments of Congressman Austria on this issue. The FAA is just dragging its feet.  The point of the test sites is to solve the issues of safety and privacy.  If these issues were completely worked out, we wouldn’t need test sites–do not pass go, do not collect more appropriations, proceed directly to airspace integration.

The point of the test sites is to work on these issues and give the general, civil, and commercial aviation community time to come to grips that some new craft are going to be joining their previously exclusive community.  Delaying the test site selection is the complete wrong approach.  The right approach is to begin testing–as most other developed countries already have.

How is privacy even the FAA’s jurisdiction?  In all seriousness, I hope that whatever regulations apply to UAS apply to cellphones.  I’m a lot more likely to have my privacy invaded through cell phone than through unmanned aircraft.

Even the Navy Has Market Risk (they just call it something else)

My long awaited article in Proceedings just came out!  You might not have been waiting for it, but I have!  I started the article over a year ago.   It was a slog.  I can’t quite believe that I’m now signing up to publish an academic paper on the capital structure of robotics companies.

Image Credit: DTIC

In summary, the U.S. Navy is making a terrible mistake in it unmanned maritime vehicle policy.  The Navy is basically designing all their programs for robots that swim in the water to fail.  The technology exists today to make really cool, useful maritime robots.  However, the technology does not exist today to build the Navy’s dream robots.  (Especially since the Navy’s secret dream is to need more manned ships of the type we have today.)  Essentially, the Navy is pulling the equivalent of refusing to look at Roomba because it is not Rosie.

I’ll try and expand upon some of the key ideas from the paper over the next couple of weeks.  Readers of this blog will be familiar with the core ideas which have been translated from business to military jargon.  The Navy has to figure out what it needs its robots to do and the ecosystem around them at the same time that it is working on building the systems.  That’s what we in business call market risk!  The Navy needs to take some steps to reduce that risk.  Although the defense acquisition process stacks the deck against the Navy and it has some truly heroic individuals working on the problem, as an institution, the Navy really isn’t putting forth an adequate showing considering we’re talking about the institution’s future.

As a patriotic citizen of the United States–and as someone who understands that the U.S. Navy as much any institution on the planet has guaranteed an era of global trade, peace, and freedom–I really want our Navy to have a bright future.  Everyone who studies the naval budget–horses and bayonets snark aside–knows that the Navy isn’t on a sustainable path.  Robotics offer the Navy a future even brighter than the past.  To have this future, the Navy will have to learn how to manage and implement this technology.  It won’t be easy, but there are solid principles for doing this.


Also, readers, I want to thank you.  Thank you for being patient with a terrible layout, a casual tone, mixed quantitative/qualitative arguments, poor citation, and irregular tables. I do want you to know that you are reading a blog whose underlying ideas are good enough to go through peer review.  I, for one, commend you for that.  I hope that the ideas have a practical impact in advancing robotics that improve the world.  Now, stop indulging my self-congratulation and get back to putting more robots into the world!

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:

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!