F15: Fury - Revision history

243 user5: /* Acknowledgement */

2016-01-05T20:25:25Z

‎Acknowledgement

243 user5: /* Software Design */

2015-12-19T16:27:47Z

‎Software Design

Proj user11: /* Master Controller */

2015-12-19T16:27:06Z

‎Master Controller

243 user5: /* Hardware Interface */

2015-12-19T16:24:05Z

‎Hardware Interface

Proj user11: /* Testing & Technical Challenges */

2015-12-19T16:22:51Z

‎Testing & Technical Challenges

Proj user11: /* Master Controller */

2015-12-19T16:21:59Z

‎Master Controller

Proj user11: /* Schedule */

2015-12-19T16:18:48Z

‎Schedule

243 user5: /* Testing & Technical Challenges */

2015-12-19T16:15:15Z

‎Testing & Technical Challenges

243 user5: /* Software Design */

2015-12-19T16:12:17Z

‎Software Design

243 user5: /* Implementation */

2015-12-19T16:11:10Z

‎Implementation

@@ Line 1,646: / Line 1,646: @@
 *[https://www.codecademy.com/learn/learn-git Learning Git Tutorials]
 === Acknowledgement ===
-We would like to thank our instructor Preet for always inspiring, encouraging and guiding us to learn and build cool projects related to embedded systems. We really appreciate his patience. This was our first exposure to CAN bus communication and we learned a lot about it. We would also like to thank all our team members for helping each other out while working on this project.
+We would like to thank our instructor Preet for always inspiring, encouraging and guiding us to learn and build cool projects related to embedded systems. We really appreciate his patience. This was our first exposure to CAN bus communication and we learned a lot about it. We would also like to thank all our team members for helping each other out while working on this project. Special thanks to Julio Fuentes for designing the hardware frame.
 === Appendix ===
 * Laser Distance Sensor [[File:F15 243 Fury Lidar spec.pdf]]
 * Sonic Sensor [[File:CmpE243_F15_Fury_XL-MaxSonar-EZ_Datasheet.pdf]]

@@ Line 594: / Line 594: @@
 [[File:CmpE243_F15_Fury_MinDutyCycle.BMP| 400px | right | thumb | Minimum Duty Cycle for turning left/going backward]]
 [[File:CmpE243_F15_Fury_DutyCycle.BMP| 400px | center| thumb | Duty Cycle for going straight/stop]]
 === Software Design ===

@@ Line 446: / Line 446: @@
 The obstruction avoidance algorithm took the messages from the Geo-controller and the sensor controller and turns the car suitably guiding it towards the checkpoint. Below is the detailed flowchart for the same:
-{|
-|[[File:F15_Fury_master_10hz_task.png| 700px | left| thumb | Master Controller 10Hz task]]
+[[File:F15_Fury_master_obstruction_algo.png| 700px | left| thumb | Master Controller obstruction avoidance algorithm]]
-|[[File:F15_Fury_master_obstruction_algo.png| 700px | center| thumb | Master Controller obstruction avoidance algorithm]]
+[[File:F15_Fury_master_10hz_task.png| 700px | center| thumb | Master Controller 10Hz task]]
 Since Full CAN was implemented, the master controller was never required to use any queues or wait for the CAN message to be received.

@@ Line 571: / Line 571: @@
 === Hardware Interface ===
-'''CAN''' - Master controller makes decision for motors’ behavior. The decision is sent to motor controller through CAN bus with options that provided by each module. Full can is enabled in motor/IO controller board, which means when the module receives CAN messages, messages are put into ram memory by hardware. Since LCD provides information display screen for each controller on this car, many CAN messages are received. Using normal CAN in this case accumulates the queue in CAN easily and receives messages with the same message id most likely occurs more than once but only the last one matters. Therefore, full can is a better option since the software can read from the ram for the most recent messages. For motor controller, software reads and analyzes motor messages (message ID 0x20, 0x21 and 0x22) every 0.01s, and send 2 messages(message ID 0x100 and 0x102) to CAN bus every 1s. Following is the DBC file for those messages.
+'''CAN''' - Master controller makes decision for motors’ behavior. The decision is sent to motor controller through CAN bus with options that provided by each module. Full can is enabled in motor/IO controller board, which means when the module receives CAN messages, messages are put into ram memory by hardware. Since LCD provides information display screen for each controller on this car, many CAN messages are received. Using normal CAN in this case accumulates the queue in CAN easily and receives messages with the same message id most likely occurs more than once but only the last one matters. Therefore, full can is a better option since the software can read from the ram for the most recent messages. For motor controller, software reads and analyzes motor messages (message ID 0x20, 0x21 and 0x22) every 0.01s, and send 2 messages(message ID 0x100 and 0x102) to CAN bus every 1s. Following DBC file is used to generate CAN messages that is used in motor-io module.
              BO_ 20 RESET_MOTOR: 1 DRIVER
@@ Line 595: / Line 595: @@
 [[File:CmpE243_F15_Fury_MinDutyCycle.BMP| 400px | right | thumb | Minimum Duty Cycle for turning left/going backward]]
 [[File:CmpE243_F15_Fury_DutyCycle.BMP| 400px | center| thumb | Duty Cycle for going straight/stop]]
 === Software Design ===

@@ Line 454: / Line 454: @@
 === Testing & Technical Challenges ===
 * Make sure the CAN message IDs for FullCAN is added in the ascending order and this includes the dummy IDs as well.
 * Make sure to read the CAN header file thoroughly before implementing FullCAN.

@@ Line 288: / Line 288: @@
 | 10/18/2015
 | Come up with a kill switch mechanism with the existing remote control and complete building the car.
-| In Progress
+| Completed
+| 12/04/2015
+| Delayed to focus on primary objectives for project
 |-
 ! scope="row"| 6
@@ Line 296: / Line 296: @@
 | 10/30/2015
 | Set up inter board communication with CAN and test specific messages sent to a module and broadcast messages.
+| Completed
+| 10/30/2015
+|
 |-
@@ Line 304: / Line 304: @@
 | 10/30/2015
 | Get the car running by integrating with the motor controller and Implement logging.
+| Completed
+| 10/30/2015
+|
 |-
@@ Line 312: / Line 312: @@
 | 11/13/2015
 | Integrate GPS module and implement the algorithm for the car to travel to the destination with a hard coded Destination co-ordinates.
+| Completed
+| 11/13/2015
+|
 |-
@@ Line 320: / Line 320: @@
 | 11/21/2015
 | Integrate sensor module and implement obstruction avoidance mechanism.
+| Completed
+| 10/30/2015
+|
 |-
@@ Line 328: / Line 328: @@
 | 11/25/2015
 | Integrate the Bluetooth bridge and get co ordinates from hone as well as send vehicle parameters to the phone for displaying in the app.
+| Completed
+| 11/25/201
+|
 |-
@@ Line 336: / Line 336: @@
 | 12/15/2015
 | Testing and fine tuning as required.
+| Completed
+| 12/15/2015
+|
 |}

@@ Line 722: / Line 722: @@
 * Backward - We did not know how to control the car goes backward. After quite a bit of research and experiment with the car, we found out that the ESC requires two clicks from the remote to change direction. As a result, we simulates it by sending 2 different close-to-base PWM values.
-* Brake - Our car does not have a brake. When the base PWM is sent to the ESC. The car will still move forward due to momentum. Master controller may need to take this into calculation. We will suggest to pick a car with a brake option.
+* Brake - Our car does not have a brake. When the base PWM is sent to the ESC. The car will still move forward due to momentum. Master controller needs to take this into calculation. We will suggest to pick a car with a brake option.
 * Speed sensor - At first, we stick 1 magnetic on the right back wheel and target rpm is 120. This also means about 2 pulses per second is received. Since number of data is too little for each second, the analysis/tuning of speed only can happen every 1 second. To increase the number of data, we stick 5 magnetic in total on the wheel, which means about 10 pulse per second. Now, the analysis/tuning of speed will happen every 0.5 second.
 * Computer program - One of our teammates' computer, was used to program the flash all the time, all of a sudden, causes the board rebooting after loading the program. We tried to load the exact same hex with another computer to the same board, and the board works fine.
 *LCD - We initially planned to use 4D System's 32-PTU LCD. It came with its own GUI interface, called VisieGenie. We faced some problems in getting the GUI to change its value when certain hex codes were sent out on UART. So we decided to go with the simple 20X4 LCD, without a GUI, and display values from sensors early on.

@@ Line 636: / Line 636: @@
 === Implementation ===
-'''LCD''' - LCD is used for displaying sensor data and for debugging and tuning purposes. LCD module communicates to SJSUOne Board via Uart (Uart2 Rx and Tx pins in our case). LCD displays the following information: 1) RPM received from the speed sensor 2) Right, left and front sensor readings 3) Action the car is supposed to do: For example: Go forward or Stop 4) GPS information 5) Distance to destination.
+'''LCD''' - LCD is used for displaying sensor data and for debugging and tuning purposes. LCD module communicates to SJSUOne Board via Uart (Uart2 Rx and Tx pins in our case). LCD displays the following information:(See photo in Hardware Design)
 {| class="wikitable"
 |+ LCD Module Commands
 |-
 ! scope="col"| Action
-! Commands
+! scope="col"| Commands
 |-
 ! scope="col"| Initialize UART
-! Uart2::getInstance().init(38400)
+| Uart2::getInstance().init(38400)
 |-
 ! scope="col"| Sample code for displaying rpm and car action: