S20: Bucephalus - Revision history

Proj user3 at 06:52, 10 April 2026

2026-04-10T06:52:17Z

Proj user2: /* Technical Challenges */

2020-05-23T06:53:39Z

‎Technical Challenges

Proj user2: /* Technical Challenges */

2020-05-23T06:53:03Z

‎Technical Challenges

243 user1: /* UI crash */

2020-05-23T06:51:27Z

‎UI crash

243 user1: /* Conclusion */

2020-05-23T06:31:34Z

‎Conclusion

243 user1: /* Advise for Future Students */

2020-05-23T06:28:43Z

‎Advise for Future Students

243 user1: /* Conclusion */

2020-05-23T06:06:57Z

‎Conclusion

243 user1: /* Conclusion */

2020-05-23T06:05:57Z

‎Conclusion

Proj user2: /* Essential GPS Data Calculation */

2020-05-23T06:05:00Z

‎Essential GPS Data Calculation

243 user1: /* Hardware Integration: Printed Circuit Board */

2020-05-23T06:03:14Z

‎Hardware Integration: Printed Circuit Board

@@ Line 66: / Line 66: @@
 ** <font color="CDCC1C"> '''Bridge and Sensor Controller'''
-* <font color="black"> '''Hari Haran Kura [https://gitlab.com/hariharankura GitLab] [https://www.linkedin.com/in/hariharankura/ LinkedIn]'''
+* <font color="black"> '''Hari'''
 ** <font color="4CA821"> '''Motor Controller'''
 ** <font color="blue"> '''Testing Team / Code Reviewers'''

@@ Line 1,375: / Line 1,375: @@
 We used the GPS antenna to get a faster fix and we noticed a lot more accurate GPS coordinates after connecting the antenna.
-==== 5 Unreliable GPS lock ====
+==== 3 Unreliable GPS lock ====
 After the GPS module got a lock, it would sometimes lose the lock and give incorrect GPS coordinates as the GPS Valid bit value sometimes came as 1 or 2.

@@ Line 1,356: / Line 1,356: @@
 === <font color="0000FF"> Technical Challenges </font> ===
-====Getting correct BAUD rate for GPS====
+==== 1. Calibrating Compass Module ====
-====Compass reading was not accurate and would deviate from initial calibration====
+The compass module was not giving stable values on default calibration. The compass north changed every time the module powered off. The compass value would change after a full 360-degree rotation. The compass value moved up on tilting the module.
-====Parsing NMEA sentences====
+'''''Solution:'''''
-* When we are receiving NMEA sentences from the gps module, sometimes we would receive garbled up messages. Since our GPS module continuously send out NMEA sentences and lacks a trigger pin that send NMEA sentence when prompted, we have no idea, when we are using uart driver to read the message, when the start of the message will first appear. To solve this issue, we implemented several checks to our GPS parsing. First, the processing of the messages only happens if the first character of the message is the character '$', which begins our GPRMC sentence. Next, we will only take in latitude and longitude values if the third and fifth entries read are 'N' and 'W', respectively. These checks ensure that the message is not fragmented and allow us to obtain correct longitude and latitude data.
 <HR>

@@ Line 1,783: / Line 1,783: @@
 We faced a few issues with the Android App as it used to crash, using better modules (Handler, Threads) solved the issue.
-====UI crash====
+====UI Crash====
 The UI was crashing/hanging because proper data received continuously from bluetooth had to be updated on the UI. Android provides Handler modules using which the issue was solved.

← Older revision		Revision as of 06:31, 23 May 2020
Line 1,802:		Line 1,802:

	Working on this project was a difficult yet ultimately rewarding experience. It taught us how to make use of unit tests so that we don't need hardware at all and this helped alot in online coordination with team members. We can't stress enough how important is to start the project as early as possible in the semester and to keep pushing until the final demo. Each of contributed roughly 20 hours a week to work on the project. As a result, we were exhausted by the end of it, but we also never had to pull nights sometimes to meet the deadlines. We had excellent leadership from our team lead, Mohit Ingale, as well as our mentors, Preet and ISA members Aakash, Vignesh. We also had excellent peers in CMPE 243 and are proud of what they achieved as well. Overall, we were happy to be part of this class and we hope that our project will inspire future students to develop electric vehicles.		Working on this project was a difficult yet ultimately rewarding experience. It taught us how to make use of unit tests so that we don't need hardware at all and this helped alot in online coordination with team members. We can't stress enough how important is to start the project as early as possible in the semester and to keep pushing until the final demo. Each of contributed roughly 20 hours a week to work on the project. As a result, we were exhausted by the end of it, but we also never had to pull nights sometimes to meet the deadlines. We had excellent leadership from our team lead, Mohit Ingale, as well as our mentors, Preet and ISA members Aakash, Vignesh. We also had excellent peers in CMPE 243 and are proud of what they achieved as well. Overall, we were happy to be part of this class and we hope that our project will inspire future students to develop electric vehicles.
−

	=== Project Video ===		=== Project Video ===

@@ Line 1,811: / Line 1,811: @@
 [https://gitlab.com/bucephalus/bucephalus-android-app Android Application Code]
-=== Advise for Future Students ===
+=== Advice for Future Students ===
-* '''FORM YOUR TEAM AS EARLY AS POSSIBLE AND START WORKING ON THE PROJECT AS EARLY AS POSSIBLE''' Dont't go by the team size. There is lot of work which keeps on stalking up and then can haunt us in the end of semester.
+* '''FORM YOUR TEAM AS EARLY AS POSSIBLE AND START WORKING ON THE PROJECT AS EARLY AS POSSIBLE''' Don't go by the team size. There is lot of work which keeps on stalking up and then can haunt us in the end semester.
-* If you are having trouble with your GPS or compass, ultrasonic(due to more obstacles at residential areas) try testing on top of one of the SJSU parking garages on a weekend. There is much less signal interference.
+* If you are having trouble with your GPS, compass, or ultrasonic sensors (due to more obstacles at residential areas) try testing on top of one of the SJSU parking garages on a weekend. There is much less signal interference.
 * Order spare parts and all parts before hand so that you don't keep running around at last moment. You will encounter defective parts and shipping wastes time and increases stress (especially nearing demo day)
-* Make sure to get a power supply doesn't bun you board's fuse and supplies current less than 1A. When all the car's subsystems are running, the current draw may be higher than expected
+* Make sure to get a power supply that doesn't burn your board's fuse and supplies current more than 1A. When all the car's subsystems are running, the current draw may be higher than expected
 * Don't go for cheap modules and car model from Ebay, those will probably waste more of your time and probably cost you more at the end as you might end up buying hardware again. Get quality modules and they will pay for themselves down the road.
 * Make use of all the holidays specially Spring break as there are assignments from other classes too and this would be the best time when probably everyone can be free. This will save you on the final DEMO day.

@@ Line 1,799: / Line 1,799: @@
 It wasn't always fun and lively though. We experienced soaring highs, during few of our progress demos, where we hit almost all of our specs. We also experienced devastating lows, when we were not able to demo properly as there were coordination issues offline at the start. While we look back fondly on our project, the reality is that it was the result of 7 graduate students spending almost every day of the semester developing and fine tuning the final product. We failed and succeeded together as a team. The goal was too important. Blame fell on the team as a whole and so did success and praise. We succeeded because we failed together. We succeeded because we didn't let failure break us and instead worked harder to fine tune and improve our test cases so that no case in the testing is left unexplored and the car worked exceptionally well.
-There was so much to learn. Always something new, it felt like. We developed a clean and best working PCB, to integrate all of our subsystems together with least number of wires needed and visible on the car, even though none of us had experience developing a board that complex before. We also approached new challenges such as developing an Android Mobile Application, even though none of us knew JAVA or knew Android Studio beforehand. We never stopped learning. We learned the value of investing in quality components. We honed our unit testing skills, trying to write firmware that was as high quality as our hardware. We learned about CANbus on an intimate level and applied all of the knowledge. Testing at residential area gave us a tough time especially with the GPS module and the ultrasonic sensors as the google maps did not give us the exact co-ordinates of internal society roads. while the ultrasonic sensors faced difficulty in detecting low height sidewalks.
+There was so much to learn. Always something new, it felt like. We developed a clean and best working PCB, to integrate all of our subsystems together with least number of wires needed and visible on the car, even though none of us had experience developing a board that complex before. We also approached new challenges such as developing an Android Mobile Application, even though none of us knew JAVA or knew Android Studio beforehand. We never stopped learning. We learned the value of investing in quality components. We honed our unit testing skills, trying to write firmware that was as high quality as our hardware. We learned about CANbus on an intimate level and applied all of the knowledge. Testing at residential area gave us a tough time especially with the GPS module and the ultrasonic sensors as the google maps did not give us the exact co-ordinates of internal society roads, and the ultrasonic sensors faced difficulties in detecting low height sidewalks.
 Working on this project was a difficult yet ultimately rewarding experience. It taught us how to make use of unit tests so that we don't need hardware at all and this helped alot in online coordination with team members. We can't stress enough how important is to start the project as early as possible in the semester and to keep pushing until the final demo. Each of contributed roughly 20 hours a week to work on the project. As a result, we were exhausted by the end of it, but we also never had to pull nights sometimes to meet the deadlines. We had excellent leadership from our team lead, Mohit Ingale, as well as our mentors, Preet and ISA members Aakash, Vignesh. We also had excellent peers in CMPE 243 and are proud of what they achieved as well. Overall, we were happy to be part of this class and we hope that our project will inspire future students to develop electric vehicles.

@@ Line 1,795: / Line 1,795: @@
 == Conclusion ==
-This project taught us how to work with so many people with same goal but different working patterns to come together and execute their ideas together in tandem to accomplish the team goal. We developed an autonomously navigating RC car. Each team member brought unique skills, passions and personalities to the project. Some team people were skilled with designing and placing components on the PCB Board, while others were skilled in  firmware development, project management, catching bugs, organizing meetings etc. Some people had the ability to lighten the mood on disappointing demo days, while others had the management skill to keep the team focused and making the car its best version than the day before, while avoiding burning the team out at each other. When these different minds and their skills came together, it resulted in the final product that we all are extremely proud of, as well as one that performed well on the final demo day. <B>The shelter in place due to COVID-19 brought more challenges in coordination as we couldn't meet much for in person meetings and everyone needed the hardware for testing their code. It was difficult for a single person who had all the hardware to always test with few members or alone and to explain others where exactly their code was failing.</B>
+This project taught us how to work with so many people with same goal but different working patterns to come together and execute their ideas together in tandem to accomplish the team goal. We developed an autonomously navigating RC car. Each team member brought unique skills, passions and personalities to the project. Some team people were skilled with designing and placing components on the PCB Board, while others were skilled in  firmware development, project management, catching bugs, organizing meetings etc. Some people had the ability to lighten the mood on disappointing demo days, while others had the management skill to keep the team focused and making the car its best version than the day before, while avoiding burning the team out at each other. When these different minds and their skills came together, it resulted in the final product that we all are extremely proud of, as well as one that performed well on the final demo day. <B>The shelter in place due to COVID-19 brought more challenges in coordination as we couldn't meet much for in person meetings and everyone needed the hardware for testing their code. It was difficult for a single person who had all the hardware to always test with few members or alone and to explain to others where exactly their code was failing.</B>
 It wasn't always fun and lively though. We experienced soaring highs, during few of our progress demos, where we hit almost all of our specs. We also experienced devastating lows, when we were not able to demo properly as there were coordination issues offline at the start. While we look back fondly on our project, the reality is that it was the result of 7 graduate students spending almost every day of the semester developing and fine tuning the final product. We failed and succeeded together as a team. The goal was too important. Blame fell on the team as a whole and so did success and praise. We succeeded because we failed together. We succeeded because we didn't let failure break us and instead worked harder to fine tune and improve our test cases so that no case in the testing is left unexplored and the car worked exceptionally well.

@@ Line 1,310: / Line 1,310: @@
 ===== Bearing, Distance, and Deflection Angle Calculation =====
-Bearing, calculated as an angle from true north, is the direction of the checkpoint from where the car is. The code snippet to calculate bearing is below. Lon_difference is the longitude difference between checkpoint and current location. GPS is the current location, and DEST is checkpoint location. For all trig functions used below, the longitude and latitude values have to be converted to radian. After the operations, the final bearing angle is converted to degrees and a positive value between 0 and 360.
+Bearing, calculated as an angle from true north, is the direction of the checkpoint from where the car is, it is calculated using current and destination GPS coordinates . The code snippet to calculate bearing is below. lon_difference is the longitude difference between checkpoint and current location. GPS is the current location, and l_destination_gps_coordinates is checkpoint location. For all trig functions used below, the longitude and latitude values have to be converted to radian. After the operations, the final bearing angle is converted to degrees and a positive value between 0 and 360.
- bearing = atan2((sin(lon_difference) * cos(DEST.latitude)), ((cos(GPS.latitude) * sin(DEST.latitude)) - (sin(GPS.latitude) *
+  if (check_valid_source_destination_coordinates(&l_current_gps_coordinates, &l_destination_gps_coordinates)) {
- cos(DEST.latitude) * cos(lon_difference))));
+    convert_source_destination_to_radian(&l_current_gps_coordinates, &l_destination_gps_coordinates);
-     bearing = (bearing * 180) / PI;
+    lon_difference =
-     if (bearing <= 0) bearing += 360;
+        (l_current_gps_coordinates.BRIDGE_GPS_longitude - (l_destination_gps_coordinates.BRIDGE_GPS_longitude));
-       return bearing;
+    bearing = atan2(
-Distance between the car and the checkpoint can be calculated using GPS along. The code snippet to calculate distance is shown below. It utilizes the haversine formula to calculate the great-circle distance between two points on a sphere given their longitudes and latitudes. Like the bearing calculation, all coordinates must be in radian. The value 6371 below is earth’s radius in km.
+Distance between the car and the checkpoint can be calculated using GPS current and gps coordinate. The code snippet to calculate distance is shown below. It utilizes the haversine formula to calculate the great-circle distance between two points on a sphere given their longitudes and latitudes. Like the bearing calculation, all coordinates must be in radian. The value 6371 below is earth’s radius in km.
- float a = pow(sin((DEST.latitude - GPS.latitude) / 2), 2) + cos(GPS.latitude) * cos(DEST.latitude) *
+if (check_valid_source_destination_coordinates(&l_current_gps_coordinates, &l_destination_gps_coordinates)) {
- pow(sin((DEST.longitude - GPS.longitude) / 2), 2);
+    convert_source_destination_to_radian(&l_current_gps_coordinates, &l_destination_gps_coordinates);
- float c = 2 * atan2(sqrt(a), sqrt(1 - a));
+    float lat_diff = l_destination_gps_coordinates.BRIDGE_GPS_latitude - l_current_gps_coordinates.BRIDGE_GPS_latitude;
- float distance = 6371 * 1000 * c;
+    float lon_diff =
- return distance;
+        l_destination_gps_coordinates.BRIDGE_GPS_longitude - l_current_gps_coordinates.BRIDGE_GPS_longitude;
-After obtaining heading and bearing values, deflection angle, the difference in angle between your car and the checkpoint, is calculated. This is the angle value that is given to the master for steering purposes. We made that if the deflection angle is negative, the car should steer to the left. If the angle is positive, then the car should steer to the right.
+After obtaining heading and bearing values, deflection angle, the difference in angle between your car and the checkpoint, is calculated. This is the angle value that is given to the master for steering purposes. These values are given to the driver module for taking the decision of the car direction
-  deflection = gps_bearing - compass_heading;
+  deflection = heading_angle->GEO_COMPASS_current_heading - heading_angle->GEO_COMPASS_desitination_heading;
-   if (deflection > 180)
+   if (deflection > 180) {
      deflection -= 360;
-   else if (deflection < -180)
+   } else if (deflection < -180) {
      deflection += 360;
 ===<font color="0000FF"> Software Design </font>===

@@ Line 579: / Line 579: @@
 ) Ultrasonic sensors are connected to Bridge and Sensor Controller. LCD is connected to Driver Controller. Bluetooth is connected to Bridge and Sensor Controller. CAN Bus is implemented using CAN Transceivers SN65HVD230 terminated by 120 Ohms; with PCAN for monitoring CAN Debug Messages and Data. Some Components need 5V while some sensors worked on 3.3V power supply. Also it was difficult to use separate USB's to power up all boards.Hence we used CorpCo breadboard power supply 3.3V/5V. <br>
 ) PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 with the lead time of 1 week. We implemented 2 layers of PCB with most of the parts in top layer GPS sensor and Compass sensor. We implemented rectangular header connector for SJTwo boards, RPM sensor, DC & Servo Motor on the bottom layer. There were 2 iterations of this board.<br>
-) <b> Challenges :-</b>We also need to change the header for LCD since it was having different pitch.
+) <b> Challenges: </b>We also need to change the header for LCD since it was having different pitch.
 <br><br><br>