S22: TBD - Revision history

243 user4: /* LCD Implementation */

2022-05-28T06:43:39Z

‎LCD Implementation

243 user4: /* Conclusion */

2022-05-28T06:04:19Z

‎Conclusion

243 user4: /* Drive Logic */

2022-05-28T05:04:45Z

‎Drive Logic

243 user4: /* Drive Logic */

2022-05-28T05:01:29Z

‎Drive Logic

243 user4: /* Software Design */

2022-05-28T04:46:44Z

‎Software Design

243 user4: /* Drive Logic */

2022-05-28T04:33:55Z

‎Drive Logic

243 user4: /* Software Design */

2022-05-28T04:29:12Z

‎Software Design

243 user4: /* LCD Implementation */

2022-05-28T04:26:44Z

‎LCD Implementation

243 user4: /* Drive Logic */

2022-05-28T04:20:27Z

‎Drive Logic

243 user4: /* Software Design */

2022-05-28T04:20:23Z

‎Software Design

← Older revision		Revision as of 06:43, 28 May 2022
Line 1,017:		Line 1,017:
	===LCD Implementation===		===LCD Implementation===

−	The LCD needed to be set to 4-bit mode with specific delays, enables and functionality. The LCD data is set in two formats. One is for displaying characters on the screen using ~~ASIIC~~. The hex ~~ASIIC~~ value is sent 4 times. Each time is sent, the first four bits are based on the ~~ASIIC~~ hex value. For example, 'a' is 0x1C, therefore the first four bits for the first two writes will be 0x1 and the other two will be 0xC. The other four bits are for setting brightness, enable, r/w, and select. The other format is command send, which is for implementation purposes, or location setting. It follows the same methodology as sending ~~ASIIC data~~, but the select is off for all four transmissions. To write to the display, we would need to send a command to set the location of the message. Then we need to send the actual data as a string. If it is a short string, the rest of the pixels need to be set to empty spaces. This is necessary to display values that are constantly being updated. If not set, the LCD would display old characters. This is call at 100Hz in periodic callbacks.	+	The LCD needed to be set to 4-bit mode with specific delays, enables and functionality. The LCD data is set in two formats. One is for displaying characters on the screen using ASCII. The hex ASCII value is sent 4 times. Each time is sent, the first four bits are based on the ASCII hex value. For example, 'a' is 0x1C, therefore the first four bits for the first two writes will be 0x1 and the other two will be 0xC. The other four bits are for setting brightness, enable, r/w, and select. The other format is command send, which is for implementation purposes, or location setting. It follows the same methodology as sending characters, but the select is off for all four transmissions. To write to the display, we would need to send a command to set the location of the message. Then we need to send the actual data as a string. If it is a short string, the rest of the pixels need to be set to empty spaces. This is necessary to display values that are constantly being updated. If not set, the LCD would display old characters. This is call at 100Hz in periodic callbacks.

@@ Line 1,159: / Line 1,159: @@
 == Conclusion ==
-Overall this project taught us many industry relevant topics. We were able to utilize and understand the CAN Bus to create a realistic self-driving RC car which emulated how a real car would function. Different controllers were used for: Obtain geological and position related data, obtain RPM and distance data through various sensors, control steering servo and control forward/ reverse speed, and a singular driver controller to control logic.
+Overall this project taught us many industry relevant topics. We were able to utilize and understand the CAN Bus to create a realistic self-driving RC car which emulated how a real car would function. Different controllers were used for: obtaining geological and position related data, obtain RPM and distance data through various sensors, control steering servo and control forward/ reverse speed, and a singular driver controller to control logic.
 === Project Video ===
@@ Line 1,183: / Line 1,187: @@
 * Once your car can move, test outside on the garage.
 ** Ultrasonic sensors give incorrect readings at steep angles, making testing in the hallway somewhat difficult.
-** Compass readings are also more accurate outside the building where there is less interferance.
+** Compass readings are also more accurate outside the building where there is less interference.
 === Acknowledgement ===
-We would like to acknowledge our instructor, Preet, for encouraging us to gather knowledge and to tackle difficult problems.
+We would like to acknowledge our instructor, Preet, for encouraging us to gather knowledge and to tackle difficult problems. We would also like to thank him for sharing his industry experience and providing us with a class and project that will be beneficial for us and our success in the industry going forward.
 === References ===

@@ Line 1,054: / Line 1,054: @@
 The above flowchart shows the high level overview of our driver logic which begins with receiving sensor values from the sensor controller. The first check is to see if we are currently idle or not. This is the one check that will override all others, including emergency stop thresholds. We decided on this design since there are no real breaks for the car, we wanted to be able to steer as the car is coming to a stop. Emergency stop is handled in a different routine, thus we had to make this check first to obtain the desired functionality. If the car is not in the idle state, then we next check the sensor values to see if any are within the emergency stop threshold which we set to 30cm or 1 foot. If any of the readings indicated this, then we went to the emergency stop routine, described below. If the sensor readings all read above the emergency stop threshold, then we check to see if there is an obstacle within our next threshold. The threshold to detect an obstacle is 140cm. This value was chosen because of the sensor configuration giving most accurate values up to this distance. When an obstacle is detected, we perform a deflection calculation which would give us a linear mapping of how much to change the steering angle depending on how far away it was from the car. The closer the obstacle, the harsher the steering angle we would send. If no obstacle was in the threshold value, then we simply sent the same steering that was calculated according to our destination and current heading. The correlation between deflection/motor speed and obstacle distance is illustrated in the diagram below.
-[[File:Obstacle_plot.png|600px]]
+[[File:Obstacle_plot.png|800px]]
 '''Emergency Stop'''

@@ Line 1,052: / Line 1,052: @@
 [[File:Drive_logic.PNG|400px|Driver Algorithm]]
-The above flowchart shows the high level overview of our driver logic which begins with receiving sensor values from the sensor controller. The first check is to see if we are currently idle or not. This is the one check that will override all others, including emergency stop thresholds. We decided on this design since there are no real breaks for the car, we wanted to be able to steer as the car is coming to a stop. Emergency stop is handled in a different routine, thus we had to make this check first to obtain the desired functionality. If the car is not in the idle state, then we next check the sensor values to see if any are within the emergency stop threshold which we set to 30cm or 1 foot. If any of the readings indicated this, then we went to the emergency stop routine, described below. If the sensor readings all read above the emergency stop threshold, then we check to see if there is an obstacle within our next threshold. The threshold to detect an obstacle is 140cm. This value was chosen because of the sensor configuration giving most accurate values up to this distance. When an obstacle is detected, we perform a deflection calculation which would give us a linear mapping of how much to change the steering angle depending on how far away it was from the car. The closer the obstacle, the harsher the steering angle we would send. If no obstacle was in the threshold value, then we simply sent the same steering that was calculated according to our destination and current heading.
+The above flowchart shows the high level overview of our driver logic which begins with receiving sensor values from the sensor controller. The first check is to see if we are currently idle or not. This is the one check that will override all others, including emergency stop thresholds. We decided on this design since there are no real breaks for the car, we wanted to be able to steer as the car is coming to a stop. Emergency stop is handled in a different routine, thus we had to make this check first to obtain the desired functionality. If the car is not in the idle state, then we next check the sensor values to see if any are within the emergency stop threshold which we set to 30cm or 1 foot. If any of the readings indicated this, then we went to the emergency stop routine, described below. If the sensor readings all read above the emergency stop threshold, then we check to see if there is an obstacle within our next threshold. The threshold to detect an obstacle is 140cm. This value was chosen because of the sensor configuration giving most accurate values up to this distance. When an obstacle is detected, we perform a deflection calculation which would give us a linear mapping of how much to change the steering angle depending on how far away it was from the car. The closer the obstacle, the harsher the steering angle we would send. If no obstacle was in the threshold value, then we simply sent the same steering that was calculated according to our destination and current heading. The correlation between deflection/motor speed and obstacle distance is illustrated in the diagram below.
 '''Emergency Stop'''

← Older revision		Revision as of 04:46, 28 May 2022
Line 622:		Line 622:

	A simple algorithm was used to determine the PWM signal sent to the steering servos. We decide to have the driver node send a direction between the values of -180 to 179. After some quick testing with the values, we found the range to be much larger than then we required to get the steering to be a fluid motion. To solve this, we had our firmware treat any signal above 40 and below -40 to be max right and left respectively. We then had to scale the values within that range using the algorithm in the flow chart above.		A simple algorithm was used to determine the PWM signal sent to the steering servos. We decide to have the driver node send a direction between the values of -180 to 179. After some quick testing with the values, we found the range to be much larger than then we required to get the steering to be a fluid motion. To solve this, we had our firmware treat any signal above 40 and below -40 to be max right and left respectively. We then had to scale the values within that range using the algorithm in the flow chart above.
		+
		+	Steering Algorithm code snippet showing the scaling duty cycle outside of the +/- 40 range sent from driver.
		+
		+	<syntaxhighlight lang="cpp">
		+	void motor_controller__set_direction(int16_t direction) {
		+	if (direction < -40) {
		+	motor_controller__set_direction_pwm_cycle(11.96); // 6.66
		+	} else if (direction > 40) {
		+	motor_controller__set_direction_pwm_cycle(6.66);
		+	} else {
		+	float duty_cycle = (9.31 - (direction / 40.0) * 2.65);
		+	motor_controller__set_direction_pwm_cycle(duty_cycle);
		+	}
		+	}
		+	</syntaxhighlight>

	'''Forward Backward Algorithm'''		'''Forward Backward Algorithm'''

← Older revision		Revision as of 04:33, 28 May 2022
Line 1,043:		Line 1,043:
	[[File:Driver_estop.PNG\|400px\|Emergency Stop]]		[[File:Driver_estop.PNG\|400px\|Emergency Stop]]

		+	Emergency stop was handled as a special case of object detection. If an object entered the threshold for an emergency stop (30cm), then we send an idle speed to the motors and start a timer in which we monitor the sensor values. If at the end of the timer (timer is just a counter based on callback count) one or more of the ultra sonic sensors are still detecting an object within the emergency stop threshold, then we enter the reverse routine below.

@@ Line 801: / Line 801: @@
 '''Compass Implementation and Calibration'''
-Once the required registers have been initialized, the compass will return uncalibrated x, y, and z values. For its calibration we used the software Magneto v1.2. Magneto requires a txt file of raw magnetometer values and our locations magnetic field. Magneto will then provide the bias and scaling factor matrix needed for calibration. Those values are then plug into the equation Matrix^-1((raw/gain*100)-bias), where gain is 1100 gauss for the x and y values and 980 gauss for the z value. Those calibrated x and y values are used to find the radians of the compass heading. The radians are then converted and returned as degrees. By flipping the compass upside down, the compass was able to reduced tilt factor to provide accurate readings.
+Once the required registers have been initialized, the compass will return uncalibrated x, y, and z values. For its calibration we used the software Magneto v1.2. Magneto requires a txt file of raw magnetometer values and our locations magnetic field. Magneto will then provide the bias and scaling factor matrix needed for calibration. Those values are then plug into the equation in the code below, where gain is 1100 gauss for the x and y values and 980 gauss for the z value. Those calibrated x and y values are used to find the radians of the compass heading. The radians are then converted and returned as degrees. By flipping the compass upside down, the compass was able to reduced tilt factor to provide accurate readings.
 <syntaxhighlight lang="cpp">

← Older revision		Revision as of 04:26, 28 May 2022
Line 1,003:		Line 1,003:

	The LCD needed to be set to 4-bit mode with specific delays, enables and functionality. The LCD data is set in two formats. One is for displaying characters on the screen using ASIIC. The hex ASIIC value is sent 4 times. Each time is sent, the first four bits are based on the ASIIC hex value. For example, 'a' is 0x1C, therefore the first four bits for the first two writes will be 0x1 and the other two will be 0xC. The other four bits are for setting brightness, enable, r/w, and select. The other format is command send, which is for implementation purposes, or location setting. It follows the same methodology as sending ASIIC data, but the select is off for all four transmissions. To write to the display, we would need to send a command to set the location of the message. Then we need to send the actual data as a string. If it is a short string, the rest of the pixels need to be set to empty spaces. This is necessary to display values that are constantly being updated. If not set, the LCD would display old characters. This is call at 100Hz in periodic callbacks.		The LCD needed to be set to 4-bit mode with specific delays, enables and functionality. The LCD data is set in two formats. One is for displaying characters on the screen using ASIIC. The hex ASIIC value is sent 4 times. Each time is sent, the first four bits are based on the ASIIC hex value. For example, 'a' is 0x1C, therefore the first four bits for the first two writes will be 0x1 and the other two will be 0xC. The other four bits are for setting brightness, enable, r/w, and select. The other format is command send, which is for implementation purposes, or location setting. It follows the same methodology as sending ASIIC data, but the select is off for all four transmissions. To write to the display, we would need to send a command to set the location of the message. Then we need to send the actual data as a string. If it is a short string, the rest of the pixels need to be set to empty spaces. This is necessary to display values that are constantly being updated. If not set, the LCD would display old characters. This is call at 100Hz in periodic callbacks.
		+
		+
		+
		+	<syntaxhighlight lang="cpp">
		+	void i2c_lcd__send_command(char command) {
		+
		+	uint8_t cmd_w[4];
		+	cmd_w[0] = (command & 0xf0) \| 0x0C;
		+	cmd_w[1] = (command & 0xf0) \| 0x08;
		+	cmd_w[2] = ((command << 4) & 0xf0) \| 0x0C;
		+	cmd_w[3] = ((command << 4) & 0xf0) \| 0x08;
		+	i2c__write_single(i2c_lcd__sensor_bus, i2c_lcd__address, cmd_w[0], cmd_w[1]);
		+	i2c__write_single(i2c_lcd__sensor_bus, i2c_lcd__address, cmd_w[2], cmd_w[3]);
		+	}
		+
		+	void i2c_lcd__send_data(char data) {
		+
		+	uint8_t data_w[4];
		+	data_w[0] = (data & 0xf0) \| 0x0D;
		+	data_w[1] = (data & 0xf0) \| 0x09;
		+	data_w[2] = ((data << 4) & 0xf0) \| 0x0D;
		+	data_w[3] = ((data << 4) & 0xf0) \| 0x09;
		+
		+	i2c__write_single(i2c_lcd__sensor_bus, i2c_lcd__address, data_w[0], data_w[1]);
		+	i2c__write_single(i2c_lcd__sensor_bus, i2c_lcd__address, data_w[2], data_w[3]);
		+	}
		+	</syntaxhighlight>

	=== Drive Logic ===		=== Drive Logic ===

← Older revision		Revision as of 04:20, 28 May 2022
Line 1,023:		Line 1,023:

	Reverse logic was needed in the case that the car stayed within the emergency stop threshold of an object for a preset amount of callbacks. If this was the case, we would reverse in the same direction of the sensor with the lowest distance reading. The logic behind this was that we wanted to head in a direction which way away from the object that got us stuck in the first place. IE if the right most sensor was within the emergency stop threshold, we would reverse back and to the right so that the car would face in a more leftward direction away from the obstacle.		Reverse logic was needed in the case that the car stayed within the emergency stop threshold of an object for a preset amount of callbacks. If this was the case, we would reverse in the same direction of the sensor with the lowest distance reading. The logic behind this was that we wanted to head in a direction which way away from the object that got us stuck in the first place. IE if the right most sensor was within the emergency stop threshold, we would reverse back and to the right so that the car would face in a more leftward direction away from the obstacle.
		+
		+	<syntaxhighlight lang="cpp">
		+	static int16_t obstacle_avoid_direction_when_reversing(dbc_SENSOR_TO_DRIVER_SONARS_s *sense) {
		+	uint8_t lowest_value = lowest_sensor_reading(sense);
		+	if (lowest_value == sense->SENSOR_TO_DRIVER_SONARS_front_middle) {
		+	return 0;
		+	} else if (lowest_value == sense->SENSOR_TO_DRIVER_SONARS_front_right) {
		+	return 90;
		+	} else {
		+	return -90;
		+	}
		+	}
		+
		+	</syntaxhighlight>

	=== Technical Challenges ===		=== Technical Challenges ===

← Older revision		Revision as of 04:20, 28 May 2022
Line 802:		Line 802:

	Once the required registers have been initialized, the compass will return uncalibrated x, y, and z values. For its calibration we used the software Magneto v1.2. Magneto requires a txt file of raw magnetometer values and our locations magnetic field. Magneto will then provide the bias and scaling factor matrix needed for calibration. Those values are then plug into the equation Matrix^-1((raw/gain*100)-bias), where gain is 1100 gauss for the x and y values and 980 gauss for the z value. Those calibrated x and y values are used to find the radians of the compass heading. The radians are then converted and returned as degrees. By flipping the compass upside down, the compass was able to reduced tilt factor to provide accurate readings.		Once the required registers have been initialized, the compass will return uncalibrated x, y, and z values. For its calibration we used the software Magneto v1.2. Magneto requires a txt file of raw magnetometer values and our locations magnetic field. Magneto will then provide the bias and scaling factor matrix needed for calibration. Those values are then plug into the equation Matrix^-1((raw/gain*100)-bias), where gain is 1100 gauss for the x and y values and 980 gauss for the z value. Those calibrated x and y values are used to find the radians of the compass heading. The radians are then converted and returned as degrees. By flipping the compass upside down, the compass was able to reduced tilt factor to provide accurate readings.
		+
		+	<syntaxhighlight lang="cpp">
		+	double calibrated_vales(lsm303_compass__data_s compass_data) {
		+
		+	float X_offset, Y_offset, Z_offset;
		+
		+	/calibration data for 36.6777° N, 121.6555° W/
		+	X_offset = (compass_data.x / 1100.00 * 100) - 10.607740; // axis raw value divided by gauss value - bias
		+	Y_offset = (compass_data.y / 1100.00 * 100) + 23.867664; //
		+	Z_offset = (compass_data.z / 980.0 * 100) + 29.267481; // Z-axis has a different gauss value
		+
		+	X_offset = 0.759463 * X_offset + 0.019219 * Y_offset + 0.004519 * Z_offset; // value of 3x3 matrix from magneto
		+	Y_offset = 0.019219 * X_offset + 0.760030 * Y_offset + 0.003038 * Z_offset; //
		+	Z_offset = 0.004519 * X_offset + 0.003038 * Y_offset + 0.738498 * Z_offset; //
		+
		+
		+	return atan2(X_offset, Y_offset) * 180 / M_PI;
		+	}
		+	</syntaxhighlight>
		+