Escolar Documentos
Profissional Documentos
Cultura Documentos
edu/ee476/FinalProj…
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.
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.
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.
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:
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
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.
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.
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
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.
Due to the relatively slow servo motor maximum speed, encoder signal noise, and difficulties with
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).
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).
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.
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.
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.
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.
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.
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.
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.
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…
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.
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
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
Source Code
Task Distribution
Andrew Gifft
Rob Miceli
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
References
AtMega644 Datasheet
Encoder Datasheet
H‐Bridge Datasheet
Accelerometer Datasheet