Difference between revisions of "F16: Autonomous Runaway Alarm Car"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Team Members & Responsibilities)
(Stabilizing the Parts)
 
(107 intermediate revisions by the same user not shown)
Line 1: Line 1:
=== Grading Criteria ===
+
[[File:CmpE146 F16 T10 Final Car Model.JPG|thumb|right|530px|Figure 1. Final Car Design]]
<font color="green">
 
*  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.
 
</font>
 
  
 
== Project Title ==
 
== Project Title ==
 +
<center><h3> The Alarm Car </h3></center>
  
 
== Abstract ==
 
== Abstract ==
The Autonomous Runaway Alarm Car is a mobile alarm clock designed to really get people out of bed in the morning. When the alarm goes off, the Runaway Alarm Car starts moving and starts playing an annoying sound or song, forcing the user to chase it around to stop it. This car is capable of detecting obstacles and avoiding them.
+
Students follow a set routine in their daily lives. It begins with waking up in the morning and ends with going to sleep at night, usually. In between, they go to school, eat, and study for their classes. Students use a clock that is synchronized with their local time to indicate which part of their daily routine to perform. While it is easy to switch from task to task when the student is awake, it can be difficult to switch from task to task when one is asleep.
 +
 
 +
Waking up can be one of the most difficult task of the day for an average student. Often times, the student sets an alarm to wake them up in the morning, but they can prove to be ineffective as only a button or switch is required to turn off the alarm. Since the alarm clock is always set at the same location, so turning off the alarm can be an effortless task.
 +
 
 +
The alarm car makes the student really work towards turning off the alarm. It has a high pitched buzzer to irritate and motivate the student to shut the alarm off. To ensure that the student is awake when they shut off the alarm, the car is autonomous and mobile. It uses IR sensors to avoid obstacles and determine the next direction in which the car moves. With this alarm car, the student will be awake and ready to take on their day.
  
 
== 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.
 
 
 
The objective of this project is to create a car that has the functionalities of an alarm clock and be able to avoid obstacles.
 
The objective of this project is to create a car that has the functionalities of an alarm clock and be able to avoid obstacles.
  
 
* Set a timer on the board
 
* Set a timer on the board
 
* Display the timer
 
* Display the timer
* Produce a noise from the buzzer after the timer runs out of time
+
* Produce a noise with the buzzer after the timer reaches 0
 
* Have the car move forward and avoid obstacles using IR sensors when the timer reaches 0
 
* Have the car move forward and avoid obstacles using IR sensors when the timer reaches 0
 
* Turn off the alarm car by pressing a button on the car
 
* Turn off the alarm car by pressing a button on the car
*
 
 
  
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
 
*  Jonathan Chen
 
*  Jonathan Chen
** Motors and wheels
+
** Designed the structure of the car
*** Constructed the car and programmed the board to run the motors  
+
** Programmed the SJOne board to control the DC motors
 
** Implemented the logic for obstacle avoidance
 
** Implemented the logic for obstacle avoidance
 
  
 
*  Andrew Javier
 
*  Andrew Javier
** Implementing the timer task
+
** Implemented the timer task
 +
** Implement the countdown task
 
** Programmed the IR sensor task
 
** Programmed the IR sensor task
** Programmed the buttons to turn on the alarm car
+
** Programmed the buttons to turn on the timer
  
 
== 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 58: Line 47:
 
| 11/13
 
| 11/13
 
| Order the parts
 
| Order the parts
| Complete
+
| Completed
 
| 11/10
 
| 11/10
|
+
| Majority of the parts were ordered
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
Line 66: Line 55:
 
| 11/20
 
| 11/20
 
| Determine design of the car, begin building
 
| Determine design of the car, begin building
| Complete
+
| Completed
 
| 11/19
 
| 11/19
|
+
| Found out that a H-bridge was needed to run the DC motors. Had to order an H-bridge. Built the chassis for the car.
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
Line 74: Line 63:
 
| 11/27
 
| 11/27
 
| Build the car
 
| Build the car
| Complete
+
| Completed
 
| 11/23
 
| 11/23
|
+
| Plan out the connections between the peripherals and the SJOne board
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
Line 82: Line 71:
 
| 12/04
 
| 12/04
 
| Program the car (phase 1)
 
| Program the car (phase 1)
| Complete
+
| Completed
 
| 12/02
 
| 12/02
|
+
| Implemented the timer and buzzer tasks
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
Line 90: Line 79:
 
| 12/11
 
| 12/11
 
| Program the car (phase 2)
 
| Program the car (phase 2)
| Complete
+
| Completed
 
| 12/11
 
| 12/11
|
+
| Had difficulties programming the LCD display and switched to a different alternative display
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
 
| 12/12
 
| 12/12
| 12/20
+
| 12/21
 
| Testing, write the report, make the video, demo
 
| Testing, write the report, make the video, demo
| Incomplete
+
| Completed
|  
+
| 12/21
|
+
| Finished the report and the video
 
|-
 
|-
  
Line 106: Line 95:
  
 
== 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 118: Line 105:
 
! scope="row"| 1
 
! scope="row"| 1
 
| San Jose State University
 
| San Jose State University
| SJ-One Board
+
| SJOne Board
 
| $80.00
 
| $80.00
 
|-
 
|-
Line 138: Line 125:
 
! scope="row"| 2
 
! scope="row"| 2
 
| Amazon
 
| Amazon
| GP2Y0A21Yk0F IR Sensor
+
| GP2Y0A21YK0F IR Sensor
 
| $17.99
 
| $17.99
 
|-
 
|-
Line 175: Line 162:
 
| LCD1602 Monitor
 
| LCD1602 Monitor
 
| $8.49
 
| $8.49
 +
|-
 +
! scope="row"| 1
 +
| Software and Computer Engineering Society
 +
| Buzzer
 +
| Free
 
|-
 
|-
 
! scope="row"|  
 
! scope="row"|  
Line 184: Line 176:
  
 
== 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 ===
+
This is a system overview diagram of the alarm car. There are four main attachments to the SJOne board: two IR sensors, the H-bridge, and a buzzer. The buzzer and IR sensors are standalone and have no additional connections. There are four DC motors connected to the H-bridge.
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
 
 +
[[File:CmpE146 F16 T10 HWBlockDiagram.PNG|frame | center| <center> '''Figure 2. Hardware Block Diagram: System Overview '''</center>]]
  
 
=== 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.
+
==== GPIO ====
 +
Much of the functionality of this project involved the use of the GPIO functionalities of the SJOne Board. During the timer set portion of the project, the GPIO ports use the switch buttons to manipulate the time as well as set the alarm. In both the timer set and countdown portions of the project, the 7-segment display and on board LEDs are used to display the amount of time left before the alarm goes off. For the remaining tasks of the project, the GPIO pins are used to connect to the H Bridge to control the direction of the wheels.
 +
 
 +
<center>
 +
'''GPIO: Pin Connectivity Table'''
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Item
 +
! scope="col"| Port.Pin
 +
! scope="col"| Direction
 +
! scope="col"| Peripheral
 +
! scope="col"| Peripheral Port
 +
|-
 +
! scope="row"|1
 +
| P1.0
 +
| Output
 +
| SJ One Board
 +
| LED0
 +
|-
 +
! scope="row"| 2
 +
| P1.1
 +
| Output
 +
| SJ One Board
 +
| LED1
 +
|-
 +
! scope="row"| 3
 +
| P1.4
 +
| Output
 +
| SJ One Board
 +
| LED2
 +
|-
 +
! scope="row"| 4
 +
| P1.8
 +
| Output
 +
| SJ One Board
 +
| LED3
 +
|-
 +
! scope="row"| 5
 +
| P1.9
 +
| Input
 +
| SJ One Board
 +
| SW0
 +
|-
 +
! scope="row"| 6
 +
| P1.10
 +
| Input
 +
| SJ One Board
 +
| SW1
 +
|-
 +
! scope="row"| 7
 +
| P1.14
 +
| Input
 +
| SJ One Board
 +
| SW2
 +
|-
 +
! scope="row"| 8
 +
| P1.15
 +
| Input
 +
| SJ One Board
 +
| SW3
 +
|-
 +
! scope="row"| 9
 +
| P1.19
 +
| Output
 +
| H Bridge
 +
| IN1
 +
|-
 +
! scope="row"| 10
 +
| P1.20
 +
| Output
 +
| H Bridge
 +
| IN2
 +
|-
 +
! scope="row"| 11
 +
| P1.22
 +
| Output
 +
| H Bridge
 +
| IN3
 +
|-
 +
! scope="row"| 12
 +
| P1.23
 +
| Output
 +
| H Bridge
 +
| IN4
 +
|}
 +
 
 +
</center>
 +
 
 +
==== ADC ====
 +
The ADC pins were used to interface the IR sensors with the SJOne Board. These sensors send an analog signal to the board which is then converted to a numeric value with the on-board function of the SJOne Board. This value is used to determine how close an object is to the front of the car which is used to control whether the car goes straight, turns left, or turns right.
 +
 
 +
<center>
 +
'''ADC: Pin Connectivity Table'''
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Item
 +
! scope="col"| Port.Pin
 +
! scope="col"| Direction
 +
! scope="col"| Peripheral
 +
! scope="col"| Peripheral Port
 +
|-
 +
! scope="row"|1
 +
| P0.26
 +
| Output
 +
| IR Sensor
 +
| Vo
 +
|-
 +
! scope="row"| 2
 +
| P1.31
 +
| Output
 +
| IR Sensor
 +
| Vo
 +
|}
 +
 
 +
</center>
 +
 
 +
==== PWM ====
 +
The PWM pins serve two purposes in the project. Its main function is to control the speed of the wheels of the alarm car. The speed is manipulated by changing the amount of time within the PWM frequency stays at high. The more time the wave is set at high, the faster the car moves. It is also used to sound the buzzer of the alarm car since it requires some sort of frequency to make a sound.
 +
 
 +
<center>
 +
'''PWM: Pin Connectivity Table'''
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Item
 +
! scope="col"| Port.Pin
 +
! scope="col"| Direction
 +
! scope="col"| Peripheral
 +
! scope="col"| Peripheral Port
 +
|-
 +
! scope="row"|1
 +
| P2.2
 +
| Output
 +
| H Bridge
 +
| DC Motor 1
 +
|-
 +
! scope="row"| 2
 +
| P2.4
 +
| Output
 +
| H Bridge
 +
| DC Motor 2
 +
|-
 +
! scope="row"| 2
 +
| P2.5
 +
| Output
 +
| Buzzer
 +
| -
 +
|}
 +
 
 +
</center>
 +
 
 +
==== SJOne Board ====
 +
[[File:Devtutorial SjOneBoardOverlay.png |frame | center| <center> '''Figure 3. SJOne Board  '''</center>]]
 +
 
 +
==== L298N Dual H-Bridge ====
 +
[[File:CmpE146 F16 T10 H-Bridge.jpg|frame | center| <center>'''Figure 4. L298N H-Bridge  '''</center>]]
 +
Using the L298N Dual H-bridge, it is powered by the 6.4V battery pack. The motors for the wheels are connected in pairs; the two on the left side of the car are connected together and the two on the right side of the car are connected together. This device uses both the GPIO and PWM functionalities of the SJOne Board to control the motion of the alarm car. The PWM pins control the speed of the car by manipulating the amount of high voltage sent to the motors in a given time frame. These pins are connected to the DC Motor Enable pins of the H-bridge. The GPIO pins are used to control the rotational direction of the wheels. Each pair of wheels has two pins on the L298N to interface with the four GPIO pins used with the module. IN1 and IN2 control the wheels on the left while IN3 and IN4 control the wheels on the right. When IN1 is high and IN2 is low, the wheels on the left move forward. In the reverse, those wheels move backwards. When IN3 is high and IN4 is low, the wheels on the right move forward, while with the reverse, they move backwards. If both wheels are moving forward, the car goes forward. When the wheels on the right go forward with the ones on the left go backward, the car turns left. When the wheels on the left go forward and the wheels on the right go backwards, the car turns right.
 +
[[File:CmpE146 F16 T10 H-Bridge Block Diagram.png |frame | center| <center> '''Figure 5. L298N H-Bridge '''</center>]]
 +
 
 +
==== IR Sensor ====
 +
[[File:CmpE146 F16 T10 IRSensorImage.jpg |frame | center| <center> '''Figure 6. IR Sensor '''</center>]]
 +
Each IR sensor has three wires. The three wires consist of a ground, power, and Vo. The power is supplied from the 6.4V battery box. The ground wire is tied to the common ground of the battery box and the SJOne board. The Vo wire is connected to appropriate GPIO pins from the SJOne board. When an object approaches the IR sensor, the voltage from the analog signal increases. This analog signal is converted using the built-in ADC via the ADC pins of the SJOne board. The alarm car uses two IR sensors to send data to the SJOne board. If either of the sensors exceed a pre-programmed value (in the case of this project, 900), then the car will turn. To ensure that the car takes a path with less obstacles, the board compares the readings from both of the sensors to determine which direction to turn. If the left sensor has a higher reading, the car turns left. If the previous statement is false, the car turns right.
 +
[[File:CmpE146 F16 T10 IRSensors.png |frame | center| <center> '''Figure 7. IR Sensor Block Diagram  '''</center>]]
 +
 
 +
==== Buzzer ====
 +
[[File:CmpE146 F16 T10 Buzzer.jpg |frame | center| <center> '''Figure 8. Buzzer  '''</center>]]
 +
 
 +
The buzzer has only two pins which are non-polarized when it comes to the connection to the SJOne board. One of the pins is connected to ground while the other pin is connected to a PWM pin of the SJOne board. Since sound comes in the form of waves, a PWM pin was used over the GPIO pin since it outputs a frequency. To keep the waves consistent, the PWM is set to 50% since the waves are consistent throughout.
  
 
=== Software Design ===
 
=== Software Design ===
Show your software designFor 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.
+
 
 +
[[File:CmpE146 F16 T10 ASMChart.png |frame | center| <center> '''Figure 9. Algorithmic State Machine Chart '''</center>]]
 +
 
 +
The whole project has three main phases: the timer set, the countdown, and the alarm phase. State 0 takes place during the timer set phase and the system will stay in that phase until the alarm set button has been pressed. When that button is pressed, the countdown phase begins. This is represented in State 1. The value built up during the previous phase is then count down every second. The system stays in this phase until the counter hits zero when the alarm phase begins. The alarm phase encompasses States 2, 3, and 4 of the ASM which covers the steering of the car and the buzzer going off. The alarm car stays in this phase until the stop button is pressed. At that point, the car stops and the alarm is complete. These phases act like a waterfall progression in that the next phase does not start until the previous one finishes and that once a phase finishes, the system will not go back to it.
 +
 
 +
 
 +
[[File:CmpE146 F16 T10 TaskChart.png |frame | center| <center> '''Figure 10. Task Chart '''</center>]]
 +
 
 +
Much like the ASM progression of the system, the tasks work in a similar fashion. When the SJOne board is powered on, the user sets the timer. On Free RTOS, only the Timerset task is active. Once the user starts the alarm and starts the next phase, the Countdown task is active and will be the only one active. During the final phase of the alarm car, the State Machine task, the IR tasks, and the Buzzer task are all active in equal priority until the stop button is pressed.
  
 
=== 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.
+
*IR sensor to the SJOne board
 +
**The pins connecting to the sensor are configured to use their ADC functionality.
 +
**The IR sensors repeatedly send information to the SJOne board.
 +
**Both pins are checked to see if they exceed a value of 900.
 +
**When either sensor reaches the value of 900, the car will turn.
 +
***The direction of the turn depends on which sensor value is higher.
 +
****If the right sensor is higher, the car turns left.
 +
****In any other case, the car turns right.
 +
**If neither value exceeds 900, the car remains on a straight path.
  
 
== 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:
+
=== LCD Display ===
  
=== LCD Display ===
+
*Problem
Initially, the project called for the implementation of the 1602A v2 LCD Display to be used to display the time. The first issue with the board was the lack of datasheets available for the display. The closest datasheet for this display module was for v1.2, although that datasheet was vague. To minimize the number of pins needed for the LCD display, we decided on using it in 4-bit mode. The datasheet for v1.2 of the display showed that 4-bit mode was possible, but said little about implementation of the mode.
+
Initially, the project called for the implementation of the 1602A v2 LCD display to be used to display the time. The first issue with the board was the lack of datasheets available for the display. The closest datasheet found for this display module was for v1.2, although that datasheet was vague. To minimize the number of pins needed for the LCD display, we decided on using it in 4-bit mode. The datasheet for v1.2 of the display showed that 4-bit mode was possible, but said little about implementation of the mode.
  
As a workaround to this issue and to retain the alarm clock-like functionalities of the project, we decided to use the on board 7-segment display and LEDs to indicate the amount of time left before the alarm goes off. The 7-segment display represents the amount of minutes and the LEDs give an indication of the number of seconds before the alarm goes off. Within the final minute of the countdown before the alarm, the 7-segment display will show the time remaining before the alarm goes off and the car starts moving.
+
*Solution
 +
As a workaround to this issue and to retain the alarm clock-like functionalities of the project, we decided to use the onboard 7-segment display and LEDs to indicate the amount of time left before the alarm goes off. The 7-segment display represents the amount of minutes and the LEDs give an indication of the number of seconds before the alarm goes off. Within the final minute of the countdown before the alarm, the 7-segment display will show the time remaining in seconds before the alarm goes off and the car starts moving.
  
 
The workaround involves two tasks: one to set the timer and the other to count down to 0. In the timer set task, the user uses Switches 0 and 1 to set the time needed to elapse for the alarm to go off. Switch 0 increments the timer to 1 minute while Switch 1 resets the timer in case the user goes too far. When the user has the desired time set, Switch 2 is pressed which allows the RTOS to context switch to the countdown.
 
The workaround involves two tasks: one to set the timer and the other to count down to 0. In the timer set task, the user uses Switches 0 and 1 to set the time needed to elapse for the alarm to go off. Switch 0 increments the timer to 1 minute while Switch 1 resets the timer in case the user goes too far. When the user has the desired time set, Switch 2 is pressed which allows the RTOS to context switch to the countdown.
 +
 +
=== Stabilizing the Parts ===
 +
 +
*Problem
 +
Since the car is moving, there is a chance that parts such as the sensors, SJOne Board, battery sources, and breadboards could fall off of the chassis. Unless those parts were stabilized, there is a good chance that some parts could fall off the car and disconnect some pieces of the circuit. This issue is also bad since forceful removal of pieces could damage the pins and parts used during testing. It would also negatively affect the functionalities of the car since the IR sensors need to be stable in order to have the car avoid the obstacles.
 +
 +
*Solution
 +
Our solution was to use a combination of double sided tape and zip ties to hold all of the pieces down. The breadboard and battery packs were held down by using the double sided tape. Since the SJOne Board is a more sensitive device due to all of the electrical components, multiple zip ties were used to tie down the board and keep it stable while the car is running. The IR sensors used a combination of both zip ties and the double sided tape to keep it stable and in place. The zip ties helped support the sensor while the double sided tape was used to keep the sensor stuck in place to keep the readings consistent.
 +
 +
=== Limited Chassis Size ===
 +
 +
*Problem
 +
The entire project required many parts that needed to fit onto the chassis of the alarm car. The alarm car chassis is relatively small and has multiple wires hanging out of each of the components. This limited the amount of space to work with since the wires had to be loose enough to connect all of the pieces properly, but tight enough to not get caught in the wheels when the car is running. Much like the previous issue listed, this could damage the parts and affect the completion of the project.
 +
 +
*Solution
 +
The solution was to make use of both layers of the chassis. In the bottom layer, the AA Battery holder and power bank were placed to save space on the top layer. Since both of these connections to the boards on the top layer were simple, they were placed on the bottom with their respective wires going through the slit on the top layer to easily power up the devices. The IR sensors were also placed on the bottom layer to save space up front on the car. The breadboards were placed towards the back with the SJOne board resting on top and in the middle. While this uses up some breadboard space, it leaves enough space for all of the connections to be made. With enough space, the H-bridge was placed towards the front of the chassis to easily connect to the motors, to the SJOne Board, and to the battery pack.
 +
 +
=== DC Motors ===
 +
 +
*Problem
 +
When the driving tasks of the alarm car were combined with the timer tasks, the DC motors did not work as expected. When the alarm goes off, the motors start running, but only the wheels on the right turn. The sensor functions are still active and working as indicated by the changing of direction from the wheels on the right. When the state machine task is suspended, the wheels continue to run independent of the task.
 +
 +
*Solution
 +
There were no solutions that we implemented that caused the wheels to function when the timer was implemented. Some solutions we implemented include having a stop function run that paused all of the PWM pins until the timer reaches zero and having a start signal start up and initialize the car. In both cases, the same problem occurred with the right wheels only turning. If there was more time to implement this into the project, we would consider using a semaphore to allow the tasks to run.
  
 
== 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?
+
Overall, the project was operational in parts, but not fully to the original specifications given for the project. The driving function was able to work and avoid obstacles, and the timer function could be set and eventually count down to 0, but the two pieces could not work together without either of the parts malfunctioning. Throughout the project, there were roadblocks that prevented progress from being made. To keep the project moving and to raise the chances of a working product at the deadline, many compromises were made. The main compromise was the removal of the LCD display and clock portion in favor of the display on the SJOne board. While it makes the overall system less robust, it gave us something to work with and simulate a similar scenario in which the car can operate under.
 +
 
 +
We learned a lot through this project. The open-ended nature of the project allowed us to be creative and gave us options as to what the project would do, the parts that would be implemented, and the way in which they are integrated into the whole system. This forced us to heavily rely on datasheets and program the board in a way that makes each individual connected device work best. Since multiple tasks were used, the project helped us better understand the priority concepts of Free RTOS.  
 +
 
 +
The biggest improvement we could have made during the project was to spend more time during the planning phase. We planned out the parts that were used in the project but spent little time looking into their respective datasheets. With better planning, this could have been easily avoided and the project could have been completed with more of the original specifications. Despite this, there was a working alarm car. In conclusion, we learned a lot from the project that we could implement in future semesters and post-undergrad careers.
  
 
=== Project Video ===
 
=== Project Video ===
Upload a video of your project and post the link here.
+
[https://www.youtube.com/watch?v=PdwOVxGxR2A&feature=youtu.be Project Video]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
[https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]
+
[https://github.com/jochen12/The-Alarm-Car Alarm Car Github Link]
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.
+
This project could not have been completed without the guidance and assistance of the following people:
 +
* Dr. Haluk Ozemek
 +
* Preetpal Kang
 +
* Charles MacDonald
 +
* Praveen Prabhakaran
  
=== References Used ===
+
=== Appendix ===
List any references used in project.
+
'''Datasheets'''
 +
* [https://www.sparkfun.com/datasheets/Robotics/L298_H_Bridge.pdf L298N H-Bridge]
 +
* [https://www.openhacks.com/uploadsproductos/eone-1602a1.pdf LCD Screen]
 +
* [http://www.sharpsma.com/webfm_send/1208 IR Sensor]
  
=== Appendix ===
+
'''Links'''
You can list the references you used.
+
* [http://www.instructables.com/id/Arduino-Modules-L298N-Dual-H-Bridge-Motor-Controll/ Dual H-Bridge Motor Controller Start Guide]
 +
* [http://blog.pennybuying.com/down/f/F815A.pdf L298N Dual H-Bridge Motor Driver User's Guide]
 +
* [http://www.socialledge.com/sjsu/index.php?title=Main_Page SJOne Board]

Latest revision as of 07:22, 27 December 2016

Figure 1. Final Car Design

Project Title

The Alarm Car

Abstract

Students follow a set routine in their daily lives. It begins with waking up in the morning and ends with going to sleep at night, usually. In between, they go to school, eat, and study for their classes. Students use a clock that is synchronized with their local time to indicate which part of their daily routine to perform. While it is easy to switch from task to task when the student is awake, it can be difficult to switch from task to task when one is asleep.

Waking up can be one of the most difficult task of the day for an average student. Often times, the student sets an alarm to wake them up in the morning, but they can prove to be ineffective as only a button or switch is required to turn off the alarm. Since the alarm clock is always set at the same location, so turning off the alarm can be an effortless task.

The alarm car makes the student really work towards turning off the alarm. It has a high pitched buzzer to irritate and motivate the student to shut the alarm off. To ensure that the student is awake when they shut off the alarm, the car is autonomous and mobile. It uses IR sensors to avoid obstacles and determine the next direction in which the car moves. With this alarm car, the student will be awake and ready to take on their day.

Objectives & Introduction

The objective of this project is to create a car that has the functionalities of an alarm clock and be able to avoid obstacles.

  • Set a timer on the board
  • Display the timer
  • Produce a noise with the buzzer after the timer reaches 0
  • Have the car move forward and avoid obstacles using IR sensors when the timer reaches 0
  • Turn off the alarm car by pressing a button on the car

Team Members & Responsibilities

  • Jonathan Chen
    • Designed the structure of the car
    • Programmed the SJOne board to control the DC motors
    • Implemented the logic for obstacle avoidance
  • Andrew Javier
    • Implemented the timer task
    • Implement the countdown task
    • Programmed the IR sensor task
    • Programmed the buttons to turn on the timer

Schedule

Week# Start Date End Date Task Status Completion Date Notes
1 11/07 11/13 Order the parts Completed 11/10 Majority of the parts were ordered
2 11/14 11/20 Determine design of the car, begin building Completed 11/19 Found out that a H-bridge was needed to run the DC motors. Had to order an H-bridge. Built the chassis for the car.
3 11/21 11/27 Build the car Completed 11/23 Plan out the connections between the peripherals and the SJOne board
4 11/28 12/04 Program the car (phase 1) Completed 12/02 Implemented the timer and buzzer tasks
5 12/05 12/11 Program the car (phase 2) Completed 12/11 Had difficulties programming the LCD display and switched to a different alternative display
6 12/12 12/21 Testing, write the report, make the video, demo Completed 12/21 Finished the report and the video

Parts List & Cost

Qty Vendor Description Price
1 San Jose State University SJOne Board $80.00
1 Amazon Emgreat 4-wheel Robot Smart Car Chassis Kit $23.99
1 Amazon Qunqi L298N Motor Drive Controller Board Module Dual H Bridge $6.99
16 Excess Solutions Wires $0.76
2 Amazon GP2Y0A21YK0F IR Sensor $17.99
1 Radio Shack AA Batteries (4 Pack) $4.99
1 Radio Shack 4 AA Battery Holder $2.99
1 Radio Shack Universal Breadboard $9.99
1 Fry's Electronics Male/Female Jumpers (10 Pack) $3.99
1 Fry's Electronics Female/Female Jumpers (10 Pack) $3.99
1 SJSU Bookstore Dual Sided Tape $3.28
1 Amazon LCD1602 Monitor $8.49
1 Software and Computer Engineering Society Buzzer Free
Total $167.45

Design & Implementation

Hardware Design

This is a system overview diagram of the alarm car. There are four main attachments to the SJOne board: two IR sensors, the H-bridge, and a buzzer. The buzzer and IR sensors are standalone and have no additional connections. There are four DC motors connected to the H-bridge.

Figure 2. Hardware Block Diagram: System Overview

Hardware Interface

GPIO

Much of the functionality of this project involved the use of the GPIO functionalities of the SJOne Board. During the timer set portion of the project, the GPIO ports use the switch buttons to manipulate the time as well as set the alarm. In both the timer set and countdown portions of the project, the 7-segment display and on board LEDs are used to display the amount of time left before the alarm goes off. For the remaining tasks of the project, the GPIO pins are used to connect to the H Bridge to control the direction of the wheels.

GPIO: Pin Connectivity Table

Item Port.Pin Direction Peripheral Peripheral Port
1 P1.0 Output SJ One Board LED0
2 P1.1 Output SJ One Board LED1
3 P1.4 Output SJ One Board LED2
4 P1.8 Output SJ One Board LED3
5 P1.9 Input SJ One Board SW0
6 P1.10 Input SJ One Board SW1
7 P1.14 Input SJ One Board SW2
8 P1.15 Input SJ One Board SW3
9 P1.19 Output H Bridge IN1
10 P1.20 Output H Bridge IN2
11 P1.22 Output H Bridge IN3
12 P1.23 Output H Bridge IN4

ADC

The ADC pins were used to interface the IR sensors with the SJOne Board. These sensors send an analog signal to the board which is then converted to a numeric value with the on-board function of the SJOne Board. This value is used to determine how close an object is to the front of the car which is used to control whether the car goes straight, turns left, or turns right.

ADC: Pin Connectivity Table

Item Port.Pin Direction Peripheral Peripheral Port
1 P0.26 Output IR Sensor Vo
2 P1.31 Output IR Sensor Vo

PWM

The PWM pins serve two purposes in the project. Its main function is to control the speed of the wheels of the alarm car. The speed is manipulated by changing the amount of time within the PWM frequency stays at high. The more time the wave is set at high, the faster the car moves. It is also used to sound the buzzer of the alarm car since it requires some sort of frequency to make a sound.

PWM: Pin Connectivity Table

Item Port.Pin Direction Peripheral Peripheral Port
1 P2.2 Output H Bridge DC Motor 1
2 P2.4 Output H Bridge DC Motor 2
2 P2.5 Output Buzzer -

SJOne Board

Figure 3. SJOne Board

L298N Dual H-Bridge

Figure 4. L298N H-Bridge

Using the L298N Dual H-bridge, it is powered by the 6.4V battery pack. The motors for the wheels are connected in pairs; the two on the left side of the car are connected together and the two on the right side of the car are connected together. This device uses both the GPIO and PWM functionalities of the SJOne Board to control the motion of the alarm car. The PWM pins control the speed of the car by manipulating the amount of high voltage sent to the motors in a given time frame. These pins are connected to the DC Motor Enable pins of the H-bridge. The GPIO pins are used to control the rotational direction of the wheels. Each pair of wheels has two pins on the L298N to interface with the four GPIO pins used with the module. IN1 and IN2 control the wheels on the left while IN3 and IN4 control the wheels on the right. When IN1 is high and IN2 is low, the wheels on the left move forward. In the reverse, those wheels move backwards. When IN3 is high and IN4 is low, the wheels on the right move forward, while with the reverse, they move backwards. If both wheels are moving forward, the car goes forward. When the wheels on the right go forward with the ones on the left go backward, the car turns left. When the wheels on the left go forward and the wheels on the right go backwards, the car turns right.

Figure 5. L298N H-Bridge

IR Sensor

Figure 6. IR Sensor

Each IR sensor has three wires. The three wires consist of a ground, power, and Vo. The power is supplied from the 6.4V battery box. The ground wire is tied to the common ground of the battery box and the SJOne board. The Vo wire is connected to appropriate GPIO pins from the SJOne board. When an object approaches the IR sensor, the voltage from the analog signal increases. This analog signal is converted using the built-in ADC via the ADC pins of the SJOne board. The alarm car uses two IR sensors to send data to the SJOne board. If either of the sensors exceed a pre-programmed value (in the case of this project, 900), then the car will turn. To ensure that the car takes a path with less obstacles, the board compares the readings from both of the sensors to determine which direction to turn. If the left sensor has a higher reading, the car turns left. If the previous statement is false, the car turns right.

Figure 7. IR Sensor Block Diagram

Buzzer

Figure 8. Buzzer

The buzzer has only two pins which are non-polarized when it comes to the connection to the SJOne board. One of the pins is connected to ground while the other pin is connected to a PWM pin of the SJOne board. Since sound comes in the form of waves, a PWM pin was used over the GPIO pin since it outputs a frequency. To keep the waves consistent, the PWM is set to 50% since the waves are consistent throughout.

Software Design

Figure 9. Algorithmic State Machine Chart

The whole project has three main phases: the timer set, the countdown, and the alarm phase. State 0 takes place during the timer set phase and the system will stay in that phase until the alarm set button has been pressed. When that button is pressed, the countdown phase begins. This is represented in State 1. The value built up during the previous phase is then count down every second. The system stays in this phase until the counter hits zero when the alarm phase begins. The alarm phase encompasses States 2, 3, and 4 of the ASM which covers the steering of the car and the buzzer going off. The alarm car stays in this phase until the stop button is pressed. At that point, the car stops and the alarm is complete. These phases act like a waterfall progression in that the next phase does not start until the previous one finishes and that once a phase finishes, the system will not go back to it.


Figure 10. Task Chart

Much like the ASM progression of the system, the tasks work in a similar fashion. When the SJOne board is powered on, the user sets the timer. On Free RTOS, only the Timerset task is active. Once the user starts the alarm and starts the next phase, the Countdown task is active and will be the only one active. During the final phase of the alarm car, the State Machine task, the IR tasks, and the Buzzer task are all active in equal priority until the stop button is pressed.

Implementation

  • IR sensor to the SJOne board
    • The pins connecting to the sensor are configured to use their ADC functionality.
    • The IR sensors repeatedly send information to the SJOne board.
    • Both pins are checked to see if they exceed a value of 900.
    • When either sensor reaches the value of 900, the car will turn.
      • The direction of the turn depends on which sensor value is higher.
        • If the right sensor is higher, the car turns left.
        • In any other case, the car turns right.
    • If neither value exceeds 900, the car remains on a straight path.

Testing & Technical Challenges

LCD Display

  • Problem

Initially, the project called for the implementation of the 1602A v2 LCD display to be used to display the time. The first issue with the board was the lack of datasheets available for the display. The closest datasheet found for this display module was for v1.2, although that datasheet was vague. To minimize the number of pins needed for the LCD display, we decided on using it in 4-bit mode. The datasheet for v1.2 of the display showed that 4-bit mode was possible, but said little about implementation of the mode.

  • Solution

As a workaround to this issue and to retain the alarm clock-like functionalities of the project, we decided to use the onboard 7-segment display and LEDs to indicate the amount of time left before the alarm goes off. The 7-segment display represents the amount of minutes and the LEDs give an indication of the number of seconds before the alarm goes off. Within the final minute of the countdown before the alarm, the 7-segment display will show the time remaining in seconds before the alarm goes off and the car starts moving.

The workaround involves two tasks: one to set the timer and the other to count down to 0. In the timer set task, the user uses Switches 0 and 1 to set the time needed to elapse for the alarm to go off. Switch 0 increments the timer to 1 minute while Switch 1 resets the timer in case the user goes too far. When the user has the desired time set, Switch 2 is pressed which allows the RTOS to context switch to the countdown.

Stabilizing the Parts

  • Problem

Since the car is moving, there is a chance that parts such as the sensors, SJOne Board, battery sources, and breadboards could fall off of the chassis. Unless those parts were stabilized, there is a good chance that some parts could fall off the car and disconnect some pieces of the circuit. This issue is also bad since forceful removal of pieces could damage the pins and parts used during testing. It would also negatively affect the functionalities of the car since the IR sensors need to be stable in order to have the car avoid the obstacles.

  • Solution

Our solution was to use a combination of double sided tape and zip ties to hold all of the pieces down. The breadboard and battery packs were held down by using the double sided tape. Since the SJOne Board is a more sensitive device due to all of the electrical components, multiple zip ties were used to tie down the board and keep it stable while the car is running. The IR sensors used a combination of both zip ties and the double sided tape to keep it stable and in place. The zip ties helped support the sensor while the double sided tape was used to keep the sensor stuck in place to keep the readings consistent.

Limited Chassis Size

  • Problem

The entire project required many parts that needed to fit onto the chassis of the alarm car. The alarm car chassis is relatively small and has multiple wires hanging out of each of the components. This limited the amount of space to work with since the wires had to be loose enough to connect all of the pieces properly, but tight enough to not get caught in the wheels when the car is running. Much like the previous issue listed, this could damage the parts and affect the completion of the project.

  • Solution

The solution was to make use of both layers of the chassis. In the bottom layer, the AA Battery holder and power bank were placed to save space on the top layer. Since both of these connections to the boards on the top layer were simple, they were placed on the bottom with their respective wires going through the slit on the top layer to easily power up the devices. The IR sensors were also placed on the bottom layer to save space up front on the car. The breadboards were placed towards the back with the SJOne board resting on top and in the middle. While this uses up some breadboard space, it leaves enough space for all of the connections to be made. With enough space, the H-bridge was placed towards the front of the chassis to easily connect to the motors, to the SJOne Board, and to the battery pack.

DC Motors

  • Problem

When the driving tasks of the alarm car were combined with the timer tasks, the DC motors did not work as expected. When the alarm goes off, the motors start running, but only the wheels on the right turn. The sensor functions are still active and working as indicated by the changing of direction from the wheels on the right. When the state machine task is suspended, the wheels continue to run independent of the task.

  • Solution

There were no solutions that we implemented that caused the wheels to function when the timer was implemented. Some solutions we implemented include having a stop function run that paused all of the PWM pins until the timer reaches zero and having a start signal start up and initialize the car. In both cases, the same problem occurred with the right wheels only turning. If there was more time to implement this into the project, we would consider using a semaphore to allow the tasks to run.

Conclusion

Overall, the project was operational in parts, but not fully to the original specifications given for the project. The driving function was able to work and avoid obstacles, and the timer function could be set and eventually count down to 0, but the two pieces could not work together without either of the parts malfunctioning. Throughout the project, there were roadblocks that prevented progress from being made. To keep the project moving and to raise the chances of a working product at the deadline, many compromises were made. The main compromise was the removal of the LCD display and clock portion in favor of the display on the SJOne board. While it makes the overall system less robust, it gave us something to work with and simulate a similar scenario in which the car can operate under.

We learned a lot through this project. The open-ended nature of the project allowed us to be creative and gave us options as to what the project would do, the parts that would be implemented, and the way in which they are integrated into the whole system. This forced us to heavily rely on datasheets and program the board in a way that makes each individual connected device work best. Since multiple tasks were used, the project helped us better understand the priority concepts of Free RTOS.

The biggest improvement we could have made during the project was to spend more time during the planning phase. We planned out the parts that were used in the project but spent little time looking into their respective datasheets. With better planning, this could have been easily avoided and the project could have been completed with more of the original specifications. Despite this, there was a working alarm car. In conclusion, we learned a lot from the project that we could implement in future semesters and post-undergrad careers.

Project Video

Project Video

Project Source Code

Alarm Car Github Link

References

Acknowledgement

This project could not have been completed without the guidance and assistance of the following people:

  • Dr. Haluk Ozemek
  • Preetpal Kang
  • Charles MacDonald
  • Praveen Prabhakaran

Appendix

Datasheets

Links