I must say I really love the Carambola, no other embedded hardware platform at this price would've allowed me to develop a WiFi enabled tank drone within a week.
Well, obviously the development is far from finished, but I've got a tracked vehicle with the following features already working:

[*] WiFi remote Control
[*] Webcam Streaming (up to 720p)
[*] GPS
[*] Battery Voltage Monitoring (Both cells individually)
[*] System current consumption monitoring
[*] Dual H-Bridge motor controller with PWM based speed control
[*] Servo controller (since I only had one Servo in my parts bin it's used to rotate the camera around)

The Hardware Controller is based on a Parallax Propeller Chip, the Dual H-Bridge was built from 2 VNH 3SP30 and accepts the 3.3V Logic levels from the propeller for its logic inputs (datasheet states only 5V compatible inputs though). A MAX1270 is used to read the Battery Voltage and the output from the 20A hall effect based current sensor (ACS712), later it will also read the output from 3 Sharp IR distance sensors.
For now the Carambolas WiFi is in Client mode, later it will run in AP mode - the plan is to write an Android Software to control the tank from my Android tablet independently of any stationary AP's.
At the moment a temporary PC Software written in Python (quick and dirty) is there to display the camera stream and remote control the tank.

Propeller and Carambola communicate over UART0 (/dev/ttyS0 in Linux) @115200Baud, the Carambola communication server for the drone is also written in Python, programms and additional data are stored on a 4GB USB drive.

The chassis for the vehicle is taken froma RC-Toy Tank (Heng Long), they're cheaply available from eBay.

Sounds seriously cool.

I so can't believe it!! Naythan, I'm doing the same (almost) thing!!

Look: http://www.mighty-prototype.com/wordpress/?p=79

LOL, what a coincidence. ^^

So you're using gstreamer to stream the webcam, what's the advantage over mjpg_streamer? Is UDP streaming possible with it?
I use mjpg_streamer over http. The test-Software I wrote to remote control the tank and display the stream is in Python (in my Idea the perfect prototyping language, as you quickly achieve the result you're looking for). But I believe I already mentioned, that the real remote control Software will be an Android app.
I didn't use ser2net, I wrote a "drone server" in Python. Works very reliable.
The Server opens the serial port @115200,8,N,1, runs an UDP Server to recieve movement control commands and a TCP Server to reliably pass on the sensor data and recieve configuration commands (I'm gonna make the stream adjustable in resolution and frame rate, as I also plan to control the tank over 3G/UMTS which won't allow for the same high quality streaming as WiFi does.)

So, auxtony78, let me know if you want to take a peek at my solution to the serial2net problem.

Actually I use the same as you mjpg_streamer! (I've corrected my site, thks for pointing it btw!)

I'm really interrested in using Python like you do. I'm ASM, C, C++ developer IRL. But I'm might get into that.
Could you describe which package, librairie you use in Pyhton?
Client side and server side!

Looking forward to it !

Well IRL I'm a web developer. ASM and C I only write in the microcontroller world and Python is my number one choice for everything else.
On the Carambola Python only uses one module that's not part of the standard distribution, which is pyserial for easy access to the serial port.
Now as you might already know the standard Python distribution is too large for Carambolas limited Flash ROM, so I use the python-mini package and had to improvise a bit to get pyserial and a few modules from the standard distribution.

First off you can install python-mini and pyserial with opkg, but pyserial won't work without the Termios.so that's missing from the python-mini distribution.
So what I did was to doenload the normal python package for OpenWRT/Carambola and extract the Termios.so. Then I copied it to the appropriate folder on the Carambola.
I did the same for the other standard modules (and dependencies) I needed for this project. (actually I ended up being lazy and just copying the entire standard modules folder to the USB flash disk and adding the include path in the python programm I wrote at runtime)

Anyway, following a list of the modules I used on the Carambola side of things:

os, sys, time (included in python-mini)
Queue, serial
from SocketServer : BaseRequestHandler, ThreadingTCPServer, ThreadingUDPServer

The entire server runs on 486 lines of code (as you can see that includes threaded UDP and TCP Servers as well as the whole serial communication protocol).

The PC Programm for displaying the stream and controlling the tank/displaying sensor data (like GPS) was more of a quick hack, since I only needed to test that the server works before I moved on to learning Java for Android.

It uses the following Modules:

Tkinter (part of the standard python distribution on all platforms, except Linux where it's a seperate package most of the time)
sys, os, time, Queue, threading, httplib, StringIO, socket (all part of the standard distribution)
pygame (2D game related library, used for rendering the mjpg stream)

Interestingly the Client Software, although havin to perform the potentially more complex task of handling the mjpg stream and the GUI, runs on only 390 lines of code. (there's still a lot of garbage in there, probably closer to 290 lines of code without that)

Everything works fine so far, except I'm thinking about switching from UDP to TCP for the movement controls, as WiFi is inherently prone for UDP packet loss (and since UDP is a connection less protocol which makes it so great for bombarding a server with lots of individual packets, those packets are lost for good, which means control commands sometimes don't get through properly). I'll have to do more network expermiments to be sure what the best course of action will be.
In the end I might have to go down the full TCP route anyway, since I plan to add 3G/UMTS support.

Waoo! Thank you very much for the reply! Now I have to digest all of that!

Talking about UDP and TCP, I know a little bit that problem as I'm actually an embedded software engineer and it happens that I work with communication.

Throught Wifi, it's really common to loose packet you are right. Now it depends on how do you manage the tank.
If you give order like "go straight" and the tank is going straight until you say "stop", yeah you better get a connected socket (ie TCP). But IMHO, if you just do like I do for now, you give order "go straight" and the tank goes straight as long as you give the order (ie the buttons is pressed), well, in case of socket drop, the tank will stop and nothing can happen to him. So the UDP socket might not be bad choice. Now, if you loose too much packet, the tank might also saccade...
So test will be really interresting ! I don't know if you know that but in TCP, the KEEP_ALIVE packet/option, might save yourself in some tricky situation where the socket drop without knowing why!

Good luck my friend, keep the good work updated here !

Oh well, seems like my real problem isn't the UDP communication at all.
I've implemented the idea from my previous post, implementing a LIFO Queue. It improved things a little bit. But everything started to work perfectly fine when I turned off reading in the sensor data from the serial Port.
After that controlling the drone over UDP commands was perfectly smooth, just as you'd want it to be.
So my problem resides with serial reads of sensor data, which seems to be taking up just enough time to cause control lags.
I guess that's not a problem of serial communication speed, as the control messages get through fast enough. I might have to look into speeding up the message generator in the propeller chip. Instead of updating the data when the request comes in I'll have to update the data continuously and then just spit out the existing results on request. Hopefully that'll improve things.
Otherwise I might have to open another hardware interface (maybe try the i2c on the carambola) to completely separate reading sensor data from writing control data. Well, I still got a few cores left unused in the Propeller, so that wouldn't be a problem (just seems dirty wasting interfaces like that).

EDIT: Scratch that last part, I'm gonna try something adventurous. I'll create two instances of the serial port, one for exclusive writing and one for exclusive reading. Simultaneous access to the serial port shouldn't be a problem as long as I don't try to write in both threads at the same time. The UDP Thread will get the exclusive writes, ensuring that every control command gets through in time. Control commands don't produce any ouput anyways, so the TCP Thread will get exclusive reads. The TCP Thread is handling the requests for sensor data. It can pass on those requests through the main thread into the UDP thread where the request is put out to the serial port along with the control commands. The TCP thread can wait the extra time on that sensor data (GPS updates like twice every second only, so that's more than enough time to pass along a message between three threads and a microcontroller).