Search This Blog

Sunday, October 17, 2004

Roamer: recent updates

[Audio Version]

I've made quite a bit of progress along the way of this project. It would be tedious to document the full progression since the start. Still, I suppose I should get in the habit of documenting progress from time to time.

Since my previous posting, when I wrote an opening summary of the Roamer project, I've made some significant progress. Most importantly, I noticed a memory leak that was occurring because of the poor way I was using the graphics features of the .NET framework. I'm a bit disappointed that it doesn't seem to deal well with cleaning up after itself. With a little effort, I eliminated that memory leak nearly completely. It's hard to tell, though, because, as the .NET documentation indicates, garbage collection doesn't happen immediately as objects are removed from use.

One exciting change is that now I can define a world using an XML file. Previously, I had to hard-code the initializations of each demonstration. It's not just a matter of moving code to an external file, though. More importantly, the format I chose offers an important layer of object abstraction. In my hard-coded demos, I would instantiate particle after particle for a critter. In my XML file, by contrast, I can define a segment of particles - perhaps a leg or arm, for example. That segment can be duplicated any number of times and put into different positions and at different angles. Moreover, each duplicated instance of a segment can specify changes that add, remove, or modify particles from the original definition. Segments can be composed of other segments, which in turn can be composed of other segments, and so on. It's a particularly object-oriented way of looking at the critters, and blends nicely with the notion of segmentation to the evolution of complex life forms on Earth.

The end result of all this reusability is the ability to construct worlds composed of potentially thousands of particles that may only require dozens of definitions in an XML file.

What I haven't done yet is to implement the same for the brains of these beasts. Although I originally conceived the use of XML files for defining brain wiring, I realized it was going to be more complicated than doing the same for the world. That's next on my list.

Wednesday, October 13, 2004

New Roamer project

[Audio Version]

I keep trying to figure out how to get started with this blog. I'm in the process of a new research project, but I don't really have a lot of time now to describe it in detail. Yet I think it'll be worthwhile to give updates as it progresses. So I guess the best compromise is to at least summarize my current project.

For various reasons, I've called it "Roamer". One of my first design goals was to do what I've wanted to for many years: to create a rich "physical" environment that can be used for AI and AL research. I've basically succeeded in that already. The environment allows for one or more "planets", like Petri dishes with their own different experiments. Each planet is a 2-dimensional, rectangular region populated by various barriers, force fields and, most importantly, particles. All "critters" are composed of particles, basically circles with distinct masses, radii, colors, and so on that act like balls zipping around the planet and interacting with the other elements. One key element is the link, which is a sort of spring that connects any two particles. So a critter can be minimally thought of as a collection of particles joined by springs. The physics of this are such that one may laugh at how a critter jiggles and bounces, but I find it's easy to get what's going on as one watches. The math behind the forces involved in the interactions is pretty simple, but the overall behavior is fairly convincing.

On top of this "physical world", I've begun creating robotic components. These are derived from the basic particle class. Some sense touch and smell. Some produce thrust or induce links to act like muscles. There will be others soon that offer things like vision, enable grabbing objects, and so on.

I've also begun creating "brain" components. I originally made these as particles, but found that cumbersome. So I created a "brain chassis" particle that's meant to house decision making components. The first two I've created thus far are the finite state machine (FSM) and the "olfactor", which is concerned with recognizing smells the nose particles detect.

I'm at a point now where creating new demonstrations is getting to be quite a chore, because each critter design is hard-coded into the program. Now that I've gotten a bit of experience creating critters and wiring brains for them, I have an understanding of the commonality that's involved with these tasks and so am now devising a way to represent designs for worlds in XML files instead of code. This may sound superfluous and overly limiting, but one significant benefit is that I've already engendered a notion of one "body segment" to be modeled after another one already defined and even to modify it a little. As such, it's easy to have a critter that's composed of repeating segments and even segments that grow progressively different or have different uses. It's a sort of object oriented way of describing things, with inheritance and polymorphism. So far, I've proven the concept with segments within segments and ultimately embodied as particles. I have yet to implement the links that tie them together, but that'll be pretty easy. More importantly, I have yet to start implementing this same concept with brain components. Once these steps are done, I'll be able to create richly complex critters with much less effort.

Although my present goals are oriented toward AI research, I keep getting tempted by how relevant this "physical world" I've created seems to be to artificial life (AL) research. There's no reason I couldn't add some extra code to all this and turn it into a world of evolving critters using traditional genetic algorithm techniques. The XML definitions of critters could be the genetic code, for instance. One reason I don't intend to any time soon, though, is that while my simulation of how the world works is pretty good, it's also brittle. I tried to engender conservation of energy and entropy into the system, but I was not able to get away from the fact that in some circumstances, "energy" does get created from nothing and sometimes spiral out of control until the world experiences numeric overflow exceptions. I would expect that evolving critter designs would find and exploit these features. And while such exploits would not necessarily be bad - so long as they don't cause exceptions - one thing I consider unacceptable about them is that they lose that nicely intuitive feel of the system, making it harder for the casual viewer to get a quick sense of what's happening.

On that note, I consider it important in AI and AL research to not only create things that are smart or lifelike, but also to do so in a way that most people can see it for themselves, at least on some level. That's one reason I've wanted for so many years to create a physics-plus-graphics engine like the one I have now. For a researcher like me with no research funding, I think it basically satisfies the requirement of Rodney Brooks that a robot be "embodied" in a way that grid-style worlds and other tightly constrained artifices can't reliably be expected to simulate. I don't ever expect a robot designed in this 2D world to be turned into a physical machine in our 3D world for us to kick around, though. I see this as the end of the line for such critters.

I do, incidentally, think that the model I've devised thus far can readily be transformed into a 3D world. The main two reasons I chose a 2D model are that it's harder to program a useful graphics engine and viewer for a 3D world and that it's simply harder for the researcher or casual observer to understand what's going on in a 3D world, where lots of important things can be hidden from view. Still, this seems a natural step ... for another day.

Saturday, October 9, 2004

First entry

[Audio Version]

This is my first entry into this blog. The subject matter generally is Artificial Intelligence.

I have been engaged in AI research in one way or another since around 1990, when I first read the Time-Life book "Alternative Computers", part of their "Understanding Computers" series, a colorful if brief look from a layman's perspective at a variety of technologies that even today get the statuses of cutting edge or bold speculation. As I recall, it touched on neural networks, nanocomputers, optical computing, and so on. Given my intense interest at the time in robotics and digital processors, what most caught my eye was a section on artificial intelligence. At that time, I had followed an odd path that led me from studying simple electronics to digital logic and all the way up to microprocessor architecture.

What I was finally realizing around this time was that in order to understand how digital computers worked, I was going to have to learn how to program. I didn't have any particular problem to solve by programming; I just wanted to really understand what all the complex architecture of a digital computer was really for. The idea of a machine endowed with intelligence was not new to me at this time, but I guess the timing of this book and my interest in learning to program were such that they led me to conclude that I should learn to program and that I should cut my teeth on the problems of AI.

Thanks to my gracious and encouraging parents, I was lucky enough at this time to have a Tandy 1400LT laptop computer like the one shown in the illustration at right. It was great for word processing, spreadsheets, playing cheesy video games, and some other things. It had a squashed, 4-shades-of-blue LCD screen, two floppy drives, no hard drive, a 7 MHz Intel 8088-compatible CPU, and 640KB of RAM. When I decided to learn to program, my father insisted I do some research first into programming languages. After a while, I settled on Turbo Prolog (TP) because PROLOG had earned a good reputation in the AI community, especially for the part of it that was my first focus in AI: natural language processing (NLP). Once I had read my first book on the language, my father was finally convinced I was serious enough and gladly bought me a copy of TP.

In some ways, this nearsighted choice of mine to learn to program in a language few people in the business world to this day have ever heard of may have put off entry into my career as a professional programmer by a few years. Still, the way of thinking about automation engendered in PROLOG has helped my understanding of search algorithms, regular expressions, and other practical technologies and problems. And while I felt pretty out of place when I started learning C++ a year or two later, my understanding of PROLOG really crystallized my understanding of what the procedural languages that have dominated my professional life since are really all about in a broader context perhaps many programmers lack.

The books I read, including the manuals that came with Turbo Prolog, emphasized the strength of PROLOG in natural language processing (NLP), so I began my life as a programmer there. I would not say that in these early days I made any novel discoveries. I was simply following in the footsteps of many bright researchers who came before me. But I quickly came to understand just how hard the task was. My impression is that even today, NLP is a black art that has more to do with smoke and mirrors than with cognition. Still, the timing was actually fortuitous, since I was also learning the esoteric skill of sentence diagramming in high school around this time. Nobody but linguists care about this archaic skill any more, but it couldn't have come at a better time for me than then.

PROLOG was also touted as an excellent language for developing expert systems. I made my first primitive examples around this period as well. Expert systems also provided a natural application for NLP, so I experimented with simple question and answer systems of the sort one might imagine in a medical application where doctors and patients interact with information and questions for each other. Again, I hasten to add that I made no noteworthy progress here that others hadn't already achieved years before. It was really just a learning experience for me.

Sometime not long before I went off to college in 1992, I got interested in chaos theory (James Gleick's "Chaos: Making a New Science") and, as a sort of extension of it, Artificial Life ("a-life"). My programs started to be geared more toward generating the Mandelbrot set, l-systems, and other fractals. Once I got to the Stevens Institute of Technology, I was digging into a-life (Steven Levy's "Artificial Life"), especially with Conway's Life, genetic algorithms, and the like.

In modesty, I have to say that I did little that was new in all this time, but I was constantly going off in my own directions. Admittedly, this is probably because I have rarely had the patience to learn enough about any particular subject before diving into it, so I end up filling in the gaps with whatever makes sense to me. This process is inherently creative, and sometimes leads to unexpected places. Along the way I did start doing my own research, though. I wanted so much to succeed where others appeared to have failed in creating things that the average person could genuinely recognize as alive in a digital soup.

Sadly, by the time I left school, my AI and a-life research had ground to a nearly complete halt. I had jumped on the World Wide Web bandwagon almost at its beginning and have still not gotten off it yet. I was at the "serious" start of my career and the focus was almost wholly on making a success of it. I've been quite successful at it because I work so hard at it, but it's always been driven by a belief that my success will eventually free me to get back to my AI research.

Ten years later, I've had to come to the realization that I've made a mistake in not just continuing my research on the side and just dealing with the fact that I have to keep working full time on something other than my AI research in order to pay the bills. In the past few years, though, this has been sinking in and I'm starting to do AI research again. I've been focusing my attention on the bold claim that AI has always promised of sentient machines. Other great minds have done such a great job in other areas of AI that we can at least claim to have machines with roughly insect-level intelligence. But thanks to post-modern philosophical skepticism about the very existence of reason and other misguided debunking of AI, most researchers seem to have given up going for the most important piece of the puzzle: conceptualization.

In all those years I wasn't doing actual AI research, I was still thinking about the related problems. With each new thing I learned in other areas, about philosophy, programming, economics, and so forth, I gained new insights into AI. Always with me has been the question, "how would I get a computer to do that?" I continue forward now with the strong conviction that conceptualization is not only possible for computers, but also that it is a necessary part of the solution for many outstanding problems in computing. So I've devoted most of my renewed efforts in AI to date to the problem of engendering conceptualization in computer programs.

So that's where I am today and how I got to this point.