Really interresting stuff ! Can't wait to read your next step !

Something is bugging me though.
I don't know how the serial driver is made on Linux. I just don't know if there is any DMA activated or not on the serial.
Don't forget there is only one byte FIFO in the UART. If you are not able to get the byte before another one arrived, then the byte is lost and you loose data. However, if the DMA is activated, you have a small buffer. I think, I'm not sure though, you can set this buffer with IOCTL.
Multiple access to a communication port is a tricky thing.
Someone talked about real-time in the forum, man, I can assure you, you are going right into those problematics.

What would a developers life be without all those little problems, right?
I can assure you though, messages from the serial port get piled up far beyond 1 Byte. So if there really is only a one Byte FIFO, Linux has to store the rest in RAM. I had an Error in my Propeller code that caused it to spam the serial port with messages. When I tried reading from the serial port I'd get thousands of Bytes of old data.
I guess I don't need real RT capability, I just need for serial reads not to block serial writes. The serial port is supposed to be full duplex, so theoretically it should work handling reads and writes in seperate threads. I've already tested access to the serial port from within two different processes at once and it works. So there's no lock on the port once it's opened. So it should work, I'm confident. (famous last words, right?) Although I might have to change the Propeller code to do reading/writing in two seperate cores as well, we'll see.
And if it doesn't work I'll just waste another hardware port to get a second serial (I2C) line for reading the data.

Well, separating reading and writing into two different threads mostly solved my problems. But now that I'm further thinking about it, reading sensor data has become quite slow. Which is fine for GPS and power monitoring. But what if I want to attach other sensors like distance sensors. Then I'd need a fast read of status information as well to have the chance to act on that data.
So I guess in the next version of the circuit the motor controller will get a dedicated serial line for a fast and near real time response to control commands and the sensor subsystem will get its own serial connection for fast aquisition of sensor data.
I might try to rearrange the whole system to expect constant writes from the hardware controller, so that I don't have to poll for it and therefor can aquire data more quickly.
Maybe I'll have to switch from python to C/C++ to get more speed on the communications and message handling inbetween the different threads.
Any ideas on how to reorganize this system to maximize performance would be greatly appreciated.

But since it's fine for the moment I'll concentrate my efforts on creating the remote control app for Android now.

It's been a while since my last update, so I thought I'd write a few lines on the projects status now.
I've been working to improve the firmware of the hardware controller, shrink the circuit footprint (I eliminated the need for the dev board) and develop the Android app.
The app is the most important step forward at the moment since it's going to be the primary method for remote controlling the drone.
I've already been thinking of goingin a different direction with the PC Version of the software though, it'd be nice to use the processing power of a PC to control a swarm of such drones. The PC would also have enough power to do image processing. One possible application could be to map out an area in 3D (that requires at least 2 drones and a knowledge of their position and direction relative to each other).

The Android app is coming along slowly but steadily. I've already got the camera stream displayed and I got a Map view working (which currently only displays the location of the remote itself, as I didn't yet implement the TCP Client for retrieving all the telemetry).
Interestingly implementing the analog control sticks seems like it's going to be the most complex task, as it requires me to write my very own widget, which is a more involved task than anything I've done on Android/Java so far (remember I've only started learning Android/Java programming for this project about a week ago).

I've already ordered a couple more Carambolas and the parts for more hardware controllers. So in a not too distant future I'll have my swarm of drones.

Hi Naythan,

Look what have found:
http://blog.ianrenton.com/tag/raspberry ... ?order=asc

It's with a R.PI but it could give you another idea!

Interestingly I planned on integrating a Raspberry Pi into my Tamiya Tank. But since I had to wait for like forever before I could order one and have found the Carambola in the mean time I'm gonna go with that.
The poor guy didn't notice that you don't have to disassemble the tracks to get them off the tank, you just need to unscrew the drive sprocket ^^
On the other hand I managed to disassemble my Heng Long Tank without removing the tracks after all.

Interestingly he's got the motor control unit seperately from the receiver unit, which makes it possible for him to reuse the motor controller.
In my tank it was all on one PCB, sadly. I would've liked to be able to reuse the motor controller.

In the mean time I've started building a small (scale 1/24) Carambola controlled RC car as a present for a friend (birthday coming up). It's basically just the Carambola + webcam + motor controller from the tank version (so without telemetry). For this I've already finished the Android control software, but I'm having major issues with the USB right now.

I guess I'll need to take a few pictures (or record a video even) and put that online.
Gotta show the world that the Carambola is a serious competitor in the mobile R/C world

Oh well, who would've thought, my Raspberry Pi arrived today.
So attached to this post you'll find two pictures, comparing sizes of the Raspberry Pi and the Carambola.
As you can see, the Ras.Pi is more than twice as big as the Carambola. Ironically the Carambolas SoC is almost twice as big the Ras.Pi's SoC (and that one even includes the memory).

If I get one free wish for christmas it'd be a system the size of the not yet released Carambola Nano, with the power of the Ras.Pi SoC and for the peripherals integrated 150MBit/s WiFi, USB, 2xUART, SD, SPI, LCD(or other video out) and a few GPIO's. Of course for a price similar to the Carambola or Ras.Pi.
But I'll probably have to wait for christmas in 5 years or so before that's going to happen

Nice job NaYthan, I built a my wifi tank out of a hacked up 703n and teensy. This was well before I had stumbled across the Carambola.
The 703n is hosting a webpage streaming a webcam via mjpg-streamer and I use JavaScript to detect keyboard key states on the page.
JavaScript functions using a little Ajax (preventing the page from refreshing) to post/call cgi shell scripts which
echo commands at /dev/ttyACM0 (the teensy microcontroller) to drive the motor-controller.
Was a bit concerned about this hacked together setup being laggy but the response time far exceeded my expectations.
I've had friends drive/control the tank from several thousand miles away without issue or complaint.
Really wanted to use a python server I had written for this project but memory constraints of the 703n prevented it's use.
Openwrt's native lua could easily be modded but I'm not familiar with the syntax and didn't feel like learning another one.
Anyway here's some pics:

Ver nice build. I like your chassis a lot.
I wouldn't have expected the JavaScript control scheme to have a good response time either, especially since there's so much overhead on the HTTP protocol for a simple key press event.
I've encountered one problem with displaying mjpeg streams on webpages, Firefox will keep every image in RAM, eventually eating up all the memory it can get until either your RAM is full or if you have enough of it until Firefox crashes.
My final goal was to have an App run on Android to control the tank. I've got the major features down: Streaming Video, Touchscreen joystick controls, Google Maps integration, Telemetry display, etc. but I'm also hitting a performance problem on Android. Networking seems to be a bit laggy on it. Unfortunately this was my first time programming in Java and for Android, so I still don't know how this Networking problem could be solved. But at least all the commercial products out there that offer video streaming and remote control of a vehicle through Android show that it must be possible.

Your control scheme through ajax requests gives me hope though. Until now I've always believed in using UDP for realtime control of a vehicle. But if the relatively slow ajax requests are enough, then maybe I could rewrite my server to deliver the mjpeg stream and accept control commands through a single TCP Stream channel.

Oh and btw. I use Python on Carambola, there's a python-mini package in the OpenWRT repositories that will install on systems with small internal memory. I then used a USB memory stick to store all the modules that were missing from the python mini package (but which were required for my server).