Ok… obviously this isn’t going to be a simple programming job. So here’s what I propose:
-following the example of the Linux kernel and other excellent open-source products, lets establish a CVS or some other type of development system so all the programmers involved can contribute at the same time (someone said something about a website… ). Following this example further, appoint project directors and code reviewers who make sure everything is up to par. (now of course this is assuming we get enough interest of more than 5-10 programmers). Now since this isn’t going to be an open-source project, we need to make sure that access is only available to developers and not competitors
-At the heart of the system, lets use a very powerful PC (or two) running a Linux kernel. give the system a RAID array with lots of room for stuff, 512MB+ of memory, and like an Athlon or P4… and whatever else we will need (lots and lots of communication ports!). There are many I/O devices, and methods of communication available for PCs. Linux is easily modified, and can run many types of programs and can be programmed using many languages. This opens up our project to myriad’s more programmers.
-We use embedded systems to handle “small” tasks (such as coordinating sensors) and then feed that data to/from the central system
-Let’s use a LAYERED approach. People are talking about using StangPS and etc… (and I haven’t seen the code so I don’t know), but while I recognize its genius… its just a single program. We need to use a layered approach, such as the OSI model or Win32 API or any other similar model. We need to figure out what layers are needed, communication between layers, and appoint a function to everything.
On that note, each function or data crunching/handling should be handled by a separate process/program. The processes communicate to the master process through some sort of mechanism to be determined later. I definitely think a layered approach will promote stability and will allow each function to be programmed in a different language (one can be C, another be a Perl script, etc) according to its need for speed, and so we can allow as many programmers in as possible, instead only limiting it to C/C++ programmers or BASIC or etc…
(and really, isn’t the whole project kinda just a huge StangPS system anyways? But yes, stang’s assistance in these navigational principles and stuff they learned from developing it would be greatly appreciated obviously… )
-Simplicity. As this will be huge, a simple approach is necessary. Let’s not overcomplicate it. Layered programming will contribute to this. (ok, maybe it sounds like I’m complicating it… but really if you think about it I’m not. lots of thought :D)
-Redundancy redundancy redundancy… as someone else mentioned, we don’t want a wire or something stopping us dead in our tracks.
-Abstraction. I think we need to make the programming as abstract as possible, to allow more generic development. The layered approach will allow this because the lower levels will translate the abstract into the real for the robot… or something like that. Basically, instead of concentrating on actual places or coordinates the programming system needs to have an abstract system that gets translated into what the robot does and is coordinated to get it where it needs to go. Heck, we could make a video game AI… lol. Thats essentially what it is.
-Modularity. I don’t think this can be stressed enough! Just about every part of the program should be easily reprogammed, replaced, upgraded, etc… I am very convinced through my own experiences (and im sure others will agree) that having a modular design from the start will be very helpful. Like I said before… layers.
Ok, once again those were my two cents worth… everyone fire away with better ideas and improvements to mine.