 A 1996 Firebird after crashing into a telephone pole. |
Introduction - cars and vehicles have been integrated into society as one of the most efficient, easiest, accessible means of transportation available. But while it is a convenient and common means of transportation, it is also an incredibly dangerous mode of transport. Thousands of people die in automobile accidents each year, whether it is a collision with another vehicle or a stationary object.
A method of early collision detection and avoidance could curb several of the accidents that may be related to factors such as loss of control, careless driving, sleepy/drunk drivers, and not paying attention to the road. Although it is not a standard safety feature in any car on the current market, the use of sensory equipment to detect potentially dangerous objects a certain distance away and either slow the car down or steer to a safer path has not been released.
Our project was to take a remote controlled Humvee vehicle and add an ultrasonic sensor to it. Simulating a possible advancement in safety/security systems in cars and automobiles, the R/C Humvee and Sensor would be able to operate normally until the sensor detects a possible hazard. In our case, the sensor would face forwards until the car came within ~4 feet of an object, at which time user control would be disconnected from the motor, the sensor would rotate to find the safest path, if any (or back up if there was none), and steer towards that path.
The "smart" logic of the car would be controlled through an Atmel Mega163 programmable chip, which we coded for the project. The recieved commands from the "driver" (the remote control) would pass through the Mega163, and the Mega163 would determine the car's best course of action based on the results of pulses from the sensor. The Mega163 would then drive the car motors as well as recieve information on object distance from the sensor in order to avoid any collisions. The design, implementation, analysis, schematics, and code can be found through the rest of this web page.
High Level Design
The modified remote control vehicle we purchased had to have certain functionalities:
1. The user must still be able to "drive" it - after all, you don't just get into a car and let the car run.
2. The vehicle must never collide with any objects.
3. The vehicle must have its own power to detect "danger" if the driver cannot.
4. The vehicle must take a course of action since the human cannot be trusted.
5. This simulation vehicle must be implemented with a programmable Mega163.
6. The vehicle must stand on its own [i.e. be mobile].
 A top view of our vehicle. |
1. Since the user must be able to drive the vehicle normally, the Mega163 must read the original commands of the driver and be able to pass these instructions to the motor system during normal operation. In the design of our vehicle, we merely cut the connections from the reciever in the car to the motor system and used it as an input to our Mega163 [input to port D]. The functions of the car [forwards, backwards, left, right] were controlled through four connections in the original implementation; we "intercepted" these 4 signals and used them as inputs to our PORT D. During normal operation (where objects are further than 4 feet away) the input from PORT D is translated to the output from our PORT B that feeds into the motor system (see part 6).
2. The vehicle never collides with any objects because power to the motors is cut off completely when you come within 4 feet of an object. At this time, the sensor is rotated to find the best possible path of "escape", and the car forces itself to drive in that direction (or reverse in the case where no path is greater than 4 ft.).
3. To detect this danger, we chose to use a DevanTech SRF04 Ultrasonic Range Finder. The means through which distance was found was through a pulsing methodology: a sonic pulse would be sent out from the SRF04 using an interrupt scheme from our Mega163, and then the time until the pulse returned to the SRF04 was measured. Using the speed of sound in air, the distance to the object could be determined from the time for the pulse to go to and from the object.
THE SRF04 was mounted on a rotating motor that would be able to swing in both the left and right directions. In the case where a possible "danger" was detected, the SRF04 would swing left, detect "safety" distance there, swing right, detect "safety distance" on the right, and then allow the Mega163 to determine which had a better path of safety.
 An angled view of our car. |
4. From the previous part, if an object was encountered, the SRF04 range finder would take reading from both the front left and the front right of the vehicle. If "safe distance" was greater on one side (and above 4 ft.) then the car would know to steer in that direction for 2 seconds. If none of these conditions are met, then the vehicle backs up for 2 seconds. Logically, this should cover all situations, since the vehicle steers away from walls, and if it runs into a corner then it backs up and allows the user to reevaluate his course.
5. To implement these decisions and features in a R/C Car with a Mega163, the SRF04 needed to be attached to all 4 PORTs. PORT A was used to send the pulse, as well as recieve it. PORT B was attached as an output from the Mega163 to the motor control systems (for steering the car forward, back, left, and right), PORT C was used to control the motor that's used to rotate the sensor, and PORT D was an input from the user's remote.
6. The vehicle's mobility is due to the motor control system and the Mega163 being attached to an on-vehicle breadboard and being powered by standard 9V and AA batteries. The motor control systems were designed from H-Bridges, constructed using transistors found in lab.
Program Design
Program Design - our program design used an interrupt-driven scheme to poll object distance, calculate, and rationalize the best course of action. The vehicle itself was a state machine, having the states of "Normal Operation", "Detect Left Distance", "Detect Right Distance", "Center", and "Evasive Action" - all of which are fairly self explanatory states. The main() method of our program uses the interrupt to determine times at which to send a pulse through the range finder (30ms) and the times to detect the echo of the pulse recieved back (every 1ms). Since the speed of the vehicle was extremely slow, this was an adequate enough accuracy for the car to be able to determine a decently accurate reading of distance.
Pulsing - Pulsing was done by raising the 0 bit of PORT A high and then switching it back low. This would send a supersonic wave out to "bounce" off any objects in the direction it was sent. A counter variable was incremented for every time period the pulse was not returned, and when the pulse was returned (PORTA.1 high being a recieved pulse) then the distance was calculated.
The process is outlined as follows:
Our state machine runs off timer0 with a period of about 30ms.
The cycle flows as follows:
(1) Check to see if last distance measurement was less than 3 feet.
(2) Run State machine function
(2a) If distance was not less than three feet, assign remote control signal to steering and motor.
(2b) If distance was less than three feet, change state and continue to run in the check left state for 16 periods (or about half a second)
(2c) If 16 periods have passed then change state to check right. Run check right for 24 periods (or about one second)
(2d) If 40 periods have passed then change state to center. Run center for 16 periods.
(2e) If 56 periods have passed then change to evade state and use left and right distances to determine whether to go back forward left or forward right.
(3) Put Sensor pulse high
(4) Zero distance
(5) Put Sensor pulse low
Normal Operation State - During this state, commands from the driver/user are merely passed to the motor scheme.
Detect Distance Left State - The motor controls are shut down and the car is brought to a halt if the distance to an object in the front of the vehicle is less than ~4 ft. The motor attached to the sensor is operated to direct the sensor in the forward left direction to detect objects.
Detect Distance Right State - the motor attached to the sensor is operated to direct the sensor in the forward right direction to detect objects.
Center - The sensor is re-aligned in the forward direction for future detection of objects in front of the vehicle.
Evade - the code calls to run the motors in the proper direction (forward left, forward right, or backwards) for 2 seconds in order to "evade" obstacles.
Hardware Design
Hardware Design - the Hardware we designed was used to "intercept" the user controls and then output our own controls to the vehicle. We therefore used the reciever/transmitter system that came with the R/C Humvee, and had to construct our own motor-driving system using H-bridges for bi-directionality in order to implement our "Safety Features". For additional info, see "Results".
Motor System [H Bridge] - The 5V output from the PORT B pins did not have enough current to drive the motors to steer and drive the vehicle, or to rotate the sensor. For that reason we were forced to use self-made H-Bridges in order to drive the motors. Using two TIP32C (PNP) Transistors and two TIP31C (NPN) Transistors, along with diodes and resistors to draw current from the inputs, we constructed H-Bridges that could operate the motor in the forward and reverse directions using complementary inputs, as shown in the schematic below:
H-Bridge
The same system was used for Left/Right, and the sensor motor's Left/Right. Unfortunately, this H-Bridge system was not as powerful as we had hoped. For this reason, we used a 9V battery to supply power to the motors, while still powering the Mega163 with 4 AA batteries.
SRF04 Range Finder - We used a sonic range sensor pointed straight ahead to determine if there is an obstacle in front of the vehicle. The range finder has a detection cone of 30 degrees so we will be able to find objects at about 1.5 m at that are about 1.2 feet to our left, right, and above. The range finder is mounted to a block of wood which turns 30 degrees to the left and 30 degrees to the right. The detection system is mounted on top of the hummer and has an obstruction to prevent turns that are out of range. Upon detection of an object, the microcontroller puts 5V on one of the wires connected to the detection system H-bridge and 0V on the other wire. This difference in potential causes the sensor detection system to check left. About a half second later the microcontroller flips the polarity of the signal so that the detection system can check right. Finally in about 1 second the polarity is flipped again to return the sensor to center.
Functionality of the range finder - The range finder takes as input a pulse with a period of 30ms and a pulse duration of 10 micro seconds. The output is a signal that is held high for a duration proportional to the distance.
The Range Finder does not automatically detect distance; rather, the range finder had to be connected as follows:
SRF04
Echo Output would send a signal to the Mega163 when a pulse was recieved back, while Pule Trigger Input took a signal from the Mega163 in order to send out the sonic pulse.
Atmel Mega163 Connections - The Mega163 was removed from the STK200 board and placed on our bread board. We used the internal 1MHz clock (using fuse bits to select the internal clock during programming) and attached Vcc and ground to 4 AA batteries. We used a resistor to connect !RESET to Vcc as well. The PORT/PIN connections are as follows:
Atmel Mega163 Pin Connections
Results
Sensor System - The Range Finder/Sensor System worked beautifully. However, the rotation of the sensor did not. Essentially, the motor that rotates the sensor was not powerful enough to overcome the force exerted on the sensor by the connection wires (which were pretty stiff). When the sensor has no wires attached, the system can rotate. The problem led to very limited use of the "detect left" and "detect right" function where we choose the safest path. The sensor system did work in the fact that it always cut the power when it approached an object, and then attempted to scan around (the sensor can be seen twitching to try to rotate left and right to scan), and then the motor was activated for evasive action for 2 seconds in the proper direction. If the motor to rotate the sensor worked better, then this part of the project would have worked beautifully.
Motor System - the motor system was an unexpected complication in our project. When designing our project, we focused completely on the sensor aspect of the project. It did not even occur to us that outputs from the Mega163 would not have enough current draw to activate or drive the motors. This resulted in us having an unexpected "2nd half" to our final project that we totally did not know about or plan until it was too late to order parts. Therefore, we had to construct a home made H-Bridge System (we did try to go to Radio Shack and other electronics store but these parts were unavailable). The performance of our H-Bridge is very lacking, considering the car cannot steer fully left, fully right, nor can it propel itself on its own (without a little shove). Essentially, our remote control vehicle is stationary if it's on the ground. If you lift it off the ground, then you can see the steering, and the driving, but the force of the vehicle's own weight is too much for the motor to handle.
Overall Project - unfortunately, our inability to create powerful enough motor drive limited a lot of what our project can do. The sensing using the range finder worked, and our code [theoretically] works as it should, so overall the vehicle would operate according to our original intentions if our motors were able to operate with more power. The best we can do is pick up and carry the vehicle and simulate its movement [while being able to see the direction of the wheels' turn] through a space and towards/away from objects.
One noticable problem did occur in the response to user controls. When the user input certain commands, the commands would "stick" even after the controls were released. For example, if the user pressed "reverse" on the remote, then the car would go in reverse and continue to go in reverse until "forward" was pressed, or the sensor detected a dangerous object. The same happened with the steering for left and right. Upon checking the code, we could not find any reason for this to happen, since the "still" command is set for when there is no user input. Also, there were problems with the sensor detecting the ground sometimes [which was always within 4 ft]. We raised the angle of the sensor to escape the cone of detection, but for some reason [possibly a very high resonance or noisy environment] it would still detect the ground [we know it is detecting ground because when we carry it in the air it operates successfully]. Because of this, it was constantly throwing itself into evasive mode, and user input was therefore hampered "too much" (i.e. the car would be doing "evasive action" all the time, even when it did not need to).
Analysis
Given more time - we could have ordered parts for a more powerful motor control H-Bridge. As far as we can test through operation of our vehicle (see results) the functionality works fine (except for the "sticking" controls). The addition of a more powerful, better controlled H-Bridge could possibly have made our project exactly what we imagined it to be during conception.
As it is, we are very happy with how the vehicle turned out, considering certain circumstances and the unforeseen motor problems, since our original plan completely revolved around the sensor equipment, which we finished.
Code - The code for our final project can be found here:
/*Henry HsuOscar RamirezECE 476 Final ProjectORT D [Input from RC Reciever]PPin Hookup 0 Motor -3 Steeri1 Motor + 2 Steering -ng +[Output from Board to Vehicle Motors] Pin HPORT B ookup 0 Forward 1 !Forward 2 Reverse!Right POR3 !Reverse 4 Left 5 !Left 6 Right 7 T C [Output from Board to Sensor Motors]Right PORTPin Hookup 0 Left 1 !Left 2 Right 3 ! A [Input/Output from sensor] Pin Hookup 0 Echorement ticks at abo1 Pulse Trigger distance = 2/foot distance in cut 1ms get new distance about every 30ms */ #include <Mega163.h>end } #define t1#include <stdio.h> #include <stdlib.h> #define begin { #defin e16 //left #define t2 24 //right #define t3 16#define t5 120 //Period of sensor readings #define#define t4 66 // t4 is evade time about equals 2 s t6 5 //distance check ticks #define regular 1ions #define forwar#define checkLeft 2 #define checkRight 3 #define center 4 #define evade 5 //Direction output defini td 0xa9 #define back 0xa6 #define left 0x9a #define right 0x6a #define forwardLeft 0x99 #define forwardRight 0x69ht, controls; unsigne#define backLeft 0x96 #define backRight 0x66 #define still 0xaa unsigned char distance, distanceLeft, distanceRi gd char reload; unsigned int time1, time2,time3; unsigned int time4, time5,time6; unsigned char status; void safetyControl(void);(void) begin //reloavoid detectDanger(void); void initialize(void); void pulse(void); void detectecho(void); interrupt [TIM0_OVF] void timer0_overflo wd to force 1 mSec overflow TCNT0=reload; //Decrement the timer if not equal to zero if (time5>0) --time5; if (time6>0) --time6; endting the echo,void main(void) begin initialize(); while(1) begin if (time5==0) pulse(); //pulsing through the sensor if (time6==0) detectecho();//dete cand therefore distance end end void safetyControl(void) begin switch(status) begingin controls = PIND; if (controls == 0) PORTB = still; else if (contrcase regular: //the case where regular operation sends user commands to the motor b eols == 0x01) PORTB = forward; else if (controls == 0x02) PORTB = back; else if (controls == 0x04) PORTB = left; else if (controls == 0x08)PORTB = backRigPORTB = right; else if (controls == 0x05) PORTB = forwardLeft; else if (controls == 0x09) PORTB = forwardRight; else if (controls == 0x0a) ht; else if (controls == 0x06) PORTB = backLeft; else PORTB = still; time1 = t1; break; endbegin PORTC.0=1; //turn on motor to rotate sensor left PORTC.1=0//the case where user input has been cut and we are now "seeking" a safe path case checkLeft: begin if(time1>0 ); PORTC.2=0; PORTC.3=1; PORTB=still; time1--; end else if(time1==0) begin status=checkRight; time2=t2; PORTC.0=0; PORTC.1=1;time2--;PORTC.2=1; PORTC.3=0; distanceLeft = distance; end break; end //testing the forward right direction case checkRight: begin if (time2>0) begi nPORTC.0=0; //turn on motor to rotate sensor right PORTC.1=1; PORTC.2=1; PORTC.3=0; end else begin PORTC.0=0; PORTC.1=1; PORTC.2=0; PORTC.3=1;ORTC.2=0; PORTC.3=1;distanceRight = distance; status=center; time3=t3; end break; end //state to re-center the sensor case center: begin if (time3>0) begin PORTC.0=1; PORTC.1=0; Ptime3--; end else begin PORTC.0=0; PORTC.1=1; PORTC.2=0; PORTC.3=1; status=evade; time4=t4; end break; end case evade: begin(distanceLeft < distanceRight) PORTB=forwardRight; else PORTB=baif(time4>0) //take evasive action front left, front right, or backwards begin time4--; if (distanceLeft > distanceRight) PORTB=forwardLeft; else if ck; end else if (time4==0) //return to regular state begin PORTB=still; status=regular; end break; end end end void detectDanger(void) begin if ((distance != 0) && (distance <= 6) && (status==regular))5=t5; //setting the length of the pulse detectDanger(); safetystatus=checkLeft; //dangerous object detected, go to next state end void detectecho(void) begin time6=t6; if(PINA.0==1) begin distance=distance+1; //incrementing the distance due to time delay end end void pulse(void) begin tim eControl(); //determine output to motors PORTA.1=1; //pulsing distance=0; PORTA.1=0; end void initialize(void) begin DDRD=0x00; // PORT D is an input DDRB=0xff; // PORT B is an ouput DDRC=0xff; // PORT C is an ouput DDRA=0xfe; // PORT A.0 is input else output PORTB=still;distance=0; time1=0; time2=0; time3=0; time4=0; time5=t5; time6=t6; status=regular; reload=256-16; //value for 1/4 Msec TCNT0=reload; //preload timer 1 so that is interrupts after 1/4 mSec. TCCR0=2; //prescalar to 8 TIMSK=1; //crank up the ISRs #asm sei #endasmend
SchematicsSchematics -H-Bridge (used with LEFT, RIGHT also)SRF04Atmel Mega163 Pin Connections
0 comments:
Post a Comment