5/14/2011 courses.cit.cornell.

edu/ee476/FinalProj…

Robotic Car Traction Control

Andrew Gifft atg23
Rob Miceli rjm73

Contents
• Introduction
• High Level Design
o Rational
o Background Math
o Logical Structure
o Hardware/Software Tradeoffs
o Standards
o Existing Patents and Copyrights
• Hardware and Software Design
o Software Design
o Hardware Design
• Results
• Conclusions
o Analysis
o Standards and Intellectual Property
o Ethics
• Appendix
• Acknowledgements
• References

Introduction
For our ECE 4760 Final project we have developed a traction control system that detects wheel slip and
adjusts the velocity of the wheels accordingly.

Robotic vehicles are becoming increasingly complex and often need high levels of movement control.
Specifically, when the wheels of a vehicle begin to slip, it is optimal to adjust their speed so that the vehicle
moves towards its intended direction. Applications include vehicles traveling over rough terrain, exploratory
robots, and remote controlled cars. The purpose of our project is to design and implement a four wheel drive
robot that monitors the rotational velocity of each wheel and limits the amount of slip when the vehicle is
accelerating.

…cornell.edu/…/Traction Control Andre… 1/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 1: Front Two Traction Control Wheels

High Level Design

An electronic limited slip differential system controls the rotational velocity of the output shafts of a
vehicle using speed sensors, anti‐lock brakes, and microcontrollers. By electronically monitoring slipping, the
microcontroller can activate the anti‐lock brakes to slow down the wheel that is moving too quickly. An
electronic system has the ability to be adjusted for different applications or conditions, such as on and off‐
road terrain, slippery weather, or driving at different speeds. This makes it much more attractive than a
mechanical system. While the dynamics of modern day traction control systems are very complex, the basic
idea motivated our project. The applications for this design are very practical and universal. Any vehicle with
two or more wheels will benefit from greater stability and movement control with our traction control
system.

The main component of our traction control system is a feedback loop that adjusts the velocity of each
individual wheel to the velocity of the slowest wheel on the vehicle. It contains both positive and negative
feedback by slowing down the fastest wheel motor and speeding up the slowest. A basic schematic of our
system is shown in Figure 1. This block diagram is implemented four times in software for each wheel.

…cornell.edu/…/Traction Control Andre… 2/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 2: Basic Feedback Loop Structure

Background Math

Velocity and Acceleration

To calculate the velocity and acceleration from the encoders, we need to record the time between
phase changes. We also need two velocity readings to estimate acceleration and will assume a constant
acceleration between adjacent phases.

To calculate velocity we use the standard formula:

Notice we are sampling and using since our changes are finite. To find we start a timer at each
edge and record it at the following edge. This gives us the elapsed time between known positions. Therefore
our velocities are:

We can normalize distance out of our calculations since the distance traveled between each reading is
constant at 1/8th a rotation.

These velocities are the average velocities over the recorded time interval and therefore if we are
going to use them to calculate acceleration we must use the velocities at the midpoints of the time intervals.
The acceleration is:

We found it easier to calculate acceleration directly from the time differences using the formula:

…cornell.edu/…/Traction Control Andre… 3/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 3: Sample graph of velocity calculations

Pulse Width Modulation

Pulse width modulation of a square wave of changes its duty cycle to control the amount of time a
signal is high during a single period. The average value of a square wave is defined as,

Where T is the period of the square wave and f(t) is the square wave function. This function can be described
as some maximum value ymax between 0 < t < D·T and some minimum value ymi n for the rest of the period,
D·T < t < T. Here D (duty cycle) is the fraction of the period that the square wave is at its maximum value.
Substituting this into the integral above and then solving for :

All signals generated for this project have a minimum value of zero. Therefore, the average value of each
PWM signal is directly proportional to its duty cycle.

Logical Structure

…cornell.edu/…/Traction Control Andre… 4/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 4: Basic Schematic of the Traction Control System

This is a basic block diagram of our traction control system. The Mega644 microcontroller was used to
generate four PWM signals to be sent to the H‐Bridges and to read the rotary encoder signals. Electrical
connections are shown in blue and mechanical connections are shown in red. Inputs to the microcontroller
are labeled as PINxn and outputs are labeled as PORTxn. OCRnx are the PWM output registers that control the
motor speed. This diagram is explained in detail in the software and hardware design sections of the report.

Hardware/Software Tradeoffs

There were many trade‐offs that had to be made in our design, many of which we discovered while
debugging and testing. One major trade‐off was the rotary encoders we used to determine wheel velocity.
There are two major classes of encoders, optical and mechanical. Optical encoders offer significantly higher
accuracy, can offer much faster maximum rotational speeds and most importantly for this project, must higher
pulses per revolution (easily exceeding 128 ppr). The greater the pulses per revolution, the quicker the
response, and/or the more accurate the velocity reading. Unfortunately these encoders are priced outside of
our budget and we were forced to use a mechanical encoder with 16 pulses per rotation. This means that we
would require two full rotations of the wheel to gather as much data as 1/4 revolution of a fairly common
optical encoder. The additional information could help the effectiveness of a traction control system on two
accounts. First we could detect a slip quicker, apply a duty cycle change, and check the effectiveness of that
change in a much shorter time frame and more importantly, a much smaller wheel rotation. Or, if there are
inaccuracies in our time readings (as we see with our current encoders) we could average 16 readings in 1/8
revolution with the optical and a maximum of two readings with the mechanical encoder. We can easily see
the disadvantage of so few pulses in our prototype as it takes multiple revolutions to reach the desired speed.

We also encountered tradeoffs that had to be made within the design of our software. We started out
designing an edge triggered interrupt to accurately detect a phase change on the encoder signal and get an
accurate time reading. Since the Mega644 only has one comparator we had to combine the pulses from the
…cornell.edu/…/Traction Control Andre… 5/18
5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
four wheels onto 1 signal wire. We found a hardware solution to implement this (by XORing the previously
read data points and ORing the XOR’s outputs). But this required us to allow our edge‐triggered interrupt to
be interrupted. Another difficulty with our edge triggered interrupt was the significant switch bounce seen on
the encoders during a phase change. This problem is described in greater detail in the software section. The
combination of our re‐entrant interrupt and significant bounce noise required us to switch to polling the
encoders. This gives us much less accurate timing, but is significantly easier to implement.

Figure 5: Design of edge triggered interrupt external hardware

(not used in final design)

Finally, we identified a tradeoff with our threshold settings. The more we allowed wheel velocity to
vary, the faster the wheels would reach the target speed. This is truly a tradeoff as both results are desired.
We simultaneously want fast response as well as matched wheel speeds. Of course the solution to this
problem is to implement a sophisticated algorithm and feedback control. Unfortunately we did not have the
time, nor the expertise required to properly characterize the system and develop the stable and efficient
algorithms needed to fully utilize the system and perfect the design.

Standards

Our project was not required to follow any standards when it is under operation. It consists of a self
contained system that does not transmit or receive any external data. Additionally, our robotic vehicle
obeyed all speed limits and local traffic laws. When programming and debugging our software, we followed
the RS‐232 standards for serial data.

Existing Patents and Copyrights

The ideas used in our project were considered to be in the public domain and we did not copy any
patented designs to accomplish our goals. This project was used for educational and demonstrational
purposes only. At the conclusion of our project, we are not considering to pursue any copyrights or patents on

…cornell.edu/…/Traction Control Andre… 6/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
our design.

Figure 6: Complete Traction Control Vehicle

Software Design
The software can be broken up into three major sections, timers, PWM signal edge detection, and
wheel torque adjustments. In combination these parts are able to accurately read each wheel’s velocity and
acceleration and allocate the proper amount of torque to reach and maintain a desired speed while improving
traction by reducing wheel slip.

Interrupts and Timers

Due to the relatively slow servo motor maximum speed, encoder signal noise, and difficulties with

…cornell.edu/…/Traction Control Andre… 7/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
edge triggered interrupts, we decided it would be sufficient to poll the rotary encoders. Therefore we
maintained a counter for each wheel that was incremented in our interrupt every 0.2ms. Placing the counters
in the interrupt ensures that the few hundred to roughly two thousands increments were done consistently,
and any timing accuracy lost was only during the processing of these counts. For example, during our testing
we underestimated the length of time to send data to Hyper Term. Before placing the counters in the
interrupt we saw a very large margin of error with our elapsed time measurements as the hyperterm task
influenced each increment. After moving the counters to the interrupt we only had one delay per encoder
phase instead of a delay for each additional timer increment. This gave much more consistent speed
measurements (although we decided to remove Hyper Term functionality all together for the final car).

Detecting Encoder Edges and Recording Data

Due to budget constraints we were forced to use the less expensive and reliably mechanical type
encoder instead of the more advanced optical encoders. During our debugging process we noticed that the
edges during phase transitions were very inconsistent as the switches would make and break a connection
multiple times at each transition. This variability would often continue for around 1ms (see diagram).

Figure 7: Rotary Encoder Edge Noise

In order to accurately detect a single edge we implemented the debouncing technique used in the
DTMF dialer lab. We found reliable edges could be detected with ten consistent readings (at 5kHz) This limits
the maximum phase of the PWM signal to roughly 3ms limiting wheel speed to about 41Hz, which is still far
beyond the capability of the servo motors used. After an accurate phase reading is taken, we compare the
phase with the last recorded value. Only when a change occurs is an edge detected. Once an edge was
detected the elapsed time counter was stored and reset. The previous datapoint was moved but not deleted.
Remember that two velocities are needed to calculate acceleration (see background math section).

Deciding torque adjustments

The main purpose of a traction control system is to maintain wheel grip. In order to do this we must
detect when a wheel is moving faster than the car. We use two references to control the duty cycle of the
PWMs sent to the wheels. First, the car has a desired speed. In order to make calculations as simple as
possible we refer everything to the inverse of velocity, which once distance is normalized out, are simply our
timed pulse widths. Our desired speed is therefore recorded as a pulse width and all wheels accelerate or
decelerate in order to stay within a defined margin of the desired speed. If a wheel is moving significantly
slower than the desired speed, then we ensure that no wheel is moving faster than a different pre‐defined
margin of this slowest wheel. This process allows the car to quickly reach its desired speed without slipping.

…cornell.edu/…/Traction Control Andre… 8/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
Below is a timing diagram for our PWM signal. We programmed the TCNT1 and TCNT2 registers to
count from 0 to 256. When we wanted to increase the speed of the wheel and thus the increase the duty cycle
on the PWM signal, we would increment the OCRnx register by a fixed value. This was true for the inverse.
When we decremented the OCRnx register, the duty cycle of the PWM would decrease. Also note that the
frequency of the pulses is identical no matter the duty cycle. We used a frequency of about 31 kHz to
optimize the H‐bridge functionality.

Figure 8: Mega644 PWM Output Timing Diagram

Hardware Design
The hardware was designed to create a robotic car with four individually controlled servo motors using
PWM signals and H‐bridge circuits. The rotation of each motor was measured with a 2‐bit (gray code) rotary
encoder. Additionally, the acceleration of the vehicle was measured with a z‐axis 1.5g acceleration sensor. A
basic schematic of the hardware setup is shown below.

H‐Bridge Motor Driver

The H‐Bridge circuit allows the microcontroller to run a two‐terminal motor without any large noise
spikes feeding back into the microcontroller circuitry. When the motor is switched on and off, there is a large
change in voltage in a short period of time. Since the motor can be modeled as an inductor, the big change in
voltage will cause a huge spike in current, which can destroy the input terminal of the microcontroller. This is
prevented by wiring diodes across four MOSFET in the configuration shown below to stop current from flowing
when the MOSFET is turned off. These devices have similar properties of a switch because they can limit or
amplify the flow of current depending on the voltage across the gate to body terminals.

…cornell.edu/…/Traction Control Andre… 9/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 9: H‐Bridge Motor Driver Schematic

The H‐Bridge came in a 8‐pin SOP package with inputs for V cc, ground, forward pulse width modulation
(PWM), and reverse PWM. There were two outputs to wire across the terminals of the motor. Since there
were two separate inputs for forward and reverse PWM signals, our design was utilized only the forward PWM
signal to control how the vehicle moved in the forward direction.

Figure 10: Two H‐Bridges on an SOIC Header

Rotary Encoder

The rotary encoders are used to resolve wheel velocity and acceleration. The encoders output a two
bit binary quadrature signal, meaning they output two pulse width signals that are 90 degrees out of phase.
The pulses are generated by opening and closing switches to a common ground. Therefore, in order to
generate a readable signal from the encoders, we used pull‐up resistors on the signal lines. Also, since the
two phases were not sufficiently accurate relative to eachother, we only use 1 signal from each encoder. This
cuts the number of pulses per rotation in half, but gives us a more consistent signal for accurate timing.

…cornell.edu/…/Traction Control Andre… 10/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 11: Rotary Encoder Schematic

The specific encoders we used had 16 pulses per rotation. This means that there were four periods
per rotation. The repetition would be insufficient for us to determine the position of the wheel (it is
ambiguous which quadrant the wheel is in) but satisfactory for determining velocity. An example signal and
rotary position is shown below. Velocity is determined by timing the difference between the rising and
falling edges. Similarly, acceleration can be determined by calculating the difference in velocity between two
adjacent pulses. Note the acceleration between the orange phase and green phase.

Figure 12: Pulse signal from encoder with encoder position

Servo Motors

To rotate the wheels of our vehicle, we used four continuous rotation servo motors. They run on a
maximum of 6 volts DC and rotate a full 0 to 180 degrees. An image of the motor is shown below. To attach
the rotary encoder, we modified each motor by removing the back plate and attaching a metal rod to the back
side of the rotating gear. We then used flexible clear plastic tubing to form a connection between the metal
rod and the rotary encoder. A picture of the modification is shown below.

…cornell.edu/…/Traction Control Andre… 11/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 13: Servo Motor Layout

Figure 14: Servo Motor Layout

ATmega644

The Atmel Mega644 was used to control and monitor the acceleration and velocity of our vehicle. The
major features of the Mega644 that were used for our project included one 8‐bit timer, 4 PWM output pins,
one Analog to Digital converter, and four standard I/O pins. The Mega644 chip was built on a prototype board
provided by Bruce Land. It features an easy way to power, attach a crystal clock, connect to a RS232 interface,
and program the Atmel chip. A schematic of the board can be found here.

We chose to attach the optional interface for serial communication because it provided critical debugging
features and we had extra money to budget. An image of a completed prototype board is displayed below
courtesy of the ECE 4760 website.
…cornell.edu/…/Traction Control Andre… 12/18
5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 15: Sample proto‐board from 476 website

Results
In general, the end result of our traction control was a success. The vehicle was able to ramp up its
velocity uniformly without any major slipping. When the vehicle reached its desired speed, the wheels
maintained their velocity and generally stayed in balance with each other. In order to test that out system
was working, we performed two tests. First, we placed tightly fitting rubber bands around the outside rims of
the left two wheels and kept the plastic wheels on the right side unmodified. We then started up the vehicle
in the hallway on hard tile flooring. As the car started up, the velocity of each wheel was maintained a
constant rate and the car moved in a relatively straight path for about 2 meters.

The results of the start‐up can be seen in the plot below. When the car first starts, wheel number 4,
shown in turquoise, is established as the fastest wheel and wheel number 3, shown in red is the slowest
wheel. Almost immediately, wheel 4 jumps up to 14 rpm and is promptly slowed to run at the same speed as
the other wheels. The wheels continue to pick up speed, until they reach a programmed desired speed. It is
held at this speed for a few seconds. Looking at the region between 3 and 7 seconds, wheel number 2
naturally tries to run at a speed faster than desired. This is recognized by the microcontroller and the PWM is
adjusted to make the wheel run slower. The reverse is true for wheel 3 and the microcontroller sends more
power to the motor to account for this.

The second test involved pushing down on a single wheel and slowing it down to a very low velocity.
The system would pass this test if the other wheels recognized that they were rotating too quickly and slowed
down appropriately. The results of this test are also shown in the graph below. At about 7 seconds, the
second wheel is held down and its velocity drops to about 6 rpm. The response of the other wheels 1 and 3 is
pretty fast and responds to the velocity change within a couple of measurement cycles. Wheel 4 was the
slowest to respond to the change, taking less than 1 second. Although there is a fast response time to the
velocity change, the time it takes to actually slow the other wheels to the slowest level takes a very long
time. As shown in the graph, it takes well above 2 seconds for the other wheels to drop down to 10 rpm.

…cornell.edu/…/Traction Control Andre… 13/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 16: RPM vs Time for Traction Control Start‐up

…cornell.edu/…/Traction Control Andre… 14/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…

Figure 17: Worst Case RPM vs Time Scenario

The results of our second traction control test are shown above. At about 1 second, the 4th wheel is
held down and it slows to 20 rpm. The other wheels respond in about the same manner as the first test.
Overall, we can see that it takes around 3 seconds to the wheels to completely adjust to a large change in
velocity. Then, at 12 seconds the wheel is released. Since wheel 4 naturally ran the fastest of all the wheels,
there was a large acceleration. The system tries to respond to the situation, but it takes over 8 seconds just
for the wheels to recover about ¾ of the velocity difference. This was a worst case scenario for our traction
control system.

Conclusions
Analysis

Our prototype traction control system demonstrates how a high speed microcontroller can be used to
accurately control a varying and possibly unstable system. Our controller effectively throttled wheel speed
when a slip was detected as well as actively controlled wheel rotation to maintain the desired speed.
Although our results demonstrated the functioning of our code, we originally hoped for a faster response

…cornell.edu/…/Traction Control Andre… 15/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
ideally being able to correct wheel slip within one rotation. The slow response was mainly caused by
adjusting the PWM pulses by 1% each time a measurement was recorded. We sacrificed a fast responding
system for a more stable one. This is always a careful balance to choose for many engineering problems. The
addition of higher accuracy encoders as well as implementing a more sophisticated control algorithm would
help us achieve more desirable results. Due to our implementation of a four wheel, independent drive
system, our project would require some significant overhead to be integrated with other commercial vehicle
stability systems such as ABS (anti‐lock breaking system) and ESC (electronic stability control) systems. This
again was a trade‐off as integrating with the various automotive communication standards and devices would
in itself be a substantial design project.

Standards and Intellectual Property

Our project did not require the use of any public or private domain software or any proprietary
hardware. Although our specific implementation of a traction control system itself would not be sufficient for
a patent, it does serve as a strong baseline for further development on traction control. Traction control itself
is a fairly new technology and is just now becoming main‐stream in consumer automobiles. There is certainly
substantial opportunity for improvement to the current algorithms and systems used today, especially if the
focus is moved to include performance (most traction control systems are for safety only and can negatively
affect performance).

Ethics

During the design of our traction control system we had to keep in mind the use of such systems and
the ethical responsibilities of design. Most traction control systems are used on consumer motor vehicles as a
safety system. Our system, as well as commercial grade systems, has the ability to over‐ride driver control. A
malfunction of this system could significantly compromise the safety of the passengers as well as others on
the road. Even if the system was not used on a passenger vehicle, it is still partially or wholly responsible for
the movement of a potentially dangerous object. Therefore during our design we constantly had to keep
safety in mind and try to design such that failures are minimized and will not result in an out of control
vehicle. This was reflected in our decision to keep the less aggressive method of throttling up wheel speed
and using small accepted margins of error. This means that our model car’s acceleration was significantly less
than the motors where capable of doing, but the slower accelerating vehicle would have better slip protection
favoring safety over performance.

Appendix
Budget

Item Unit Price Quantity Price

Electric Servo Motor Sampled 4 0.00
Rotary encoder 2.58 4 10.32
IC H‐Bridge 1.35 4 5.40
Atmel Mega 644 Sampled 1 0.00
MAX233ACPP Sampled 1 0.00
…cornell.edu/…/Traction Control Andre… 16/18
5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
Custom PC Board 4.00 1 4.00
Max233CPP 7.00 1 7.00
RS232 Connector 1.00 1 1.00
SOIC Carriers 1.00 2 2.00
Accelerometer Sampled 1 0.00
Car chassis Borrowed from MAE 1 0.00
Scrap Metal Free 1 0.00
Wheels Borrowed from MAE 4 0.00
9 Volt Battery 2.00 1 2.00
AA 1.5 Volt Battery 0.50 4 2.00
TOTAL $33.72

Source Code

Task Distribution

Andrew Gifft

• Motor Control Software

• Encoder Hardware and Measurement Software
• Hyperterm/ Debugging Code
• Compiling Hardware Components Together
• Debugging
• Final Report

Rob Miceli

• Robot Chassis Frame Extension

• H‐bridge Hardware
• PC Board Fabrication
• PWM Control Code
• Debugging
• Final Report

Acknowledgements

We would like to thank Bruce Land for his help and dedication to ECE 4760 Designing with
Microcontrollers. We would also like to thank our TA Yuan Ning and the other 4760 TAs for their help and
many hours in the 4760 lab. Additionally, we would like to thank Atmel and Maxim‐IC for their sampled
parts. Lastly, we would like to thank the Mechanical Engineering Department for allowing us to borrow the

…cornell.edu/…/Traction Control Andre… 17/18

5/14/2011 courses.cit.cornell.edu/ee476/FinalProj…
robotic vehicle parts.

References

AtMega644 Datasheet

Encoder Datasheet

H‐Bridge Datasheet

Servo Motor Datasheet

Accelerometer Datasheet

ECE 4760 Webpage

…cornell.edu/…/Traction Control Andre… 18/18