Monday, September 25, 2017
Home » How To's » Drive a Tank BOT From Your PC

Drive a Tank BOT From Your PC

Repurposed Wi-Fi provides an elegant control solution

I have been exploring the possibility of using 802.11G wireless networking technology (also known as Wi-Fi) to replace the analog radio systems commonly used in RC robots, cars, boats, and aircraft. Using Wi-Fi in place of the common AM and FM modulated systems could have major benefits if properly implemented: 

  • Radio interference between operators could be eliminated. Instead of requiring everyone within a certain radio range to be transmitting on a different channel or frequency, each vehicle’s receiver could be assigned a unique address just as computers on networks have unique addresses. 
  • Control ‘glitches’ could be reduced or eliminated. FM and AM PPM control signals, like any analog signal, are subject to degradation and interference from other radio signals and electrical noise which can cause control position errors. Digital control codes can be reliably sent over Wi-Fi and would not necessarily experience these problems. 
  • Down-link telemetry from vehicles would be ‘free’. Wi-Fi is inherently bidirectional, so back-channel data from controlled vehicles would be easy to add. This telemetry could include data such as motor or engine rpm and temperature, battery condition, fuel level, G-loading, etc. Since Wi-Fi transmits at relatively high speeds, even live video from the vehicle’s perspective could be transmitted.
  • More channels of more precise control could be made available. Typical analog RC systems use a 20ms control frame (meaning control signals are sent 50 times per second) and a 2ms channel frame. This limits the number of control channels to 10 or less. I estimate that at least 50 channels with 16-bit precision at a 100Hz would be practical using Wi-Fi.
  • This technology can potentially enable you to control a robot over the internet and at very long distances.

A number of problems would have to be solved for all of this to work well. For example, one of the major unknowns would be the reliability of the wireless link while mounted on a moving vehicle. To investigate these issues, I needed a platform to use as a prototype, test, and demonstration unit. After investigating numerous options for development of a Wi-Fi receiver module, I finally settled on using a Linksys WRT54G Wi-Fi as the ‘receiver’ unit router.

At first, this decision might seem strange. Wi-Fi routers are normally used as a central access point and bridge to the internet for multiple computers and other wireless and wired devices (most Wi-Fi routers also include ports for wired Ethernet devices) and most devices which are connected via Wi-Fi do not need the additional complexity of the router functions. However, using a WRT54G as the ‘receiver’ has some very important advantages:

  • The WRT54G is a complete computer system. It has a fairly powerful internal CPU, memory, and permanent storage. It runs a version of the Linux operating system and is user-programmable. This would permit experimentation with new protocols and semi-autonomous operation. 
  • It is very inexpensive and widely available. I was able to purchase one for less than $40. 
  • It already has all the software support required to handle the wireless communications and numerous networking functions. Developing this software from scratch would be a major effort. 
  • Its built-in four-port Ethernet switch provides a high-speed path to control external devices.

The WRT54G also has some disadvantages for use in radio control applications: 

  • It is not very small or light. Even when stripped of its external power supply and plastic case, it is approximately 6x7x1in. and weighs several ounces. 
  • It uses a 12V power supply. 
  • It does not have the PWM servo outputs typical of RC radio receivers nor any easy way to add them.

These issues make it impractical for most RC aircraft, cars, and boats which are simply not large enough nor have the proper power supply. However, it is a good fit for use in a ground-based robot that does not have the weight and size limitations of other types of vehicles. Not only could it provide the wireless link necessary for remote control, but its programmability could make it good for controlling sensors, actuators, and other robotic functions while also allowing it to operate semi-autonomously. The WRT54G comes up short in terms of providing an interface to robotic sensors and actuators; but I was able to find a fairly clean solution to this shortcoming which I describe below.


A potential issue with Wi-Fi remote control makes a ground-based robot a good test and prototype platform. RC aircraft and cars nearly always require real-time control, typically with only a few hundredths of a second elapsing between control input and servo response. While it should be possible to do this with a Wi-Fi system, common networking protocols which run over Wi-Fi are targeted toward guaranteed data integrity, not real-time delivery, so some work would be necessary to develop a protocol that could guarantee the responsiveness that RC modelers are accustomed to. Until that protocol is proven, the prototype platform would have to be able to operate within the limits of existing protocols, potentially having to deal with control commands being received in a non-real-time manner. This could be disastrous for RC aircraft, cars, or boats but is typically how a semi-autonomous robot works anyway: a series of relatively high-level commands are transmitted to the robot which then performs the appropriate actions in an autonomous, asynchronous manner.

The internals of the 21st Century Toys RC Stuart Tank with the top of the tank removed. On the left can be seen two drive motors and gearboxes which drive the treads. The circuit board on the left contains the motor relays for the drive motors, turret rotation motor, and missile firing motor. It is connected by a ribbon cable to the radio board. There is also a speaker mounted to the bottom of the tank. The tank’s lead-acid battery is housed in the upper part of the tank and is not visible in this picture.


I needed a robot platform to test Wi-Fi control using the WRT54G. At a recent Denver Area Robotics Club (DARC) meeting, the club organizer, Kerwin Lumpkins, was demonstrating a small robot he was building based on a small toy tank. A toy tank makes a good mechanical platform for a mobile robot. Its differential tread drive makes it easily controllable, maneuverable, and all-terrain capable. I was inspired by Kerwin’s robot to find a suitable toy tank for use in my Wi-Fi test platform.

Fortunately, while walking through the local Wal-Mart one day, I came upon the almost perfect solution in the form of a large radio-controlled tank from 21st Century Toys. I knew almost immediately that this 1/6 scale M5 Stewart Tank replica would make a great robot platform: its large size promised plenty of room for placing internal components; the fact that it was radio-controlled meant that it already had a working drivetrain; and it ran on an included 12V lead-acid battery which could provide plenty of power for the WRT54G and other electronics. It was priced at around $150, which I considered a bargain compared to what it would take to construct an equivalent platform from scratch. In one package it provided the base structure, drivetrain, power source, and part of the control system I needed. It looks pretty good too.

Internal view of the tank wired with Wi-Fi. The WRT54G, stripped of its housing, is the large board near the bottom center of the picture. The Ethernet Starter Kit interface board can be seen mounted below the WRT54G and connected via a green Ethernet cable. The blue Ethernet cable connects the router to the network camera mounted on the turret. Other wires in the picture carry power to the different devices and motors.

After getting the tank home and charging the battery, I verified that the tank was fully operational. It’s a fun toy right out of the box. When turned on, it makes engine start-up noises, and then settles into the squeaky rumble of an idling tank. The radio transmitter controls eight tank functions: left tread forward/reverse, right tread forward/ reverse, rotate turret left/right, springloaded missile firing and machine gun firing (sound effect only!).

My first goal would be to control as many of these functions as possible via Wi- Fi. I knew that I’d be able to use the existing drivetrain and motors, but thought I might have to replace all the electronics including the motor control circuitry. Armed with a screwdriver and a voltmeter, I began disassembling the tank to see what was inside.

Imagine Tools ESK


The good news is that it is mostly air inside. This would mean plenty of space for the WRT54G wireless router and whatever additional components I might need to mount inside. In addition to the open space, there are two electric motors connected via gear boxes to the external treads, and a relay board which controls power to each of the four motors in the tank: two for the treads, and one to control rotation of the turret and one to release the spring-loaded missile from the main gun.

The relay board is connected via a ribbon cable to the main electronics board. This board contains the radio circuitry, drivers for the relay board, and an audio subsystem for tank sound effects. The speaker for engine and gun sounds is mounted to the inside bottom of the tank. In the turret are motors to control the turret rotation and to fire the missile.

I could have chosen to remove all of the existing tank electronics and just use the drivetrain and turret motors with my own electronic speed controllers. This would have made possible variable-speed drive instead of the single speed control provided by the relay board. I decided that this would be a good upgrade at some future point; but it would be faster and more cost-effective to use the existing circuitry as much as possible.


I first had to determine a way to tap into the existing electronics. I used a voltmeter to probe different points on the controller circuit board as I manipulated the tank’s RC transmitter to activate each of the controller’s eight functions. Using this method, I was able to find eight logic-level pins on a single integrated circuit that mapped to each of the eight tank functions. Driving any of these pins with a high logic-level would activate the corresponding function and letting the pin ‘float’ would turn the function off.

Unfortunately, the WRT54G doesn’t have eight readily accessible logic-level outputs that could be connected to the control points. Other hobbyists have figured out ways to add a few I/O lines and serial ports to the WRT54G, so it would have been possible to construct a small circuit to convert from the small number of I/O lines or serial port to the eight control lines I needed; but this would have taken more time and would only have solved the immediate problem. I wanted to use this mobile robot as a test platform and be able to expand its capability to read sensors and control numerous additional functions. What I needed was a flexible ‘bridge’ device to convert signals from one of the WRT54G’s Ethernet ports to an interface for robot sensors and outputs.

After exploring numerous options, I finally settled on the Ethernet Starter Kit (ESK) from Imagine Tools. This kit comes complete with a RabbitCore microcontroller module, interface board, power supply, and software development tools. Most importantly, the microcontroller module has an Ethernet interface which could connect directly to the WRT54G, and the kit comes with extensive software support including a network stack and web server. The interface board has numerous I/O capabilities including digital I/O, LEDs, serial ports, and servo outputs with enough flexibility to cover many robotics applications. At less than the cost of just the software development tools for other microcontrollers, I found this kit to be a great buy at $149.

Connecting and programming the ESK was easy. I simply soldered wires from eight general- purpose I/O (GPIO) pins on the ESK interface board to the eight control points I had identified on the tank controller circuit board and hooked up power from the tank battery (the ESK runs on 12V). The ESK Integrated Development Environment (IDE) is simple to use and comes with lots of sample codes. Once a program has been compiled, it is downloaded to the RabbitCore module via a serial cable.

After a few tests and some experimentation, I was able to build an HTML-based graphical user interface (GUI) to control the tank using the RabbitWeb web server software that comes with the ESK. I connected the RabbitCore module to the WRT54G via a short Ethernet cable, mounted both the router and the ESK board in the tank, hooked up power to the router from the tank battery, and configured the wireless router to allow my laptop to connect to it. Once connected, I could bring up the GUI in a web browser and use it to control the tank.

The GUI is simply a web page with eight buttons labeled: FWD, REV, LEFT, RIGHT, FIRE, GUN, Turret Left, and Turret Right. When one of these buttons is clicked, the web browser sends an HTTP POST request (this is the same mechanism used when any web form is submitted on the internet) over the Wi-Fi link, through the wireless router, and to the web server running on the RabbitCore. The RabbitWeb server interprets the parameters sent with the request and my custom code interprets the command and outputs the appropriate signals on the GPIO lines. For example, if the FWD button is clicked, the web server receives a FWD=1 parameter which would cause my code to set the GPIO lines for ‘left tread forward’ and ‘right tread forward’ to high.


Here’s where the non-real time nature of common network protocols becomes obvious. The HTTP protocol used by all web browsers is not a real time control protocol. When one of the web page control buttons is clicked, the appropriate command is sent once. This causes the microcontroller to generate the signals necessary to execute the command. But for how long should the signals be kept active? With a standard analog RC radio, the receiver would receive a control signal fifty times every second. With a web-page based interface, no additional control signal will be received until the user clicks on another button. Should the robot just keep doing what it was last told to do until it receives another command?

Well, imagine if the robot was commanded to move forward and it started to do so; but before a command to stop could be issued, the Wi-Fi link goes down because of range or interference. The robot would continue moving, possibly driving off a cliff or running into something and causing damage. A better solution is to give the robot enough intelligence to do the right thing between commands. For example, if told to move forward, it would do so until it either received a command to stop or detected that it is about to run into something or drive off a cliff. Since the prototype did not yet have the sensors installed that would allow for this kind of intelligence, my not-so-goodbut- it-works solution is to only execute the last received command for a short period of time (about one second). A future solution will be to use a specialized protocol and a physical controller (such as a joystick) which will allow for both real time and semi-autonomous operation.


Having demonstrated wireless control via Wi-Fi, the next step was to add some interesting telemetry. To me, the most impressive telemetry is image or video data. A traditional approach would have been to take a small analog video camera and build an interface between it and the ESK interface board; but this could have taken a lot of time and money. A far simpler solution presented itself in the form of a network camera built by Panasonic. The BL-C10A is a small, relatively inexpensive device (I bought it on eBay for $129), designed to be a remote pet or nanny-cam. It can be hooked up to power supply and an Ethernet network and allows remote viewing via a webbrowser from anywhere that the network is connected. The web interface also allows the viewer to remotely pan and tilt the camera lens and its actions can be programmed with a simple command set. The image quality is good in almost any lighting condition and the camera can transmit video at up to 15 frames per second.

Integrating the BL-C10A with the robot platform was almost trivial. I just mounted the camera on top of the tank turret with some foam tape, connected an Ethernet cable from the camera to another port on the wireless router, and hooked up power from the tank battery (the camera also runs on 12V). I went through a simple configuration procedure to get the camera talking with the router, and then modified the web GUI to include an HTML frame in which the camera GUI can be seen.


At this point, I not only have a great platform for testing and prototyping wireless remote control using 802.11 technologies; but I have a working, maneuverable, telepresence robot. Perhaps more surprising, it took less than two weeks to acquire the parts and build this robot, with most of the work taking place in three days. If I had previously been asked to design and build a robot with similar capabilities, I wouldn’t have thought it possible to do in so little time. But by repurposing the WRT54G, RC tank, network camera and internet technologies, I was able to complete what could have been a very expensive, multi-man-year project in a very short time, on a small budget, with little equipment, and no support. The total cost for this project (not including my existing laptop computer) was less than $500.

Putting together this platform is just the first step, so what’s next? Here are some possibilities: 

  • Investigate how to reliably control a moving vehicle in real-time using Wi-Fi which was initially the whole point of the exercise. 
  • Add sensors that the robot could use to explore its environment. These could include touch, distance, temperature, and photo sensors. 
  • Make the robot more autonomous by programming it to respond to its senses. More importantly, program it to prevent damage to itself and its surroundings. 
  • Replace the tank turret with a robot arm which could be remotely manipulated. 
  • Shrink the electronics so it could be used in a smaller car or aircraft.

I hope to pursue these possibilities and provide updates in future issues of ROBOT. 


Denver Area Robotics Club (Source of inspiration for many robot builders)

OpenWrt (Open Source custom firmware for the Linksys WRT54G and other wireless networking products)

Wi-Fi Alliance (Information about 802.11 wireless networking technology)


21st Century Toys

Imagine Tools


Rabbit Semiconductor


Words by George Mitsuoka