Difference between revisions of "S16: Autonomous Lane Changer"
Proj 146u1 (talk | contribs) (→Issue #1) |
Proj 146u1 (talk | contribs) (→Conclusion) |
||
(14 intermediate revisions by the same user not shown) | |||
Line 86: | Line 86: | ||
| 5/2 | | 5/2 | ||
| Finish testing. | | Finish testing. | ||
− | | | + | | Completed. |
− | | | + | | 5/23 |
|- | |- | ||
! scope="row"| 5a | ! scope="row"| 5a | ||
| 5/6 | | 5/6 | ||
| Finalize project and prepare car for demo purposes. | | Finalize project and prepare car for demo purposes. | ||
− | | | + | | Completed. |
− | | | + | | 5/23 |
|} | |} | ||
Line 128: | Line 128: | ||
| $0.49 | | $0.49 | ||
|- | |- | ||
− | | | + | | 2 |
| Light colored masking tape | | Light colored masking tape | ||
− | | $ | + | | $10.00 |
|- | |- | ||
| 30 | | 30 | ||
Line 147: | Line 147: | ||
| PN2222 Transistor | | PN2222 Transistor | ||
| Free | | Free | ||
+ | |- | ||
+ | | 2 | ||
+ | | Wireless Antenna (pair) | ||
+ | | $8.99 | ||
|- | |- | ||
| | | | ||
| Total Cost | | Total Cost | ||
− | | $ | + | | $226.02 |
|} | |} | ||
Line 180: | Line 184: | ||
* '''Serial Peripheral Interface (SPI)''' | * '''Serial Peripheral Interface (SPI)''' | ||
− | In order to implement the lane changing feature, we thought it was be best to send a signal from a separate SJone board through the Nordic wireless. One board acted as a | + | In order to implement the lane changing feature, we thought it was be best to send a signal from a separate SJone board through the Nordic wireless. One board acted as the transmitter which sent the car a signal to turn "Left" or "Right". The other board, the receiver was attached to the RC car for receiving the "Left" and "Right" signal. |
Line 191: | Line 195: | ||
=== Software Design === | === Software Design === | ||
− | |||
− | |||
'''RC Car Flowchart''' | '''RC Car Flowchart''' | ||
[[File:CmpE146_S16_Jatrick_CarFlowChart.jpg|600px|thumb|center|RC Car Sensor Reading & Motor Control Flowchart]] | [[File:CmpE146_S16_Jatrick_CarFlowChart.jpg|600px|thumb|center|RC Car Sensor Reading & Motor Control Flowchart]] | ||
Line 253: | Line 255: | ||
=== Issue #2 === | === Issue #2 === | ||
− | + | The second issue the team ran into was the layout of the sensors. Originally we had 3 sensors on each side running from the front of the car to the back of the car. The problem with the original layout was that the sensors were parallel with the lane lines on our black board. Even when the car was turned slightly, it was nearly impossible for the sensors to detect the white line. With the new layout, the team put 3 sensors on the left and 3 sensors on the right. The sensors ran perpendicular to the lane lines making it easier to detect which motor had to run faster. | |
=== Issue #3 === | === Issue #3 === | ||
− | |||
− | + | The third issue we ran into was the condition when the RC car detected no lane lines. Often times when turning, the car wouldn't follow the lane lines perfectly and would eventually veer off course. In instances like these, we wanted to make sure the car knew what direction it was turning last so it could continue turning that direction until lanes were detected again. We solved this issue by including a static int variable. If the car was turning either slight left or hard left, we set the static int to 1 to signify that it was turning left last. If the car was turning slight right or hard right, we set the static int to 0 to signify that it was turning right last. The reason we used a static int variable was because its ability to keep its value after each function call. If we used a regular variable, when the task loops again, the variable would lose its value, thus the car would not know which direction it was turning last. | |
=== Issue #4 === | === Issue #4 === | ||
− | + | ||
+ | The last issue we had was when coding the conditions to turn hard left and hard right, we initially reversed the PWM set values in each motor assuming the motors would turn at exactly the same speed. It was during these tests that we realized that the right motor was a lot weaker than the left motor. After figuring this out, we had to boost the PWM values in the right motor during certain turns. Although it seemed like an easy fix, constant tests of the RC car had to be executed until we found the perfect PWM values. | ||
== Conclusion == | == Conclusion == | ||
− | |||
− | The self-driving RC car project was completed successfully. The team was able to implement the two major features, lane following and lane changing. The self-driving RC car required two SJSUOne boards and 6 IR emitter and receivers. The team first tested sensors to see if it was able to read the white lanes on a black board. Once finding the clearance of the sensor and the | + | The self-driving RC car project was completed successfully. The team was able to implement the two major features, lane following and lane changing. The self-driving RC car required two SJSUOne boards and 6 IR emitter and receivers. The team first tested sensors to see if it was able to read the white lanes on a black board. Once finding the clearance of the sensor and the lanes, assembling the RC car was a simple task. Programming the algorithm for following white lanes and changing lanes was a little tougher. Because the RC car had three sensors on each side, we had to figure out how hard each wheel had to turn to straighten out the RC car to have the sensors read the white lane again. Once we figured out how to follow lanes, both straight and curved, we had to figure out how the car should change lanes. Professor Preet gave us the idea to use the Nordic wireless capability our SJone boards had. Using his advice, we initialized 1 board as a transmitter and the board on the RC car as a receiver. In order for the car to change lanes, we had to send a signal from the transmitter to the RC car. Initializing the wireless was pretty straightforward, but the lane changing algorithm we created was quite difficult. Overall, we were able to successfully create an autonomous car capable of following lane lines and changing lanes when necessary. |
+ | |||
+ | This project ultimately gave us tremendous experience working with microcontrollers in the embedded environment. Despite this project being quite difficult, considering we are only beginners in embedded systems, it was satisfying to be able to create and complete an embedded project. We felt this was the best course in both our undergraduate careers, and we now feel inspired to pursue a career in the embedded field. | ||
=== Project Video === | === Project Video === |
Latest revision as of 04:34, 24 May 2016
Contents
Grading Criteria
- How well is Software & Hardware Design described?
- How well can this report be used to reproduce this project?
- Code Quality
- Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
- Schematic Quality
- Quality of technical challenges and solutions adopted.
Autonomous Lane Changer
Abstract
This project proposes an autonomous RC car that follows lines along the sides that can also change lanes when possible. In the real world, cars driven on the street follow lane markers, unless the car is trying to change lanes. Cars can only change lanes when the lane lines are broken. While autonomous cars are becoming increasingly popular, one of the things to consider besides the car driving itself is the way the car operates on the street, two of those things being to stay within lane markers and changing lanes. Other line following cars follow lines directly in front of them; however, our vehicle will follow lines on its side. When the lines along the side of the car are broken, our car will be able to change lanes. Doing so allows these cars to be integrated onto real city streets without having to change current road infrastructure that are already in place. The aim of this project is to mimic this idea at a smaller scale in hopes of not only finding a way for autonomous vehicles to be integrated onto existing city streets, but also for us, as inexperienced students, to learn an important skills that will be applied in our future careers.
Objectives & Introduction
Typical line following RC cars follow lines directly below and in the middle of the car. While this is a great design for the concept, we wanted to change it so that a line following RC car mimics real world self-driving cars by following real lanes on streets. The objective of this project is to create a lane following robot capable of changing lanes when necessary.
In order to achieve this, our group utilized IR receiver pair sensors to sense the road below and the lane lines along the side. In order to implement a lane changing feature, we decided to utilize the board's wireless functionality to communicate to the car when to change lanes.
Team Members & Responsibilities
- Patrick-Daniel Llanes
- Programming Sensors
- Programming Line Following Algorithm
- Programming Lane Changing Capability
- Report Writing
- Jonathan Lo
- Car assembly
- Sensor Mounting
- Programming Line Following Algorithm
- Programming Lane Changing Capability
- Report Writing
Schedule
Week# | Date | Task | Status | Completion Date |
---|---|---|---|---|
1 | 4/6 | Gathered and ordered parts for Autonomous Lane Changer. | Completed. | 4/11 |
2 | 4/11 | Begin building autonomous car. | Completed. | 4/18 |
2a | 4/13 | Complete build and begin testing IR sensors and motors. | Completed. | 4/18 |
3 | 4/17 | Compute PWM duty cycles for motors. | Completed. | 4/19 |
3a | 4/20 | Integrate IR sensors and begin testing sensors. | Completed. | 4/22 |
4 | 4/24 | Finalize project and begin testing and debugging. | Completed. | 5/19 |
5 | 5/2 | Finish testing. | Completed. | 5/23 |
5a | 5/6 | Finalize project and prepare car for demo purposes. | Completed. | 5/23 |
Parts List & Cost
Quantity | Description | Price |
---|---|---|
2 | SJone Boards | $80 each = $160 |
1 | Shadow Chassis | $12.95 |
1 | Wheel-65mm (Rubber Tire, Pair) | $2.95 |
6 | SparkFun Line Sensor Breakout QRE1113 (Analog) | $2.95 each = $17.70 |
2 | Motors | $3.95 per pair |
1 | MC14051 Analog Multiplexer | $0.49 |
2 | Light colored masking tape | $10.00 |
30 | Jumper Cables | Free |
1 | Black Duct Tape | $8.99 |
2 | 220 Ohm Resistor | Free |
2 | PN2222 Transistor | Free |
2 | Wireless Antenna (pair) | $8.99 |
Total Cost | $226.02 |
Design & Implementation
Hardware Design
To create an autonomous lane changer RC, IR emitters and receivers were used to detect lines under the RC car. The IR emitter is a source of light energy and the levels of reflectivity are received by the IR receivers. Due to the limited amount of ADC pins available on the SJOne board compared to the amount of analog sensors we implemented, we used the MC14051 Analog Multiplexer with digital controls, allowing us to implement more analog peripherals to our board, and controlling them digitally using 3 GPIO pins.
We chose a simple DC motors for our RC car. In order to use the PWM API provided by our Eclipse environment, we constructed a transistor circuit shown above. Doing so allowed us to control the speed of each individual motor, allowing more control for steering. The motors on the RC car will adjust depending on the levels of reflectivity from the IR receivers.
In order to follow lanes as accurately as possible, we mounted the sensors as shown in the figure above.
Hardware Interface
- Analog Digital Converter (ADC)
For this project, we utilized 6 analog IR emitter/receiver pair sensors. Because they were analog sensors, couldn't have connected these sensors directly to any GPIO pins, but needed to connect them to the ADC pins. Because we had more sensors than available ADC pins, we used an analog multiplexer to hold multiple analog inputs, and connected the common output a single ADC pin.
- Serial Peripheral Interface (SPI)
In order to implement the lane changing feature, we thought it was be best to send a signal from a separate SJone board through the Nordic wireless. One board acted as the transmitter which sent the car a signal to turn "Left" or "Right". The other board, the receiver was attached to the RC car for receiving the "Left" and "Right" signal.
- General Purpose Input Ouput (GPIO)
Because we used 6 analog sensors while our board only had 3 available ADC pins, we needed to use a digitally controlled analog multiplexer. We fed the outputs of the sensors as inputs to the multiplexer. The single, common output of the multiplexer was connected to the ADC pin as explained earlier. In order to control which sensor value passed through the MUX, we needed to change the control signals of the MUX. Because this was a digitally controlled MUX, we initialized 3 GPIO pins to act as the control signals.
Another utilization of GPIO pins was for the PWM signals. In order to control the motors, we contructed the circuit described in the hardware design section. We then used the PWM API provided to us in order to control the speed of each motor.
The last way we used GPIO pins was from the transmitter board. When changing lanes, we had the transmitter board send a character over Nordic wireless once one of the on-board switches was pressed. Depending on the switch, a certain character was sent to the RC car which would then execute either a left or right turn once received.
Software Design
RC Car Flowchart
Above is the flowchart for our autonomous car and how the motors react depending on the sensor values. Once everything is initialized, the values from the sensors are latched into different variables. Depending on the sensor values of each sensor, the motors will react accordingly.
Wireless Flowchart
Above is the flowchart for the wireless portion of the autonomous car. Our transmitter board's only job is to send a signal to the RC car, thus a flowchart was not necessarily vital to show the wireless implementation. The receiver board attached to the RC car has its flowchart described above. If the receiver board receives a character 'l', then the RC car will change lanes to the left. If the receiver board sends a character 'r', then the RC car will change lanes to the right.
Implementation
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
IR Sensor Implementation & Motor Control (Step by Step)
1. Send control signals to MC14051 (Analog Multiplexer) to collect data from all 6 sensors.
2. Each sensor value is stored into their own variable in the program.
3. Check Sensor Three and Four first. If Three < 1000, then turn hard Right. If Four < 1000, then turn hard Left.
4. If sensors Three and Four have a value > 1000, then check sensors Two and Five. If Two < 1000, turn slight left. If Five < 1000, turn slight right.
5. If sensors Three, Four, Two, and Five have a value > 1000, then check sensors One and Six. If either of these are < 1000, go straight.
6. Repeat steps, 1 - 5.
Nordic Wireless Communication (Tx Side) (Step by Step)
1. Initialize char hops to "1" and char address to "150".
2. Set char left = "l", char right = "r", and char x = "x".
3. Initialize switch 0 and 3 as input on transmitter board.
4. If switch 0 is pressed, send character "left" to signal RC car to turn left.
5. If switch 3 is pressed, send character "right" to signal RC car to turn right.
6. At the end of the task, send character "x" to clear buffer on receiving side.
Nordic Wireless Communication (Rx Side) (Step by Step)
1. Set node address to "150".
2. Check rx buffer to see if any character is received.
3. If pkt.data[0] == 'l', RC car changes lanes to the left.
4. If pkt.data[0] == 'r', RC car changes lanes to the right.
Testing & Technical Challenges
Issue #1
The first issue we came across was the analog pins on the SJSUOne board. For our design, we decided to use 6 analog IR sensors, used to detect lane markers on the road. After looking at the board's schematic, we realized only 3 analog pins were available to us. After doing some research, we found an IC that solved our issue: MC14051, an analog multiplexer. This multiplexer allowed up to 8 analog inputs, which was more than enough for the amount of sensors we had. What also made this multiplexer a good fix was that the control pins were digitally controlled, allowing us to configure GPIO pins from the SJOne board for the control inputs to the analog multiplexer.
Issue #2
The second issue the team ran into was the layout of the sensors. Originally we had 3 sensors on each side running from the front of the car to the back of the car. The problem with the original layout was that the sensors were parallel with the lane lines on our black board. Even when the car was turned slightly, it was nearly impossible for the sensors to detect the white line. With the new layout, the team put 3 sensors on the left and 3 sensors on the right. The sensors ran perpendicular to the lane lines making it easier to detect which motor had to run faster.
Issue #3
The third issue we ran into was the condition when the RC car detected no lane lines. Often times when turning, the car wouldn't follow the lane lines perfectly and would eventually veer off course. In instances like these, we wanted to make sure the car knew what direction it was turning last so it could continue turning that direction until lanes were detected again. We solved this issue by including a static int variable. If the car was turning either slight left or hard left, we set the static int to 1 to signify that it was turning left last. If the car was turning slight right or hard right, we set the static int to 0 to signify that it was turning right last. The reason we used a static int variable was because its ability to keep its value after each function call. If we used a regular variable, when the task loops again, the variable would lose its value, thus the car would not know which direction it was turning last.
Issue #4
The last issue we had was when coding the conditions to turn hard left and hard right, we initially reversed the PWM set values in each motor assuming the motors would turn at exactly the same speed. It was during these tests that we realized that the right motor was a lot weaker than the left motor. After figuring this out, we had to boost the PWM values in the right motor during certain turns. Although it seemed like an easy fix, constant tests of the RC car had to be executed until we found the perfect PWM values.
Conclusion
The self-driving RC car project was completed successfully. The team was able to implement the two major features, lane following and lane changing. The self-driving RC car required two SJSUOne boards and 6 IR emitter and receivers. The team first tested sensors to see if it was able to read the white lanes on a black board. Once finding the clearance of the sensor and the lanes, assembling the RC car was a simple task. Programming the algorithm for following white lanes and changing lanes was a little tougher. Because the RC car had three sensors on each side, we had to figure out how hard each wheel had to turn to straighten out the RC car to have the sensors read the white lane again. Once we figured out how to follow lanes, both straight and curved, we had to figure out how the car should change lanes. Professor Preet gave us the idea to use the Nordic wireless capability our SJone boards had. Using his advice, we initialized 1 board as a transmitter and the board on the RC car as a receiver. In order for the car to change lanes, we had to send a signal from the transmitter to the RC car. Initializing the wireless was pretty straightforward, but the lane changing algorithm we created was quite difficult. Overall, we were able to successfully create an autonomous car capable of following lane lines and changing lanes when necessary.
This project ultimately gave us tremendous experience working with microcontrollers in the embedded environment. Despite this project being quite difficult, considering we are only beginners in embedded systems, it was satisfying to be able to create and complete an embedded project. We felt this was the best course in both our undergraduate careers, and we now feel inspired to pursue a career in the embedded field.
Project Video
Demo 1: https://youtu.be/tN-m2zH6Z08
Demo 2: https://youtu.be/OK0Lh_0brkc
Project Source Code
References
Acknowledgement
- We would like to thank Preet for giving his time to teach us the fundamentals and applications of embedded systems, and giving us the opportunity to create our first embedded project. You've definitely inspired us to pursue a career in embedded systems.
- We would also like to thank Dr. Ozemek for teaching us the fundamentals of embedded systems, and giving us the inspiration to change our lifestyles.
References Used
Controlling DC Motors Using PWM
Appendix
You can list the references you used.