S21: (RC)^2 - Revision history

Proj user10: /* Technical Challenges */

2021-05-29T05:34:55Z

‎Technical Challenges

Proj user10: /* Parts List & Cost */

2021-05-29T05:30:48Z

‎Parts List & Cost

Proj user10: /* Software Design */

2021-05-29T05:25:00Z

‎Software Design

Proj user10: /* Technical Challenges */

2021-05-29T05:24:45Z

‎Technical Challenges

Proj user10: /* Parts List & Cost */

2021-05-29T05:24:09Z

‎Parts List & Cost

Proj user10: /* CAN Communication */

2021-05-29T05:24:05Z

‎CAN Communication

Proj user10: /* Mobile Application */

2021-05-29T05:23:49Z

‎Mobile Application

Proj user10: /* Software Design */

2021-05-29T05:23:40Z

‎Software Design

Proj user10: /* Printed Circuit Board & Connection */

2021-05-29T05:23:33Z

‎Printed Circuit Board & Connection

Proj user10: /* Printed Circuit Board & Connection */

2021-05-29T05:23:22Z

‎Printed Circuit Board & Connection

@@ Line 671: / Line 671: @@
 === Technical Challenges ===
-'''1.''' Inconsistent Heading
+*'''Inconsistent Heading''':
 :The heading issue turned out to be related to the PCB integration. When testing the compass separately connecting by only dupont cables it performed as expected. This raises the importance of “unit testing” components, before integration to more easily locate issues in integration.
-'''2.''' Compass Calibration
+*'''Compass Calibration''':
 :For our compass calibration we ended up implementing all the algorithms we could find. The two most prominent methods are the “simple” two-point style calibration and the magmaster / magneto ardruino method. The magmaster method was the more extensive of the two and not extremely complicated when utilizing the Arduino program developed by YuriMat. Prior to being able to use this software, getting a hand-held magnetic compass is crucial. These are extremely more useful than any compass application on the Android of Apple store. A hand-held compass allowed us to locate a spot with little to no interference, making it a good location to preform calibration.

@@ Line 314: / Line 314: @@
 | $10.89
 |-
+|}
 <HR>

@@ Line 746: / Line 746: @@
 The Driver Node receive and decode these 4 CAN frame:
-+ SONAR_VALUES: Ultrasonic sensor values from the Sensor Node.
+* SONAR_VALUES: Ultrasonic sensor values from the Sensor Node.
-+ COMPASS_HEADING_DISTANCE: Geo-location information(Heading angle, Bearing angle, and Distance to destination) from the GEO Node.
+* COMPASS_HEADING_DISTANCE: Geo-location information(Heading angle, Bearing angle, and Distance to destination) from the GEO Node.
-+ GPS_DESTINATION_REACHED: A bit to signify if it has reached its destination from the GEO Node.
+* GPS_DESTINATION_REACHED: A bit to signify if it has reached its destination from the GEO Node.
-+ DRIVE_START: Used to Start or Stop sending the Motor frame to the Motor Node, this frame is received from the Bridge Node.
+* DRIVE_START: Used to Start or Stop sending the Motor frame to the Motor Node, this frame is received from the Bridge Node.
 At the top level, the ''periodic_callbacks.c'' only calls 3 functions in the 10hz periodic callback:
-+'''''(void)can_bus_message_handler__receive()''''': Receive and decode CAN dataframe from the Sensor Node, GEO Node, and the Bridge Node. Then generate the Motor command based on those frames.
+*'''''(void)can_bus_message_handler__receive()''''': Receive and decode CAN dataframe from the Sensor Node, GEO Node, and the Bridge Node. Then generate the Motor command based on those frames.
-+'''''(void)can_bus_message_handler__transmit()''''': Transmit the Motor command onto the CAN bus.
+*'''''(void)can_bus_message_handler__transmit()''''': Transmit the Motor command onto the CAN bus.
-+'''''(void)can_handler__manage_mia_10hz()''''': Check if any dataframe is missing and handle it via the MIA handlers
+*'''''(void)can_handler__manage_mia_10hz()''''': Check if any dataframe is missing and handle it via the MIA handlers
 The main part of the Driver Node is how it can generate the appropriate Motor Command given all the data from the other 3 nodes. The workflow(Represented by the above diagram) can be understood as:
-+ Check if there is any obstacle based on the Sensor values
+* Check if there is any obstacle based on the Sensor values
-+ If there is an obstacle, update the steering value to avoid the obstacle
+* If there is an obstacle, update the steering value to avoid the obstacle
-+ If not, update the steering to head to destination based on the Geo Node frame
+* If not, update the steering to head to destination based on the Geo Node frame
-+ Set the speed of the car
+* Set the speed of the car
 In our final version of (RC)&sup2;, there are a few flags that are used to set the speed:
-+ ''start_driving'' flag: This flag is set/clear by the Start/Stop signal or the Destination_reached signal: It will set the car speed to 0
+* ''start_driving'' flag: This flag is set/clear by the Start/Stop signal or the Destination_reached signal: It will set the car speed to 0
-+ ''steering_to_destination'': If this flag is set, the car is currently steering to the destination, and the speed is set at our medium default speed (when steer you should slow down)
+* ''steering_to_destination'': If this flag is set, the car is currently steering to the destination, and the speed is set at our medium default speed (when steer you should slow down)
-+ ''very_close_to_destination'': This flag is set based on the Distance left to the destination received from the GEO node. If this flag is set, the speed will also be set to the medium default speed so that it will not overshoot the destination.
+* ''very_close_to_destination'': This flag is set based on the Distance left to the destination received from the GEO node. If this flag is set, the speed will also be set to the medium default speed so that it will not overshoot the destination.
-+ Else, the car speed is set to the default speed to drive to the destination.
+* Else, the car speed is set to the default speed to drive to the destination.
 === Technical Challenges ===

@@ Line 823: / Line 823: @@
 :The process of implementing the MQTT protocol was not straight foward. Connecting to the MQTT server via ESP8266 was also difficult since everytime the wifi access point changed it would need to be reflashed with a new IP address. Keeping a static mobile hotspot to allow the ESP8266 to connect solved us having to reflash. To solve the MQTT connection problem, we set up the MQTT server using a docker on google cloud, which worked for communication to the MQTT server.
-*'''Integration with Bridge node'''
+*'''Flashing ESP8266'''
-:When we order our PCB, we decided to combine the Bridge node and the Ultrasonic node together. However, our test shows that the structure of our programs is not in sync, which made the ultrasonic sensor froze for some time during its operation. We decided to separate the two nodes. Should the 2 nodes are developed with the same structures at the beginning, we could potentially get it working. Nonetheless, these Nodes are designed differently hence integrating it requires a complete rewrite of the nodes which we decided not to pursue
+:Flashing the ESP8266 with custom software to handle MQTT was a complicated process. Using a straight connection to the ESP8266 through GPIO we were unable to flash the module without failing. Buying a 3rd party breakout board with an Arduino UNO allowed us to easily flash the ESP8266 on the first try.
 <HR>

@@ Line 238: / Line 238: @@
 ! scope="row"| 1
 | RC Car
-| Traxxas
+| DEERC
 | 1
 | $129.99
@@ Line 301: / Line 301: @@
 | 1
 | $5.90
-|}
+|-
 <HR>

← Older revision		Revision as of 05:24, 29 May 2021
Line 335:		Line 335:
	* Driver: stop the car when missing the Sensor information when the frame is missing for more than 500ms		* Driver: stop the car when missing the Sensor information when the frame is missing for more than 500ms
	* Motor: straighten the car out and stop the car		* Motor: straighten the car out and stop the car
−	* Geo: <insert version>

@@ Line 786: / Line 786: @@
 == Mobile Application ==
-<Picture and link to Gitlab>
+https://gitlab.com/rc-2/rc_car2_android_app
 === Software Design ===

@@ Line 640: / Line 640: @@
 *;'Void geo__process_gps_data(void)’: The main function used in 10Hz callback to consistently read gps, magnetometer, and accelerometer data. It then calculates heading angle and bearing angle before sending all raw data and angles onto the CAN bus.
-:*;'Void geo__transformation_mag(float uncalibrated_acc_values[3])': Geo__transformation functions are used to apply calibration and bias values o sensor data. The hard-coded calibration and bias values are from Magmaster or Magneto calibration programs
+*;'Void geo__transformation_mag(float uncalibrated_acc_values[3])': Geo__transformation functions are used to apply calibration and bias values o sensor data. The hard-coded calibration and bias values are from Magmaster or Magneto calibration programs
 '''2.''' The ''gps module'' provides basic functions to setup and interface with the Adafruit Ultimate GPS module.:

@@ Line 316: / Line 316: @@
 Here is how each ECU is connected to there respective parts.
-[[File:Circuitry_RCRC.JPG|500px|align|center|thumb|Wiring Diagram]]
+[[File:Circuitry_RCRC.JPG|800px|align|center|thumb|Wiring Diagram]]
 <HR>

@@ Line 315: / Line 315: @@
 Here is how each ECU is connected to there respective parts.
-[[File:Circuitry_RCRC.JPG|500px]Wiring Diagrams]
 <HR>