Skip to content

Action Learning – Rethinking Product Development in Robotics

October 4, 2011

Over the last 20 years, robotics has become primarily a software discipline. Even manipulator researchers (i.e. the guys who design robotic arms) will tell you that the primary advances in their research comes from developing more sophisticated software algorithms that provide finer and finer degrees of control for robotic arms and hands. While there is still plenty of mechanical and electrical engineering to be done, the research horizon in robotics now advances on the basis of our ability to create human-like intelligence in software.

People regularly ask me, ‘Well, if robotics is now just software, then where’s the robot?’ The world is still clinging fast to fictional  and outdated  notions of robotics. It’s a fundamental hurdle that robotics professionals regularly face when speaking outside of the research community.

For many years, Star Wars presented the imagery most commonly associated with robotics: intelligent mechanical beings – literary characters that continue to be featured in entertainment productions to this day. Movies like Transformers are but the latest and probably not the last instance of our exploration of human-like robots. In the real-world robotics community, anthropomorphic (i.e. human-like) robotics researchers concentrate on building robots that look like and mimic humans. It’s a very small, but very well publicized portion of our community, in part because reporters are able to make the connection between this research niche and immensely popular science fiction films.

Anthropomorphic robots stem from a literary invention in which the author explores what it truly means to be human by comparing and contrasting human beings with robots. The robot-concept (as opposed to actual robots) enables us to examine human feelings and emotions: hope, kindness, charity, compassion, love… all of the ingredients of the human soul… by showing us mechanical versions of ourselves that lack those very qualities. We learn what we are by seeing what robots can never be.

The problem, of course, is that literary concepts do not necessarily have economic value beyond ticket sales. The advances required in robotics research to reach some future point where truly human-emulating robotic systems exist are many decades and many billions of dollars away. And if we did create such robotic systems, then what unmet market needs would they fulfill? I’m unaware of any economic problems for which incredibly expensive anthropomorphic robots are the solution… intergalactic droid armies notwithstanding.

So perhaps you see the marketing problem that our research community faces. The most common and indelible images of our work are entirely fictional and, more importantly, very unlikely to ever become fact for the very simple reason that they make little economic sense.

What to do… what to do… Let us begin by setting the record straight.

The reality of the robotics community is that our research has expanded far beyond building… well, robots… to focus on much more pragmatic ends and purposes. Rather than building artificial humans, our objective has been to extend human capabilities and human presence.

Over the last twenty five years a great deal of Federal funding has been poured into a wide variety of robotics research projects, many of which supported the needs for advances in defense and space exploration, two arenas where hostile environments often preclude human intervention. Funding eventually expanded beyond defense and space and into sectors including mining, manufacturing, cargo handling, and many others. In these research programs, robotic scientists found ways to build so-called autonomous robotic machines, i.e. vehicles that could fly, drive, or otherwise navigate without human control. This new generation of so-called Field Robots  became increasingly capable in the late 90’s and into the new millennium.

Achieving the goal of intelligent, independent mobile machines fostered a wholesale collaboration between computer science and robotics. Robotics scientists borrowed heavily from computer science, using computer vision technologies to enable field robots to see, artificial intelligence technologies to enable field robots to think, and machine learning technologies to help field robots to learn. AI gave way to more robust and specialized technologies like route planning, which in turn influenced computer science research. The whole became greater than the sum of the parts.

These research programs also slowly dented our concepts of what constitutes a robot. Field robotics is based upon the notion that we can take any existing machine, whether a mining machine, a military vehicle, or a forklift, and convert it into an intelligent mobile robot. If the robotic machine looks pretty much like the non-robotic machine, then suddenly form starts to matter less and less… intelligence makes it a robot, whether it happens to look like a robot or not.

The intelligence lives in the software. The software is the robot.

My own research took yet a further step. The premise of field robotics is that certain environments preclude human intervention. Battlefields, deep space, deep oceans, and dangerous coal mines are all places that human health and survivability is called into question. But as we worked in applications that were decidedly less dangerous, such as cargo and materials handling, the value proposition began to move from saving human lives to generating economic value.

I began to question the way we thought about robotics. We really had focused on extending human physical presence, i.e. sending robots into places that people just could not go. But, I also noted that generating economic value in modern industries is often more closely associated with building more efficient management practices and organization than focusing on physical infrastructure alone. Robotics had certainly already contributed to significant production efficiency improvements in manufacturing and process industries. We are all familiar with traditional manufacturing robots. The automotive industry adopted spot welding and painting robots to greatly improve manufacturing costs and quality. In the 1980’s and 1990’s a new generation of chip manufacturing robots  made microprocessor manufacturing cheap enough to fuel the PC revolution.

My  theory was that robotics could make significant contributions to management practices  by extending human cognitive capabilities. I am specifically intrigued by how humans manage data-intensive processes, where outcomes and performance are closely tied to the need for fast, accurate decisions made under conditions of significant uncertainty.

In 2001, I co-founded a company in Pittsburgh to develop a new type of robotic production management system for quick-service restaurants. We developed a system called HyperActive Bob (you can Google the name and read about it in detail) that managed grill chefs in fast-food kitchens. We mounted small, cheap cameras on the restaurant’s roof and used military grade computer vision technologies to track the people and cars as they headed toward the restaurant building. We used this information to feed a robotic planning system, so that it accurately generated a demand forecast focusing on the next 4-5 minutes, i.e. the amount of time it would take people to enter the building and reach an ordering terminal.

When we started the company, I went to work at a McDonald’s for about six months as a grill chef (yes, I actually did) so that I could learn the details of fast food production. It turns out that you can make any product in under six minutes, so an accurate demand forecast five minutes in the future meant that you could produce just about anything hot and fresh and have it ready for the customer when they placed the order. This ability to synchronize production with actual demand was revolutionary for this industry and had all of the expected economic benefits, hotter fresher product, faster service as product run-outs were eliminated, and less food wasted due to overproduction.

HyperActive Bob proved a significant point in the robotics community, that robotics technologies could be used to manage large numbers of human workers to achieve much better cost-performance of production. It also did away completely with the question of a robot’s form. When visitors would come to one of our restaurants and ask, “Where’s the robot?” We would always respond, “The restaurant is the robot!”

Modern robotics enable human-like intelligence to be embedded into virtually any object. Robots no longer need to look like what we used to call “robots”. They are just intelligent forms of everyday objects like cars, restaurants, and in the case of our most recent company (BluPanda)… hospital emergency rooms.

And now, with all of that as prologue… Isn’t robotics just software?

That’s rather like asking, “Isn’t a house just wood?” Asking whether robotics is software confuses the product with the building materials. Software is fundamentally a method of encoding computer executable knowledge. Robotics is the science of creating and embedding human-like intelligence into any object. Robotics is encoded into software, but software engineering is, rightfully, its own independent discipline, applied to many and various other types of software production.

While robotics has made enormous research progress in the last few decades, it is still a generally pre-commercial body of work. As such, the processes for cost-effectively developing and delivering robotics software products are still very much in flux. I would claim that some of the best work in this field has been done and is being done by Barbara Simard, a Canadian software engineer with whom I’ve worked for the past several years.

Years ago, Barbara noted that the product delivery process (i.e. software development, installation, training, and support) was significantly more complex for robotics software than, for example, traditional packaged software. You probably noticed the same thing in the descriptions of the various robotics systems earlier in the text. With robotics, we are forced to deal with the development, integration, and delivery of half a dozen software systems in parallel. Computer vision; AI planning, scheduling, and control; several different databases, each with reporting interfaces; potentially multiple human robotic interfaces; and possibly interfaces to other legacy computer systems must all be developed such that they together constitute a complete robotic system.

Barbara developed a management process around the specification, development, and delivery of this new class of robotics software. Her methods leverage many existing software engineering concepts, while focusing on decoupling the management of data-intense development components such as computer vision and AI sub-systems, from more straight forward sub-systems such as databases.

Her work represents a very good first step toward the professional management of product development and delivery for the emerging robotics software industry. But it isn’t enough. We now need to take that approach and extend it to include cost analysis and cost prediction capabilities so that we can better understand how to drive margin from current operations and make optimal choices to cost-effectively scale as we grow our organization.

This is where Action Learning becomes of significant potential impact to a company like ours. The concept is deceptively simple, use the attendee (me) to engage the host company (BluPanda) in the learning process in ways that create impact. There appear to be two keys to making Action Learning truly impactful: (i) finding an engagement model that actually works, and (ii) choosing specific host company problems where engagement with MIT students and faculty could legitimately have enormous impact. Under our theory, Action Learning requires that we bring a Big Hairy Audacious Goal (to borrow from Jim Collins) and find a way to apply relevant theory learned at MIT to the solution of that BHAG at the host company.

We’re working on that as we speak and we intend to share our results with the Sloan community in hopes that we can compare and contrast what works for our company with what works for other companies.

Our approach to Action Learning begins with actively selecting an important problem. We selected production scaling as it has a significant impact on both our revenue generation capacity (i.e. the total number of hospital units that BluPanda can address in a year) and our profit margin (i.e. the costs of development, installation, etc.). We also noted that software development processes in the robotics industry are complex and overwhelmingly manually managed, indicating a significant opportunity to control costs through learning and through the introduction of labor saving technologies. Finally, we noted that economics of both scope and scale have not been well-explored for this industry, indicating the potential to harness one or both, should that opportunity exist. All of these potential effects argue that a well conceived solution to the problem could have a significant positive impact for BluPanda.

We next focused on developing an effective knowledge transfer process. Asking Barbara to simply complete the same coursework that I am doing was obviously inefficient. We’ve decided to trying working as a knowledge transfer team, where Barbara explores the production scaling problem internally with other key people from BluPanda, while I search for new knowledge, potential solutions, analogous cases, and other relevant information at Sloan.

To formalize the learning process, Barbara debriefs me on all of the internally identified production scaling problems so that I can target specific Sloan insights to address those problems. But, rather than simply debriefing Barbara about what I’ve learned at Sloan, I am writing a production scaling plan, based on what I’ve learned. The document outlines a theoretical solution, but is missing BluPanda specific data. Barbara will take that plan outline and work with others at BluPanda to complete the solution plan, and then implement it in appropriate stages.

Forming this Action Learning team at BluPanda fundamentally changes my relationship to MIT Sloan. I’m not just studying, doing homework, or attending class. In fact, it is no longer  just  “microeconomics” when you walk into the class room with an objective like restructuring the costs of product development for an emerging industry. The implications are enormous…

What I hope to see and, honestly, what I now expect to see is that Action Learning becomes an extension of BluPanda’s existing management processes. It will be another resource or asset of the company whose impact shows up in accelerated earnings, due to the increased rate of efficiency generation inside our company. We also expect to see a new canonical formulation of product development appropriate for the robotics software industry emerge from our engagements with MIT. Given the infancy of this new industry and the general absence of a strong theoretical framework within which to consider the management of robotics software development, the chance for such an advancement is strong.

While it is still very early in the MIT EMBA program, it is never too early to formulate a strategy to seek to maximize the impact that this program could have on our company and our industry. We’re going to try our hardest to make Action Learning work for us. We’ll share our results as the program continues.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s