For our final design project, we chose to build a touch
screen radio controlled car.Essentially, the RC car will follow a path drawn by the user on the touch
screen as it is drawn in real time.Speed and direction of the car was extrapolated from the user drawn path
and sent to the car through radio frequency transmission.We utilized a touch screen taken from an old
Palm Pilot, the chassis of an old RC car (including the motors), and a
transmitter receiver pair.All circuits
for both the controller unit and the car were custom built.

We chose this particular project because RC cars are just
plain fun, and thus we chose to create something that is essentially a new
twist to an old idea.Numerous projects
on RC cars have been done throughout the years, but we felt that none of the
control schemes were ever intuitive enough to use to absolute beginners.Nothing can be more intuitive than
controlling an RC car by drawing the path that you want it to take.

Project overview

The main rationale behind this project was that it seemed to
be a fun and interesting idea to implement.Sources of inspiration initially came from previous projects,
specifically the numerous RC car projects over the years, as well as the
handwriting recognition project from 2006.The handwriting project utilized a touch screen, which gave us the idea
to apply the user input tracking capability of the touch screen to an RC car
control scheme.However, whereas the
handwriting recognition project utilized the touch screen for recognizing drawn
patterns, our project would require a greater deal of precision and timing from
the screen.We also realized that a user
drawn path was a very analog input that would require that the RC car itself
have a large number of different turn angles and speeds.The challenge was in writing the algorithm
that would effectively extrapolate both speed and direction of the car from the
user drawn path in real time, and creating a car that would be capable of
following this path.

Background Math

The math involved in extrapolating speed and direction to
control the car is essentially nothing more than basic high school
geometry.The user input path is quantized
into numerous points, which are taken 30 times every second.Below is an example of a user input path:

The touchpad is quantized into a 190 x 140 grid of points
(based entirely on the real life dimensions of the screen itself) and the
microcontroller will grab the coordinates of the current location of the user
stylus (or nailed finger) 30 times a second.If the user speeds up the stylus, naturally the points will be further
spaced apart.It is entirely from this
quantization that both speed and direction are calculated.

Speed –

Extrapolating speed is a simple
matter of calculating the length between each successive point.The longer the distance between successive
points, the faster the car should be going.Calculating this distance is a trivial matter of utilizing Pythagorean’s
Theorem: However, as one can plainly see the points are very close together
most of the time, rarely exceeding the distance of 1 to 2 pixels from each
other, as can be seen in the graph below.

This means that the calculated
distances are, for the better part of the time, either 0,
1, or 2.This makes extrapolating the
speed a little more difficult, and a lot less analog than we would like it to
be.Thus we solve this problem by simply
averaging the previous 2 distances with the current distance.This gives a much more varied speed
calculation, as can be seen from the following plot:

Direction –

Extrapolating the direction from
the points requires a bit more math and a lot more creativity.What is most important here are the not the
absolute angles derived from the points, but the angle compensation needed by
the car with respect to its current position in order to correctly follow the
user path.The desired final output is
the angle that the car’s wheels must turn in order to keep following the
path.Of course a car is restricted in
the range of angles it can turn, thus all angles greater than a predefined
value are declared as invalid inputs.

Once again we have the problem of
the points being too close together to extrapolate any real useful data, thus
for direction calculations, every group of 15 points are averaged, and the
direction calculated from these points.This means that, assuming a sampling frequency of 30 points/second, the
direction will only be updated twice a second.

The basic math behind deriving
absolute angles between points is simple trigonometry.What we desire in the end is the change in
the angle from the previous value, illustrated below:

The lines that connect each point have been elongated to
illustrate the placement of the desired angle.This angle can be easily calculated by first calculating the absolute
angle from the line connecting the current point and the previous point with
respect to the Y-axis.

Then the previous calculated absolute angle formed by the
previous formed line from the past point must be subtracted from this current
angle.This final angle will effectively
be the angle that the wheels of the car must turn to follow the user defined path.

Embedded within the problem of finding the turn angle lays
the problem of detecting when the car needs to move backwards:Below is an example of a user input that
would result in the car moving forward, then moving backwards, and then moving
forwards again.

The problem at hand is detecting when the change in
direction is sharp enough to change the motion of the car from forwards to
backwards.It is this acute angle, that
any person can obviously see, that must be reliably and efficiently detected
through code.Again, we will be
exploiting the simple properties of high school geometry to accomplish this
task.The Law of Sines
dictates that for triangles, an angle is proportional to the length of the side
directly opposite to it.Thus this acute
angle that is indicative of a change in the movement direction of the car can
be quickly extrapolated through the length of sides formed by three
points.Below is an illustration of this
theory:

The most recent detected point is labeled point 1, and each
previous angle is designated as points 2 and 3.As one can plainly see, when moving forward, the length of the line
formed between points 1 and 3 will always, without exception exceed the length
of both the lines formed between points 1 and 2, and 2 and 3.When moving backwards, the line formed by 1
and 3 will always be shorter than at least one of the other two lines.

Logical Structure

The high level structure of our project is succinctly
illustrated in the diagram below:

Hardware/software Tradeoffs

We realized from the beginning that following a user input
path has numerous pitfalls.The most
obvious problem lies in the fact that a user input path cannot be exactly
translated to RC car movements.The RC
car has a very limited range of angles it can turn, and a user input path can
very easily exceed the rate of turn for the car.Furthermore, the user can easily move the
stylus faster than the car can reasonably follow.Thus, fail safes were programmed into the
code that would reject movements that were too fast, or angles too large for
the car to follow.

FCC Standards

Our transmitter complies with FCC standards since it does
not interfere with licensed transmitters and it transmits in the acceptable
range of frequencies found in Part 15 of the FCC rules (http://www.access.gpo.gov/nara/cfr/waisidx_01/47cfr15_01.html).The circuits that we used save power by
inverting the transmitted bit stream so that it transmits a 0 when no signal is
being transmitted.We do not plan on
selling any of our products and we are building less than five of them, so no
equipment authorization is required.

Software Design

The software required for this project consisted of two primary
code bases: the code on the user side control hardware, and the code needed to
properly operate the car.All
mathematical calculations for generating speed and direction was performed on
the ATMEGA32 controller on the user end, and the controller on the car simply
took in wheel angle position and speed through RF, and generated the correct
signals for operation.

Touch screen point
capturing

Timing was an essential factor in correctly capturing the
coordinates for the current stylus position.A new point was taken in every 33.3 milliseconds (30 points/sec), which
was assured by regulating this through interrupts.As described above, the touch screen can only
output either the X or Y coordinate at any one time, thus input and output must
be quickly swapped between the four pins to get both values.The setup that was used in the Handwriting
Recognition System project, which required changing pins from input to
output, and output to input depending on which coordinate was being read, was
used in our code as well, but with heavy modifications.Timing was less of an issue for their
project, which relied on recognizing the pattern drawn rather than the absolute
positions.However, for our project, we
needed to be able to grab these points as quickly as possible.Below is the state machine used to correctly
read in the coordinates:

There is a need for a 7 millisecond wait time from switching
the port pins to actually reading in the value from the ADC because of the low
pass filter.During this time interval
the voltage reaches its proper peak value, which can then be properly read in.

Speed and direction
calculations

Within the 33.3 millisecond timeframe between successive
points, it was necessary to perform all needed calculations for both speed and
direction.The math that was involved
required very costly operations such as squaring, square roots, and arctangent
calculations.The timeframe between each
point only allows for approximately 532,800 instructions to be executed, thus
shortcuts were taken to minimize the cost of the calculations.A very finite number of values needed to be
squared, thus a small array of pre-calculated squared values was placed in
FLASH ROM, making a square operation take as long as a simple read from
FLASH.This same setup was also done for
square root values.Finding a shortcut
for arctangent calculations proved a little more difficult, however.Since an arctangent essentially calculates
the angle from a slope value, we simply calculated the slope, which required
floating point divide operation, and make a rather tediously large If statement that would assign an angle based on the range
of the slope value.

Control signal
generation for the car

The speed of the car is controlled by changing the duty
cycle of the signal that is input to the DC motors.If the car is moving, it has a minimum value
of 6/20 and a maximum value of 15/20. This value is directly obtained from the
received packet.

The turning direction and degree is controlled by a servo
motor.The steering on the RC car was
originally controlled by a servo motor that had its own custom controller.We were unable to hack this, so we purchased
our own servo and installed it in place of the original.The pulse width is obtained directly from the
received packet and ranges from 31 to 65 in units of 1/50000 of a second.The pulse begins every 20 milliseconds.The wheels are straight at a value of 48 and
higher values turn right while lower values turn left.

Things tried but
failed to work

As stated above, calculating speed and direction for
successive points proved to be ineffective due to the fact that these points
were more often than not right next to each other.This made calculation of the speed and
direction resulting in only a handful of different values.Thus averaging every point with its two
previous points to calculate speed, and averaging every 15 points to calculate
angle was necessary.

Another huge issue was transmission.The car simply refused to take in the packets
sent at a baud rate of 4000.We tried
nearly halving the baud rate, using 2400 baud instead, and this fixed the
problem.The issue was that the timing
was slightly inconsistent between the sent data and received data.Lowering the baud rate
allowed for a greater margin of error.

Hardware Design

Designing the hardware proved to be the most tedious and
time consuming part of the project.Our
project consisted of numerous components that all had to work together to make
the design functional.Controlling the
two motors on the car chassis required an H-bridge, and controlling the
direction of the wheels required a servo.The ATMEGA32 microcontroller itself required certain components, such as
a low pass filter for correct ADC operation, and low pass filters were required
for ideal operation of the touch screen as well.The circuits for the transmitter and receiver
were difficult to construct as well.

H-Bridge Design

The H-bridge allows the voltage to be flipped so that the
car can move both forwards and backwards.It is a very standard part of most RC cars.The design of this H-bridge is based off of
the design by Chuck McManis (http://www.mcmanis.com/chuck/Robotics/tutorial/h-bridge/bjt-circuit.html),
with slight modifications based on the motor circuit from Lab 5 (http://instruct1.cit.cornell.edu/courses/ee476/labs/s2007/lab5.html).One unusual property of the car chassis that
we were working with was that it was 4-wheel drive, which meant that there were
two separate motors driving the rear and the front wheels.This meant that the circuit required an
extremely high current, in excess of 3 amps at startup intervals.This meant that very high spec BJTs were needed that had maximum current ratings of in
great excess of 3A.The transistors
needed were TIP102 NPN BJTs and TIP105 PNP BJTs, with max current ratings of 8A.Two signals control the H-bridge, a reverse
and a forward signal.If both signals
are thrown high, then the car will immediately break.Optoisolators are
utilized to isolate the motor circuit from the MCU circuit.

Touch Screen

The touch screen hardware works exactly as described in the Handwriting
Recognition System project.The only
changes that were made to their setup was the removal of the amplifier, which
we felt was unnecessary, and changing the resistors and capacitors so that the
cutoff frequency would be 159.155Hz.The
touch screen will output voltages that are based on where the user is touching
the screen.When Vcc
is applied to the 3rd wire and ground applied to the 1st
wire, the remaining wires will give a voltage that corresponds to the Y
coordinate, which is fed into the ADC to be read as a value from 0 to 255.When the 4th and 2nd
wire are fed to Vcc and ground, respectively, voltage
readouts will correspond to the X coordinates.

Transmitter and
Receiver

The circuits for the RCT-433 transmitter and the RCR-433
receiver were taken from Donn Kim’s and Antonio
Dorset’s “Dual Control R/C Car” project and they are unmodified.

Results

Most goals set out for this project were ultimately
achieved, although a critical component, the RF transmission and receiving to control
the car itself, refused to work properly until a mere hour before the start of
our lab period.The user touch screen
control unit worked flawlessly, transmitting the correct directions and speed.We verified this by reading the data packets
with Meghan Desai’s reference receiver unit.Essentially all hardware was in fully functioning order, and the only
problems were software based.All
hardware was very thoroughly tested and indeed the transmitted signal was being
correctly and effectively received by the car, but the signal itself refused to
be properly processed to final control signals for the car until the very last
moments before demonstration.Our
problemWe thus had little time to test
out other aspects of the car that were buggy such as stopping the power motors
from running and getting the car to run in reverse.

Essentially 95% of our project worked flawlessly, but the
single RF component flaw ultimately prevented our design from being fully
implemented.The problem was resolved
mere hours before our demonstration time, and this did not give sufficient time
to truly test out the car.

With respect to timing issues, all necessary calculations
that were involved on the user end control module was computed within the
allotted time between grabbing successive points.The calculated turn angles and speeds all
seemed reasonable, and essentially the control module worked to exact
specifications.

Although we were not the only group utilizing RF, we
generally did not encounter any interference during testing.

Conclusions

In general, what ultimately made the project novel, the
unique user control unit, was successfully created and tested.What we did not anticipate were the hellish
issues that we encountered with the RF transmission.We assumed that since it was so well
documented, and widely used that it would be the least of our worries in this
project.Essentially, the pieces that
are unique to our project were implemented with compete success.It was purely the components that we borrowed
from other projects that failed to work, which made the problem all the more
vexing and infuriating.Ultimately, the
transmitter issue was fixed, but by then we had so
little time left that full testing was effectively impossible.If we had more time, we would have simply
implemented a different RF protocol instead of using an existing one.

To the best of our knowledge, all of the claims that we have
made are accurate.Our circuit diagrams
and descriptions match those that we implemented exactly.We have given proper credit for all aspects
of our project which we did not design or design with the help of ProfessorLand and the TAs.We accepted criticism of our work and
corrected the errors that we found.We
have been honest about the errors that we did find and they are included in
this report.Our car is as safe as the
original RC car that we took apart to build the project.If we were to market this as a consumer product,
it would not be safe for small children as the car moves quickly and there
would be opportunity for injury.