Difference between revisions of "S16: Autonomous Lane Changer"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Schedule)
(Conclusion)
 
(61 intermediate revisions by the same user not shown)
Line 11: Line 11:
 
</font>
 
</font>
  
== Autonomous Lane Changer==
+
== Autonomous Lane Changer ==
* Include Image Later
+
 
 +
[[File:CmpE146_S16_Jatrick_Car.jpg|500px|center]]
  
 
== Abstract ==
 
== Abstract ==
Line 18: Line 19:
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.
+
 
 +
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 ===
 
=== Team Members & Responsibilities ===
Line 34: Line 38:
  
 
== Schedule ==
 
== Schedule ==
Show a simple table or figures that show your scheduled as planned before you started working on the project.  Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals.  The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 76: Line 79:
 
! scope="row"| 4
 
! scope="row"| 4
 
| 4/24
 
| 4/24
| Complete project and begin testing and debugging.
+
| Finalize project and begin testing and debugging.
| Completed?  Problems Encountered?
+
| Completed.
|
+
| 5/19
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
| 4/24
 
| Finalize project and begin testing and debugging.
 
| Completed?  Problems Encountered?
 
|
 
|-
 
! scope="row"| 6
 
 
| 5/2
 
| 5/2
| Implement additional features. Ex. safety features.  
+
| Finish testing.  
| Completed?  Problems Encountered?
+
| Completed.
|
+
| 5/23
 
|-
 
|-
! scope="row"| 6a
+
! scope="row"| 5a
 
| 5/6
 
| 5/6
 
| Finalize project and prepare car for demo purposes.  
 
| Finalize project and prepare car for demo purposes.  
| Completed?  Problems Encountered?
+
| Completed.
|
+
| 5/23
 
|}
 
|}
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components.  Do not write long stories here.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 107: Line 103:
 
! scope="col"| Description
 
! scope="col"| Description
 
! scope="col"| Price
 
! scope="col"| Price
 +
|-
 +
| 2
 +
| SJone Boards
 +
| $80 each = $160
 
|-
 
|-
 
| 1
 
| 1
Line 124: Line 124:
 
| $3.95 per pair
 
| $3.95 per pair
 
|-
 
|-
| 2
+
| 1
 
| MC14051 Analog Multiplexer
 
| MC14051 Analog Multiplexer
| $0.49 each = $0.98
+
| $0.49
 
|-
 
|-
| 1
+
| 2
| IR reflecting tape
+
| Light colored masking tape
| TBD
+
| $10.00
 
|-
 
|-
 
| 30
 
| 30
 
| Jumper Cables
 
| Jumper Cables
| TBD
+
| 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 ==
 
== Design & Implementation ==
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
 
=== Hardware Design ===
 
=== Hardware Design ===
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
 
 +
[[File:CmpE146_S16_Jatrick_Sensors.jpg‎|600px|thumb|center|SJOne Board & Analog IR Sensor 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.
 +
 
 +
 
 +
[[File:CmpE146_S16_Jatrick_Motors.jpg‎|600px|thumb|center|SJOne Board & DC Motor Interface]]
 +
 
 +
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.
 +
 
 +
 
 +
[[File:CmpE146_S16_Jatrick_SensorOrientation.jpg‎|600px|thumb|center|RC Car Mounted Sensor Orientation]]
 +
 
 +
In order to follow lanes as accurately as possible, we mounted the sensors as shown in the figure above.
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
 
 +
* '''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.
 +
 
 +
[[File:CmpE146_S16_Sensor.jpg|300px|thumb|center|Analog IR Line Following Sensor]]
 +
 
 +
 
 +
* '''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 ===
 
=== Software Design ===
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+
'''RC Car Flowchart'''
 +
[[File:CmpE146_S16_Jatrick_CarFlowChart.jpg|600px|thumb|center|RC Car Sensor Reading & Motor Control 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'''
 +
[[File:CmpE146_S16_Jatrick_LaneChange.jpg|400px|thumb|center|RC Car Lane Change 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 ===
 
=== 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.
 
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 ==
 
== Testing & Technical Challenges ==
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
 
Make a smooth transition to testing section and described what it took to test your project.
 
  
Include sub-sections that list out a problem and solution, such as:
+
=== 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 ===
  
=== My Issue #1 ===
+
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.
Discuss the issue and resolution.
+
 
 +
=== 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 ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
+
 
 +
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 ===
Upload a video of your project and post the link here.
+
Demo 1: https://youtu.be/tN-m2zH6Z08
 +
 
 +
Demo 2: https://youtu.be/OK0Lh_0brkc
  
 
=== Project Source Code ===
 
=== Project Source Code ===
Line 172: Line 281:
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.
+
 
 +
* 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 ===
 
=== References Used ===
List any references used in project.
+
 
 +
[https://learn.adafruit.com/adafruit-arduino-lesson-13-dc-motors/transistors Controlling DC Motors Using PWM]
 +
 
 +
[http://www.onsemi.com/pub_link/Collateral/MC14051B-D.PDF MC14051B Analog Multiplexer]
  
 
=== Appendix ===
 
=== Appendix ===
 
You can list the references you used.
 
You can list the references you used.

Latest revision as of 04:34, 24 May 2016

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

CmpE146 S16 Jatrick Car.jpg

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

SJOne Board & Analog IR Sensor 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.


SJOne Board & DC Motor Interface

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.


RC Car Mounted Sensor Orientation

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.

Analog IR Line Following Sensor


  • 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

RC Car Sensor Reading & Motor Control 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

RC Car Lane Change 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

MC14051B Analog Multiplexer

Appendix

You can list the references you used.