F13: Bulb Ramper - Revision history

Preet: /* Grading Criteria */

2013-12-09T02:15:48Z

‎Grading Criteria

Preet: /* Project Source Code */

2013-12-08T03:55:44Z

‎Project Source Code

Preet: /* Project Source Code */

2013-12-07T05:19:17Z

‎Project Source Code

Proj user9: /* Testing & Technical Challenges */

2013-12-06T00:41:10Z

‎Testing & Technical Challenges

Proj user9: /* Hardware Interface */

2013-12-06T00:11:16Z

‎Hardware Interface

Proj user9: /* Schedule */

2013-12-06T00:01:52Z

‎Schedule

Proj user9: /* Hardware Interface */

2013-12-05T06:17:13Z

‎Hardware Interface

Proj user9: /* Project Video */

2013-12-05T06:14:19Z

‎Project Video

Proj user9 at 06:13, 5 December 2013

2013-12-05T06:13:43Z

Proj user9 at 06:12, 5 December 2013

2013-12-05T06:12:40Z

← Older revision		Revision as of 02:15, 9 December 2013
Line 1:		Line 1:
−	~~=== Grading Criteria ===~~
−	~~<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>~~
−
	== Bulb Ramper ==		== Bulb Ramper ==

@@ Line 309: / Line 309: @@
 === Project Source Code ===
-* [https://sourceforge.net/projects/sjsu/upload/CmpE240_LM_F2013/ Sourceforge Source Code]
+* [https://sourceforge.net/projects/sjsu/files/CmpE240_LM_F2013/ Sourceforge Source Code]
 == References ==

@@ Line 309: / Line 309: @@
 === Project Source Code ===
-Send me your zipped source code and I will upload this to SourceForge and link it for you.
+* [https://sourceforge.net/projects/sjsu/upload/CmpE240_LM_F2013/ Sourceforge Source Code]
 == References ==

@@ Line 228: / Line 228: @@
 There are several challenges in getting the project to work. Below are the list of the major ones that hopefully future students can avoid:
-) Have a good oscilloscope or at least, a volt meter. By seeing what is being sent out, it helps on the troubleshooting. In the beginning, the camera shutter wasn't being activated and it was hard to figure out what was happening without measuring what was coming out the chip. By having the equipment, it would have speed up troubleshooting process. The problem was that I put too high of a resistor inline with the optocoupler, so it did not have enough power for the LED to function and create a signal for the camera.
+) Have a good oscilloscope or at least, a volt meter. By seeing what is being sent out, it helps on the troubleshooting. In the beginning, the camera shutter wasn't being activated and it was hard to figure out what was happening without measuring what was coming out the chip. By having the equipment, it would have speed up troubleshooting process. The problem was that we put too high of a resistor inline with the optocoupler, so it did not have enough power for the LED to function and create a signal for the camera.
 ) User Interface: For the user interface, it is important to plan how your project will interact with the user. We ended using a model where the user can select each digit and then increment each digit individually to modify the number quickly. Instead of click a specific key a hundred times, he just needs to select the third digit and change it to "1".  We could have gone with the user inputting "100" directly but that would require input checks to make sure they did not input a letter or weird characters. Another item that gave us trouble was how to display the number so the user will know which digit was being selected. We choose to display the text in a blinking fashion so the user can track it. This was simulated by writing out the number, erase it, write the number again except skip the selected digit, erase it again and repeat from the start. For example, the following will be displayed (backspace omitted)
@@ Line 253: / Line 253: @@
 We then put a delay between each printf so the simulated blinking wasn't too quick.
-) The last of our challenges was making sure everything was working together. When we put all the tasks together, it took awhile to troubleshoot all the bugs. The scope of the programming bugs were not huge so I won't go into detail about it. However, the biggest asset for us when troubleshooting was using the printf function (or cout if using C++). By strategically placing printf functions, we can see which path the program took, what was inside a variable, and a whole multitude of other things. While I am aware there are debugging tools, the printf or cout has been the most reliable in terms of helping me figure out what the program was doing.
+) The last of our challenges was making sure everything was working together. When we put all the tasks together, it took awhile to troubleshoot all the bugs. The scope of the programming bugs were not huge so we won't go into detail about it. However, the biggest asset for us when troubleshooting was using the printf function (or cout if using C++). By strategically placing printf functions, we can see which path the program took, what was inside a variable, and a whole multitude of other things. While we are aware there are debugging tools, the printf or cout has been the most reliable in terms of helping me figure out what the program was doing.
-For example, if I expected only one of two conditions to occur (like an "if" statement), I would place a printf in each of them to make sure I wasn't accidentally trigger a path I wasn't suppose to take. In our project, we had an issue in the beginning with the motor increment factor. The motor wasn't incrementing in a set amount of steps, it just jumped from whatever starting position and went all the way to 180 on one giant step.  To figure out what was happening, had the program print out what was in the motor increment variable each time the loop ran. This helped us realize it wasn't setting the variable in the way we thought it did.
+For example, if we expected only one of two conditions to occur (like an "if" statement), we would place a printf in each of them to make sure we weren't accidentally trigger a path we were suppose to take. In our project, we had an issue in the beginning with the motor increment factor. The motor wasn't incrementing in a set amount of steps, it just jumped from whatever starting position and went all the way to 180 on one giant step.  To figure out what was happening, had the program print out what was in the motor increment variable each time the loop ran. This helped us realize it wasn't setting the variable in the way we thought it did.
 ====== Testing our project ======

← Older revision		Revision as of 00:11, 6 December 2013
Line 188:		Line 188:

	[[File: CmpE240 S13 BulbRamper PWM Pulse Widths Example.jpg\|200px\|thumb\|center\|PWM Pulse Widths Example]]		[[File: CmpE240 S13 BulbRamper PWM Pulse Widths Example.jpg\|200px\|thumb\|center\|PWM Pulse Widths Example]]
−
−	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.

	=== Software Design ===		=== Software Design ===

@@ Line 103: / Line 103: @@
 |Finalize and deliver project
 Demo project
+|The report was successfully completed.
 |}

@@ Line 172: / Line 172: @@
 === Hardware Interface ===
-There are two main interfaces for our project:
 . GPIO: GPIO is used for camera activation. It takes two GPIO ports in order to activate the camera shutter. One GPIO to focus and and the other GPIO to open the shutter.
-. PWM output:
+. UART: Main communication between the wifi chip and our terminal task.
 PWM, or Pulse Width Modulation, was used to control the 180-degree positional servo. The servo expects a train of pulses of varying widths. The pulses are repeated at a given period, typically set at 20 ms (50Hz). The width of the pulse is the code that signifies to what position the shaft should turn. The center position is usually attained with 1.3-1.5ms wide pulses, while pulse widths varying from 0.7-1ms will command positions all the way to the right (left), and pulse widths of 1.7-2ms all the way to the left (right). However, we found that the valid pulse widths were larger, ranging from 0.2 ms to 3.3 ms in our servo. Therefore, we expanded the range of pulse widths and converted the range into a degree range in software. The servo is connected to a 6V power supply and is controlled by PWM1 (P1.0)

@@ Line 300: / Line 300: @@
 === Project Video ===
 . [http://youtu.be/5IIJS4YWfFk Link to Project Demo]
 . [http://youtu.be/UULPU3zPlAY Link to Timelapse created from project]
 === Project Source Code ===

@@ Line 305: / Line 305: @@
 === Project Source Code ===
@@ Line 333: / Line 321: @@
 === Appendix ===
 You can list the references you used.

@@ Line 309: / Line 309: @@
 [[File:CMPE240 F13 BulbRamper 1.jpeg|400px|thumb|left]]
-[[File:CMPE240_F13_BulbRamper_2.jpeg]]
+[[File:CMPE240_F13_BulbRamper_2.jpeg|400px|thumb|left]]
-[[File:CMPE240_F13_BulbRamper_3.jpeg]]
+[[File:CMPE240_F13_BulbRamper_3.jpeg|400px|thumb|left]]
-[[File:CMPE240_F13_BulbRamper_4.jpeg]]
+[[File:CMPE240_F13_BulbRamper_4.jpeg|400px|thumb|left]]
-[[File:CMPE240_F13_BulbRamper_5.jpeg]]
+[[File:CMPE240_F13_BulbRamper_5.jpeg|400px|thumb|left]]
-[[File:CMPE240_F13_BulbRamper_6.jpeg]]
+[[File:CMPE240_F13_BulbRamper_6.jpeg|400px|thumb|left]]
 === Project Source Code ===