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.
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.
Figure 2: Basic Feedback Loop Structure
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:
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
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 ymin 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.
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.
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 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.
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 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 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.
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.
Figure 9: H-Bridge Motor Driver Schematic
The H-Bridge came in a 8-pin SOP package with inputs for Vcc, 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.
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.
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.
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.
Figure 16: RPM vs Time for Traction Control Start-up
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
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 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.
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).
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.
Source Code download here
References
0 comments:
Post a Comment