S15: Self-Balancing Robot - Revision history

Proj user21: /* Testing & Technical Challenges */

2015-05-27T02:43:20Z

‎Testing & Technical Challenges

Proj user21: /* Testing & Technical Challenges */

2015-05-27T02:31:51Z

‎Testing & Technical Challenges

Preet: /* Grading Criteria */

2015-05-26T04:43:59Z

‎Grading Criteria

Proj user21: /* Conclusion */

2015-05-26T02:30:58Z

‎Conclusion

Proj user21: /* Conclusion */

2015-05-26T02:29:53Z

‎Conclusion

Proj user21: /* Testing & Technical Challenges */

2015-05-26T02:29:39Z

‎Testing & Technical Challenges

Proj user21: /* Implementation */

2015-05-26T02:28:57Z

‎Implementation

Proj user21: /* Software Design */

2015-05-26T02:28:37Z

‎Software Design

Proj user21: /* Hardware Interface */

2015-05-26T02:28:18Z

‎Hardware Interface

Proj user21: /* Hardware Design */

2015-05-26T02:27:54Z

‎Hardware Design

@@ Line 337: / Line 337: @@
 === My Issue #5 ===
 Bluetooth task receive and send delay: The software for the bluetooth task was designed to read from the UART interface with the bluetooth module, decode the message, and output the appropriate direction to the UART interface with the other SJOne board. There were times when the controller sends a signal to the bluetooth module, it took a while for the message to be sent through the Tx pin of UART2(interface to other board) after it was received from the Rx pin of UART3(interface with bluetooth module). There were also times when the message was receive from the Rx of UART3 but it was not sent out to the other board. The group hypothesized that the issue came with the task delay. If the user sends the direction using the phone when the task is asleep, the message is ignored. The group tried to reorganize the code such that there is a separate task for sending the direction to the other board but the result was still the same. Another solution the group thought of but didn't have time to implement was to design their own android controller app. The android app used for the project only sends the message once when the button on the screen is pressed. If the app was designed to continuously send the control message to the bluetooth module then the group hypothesized that the issue would have been resolved. As mentioned before, trying to develop an app was too consuming for the group considering nobody had experience doing so and each member's schedule.
 == Conclusion ==

@@ Line 316: / Line 316: @@
 <br>
 <br>
 === My Issue #1 ===
 Stepper Motors. Stepper motors have high torque and can be controlled precisely (e.g. 1/4 revolution, 350 steps, etc) but writing own drivers for the stepping frequency
@@ Line 330: / Line 334: @@
 === My Issue #4 ===
 Tuning: since this is the hardest part of the project, a lot of time should be devoted in tuning the controller. The group spent a total of 4 weeks just tuning the PID and still failed to make the robot balance. This problem is a combination of the PID controller implementation and the motor driver implementation. These two should be implemented properly in order to make the tuning possible.
 == Conclusion ==

← Older revision		Revision as of 04:43, 26 May 2015
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>~~
−
	== Project Title ==		== Project Title ==
	Two Wheel Self-Balancing Robot		Two Wheel Self-Balancing Robot

@@ Line 344: / Line 344: @@
 == Conclusion ==
-Even though a PID controller is popular because of its simplicity, the implementation of it is not so simple. The three constants that are used need to be tuned perfectly in able to obtain the desired output. The problem with this is that a lot of time is needed for tune these parameters perfectly. The lack of experience about PID controllers and the necessary preparation needed (e.g. interface sensor module, writing motor drivers, etc.) made this project incredibly difficult for the group.
+Even though a PID controller is popular because of its simplicity, the implementation of it is not so simple. The three constants that are used need to be tuned perfectly in able to obtain the desired output. The problem with this is that a lot of time is needed to tune these parameters perfectly. The lack of experience about PID controllers and the necessary preparation needed (e.g. interface sensor module, writing motor drivers, etc.) made this project incredibly difficult for the group.
 This project pushed the group to their limits. Although the group failed to make the robot balance, the group learned a lot regarding the behavior of unstable systems and what are the possible solutions to stabilize them. The group also learned a lot about the PID algorithm and its implementation. The group believes that given more time, a successful PID controller implementation is possible.

← Older revision		Revision as of 02:29, 26 May 2015
Line 344:		Line 344:

	== 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?
−
	Even though a PID controller is popular because of its simplicity, the implementation of it is not so simple. The three constants that are used need to be tuned perfectly in able to obtain the desired output. The problem with this is that a lot of time is needed for tune these parameters perfectly. The lack of experience about PID controllers and the necessary preparation needed (e.g. interface sensor module, writing motor drivers, etc.) made this project incredibly difficult for the group.		Even though a PID controller is popular because of its simplicity, the implementation of it is not so simple. The three constants that are used need to be tuned perfectly in able to obtain the desired output. The problem with this is that a lot of time is needed for tune these parameters perfectly. The lack of experience about PID controllers and the necessary preparation needed (e.g. interface sensor module, writing motor drivers, etc.) made this project incredibly difficult for the group.

@@ Line 317: / Line 317: @@
 == Testing & Technical Challenges ==
 <br>
 The testing of the balancing mostly relied on the PID controller. This of course assumed that the accelerometer+gyroscope sensor provides accurate angle readings.

← Older revision		Revision as of 02:28, 26 May 2015
Line 259:		Line 259:

	=== 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.

	=== PID controller driver ===		=== PID controller driver ===

@@ Line 224: / Line 224: @@
 === 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.
 <br>

@@ Line 178: / Line 178: @@
 === 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.
 <br>
 [[File:S15_146_G8_mpu6050.PNG|center]]

@@ Line 137: / Line 137: @@
 === Hardware Design ===
-Discuss your hardware design here.  Show detailed schematics, and the interface here.
 <br>