Date: Thu, 23 Feb 2006 23:15:31 -0600 (CST) Subject: software mental block is gone X-UID: 138 Content-Type: APPLICATION/OCTET-STREAM; NAME="softarch.ver2.png" The minimal system architecture for remote driving and data collection is diagrammed. I had been mentally blocked for the last week. It came together over the last few days in the subconscious and rose to awareness this morning. My objectives in design is twofold. 1. No throwaway design or code - the first designs are correct. This is rare but possible. For instance, the A4 Skyhawk military plane went to production in essentially the same way it was originally designed by Ed Heinemann. The first design was dead on. (Here's a page about Heinemann and the A4 - http://www.skyhawk.org/2B/heinemann.htm ) With the robot hardware, I threw out the first versions of both the vehicle platform and the motor control electronics. In hindsight, this effectively doubled the amount of time it took to design the robot. Had I pursued the correct path from the start, it would have taken six months instead of one year to design and build it. Knowing what I know now, I could build the same robot in three months. But that is unreasonable as I had to learn while building. 2. Fully client-server microkernel architecture - no monolithic design. During lunch, I took along a tutorial book about QNX-Neutrino. While I am using Linux, there is much design wisdom in this operating system design. It is a hard RTOS (real time operating system) with a very clean architecture. Linux has some hard RTOS extensions but they are ugly so I never considered them seriously. Note that Stanford's robot ran Linux on Pentium blades for the DARPA Grand Challenge so Linux is fundamentally good enough for a proof of concept prototype. However, it would not be good enough for mission critical operation in which people could die should the kernel not preempt in time. I am very excited now, again. This seems strange to say but I will even posit that this robot is not a very hard problem. The idea of "Mission X" is comparitively simple. About six years ago, I saw the Eco-Challenge on television and then got it into my head that I had to do something very hard too. I was cycling a lot at the time (a 100 mile week was not unusual). So I decided I would cycle from Dallas to Austin in one day on a mountain bike. It seemed very difficult until at some point I realized that it wasn't. From Dallas to San Antonio would be difficult to do. But 250 miles is not very far to cover in one stretch on a bicycle. A guy in university who would mix wrestling with powerlifting told me once that he believed much of strength was psychological. People who have no mental blocks can release everything they are capable of which is often more than people with better genetics will do. Control theory is a marvelous subject for the matrix theory and numerical linear algebra crowd. It is a shame that so many are, in my belief, ignorant of it. I was never exposed to it in school. But it is a fascinating and deep subject. A few months ago, I picked up an older book on linear control theory. It appeared more mathematical but still at an undergraduate level. This is typically my kind of text. However, it was the wrong book. The reason is that it was too old so emphasized the frequency domain and ignored the time domain. The difference is the invention of the microprocessor in the 1970s. This revolutionized digital computation. It allows solving numerical linear algebra problems in real time at a low cost in a small package small with low power requirements. So it allows closed loop control systems which depend on numerical solutions in real time to maintain stability. This is a modern feedback control system. Older books document the time before this was practical. Systems had to use analogue methods to find stability and could not rely on solving differential equations in real time numerically. So I picked up another book at the store, this time the right one. My good, out of print, electronics book was written by MIT professors. This control theory book is written by Stanford professors. All of the modern control theory books treated digital control systems. It's a clear break from the past, just like the time before the IC and after in electronics. Design completely changes with such technology developments. The major philosophical difference in control systems is how everything must work robustly in real time. All of the computer science and mathematics I have taken in school never treated this. It's a very different way of thinking. For instance, around the same time I cycled to Austin, I was also writing a networked Mortal Kombat clone with reliable UDP (datagrams) socket communications. I read the id people's writings about the difficulty of getting the Quake games to work well over networks with lots of lag. Anyway, when you have to deal with unreliable communications, it naturally leads to looser coupling between client and server as well as a more control theory outlook. Stability is achieved by continually converging towards the optimal estimate of true state, which must always be unknown. The client/server protocol and event loops are designed around this. It's very different from what I've seen in my day jobs working with enterprise software. Business software needs to be accurate and consistent. It can be slow or even fail so long as it doesn't happen too often. So the design viewpoint is completely different. Back to the diagram in the attached PNG - I've found that laptop displays are just about unreadable outdoors. I need a reflective LCD or unpolarized plasma display with glare filter. Neither of these are made anymore. I think that military laptops use transreflective LCDs which are a good compromise considering all conditions. From a readability perspective, probably plasma with polarized glare filter would be best. Anyway, this available technology limitation leads to avoiding any reliance on video. All status for remote operation should be audio. Ergonomically and logistically this is convenient. When prepping and deploying the robot, I have more equipment than I can carry. But if I can put a laptop in a rucksack, have the radio antenna on a whip over my head (side-fire so hopefully the mobile 100 mW does not give me brain cancer), the GPS on top of the pack, a gamepad slung from a ruck strap for input, earbuds to hear output and finally a digital camera around my neck, then my hands are free to carry and work on the robot. I can carry everything with me in one go. Right now, I have to lug multiple pieces of equipment back and forth.