EE 476 Final Project

RC Car Controller
Blair "Iceman" Lee
John "Diesel" McDonald

[ Overview | The Car | Communication | Controller | Receiver | Steering Control | Speed

Control | Results | Appendix ]

Overview:

We decided to build transmitter and receiver modules for a radio-controlled (RC) car, as
well as implement variable-speed motor control and a continuous steering function. The
simple speed controls included in most RC kits seldom offer more than three forward
speeds and one reverse speed; furthermore, steering controls in most “Radio Shack” toys
only offer binary steering: Either the car is turning left, right or not at all. We felt that
overcoming these limitations would make any RC car more realistic to handle and
ultimately more fun to drive.

The Car

A Tamiya RC model kit was bought from a Maryland hobby store, along with a
rudimentary radio control unit to verify that original unit’s operation. After making sure
all parts were assembled correctly, the mechanical speed control, speed control servo, and
radio receiver module were all removed. The car we selected already implements
continuous steering with a servo attached to the steering linkage; however, because the
radio receiver was no longer being used, we decided to leave the servo in and reverse
engineer its interface.

The original implementation of speed control in the car consists of a servo which
mechanically moves the arm of a simple high-power potentiometer. While the motion of
the servo is continuous, the circuit only produces six discrete levels: three forward, two
reverse, and neutral. Hobbyists in RC cars often replace this assembly with an electronic
speed control (ESC), which uses pulse width modulation to provide a smooth speed
control. We chose to simulate the function of these commercially available ESCs by
using the microprocessor to modulate pulse width across the motor.

Communication

An RC car is of little value if the controls are tethered to the vehicle. However, we
determined during the design process that the radio system was mostly irrelevant to the
actual project, and that the time required to build the system would seriously impede on
the rest of the project. We decided instead to use a pair of commercially available radio
modems. The devices, made by National Semiconductor and used by Laplink under the
“AirShare” label, claim to establish a 115 kbps serial connection at a distance of up to 30
feet with clear line-of-sight. While this range is inferior to that of commercially available
radio control units, it is more than adequate to prove that the rest of the design works.

Command Opcode Magnitude Range

Forward 0000 0000 - 1111
Reverse 0001 0000 - 1111
Left 0010 0000 - 1111
Right 0011 0000 - 1111
Start 0100 n.a.
Stop 0101 n.a.

A simple communication protocol was established to send messages from the controller
to the car. Because the connection is serial, we encode each command into a byte-long
packet. The top nibble denotes the command, and the lower nibble represents the level at
which the command is to be executed. For discrete operations (like headlights), the
second nibble determines which functions are to be toggled. Communication travels one
way from the controller to the car, which cuts down on the hardware required for either
unit.

Controller

The original controller used spring centered potentiometers to produce analog signals
which controlled the speed and direction of the car. The analog signals were transmitted
to the car via a 75 MHz AM radio link.

In order to emulate the true RC car experience, we decided that we needed something
more visually intuitive than two potentiometers stuck into a breadboard. We purchased a
simple PC joystick from Radio Shack and removed the "turbo" button circuitry. Using
the existing interface cable, we were able to connect the internal potentiometers and
pushbuttons to the receiver board without cosmetically altering the joystick.
 Our design for the controller uses National Semiconductor serial ADCs to convert the
analog waveform from the potentiometers to a digital signal. For example, the 8-bit
value obtained from the forward/reverse potentiometer is compared against a known
value for that potentiometer’s “centered” value; we can therefore determine whether the
user intends to go forward or backward, and the rate at which she plans to do so. These
data are used to generate the opcode and value to be sent to the car over the serial
connection.

After encoding, the character is sent to the car. The controller polls the user inputs one
after another, sending out data regardless of a change in state of the input.

Receiver

In many ways, the receiver unit acts like a conventional microprocessor: Instructions
are fetched from the input byte stream, decoded into an operation and magnitude, and
dispatched to the proper control unit. Depending on the instruction, most of the work is
done by either the speed control or the turning control; all other instructions control
simple on/off devices and can be controlled directly in the receiver’s main loop.

Steering Control

As stated above, steering is controlled by a servo. Rather than supplying a simple

voltage, servos operate on a fixed voltage source and a control line that is pulsed to
dictate the turn angle. Previous work on the servo left us with a DAC circuit, and we
could have added a 555-based timer circuit for pulse width modulation; however, we
decided to simplify the design by driving the servo off the mcu. We used the Timer0
interrupt subroutine in conjunction with user input from the transmitter to determine the
pulse width to be applied and sent through the mcu's port pins.
Speed Control

The received four-bit digital signal denotes the desired speed of the motor. Instead of
using a digital-to-analog converter, we decided to drive the motor at full voltage and use
pulse width modulation to control speed. Several products exist which accomplish this
task; however, it is a simple matter to implement PWM on the microcontroller. A timer
interrupt is used to count 16 “ticks”, and the given magnitude determined how many of
those ticks the motor will be driven.

Due to the motor’s excessive power, it is impossible to drive the motor directly from
the microcontroller. The speed control circuit solves this problem by amplifying the
signals generated by the Atmel 4414 chip to allow large power transistors to drive the
motor. The motor can draw a significant amount of current, roughly 7-8 amps, when
turned on. The amplifier uses 200W rated BJTs in a class B push-pull configuration to
drive this load. Since the base current to the power BJTs is still on the order of several
hundred mAs, intermediate transistors were used to drive the base currents, which turn on
and turn off the large BJTs. The intermediate transistors are wired together with the
power BJTs in pairs so that the gain of each pair is significant enough to allow it to be
driven by the output ports on the microcontroller.

Results

In short, the system works. The joystick is able to move the car forwards and back, and
turn left and right. However, it was a long road getting to this point.
 The pulse width modulation, as it was originally conceived, was far too fast for the
motor to turn at all. Slowing down the period to approximately one second, up from 1
millisecond, solved the problem; however, there is a noticeable "jerk" to the forward and
backward motions of the car. It may be possible to reduce the period, perhaps in half or
even smaller; this was not tested in time for the project deadline. There was some initial
irregularity in the pulse itself; instead of regular intervals, it seemed as though the pulses
were being interrupted by some external stimulus. Careful programming to avoid register
clobbering solved much of the problem, but irregularities occasionally appear at
unpredictable times.

Turning the car is nicely variable but not particularly smooth. The same irregularities
found in the speed control manifest themselves to a greater extent in the servo, causing
the wheels to jerk slightly left and right of the desired turn angle. We suspect the
problem to be extremely difficult to solve with the Atmel mcu, as pulse widths for the
servo vary from 1 to 2 milliseconds; at those small periods, it is difficult to get very
accurate timing with the Timer0 interrupt. Perhaps a 555 circuit would have solved this
problem.

The software portion of the project was easy to design, and the implementation is quite
simple. By avoiding complicated code, we are able to concentrate on hardware issues.
Because most of this project relies on carefully designed circuitry, the reliability of the
program greatly simplifies the debugging process.

Easily the most contentious and dangerous piece of hardware in the project, the motor
control circuitry is both particularly frustrating to design and test. The lack of high
power, high current handling MOSFETs in Ithaca made the task significantly more
challenging. Many combinations of high power BJTs were used, and a few can drive the
car forward. Throughout the testing process we experienced excessive current draw in
any number of the BJTs despite transistor biasing and current limiting attempts. Several
high power transistors were rendered unusable after a couple seconds of exposure in
these circuits. Several fingers bear the mark of instantaneous thermal transfer from
contact with the now defunct BJTs. I even saw a 16 gauge wire solder itself in a few
seconds when a previous attempt with a 30 watt soldering iron for 20 min was
unsuccessful.

Prior to the development of the working push-pull amplifier, none of the circuits was
able to drive the car in both the forward and reverse directions. Many disastrous results
were experienced before a successful combination of components was discovered.
Sometimes the behavior of the circuits defied even Pspice. One of the circuits can be
pulse width modulated between fast and very fast, but could not be turned off. The
lesson learned is that the trick to working with BJTs is having a very tight control over
the base currents. Again, power MOSFETs would have made this significantly easier.