S24: Team X - Revision history

243 user3: /* Checkpoint Algorithm */

2024-05-23T03:52:48Z

‎Checkpoint Algorithm

243 user3: /* Checkpoint Algorithm */

2024-05-23T03:47:13Z

‎Checkpoint Algorithm

243 user3: /* Haversine Algorithm */

2024-05-23T03:45:16Z

‎Haversine Algorithm

243 user3: /* Checkpoint Algorithm */

2024-05-23T03:43:30Z

‎Checkpoint Algorithm

243 user3: /* Checkpoint Algorithm */

2024-05-23T03:42:16Z

‎Checkpoint Algorithm

243 user3: /* Geographical Controller */

2024-05-23T03:40:01Z

‎Geographical Controller

243 user3: /* Project Video */

2024-05-23T03:25:36Z

‎Project Video

243 user3: /* Team Members & Responsibilities */

2024-05-23T03:16:41Z

‎Team Members & Responsibilities

243 user3: /* Software Design */

2024-05-23T03:00:09Z

‎Software Design

243 user3: /* Software Design */

2024-05-23T02:57:53Z

‎Software Design

← Older revision		Revision as of 03:52, 23 May 2024
Line 940:		Line 940:

	<syntaxhighlight lang = "c">		<syntaxhighlight lang = "c">
−	~~static const gps_coordinates_t locations_we_can_travel[NUM_OF_CHECKPOINTS] = {~~
−	~~//(la, lo)~~
−	~~// example values~~
−	~~{50, 30},~~
−	~~{20, 10},~~
−	~~{30, 90},~~
−	~~{35, -45},~~
−	~~/*{37.339084, -121.880836},~~
−	~~{37.339178, -121.880861},~~
−	~~{37.339318, -121.880970},~~
−	~~{37.339382, -121.881054},*/~~
−	};

	gps_coordinates_t find_next_point(gps_coordinates_t origin, gps_coordinates_t destination) {		gps_coordinates_t find_next_point(gps_coordinates_t origin, gps_coordinates_t destination) {

@@ Line 940: / Line 940: @@
 <syntaxhighlight lang = "c">
 gps_coordinates_t find_next_point(gps_coordinates_t origin, gps_coordinates_t destination) {
    gps_coordinates_t closest_point;

@@ Line 894: / Line 894: @@
 ==== Haversine Algorithm ====
 <syntaxhighlight lang = "c">
 void geo_logic__haversine_calculation(void) {

@@ Line 937: / Line 937: @@
 <syntaxhighlight lang = "c">
-abdc
+gps_coordinates_t find_next_point(gps_coordinates_t origin, gps_coordinates_t destination) {
+}
 </syntaxhighlight>

@@ Line 934: / Line 934: @@
 The checkpoint algorithm is a very simple algo that provides the next "checkpoint" to drive to given the current location and destination coordinates. We first try to find the closest checkpoint, and if it brings us closer to the final destination, then travel to that checkpoint. We repeat this process until no checkpoint can bring us closer and the destination is the final "checkpoint." We use the haversine algorithm to determine how close we are to a checkpoint so that we know we reached it, otherwise we may circle back around to it.
 If no checkpoints are provided in the list, then the car will attempt to navigate to the final destination directly which will likely be very challenging for large obstacles in the path. Initially, we used Euclidian distance to find the closest checkpoint, but raw distance calculated from that formula is not very easy to understand, so we switch to using haversine to get distance in meters.
 === Technical Challenges ===

← Older revision		Revision as of 03:25, 23 May 2024
Line 1,364:		Line 1,364:

	=== Project Video ===		=== Project Video ===
		+	[https://drive.google.com/file/d/1A88K5aRfS_7tnjLPoShG8fn4YsLxWrRU/view?usp=drive_link Demo]

	=== Project Source Code ===		=== Project Source Code ===

@@ Line 19: / Line 19: @@
 === Team Members & Responsibilities ===
-<Team Picture>
+[[File: TeamX_GroupPicture.jpeg]]
 [https://gitlab.com/ashley.n.ho/sjtwo-c Gitlab Project - Team X]

← Older revision		Revision as of 03:00, 23 May 2024
Line 444:		Line 444:

	The bridge task is responsible for receiving data from the APP via bluetooth. We utilize a Adafruit module (see above for part) which acts as a uart-bluetooth bridge making it extremely easy to integrate into our system without diving too deep into making bluetooth drivers. The main messages we receive are the GPS destination coordinates, and an emergency stop request.		The bridge task is responsible for receiving data from the APP via bluetooth. We utilize a Adafruit module (see above for part) which acts as a uart-bluetooth bridge making it extremely easy to integrate into our system without diving too deep into making bluetooth drivers. The main messages we receive are the GPS destination coordinates, and an emergency stop request.
		+
		+	The emergency stop task is a task that is constantly sending a "stop" flag. This flag is false by default and only set true if received from the APP. Once the vehicle stops, our the sensor node must be manually reset to continue operation.

	==== Sensor Modules ====		==== Sensor Modules ====

← Older revision		Revision as of 02:57, 23 May 2024
Line 442:		Line 442:

	The ultrasonic get sensor data task occurs in the 1hz, but we range 8 times in the 1hz function. The 3 ultrasonic sensors are chained together to prevent crosstalk. The SJ2 board will send a trigger signal to the left sensor which will then trigger the middle sensor, then the left. This process repeats 8 times in 1 second. Due to the chaining, the sample rate is significantly reduced, but the incoming data for each sensor is more accurate. Without the chaining, the sensor readings appear to be unstable.		The ultrasonic get sensor data task occurs in the 1hz, but we range 8 times in the 1hz function. The 3 ultrasonic sensors are chained together to prevent crosstalk. The SJ2 board will send a trigger signal to the left sensor which will then trigger the middle sensor, then the left. This process repeats 8 times in 1 second. Due to the chaining, the sample rate is significantly reduced, but the incoming data for each sensor is more accurate. Without the chaining, the sensor readings appear to be unstable.
		+
		+	The bridge task is responsible for receiving data from the APP via bluetooth. We utilize a Adafruit module (see above for part) which acts as a uart-bluetooth bridge making it extremely easy to integrate into our system without diving too deep into making bluetooth drivers. The main messages we receive are the GPS destination coordinates, and an emergency stop request.

	==== Sensor Modules ====		==== Sensor Modules ====