ProjectBorg is my goal to create a robust Artificial intelligence (AI) software suite targeted toward small and large robotic platforms. The end goal is to enable any robotic hobbiest to create and download a working brain for their robot in a matter of a few minutes to a few hours.

My desire first of all is to form a think tank of individuals interesting in AI, generally but not limited to robotic AI. I was looking to join an existing project but as yet I can't find one that encompasses the required goals as I see it. A lot of robotic hobbyists create great robotic hardware platforms that then roam deaf, dumb and blind. Apparently, we have no freely available AI that easily adapts to a wide range of custom robot platforms. I've been in this situation with my Symapod robot!
 
With a think tank of individuals, many of whom may not even contribute code but only their thoughts, the design of a robust platform should be possible that would cover a wide range of robotic platforms. One man can not possible dream up a design covering such wide design parameters, so step one is fostering much group discussion. 
 
Why do I think such a robust robot OS is possible? When I say that this Robot OS could be run on small processors like PIC/Atmels, up to large processors I don't mean all features would be scalable or that a single source base would do it all. Simply that the project as a whole would consider devices large and small. Obviously, small devices would have a small AI kernel (not to be confused with a Linux kernel!) capable of running some neural nets, genetic algorithms, etc., and handle simple sensor input and effector output. The large devices would run a much more capable AI kernel that would likely run on top of a linux kernel, the uclinux or vanilla based kernel, or even windows if we can stick to platform agnostic standards.
 
An analog of what I am thinking is like the Windows API for regular systems, and the Mobile Windows API which is much smaller and less capable, but appropriate for smaller devices. These are two seperate APIs but are generally homogeneous from a developers point of view.
 
Because the AI algorithms don't really change no matter what your architecture is. The AI databases and data structures should be largely portable. For example, a few AI techniques are Neural nets/perceptrons, genetic algorithms, state/feature space graphs. The weights of a neural network could be loaded by the Atmel/PIC mini AI kernel, or the large AI kernel. I like the idea of an AI kernel that implements the AI algorithms and knows little specifics about the symbols or feature spaces, etc., it's processing. I think an AI kernel subsystem would be largely portable between large and small devices. A platform specific IO subsystem would be responsible for handling the sensor input and effector output and generating/modifying symbols inside the AI kernel, this IO subsystem would be largely specific to the capabilities of the controller.

Another large hurdle for robotic hobbyists is implementing inverse kinematics (IK) for motion planning. I cheated with Symapod and  trained a neural network (NN) using regular geometry but inverted the inputs and outputs. When training was complete, the NN converted my XYZ coordinates into joint angles. IK was too complicated for my little Z80 controller (maybe me too) at the time! The Robot OS should just be told what the effector types, lengths and locations are, and the AI should know to use it as a leg or an arm, or both!
 
Furthermore, I am also not beyond inventing a new programming language specifically designed for AI. It would likely generate code for an (AI specific) virtual machine implemented inside the AI kernel. The language would be well suited to AI programming, just as lisp (yuck) has been. The syntax of the language would allow genetic or other AI algorithms to modify parts or all of the program.
 
There would likely be Desktop User Interfaces and design/simulation environments to design your AI's on your desktop computer. Then you would have access to community pre-compiled boot images of the AI kernel for various devices, be it for small devices like PIC/Atmel or Linux+AI kernel for embedded SBCs (Single Board Computers). The data structures are then integrated or downloaded with the boot image to the robot. There shouldn't be much embedded development or cross development, that's the point of this project, most people don't have that experience --- they just want to build robot hardware.

 I see a user interface, an AI designer, that runs on the desktop where you can define the robot sensors and effectors/limbs, configure the AI goals, actions, operators, etc of the AI brain, run AI trainers, simulators, etc, then hit a generate button that packages the data structures and an AI kernel to a targeted device. More advanced people will customize, compile and share their own AI kernels and modules for example to add new communication protocols, sensor drivers or motor/output drives, etc. The custom kernels will still load and run the data structures produced by the AI designer.
 
I also like the possibility of running the brain on the desktop mega-core cpu's and have a wireless link to the robot(s). I think this can be abstracted through the AI kernel IO layer. The AI kernel could be separated into the AI subsection, running on the desktop, and the IO subsection running on the device. This would be a great way to build/debug your AI in real-time too.
 
I don't have it all worked out, but I have a general idea of what is required by the large majority of robot makers. I am not thinking any ground-breaking developments here, I just want to bring a lot of existing projects and algorithms together into a complete monolithic solution and include tools to enable a developer to build a working AI brain quickly, then expand on their new AI with custom AI programs and modules.
 
As for the AI Kernel, restricting to glibc the AI Kernel algorithms could be compiled on small devices to large devices. The IO subsystem is what is so different. For the PIC/Atmel. a basic IO subsystem can control a few motors and take a few input sensors like IR and touch sensors, simple stuff. For Linux, the sky's the limit, existing drivers process video, audio, i2c, network, etc. The IO subsystem here would load modules that can generate symbolic or feature graphs from video or audio, etc, and pass these data structures to the AI kernel, or conversely would monitor symbols, such as a for motion planning, and convert it to joint angles using IK, or other motion planning modules. Still, the algorithms for visual processing and IK, for example, are still very portable between the various larger cpu's out there. In the final solution, I see much of the difficult code can be portable and different targets would just glue algorithmic modules and subsystems together into different configurations within allowable limits of the target.
 
I would love to hear everyone's thoughts on this, email me!
 
Colin