Random Night Thoughts

COFFEE, in small amounts, and in the morning after waking, is a pleasant way to start a day. Tonight, after attending the Mass of the Immaculate Conception of Mary, and it being a very windy and cool night, tempted me to drink some more coffee with dinner. A lot more.

Now I feel like one of those intellectuals in the coffee houses of Europe during the 17^th century, with my mind whirring and no chance of getting any sleep, at least for a while. So this typing is not guaranteed to be interesting, relevant, or coherent.

Years ago, I had a friend Dave who was an aeronautical engineer, and we spent hours discussing aircraft design, a subject that always had a great appeal to me. One of our discussions was whether or not it was possible to design an electric powered aircraft, and we used as our target design the classic P-51 Mustang fighter from World War II, which was probably the greatest of propeller-driven aircraft. After drinking much coffee, we decided that yes, it was possible, but only if we used a very large capacitor to store the electricity, and this capacitor so happened to have about the same size and weight as the Mustang's impressive engine, which it would replace. So many seemingly good ideas never see the light of day, and we determined that this particular giant capacitor would explode violently with only the smallest amount of damage. Or, it could explode for no obvious reason.

Dave and I also discussed the design of unmanned aircraft. He reasoned that the commercial market for such things would be large, particularly for aerial photography, from surveying to news traffic reports, and so figured that such aircraft would be a valuable product in the future. Designing such a beast is easy, he said, because you don't have to make human accommodations, which complicates the layout and systems of the aircraft, and which also severely limits its performance characteristics. It is the control of such aircraft which is problematic. As I was the software guy, I worked up a general system design.

As it so happens, this also is easy, as long as you define and implement the system correctly. Autonomous aircraft are robots, and the design of robotic control algorithms was of great scientific interest since the late 1940s. But this research harvested little fruit and was largely abandoned by the 1960s, not to be taken up again until a couple decades later. A problem was that computers weren't fast enough. A bigger problem, not noticed at the time, was that the computer control programs were so controlling — you had one master control program attempting to do everything at once, which made these robots so slow as to be nearly unusable. Computer software in those days was kind of like the presidency of Lyndon Johnson — extreme micromanagement, with one master program trying to tell each component what to do at every moment. A dominant programming paradigm used in those days was called Master-Slave architecture; I would think that the name itself ought to have given its advocates some pause!

By the 1970s, a far more egalitarian-sounding paradigm, called Peer-to-Peer architecture, made its debut, and eventually became the foundation of the Internet. But a crucial design choice for this kind of architecture, called layering, ensured its success. Layering, implemented wisely, is like a good boss who hires excellent workers: he lets them do their job without interference, and the workers only report back upon completion of their tasks or if there is a problem they can't solve themselves. For example, your web browser sits at the very top of the Internet chain of command: you tell it to get you a web page, and the underlying layers do their job, which is no business of yours or of your web browser. No micromanagement. And because everything works according to standard interfaces, you can upgrade one component or another without changing the rest of the system, like a boss can get a new subordinate, or a subordinate can get a new boss.

But intolerable bosses still exist, and the invention of cell phones, laptop computers, and email makes a micromanaging superior a dreadful burden 24 hours a day, 7 days a week, even if you are on vacation far away. And of course there are dreadful workers, who can't and won't do their job. But that is a topic for another article.

So this is the key to my old robot airplane: you have good workers and good bosses. The workers do their job very well, and the boss doesn't interfere in their work unless something goes wrong or if there is something new to do, and all these work together in parallel, with a minimum number of meetings and status reports. For example, a low-level program in my robot plane would keep, say, an aileron fixed at a certain position called for by its boss, no matter what happens, and to the best of its ability; if this isn't possible due to equipment failure or other condition, it reports the problem back to its boss.  The boss program would determine what angle to set the aileron, but wouldn't tell the worker how to do it. The boss who decides which angles to set the control surfaces of the aircraft has its own boss, who decides the direction and altitude of the aircraft, but the bigger boss does not micromanage the details of how to do it. And there is an even bigger boss, who determines the general flight plan of the aircraft, which is ultimately controlled by the person who decides what he wants the aircraft to do, without bothering with the details. So the entire control system of the aircraft is a hierarchical series of layers, loosely connected to each other, each doing its job well, and each minding its own business.

'Minding its own business' is critical. A nosy boss is a bottleneck, as robotics researchers discovered back in the '60s and which countless workers discover every day. But this also means that the workers must be well trained and able to work very well independently. A good boss needs to know the limitations of his workers, as a good worker learns to ignore certain directives. If the boss program decides that an aileron needs to be set at 180 degrees, and if the worker knows this is impossible, it ought to strongly respond "no can do", and so the problem gets pushed up to the boss's boss, which is far better than a intimidated and submissive worker who agrees to an impossible task, only to fail sometime down the road. Likewise, if the boss program decides the left aileron needs to be set to 5 degrees, and this doesn't happen, the boss needs to bypass that component and quickly reassign the other control surfaces to compensate. 

Nobody likes a boss who is constantly breathing down his neck, which both irritates the worker and wastes the time of the boss. Likewise, each layer in my robot program must trust that the job gets done in a reasonable amount of time: the boss makes a directive to a particular subordinate, and then goes off and does something else, not waiting for completion. Likewise, a subordinate can waste his own time and that of his boss by reporting back too frequently, and especially by asking for guidance. That ultimately was the problem with the old robots of the 1960s: the master control program spent too much time checking and waiting on things that were irrelevant. As it so happens, computers back in those days actually were almost fast enough to do the job, but the programs running on them were not clever enough to know what was important.

The beauty of this system is that each task is well-defined and easy to implement, and individual programmers can work on each task largely independently: only the interface between tasks or layers needs to be designed in cooperation with others. The systems designer must strongly resist any demand to allow higher level functions to interfere with what goes on down below; for this means that the big boss programs must be not only experts in their own line of duty, but that of their subordinates also, increasing complexity and the possibility of erratic behavior or even failure. The same goes for lower layers: the program that ensures that the airplane's landing gear is down for a landing, and fails to do so, cannot have the excuse that it was busy calculating something else. Similarly, a good bishop will assign his priests to parishes, but will not schedule weddings at each church, giving him more time to write responses to angry letters from the people. A good hierarchical robot control system will allow for easy replacement and upgrades of its various layers, like a diocese may get a new bishop or newly ordained priests, with nothing much changing.

We never built our robot plane, but we had a great deal of fun thinking about it.

Have a good night!