Monthly Archives: April 2016

Another Brick From The (Research) Wall

In every research project, you eventually run into a wall.  The wall can take many specific forms, but in general it represents a point at which it seems like your idea can’t work.  There are at least four possible responses.

First, you can walk away.  You can abandon your approach to the problem, backtrack until you find an alternate path, and follow that path to its wall.

Second, you can keep battering at it until it gives way.  This only works if the wall isn’t a function of fundamental mechanisms of physics or mathematics.  Problems that are a function of processing power or available memory can be susceptible to this approach — if you wait long enough or have enough money, someone will build a computer capable of implementing your idea.  Sometimes the brute force approach is sufficient.

Third, you can revolve the problem in your mind, looking at it from all sides.  You can investigate other, apparently unrelated fields, you can attend talks on tangentially related work, and then you can come back to the problem and revolve it in your mind some more.  You can go talk to the people who will be using it, to see if there are any underlying assumptions you’ve missed, or something you’ve misunderstood.  And eventually you’ll find a path through the brambles around the side of the wall and come out on the other side.  You haven’t gained any understanding of the wall itself, but you have managed to find a new way to think about the problem, and you are likely to end up with an effective solution.  This is what happened in robotics in the 1980s.

Until that point, the software side of robotics was focused primarily on artificial intelligence approaches.  When they tried to make their robot operate even in a relatively simple environment, they hit a wall in terms of the required processor power because their interpretation of the problem assumed a high degree of object recognition and understanding of the environment.  Brooks’ key insight was that it is not necessary to understand the world in order to function within it.  The robot doesn’t need to differentiate between tables and chairs in order to avoid them.  It only needs to differentiate between floor and not-floor.  He sidestepped the wall (capturing and interpreting the complexity of the environment) and found a path through the brambles (abstracting the complexity of the world into only the things the robot needs to know).

Fourth, you can disassemble the wall, brick by brick, until you understand it.  This is the most theoretically sound approach, and often results in the cleanest solutions.

After the Wright brothers side-stepped their wall by discovering that wings needed to be rounded instead of sharp on the leading edge, engineers disassembled the leading-edge-shape wall until they thoroughly understood it, leading to modern aerodynamics.

The ViCoRob lab at the University of Girona ran into the wall of environmental factors when they attempted to stitch together imagery of the same undersea environment at different times.  Instead of hitting the problem with more and more computer time, or sidestepping the problem by mandating specific vehicle behaviors, they disassembled the wall into many individual image processing elements, each dealing with a specific confounding factor.  They compensated for brightness variation due to light placement, they compensated for particulates in the water, they compensated for chromatic variation as a function of distance, they compensated for bright and dark spots caused by light refracting through ripples on the surface, they compensated for vehicle motion estimate errors, and they compensated for scaling factors between images.  They took apart the wall, understanding it as they went, and were able to create stunningly beautiful images of large swaths of sea floor.  This approach is generally expensive and time-consuming.

What to do when you hit a wall is obviously going to be a function of many factors — how much time you have, how complex the problem is, how much money and hardware you have, and how you intuitively approach problems.  Some people will naturally gravitate towards each of these approaches, and an approach you’re good at is likely to be more effective for you than an approach you’re not good at.  It is, however, worthwhile to attain at least limited skill in each approach, if only so that you are aware of alternatives when your preferred approach fails.