This is more a proof of concept project than a finished project. I’ve always wanted to build a tank drone controlled over WiFi with Video streaming and GPS navigation. So when I discovered the Carambola WiFi board back in 2011 I finally started to actually build it. This prototype has taken me about a week to develop, as such it is still rough around the edges. I wanted to test a few concepts with it to further my knowledge towards the end goal of creating a flying drone.
Not wanting to reinvent the wheel I used a cheap RC Toy Tank I bought off of ebay as a basic motorized platform. I discarded all the electronics, except for the motors.
As previously mentioned, a Carambola is the brain of this drone. The Carambola is a really small embedded Linux board based around some Broadcom chipset. It offers a 32Bit CPU running @320MHz, 8MB Flash and 32MB RAM. It has WiFi (150MBit/s @21.5dBm), 2xEthernet, USB Host, 2xUART, SPI and I2C, just to name a few interfaces. It’s running OpenWRT and the whole thing runs on 3.3V (5V is required only for USB), which makes the I/O Ports run on 3.3V as well. It doesn’t have all that much processing power, but at 22€ it is cheap enough to incorporate in just about any microcontroller project that needs networking (i.e. Internet of things).
As the Carambola resembles a brain for this drone the Parallax Propeller microcontroller resembles its nervous system. The Parallax Propeller microcontroller (32Bit 8 Core parallel processor with 32kb shared program/data memory @80MHz) handles all the low level operations. It is connected via UART to the GPS receiver unit, another UART is used to communicate with the Carambola. Through I2C it is connected with a MAX127 (8 channel ADC with 12Bit resolution, single 5V power supply and 10V max input). This MAX127 is perfect for measuring the cell voltages of a 2 cell LiPo pack (which is used to power the drone) and at the same time keep track of current consumption through a 20A current sensor chip (Allegro ACS712).
For the motor control I used two 30A max (9A continuous) H-Bridge ICs (VNH3SP30). They have a few control inputs, two for direction, two for enable, one for PWM speed control. These chips are somewhat expensive, but worth it. These chips run at up to 40V, while the IO pins remain 5V tolerant (they work fine at 3.3V) and the PWM signal can be clocked at up to 10kHz.
The GPS receiver runs at 5V, although all the IO lines work at 3.3V (which is important, since the Parallax Propeller runs on 3.3V and is not 5V tolerant on its IOs).
I’m not going to go deeper into the hardware design, as it’s just a prototype stage that is a puzzle from the different circuits described in the datasheets of the components. So it’s basically as if I had breakout boards for every component, connected those together and put them into the tank. Just one thing, for this project the prototyping board is covered with Aluminum adhesive tape that serves as a large ground plane and helps keep interference low for the components.
The magic happens in the software. And there is quite a lot of it in this project. I’ve got the firmware for the Parallax Propeller microcontroller, the software for the Carambola, remote control software for a PC and a remote control software for Android.
The Propeller firmware reads all the sensor data (current, cell voltage, GPS) and controls the motors (via PWM and directional control via simple IOs). It connects via UART to the Carambola. The firmware is a little hacked together, as I’ve used a bunch of Objects available from the Parallax Object Exchange site. So my code just glues everything together and handles communication with the Carambola.
On the Carambola side of things a bit more work was necessary. First I had to compile my own OpenWRT image with USB Video support (Linux UVC drivers) and install all the necessary software packages. The USB Webcam (Logitech C270) works flawlessly with the UVC drivers and video streams with 720p are possible. To stream Video I installed the mjpg_streamer program, which delivers a mjpg (motion jpg) stream through HTTP. My own Software was written in Python, so I installed the python-mini package for the Carambola (the full Python package doesn’t fit into the small 8MB Flash). It is significantly smaller than the full Python package, but subsequently lacks a lot of built-in libraries. So I decided to put my Software together with those libraries on a USB thumb drive (in the end I could’ve installed everything to the Carambola by only using the libraries I really needed). Basically at this stage my software is little more than an interface between the low level Propeller and the high level remote control software. For this purpose it offers two server sockets, one TCP and the other UDP. The UDP socket is for sending control commands. UDP is usually faster and has less lag because of the lower protocol overhead compared to TCP. The disadvantage is that dropped UDP packets are not handled (as opposed to TCP). This is usually ideal for a fast responsive remote control, where a single individual control packet isn’t as important. The TCP connection is for exchanging telemetry (GPS, voltages, current). The software already converts the NMEA GPS coordinates to decimal longitude and latitude coordinates that can be used with Google Maps.
The remote control software for the PC is also a Python program. It connects to the mjpg HTTP stream and to the TCP and UDP servers of the Carambola software. It displays the mjpg stream in a window and overlays the telemetry as text. The control of movement (and later Servos attached to the Webcam to “look around”) is done by keyboard inputs.
The remote control software for Android does much the same as the PC remote control software. Except there is already a Google Maps View integrated and the control inputs are in the form of two touchscreen joysticks. The Google Maps integration already displays the position of the remote control on the map, but doesn’t yet display the position of the tank drone (although it should be easy to do that). I’ve hit a wall with the performance of network communication on Android devices. It seems to be much better to just keep a TCP socket constantly connected rather than send UDP packets. I haven’t yet changed the code to reflect that realization. There are quite a few other changes I’d need to do, before this becomes more of a working prototype rather than a work in progress.
Although this is all very unfinished I’m still going to provide most of the source code for the project.
Also have a look at the Carambola Forum, where I already posted a bit of Information about this project: