Traction control system Using Atmega644
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.
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.
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:
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 < DT and some minimum value ymin for the rest of the period, DT < 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 :
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 XORs 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.
inally, 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.
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 our 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 wheels 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).
|Electric Servo Motor||Sampled|
Atmel Mega 644
|Custom PC Board||4.00|
|Car chassis||Borrowed from MAE|
|Wheels||Borrowed from MAE|
|9 Volt Battery||2.00|
|AA 1.5 Volt Battery||0.50|
For more detail: Traction control system Using Atmega32
Leave a Comment
You must be logged in to post a comment.