F12: Evil Watchdog - Revision history

Preet: /* Appendix */

2013-02-04T22:00:27Z

‎Appendix

Waymond f12: /* Software Flowchart */

2012-12-20T17:46:48Z

‎Software Flowchart

Waymond f12: /* References */

2012-12-20T17:45:38Z

‎References

Waymond f12: /* Switch */

2012-12-20T17:40:31Z

‎Switch

Waymond f12: /* Vehicle Weight */

2012-12-20T17:39:04Z

‎Vehicle Weight

Waymond f12: /* Technical Challenges */

2012-12-20T17:32:53Z

‎Technical Challenges

Waymond f12: /* Alarm */

2012-12-20T17:32:35Z

‎Alarm

Waymond f12: /* The Entire Dog */

2012-12-20T17:30:31Z

‎The Entire Dog

Waymond f12: /* Motor Controllers */

2012-12-20T17:28:18Z

‎Motor Controllers

Waymond f12: /* Alarm Triggering */

2012-12-20T17:26:37Z

‎Alarm Triggering

@@ Line 528: / Line 528: @@
 === Appendix ===
-*  [https://sourceforge.net/projects/sjsuf12-ew/ Project source code is available at SourceForge]
+*  [http://sourceforge.net/projects/sjsuf12/files Project source code is available at SourceForge]
 *  [http://youtu.be/DoyQDPgDjoM Project Demonstration Video]

@@ Line 464: / Line 464: @@
 ===Software Implementation===
-==== Software Flowchart ====
+==== Task Flowchart ====
 The program was designed to run by employing tasks that handled sensor readings and appropriate outputs. A "drive" task was assigned to handle vehicular driving, and a "SensorValue" task was assigned to continuously capture data from the distance and motion sensors. When combined, the tasks worked to drive the vehicle safely through a path. The below illustrates how the general function of the program used to control the Evil Watchdog:
 [[File:CMPE_146_F12_EWD_Flowchart.png|thumb|center|590px|General program flow (click to enlarge).]]

@@ Line 522: / Line 522: @@
 * Dr. Haluk Özemek: Lecturer
 * Preet Kang: Lab Instructor
 === Appendix ===
 *  [https://sourceforge.net/projects/sjsuf12-ew/ Project source code is available at SourceForge]
 *  [http://youtu.be/DoyQDPgDjoM Project Demonstration Video]

@@ Line 370: / Line 370: @@
 ==== Switch ====
 [[File:CMPE_146_F12_EWD_Switch.png|thumb|220px|Switch added to circuitry.]]
-A single-pole double-throw switch was added to the board to connect and disconnect power to the system, for convenience.
+A single-pole double-throw switch was added to the board to quickly connect and disconnect power to the system.
 ===Software Design===

@@ Line 500: / Line 500: @@
 === Vehicle Weight ===
-The original toy car was designed to carry a lightweight circuit board that received RF signals to control the motors. When the car was torn apart and new components were added for this project, the amount of weight placed on the wheels rapidly increased. Additional weight required extra torque from the wheels to move the carried load, which drained the batteries much more quickly. The best way to alleviate this problem was to eliminate excess weight and to select the lightest available parts to be placed on the vehicle.
+The original toy car was designed to carry a lightweight circuit board that received RF signals to control the motors. When the car was torn apart and new components were added for this project, the amount of weight placed on the wheels rapidly increased. Additional weight required extra torque from the wheels to move the carried load, which drained the AA alkaline batteries much more quickly. The best way to alleviate this problem was to eliminate excess weight and to select the lightest available parts to be placed on the vehicle.
 ==Conclusion==

@@ Line 491: / Line 491: @@
 [[File:CMPE_146_F12_EWD_VSupply.png‎|thumb|220px|Voltage generator with amperage reading.]]
 By far, the battery pack was the most vulnerable component in keeping the Evil Watchdog alive. Only five 1.5-volt AA batteries powered the entire system. Possible solutions to this problem were to either use batteries with longer lifespans or to use rechargeable batteries to avoid wasting single-use cells. During testing, a variable-voltage DC power supply, grabbing power from a wall outlet, was used to power the project. This saved battery power later needed for demoing. One key observation was that the system consumed the most power with the rear motors spinning at full speed, allowing the motor controller to consume a full 5 amps. This was devastating to the batteries. When the rear motors were set to run at only 20% of maximum speed, the system as a whole consumed a more generous current of 0.3 amps, as shown in the picture at right.
 === Distance Sensor Placement ===

@@ Line 481: / Line 481: @@
 === Alarm ===
 Because the alarm worked with different voltages, it was tested on a voltage generator before being placed in the car. 3.3 volts was enough to supply an audible tone.
 === The Entire Dog ===

@@ Line 483: / Line 483: @@
 === The Entire Dog ===
-Once all the components were stitched and strapped onto the dog, the canine was released into the wild (the Engineering building hallways). It ran freely and occasionally bumped into walls. The distance sensor thresholds were modified to allow extra space between the dog and its nearest obstacles. At one point, steering froze for no apparent reason. A close examination revealed that super glue holding the distance sensor posts had dripped onto the front axle, preventing the dog from making turns.
+Once all the components were stitched and strapped onto the dog, the canine was released into the wild (the Engineering building hallways). It ran freely and occasionally bumped into walls. The distance sensor thresholds were modified to allow extra space between the dog and its nearest obstacles. At one point, steering froze for no apparent reason. A close examination revealed that super glue holding the distance sensor posts had dripped onto the front axle, preventing the dog from making turns. Small corrections were made to the code whenever the vehicle did not behave as expected. For example, if the rear wheels spun too fast, the PWMMR2 setting was decreased.
 ==Technical Challenges==

@@ Line 471: / Line 471: @@
 == Testing ==
 === Motor Controllers ===
-The motor controllers were the first components to run through testing after the PWM driver was written. At first, the assumption was that setting PWMMR2 to zero meant a full stop. That became untrue as the dog tried to run away at full speed even after the program shouted zero hertz. Once it was realized that a higher setting corresponded to slower motion, the rear controller was successfully configured. The front motor was tested too. The main difficulty was in mapping out the voltage levels and voltage directions to see whether they corresponded to left, right, or center steering. Using LEDs helped figure out the mappings. An interesting point to note is that to return to center steering via GPIO, a change in steering direction must take place.
+The motor controllers were the first components tested once the PWM driver was written. At first, the assumption was that setting PWMMR2 to zero meant a full stop. That became untrue as the dog tried to run away at full speed. Once it was realized that a higher duty cycle corresponded to slower motion, the rear controller was successfully configured. The front motor controller was tested too. The main difficulty was in mapping out the voltage levels and voltage directions to see whether they corresponded to left, right, or center steering. Using LEDs helped figure out the mappings. An interesting point to note is that to return to center steering via GPIO, a change in steering direction must take place.
 === Distance Sensors ===

@@ Line 454: / Line 454: @@
 ==== Alarm Triggering ====
-The alarm was connected to another GPIO pin on the board. Whenever the pin was set active, the alarm rang. As mentioned previously, 3.3 volts was enough, making the GPIO pin an ideal source of power for the piezo buzzer.
+One more GPIO pin was used for the alarm:
 ==== Loading the Software ====