F16: Autonomous Runaway Alarm Car
- 1 Project Title
- 2 Abstract
- 3 Objectives & Introduction
- 4 Schedule
- 5 Parts List & Cost
- 6 Design & Implementation
- 7 Testing & Technical Challenges
- 8 Conclusion
- 9 References
The Alarm Car
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
|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
|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|
|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||Software and Computer Engineering Society||Buzzer||Free|
Design & Implementation
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.
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
|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|
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
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
|1||P2.2||Output||H Bridge||DC Motor 1|
|2||P2.4||Output||H Bridge||DC Motor 2|
L298N Dual 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.
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.
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.
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.
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.
- 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.
- The direction of the turn depends on which sensor value is higher.
- If neither value exceeds 900, the car remains on a straight path.
Testing & Technical Challenges
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 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
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.
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
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.
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.
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.
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.
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 Source Code
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