Date: Sat, 4 Mar 2006 23:23:27 -0600 (CST) Subject: numerical control software X-UID: 141 A guy at the Dallas robot club said that he didn't consider anything that can run Linux to be truly embedded. I can understand this sentiment. But AMD is now marketing the Opteron processors to the embedded market. One application area identified is mobile military robots. The DARPA Grand Challenge teams seem to fall into three different computing platform categories. 1. Low specification, e.g. mini-ITX with VIA C3s 2. Pentium M blades 3. Dual CPU, dual core Opterons Note that additional processors and FPGAs are devoted to vehicle control, sensor processing, networking, etc. But core processing is done in compute server class hardware with power consumption low enough for the vehicle alternator to power, several hundred watts to low kilowatts being typical. The Berkeley autonomous motorcycle is very interesting as it was both the smallest robot in the competition and does not use a SICK LIDAR system like most of the other competitors. It relies exclusively on vision that nominally runs at 4 Hz. They also use a localization system that combines both the US DOD GPS and Russian GLONASS with differential correction. What's cool is that they give some history of the control system. One guy wrote a fuzzy logic control system that worked well for speeds between 3 mph to 6 mph. But it was hand-written and tuned so couldn't be extended above 6 mph. So then they implemented a more conventional PID feedback system (proportional/integral/derivative). This worked and was refined to include dynamic stochastic modeling so that the control system adapts as the robot operates. They are not using an unscented Kalman filter as they hadn't figured that out yet. So the Berkeley robot mirrors mine in some ways. They've made choices that make design challenging but also technically interesting. They rely on a low frequency vision system for obstacle avoidance and staying on the road. They found GPS to be marginal in practice. They have a relatively conventional control system approach although the details are proprietary. Some of the decisions I've made follow these. I'm starting to see the mountain of complexity in control system and software development. I believe now that this is the largest need in the larger picture. Commodity hardware would be helpful. But pretty much any team can build just about anything given enough time. There are lots of people who are good with hardware. This is not necessarily true of high complexity real time numerical software in an embedded environment. There are no IDEs (integrated development environments) that address the kind of development required with distributed multi-threaded n-tier real-time numerical control systems for autonomous robots. Every team assembles their own development platform. Even something simple like having a Linux distribution with all of the numerical libraries built properly and optimized requires some work now. I'm starting to question my earlier thesis that open source is the only way there can be significant advances in advanced field robotics. It may be that only small companies can do it right now. The reason is that the skillset required encompasses significant mathematics and software engineering. At the local robot club, these are precisely the skills that are in the shortest supply. The strongest skills are in electronics (there are many people who are comfortable with surface mount hacking) and machining (having your own machine shop is pretty normal). So I'm not sure if very many amateurs will be able to work with advanced robots. Right now, some very basic numerical control software technology is missing. It's like trying to develop Linux without all of the GNU tools and libraries. You need to build the GNU stuff before you can write Linux. The amount of work is really starting to bother me. I'm making progress on the numerical control front but need to limit how deep this goes. I can't keep working when exhausted as mathematics and numerical software requires more concentration. So I have to sleep. I have found an alternate local source of caffeinated mints, the "euromints" in both regular and cinnamon. They cost a little more than the Penguin peppermints and the tins are embossed - not as nice as the flat tins. The actual product appears to be identical, approximately 50 grams of mints in a tin, each with approximately 15 milligrams of caffeine. My current thinking is that the only way to make really significant progress in field robotics is the high technology startup model. And when you look at development today, all of the action is happening in small teams and groups, not in large companies.