As I am working on my robot, I had sort of a flash last night.
I wrote a network enabled joystick program that could use a joystick connected to one machine to control a robot over a wireless (or wired) network.
Before it is really clear what I'm thinking, let me explain the robot system I have so far, it is a pseudo real-time cooperative multitasking system that should be portable, but it is currently running under Linux.
It has one main high priority loop that uses task structures to call into "handler" routines. After all the work is done that needs to be done per iteration, it calculates how long it should sleep, then loops again. It works pretty well, and is similar to stuff I did long ago in my embedded days.
There are basically two classes that are important, tasks and event handlers. Tasks get called periodically. Event handlers get called by tasks. Event handlers may be shared amongst multiple tasks.
The robot program uses multiple tasks, with one event handler. The main event handler handles key strokes, error conditions, etc.
Using this structure, I simply created a network listening task that waited for a fixed length packet from the network joystick program, from which it created a "event" and passed it along to the main event handler.
Last night, I started thinking, I was stupid, I should have made the network task far more generic and written it so it could accept more than one connection, have bi-directional communication, as well as handle any sort of event.
So I am embarking on doing this, as I think about it, if I publish the event specification structure and format. Try to make a fairly standard API library, it should be possible to fully distribute the functionality of the robot over multiple computers fairly easily. This should be lighter weight than something like MPI or PVM, and be able to have built in error protection needed for robotics.
Any thoughts? Anyone have any suggestions on what the API should look like?