Difference between revisions of "S22: Firebolt"

Hardware Schematic Diagram

ESC & DC Motor

The DC motor is controlled by ESC using PWM signals provided by the motor controller for forward and reverse movements. We used the 9v NiMH battery to power up the ESC. The DC motor is powered by the ESC which has a dc-to-dc converter which converts 9v to 6v. The output from the ESC is used to power the Servo motor. ESC has an ease set button which is used for calibration and setting different modes for the car.

The car can be operated in the following 3 modes:
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
Racing mode(100% Forward, 100% Brakes, No Reverse)
Training mode(50% Forward, 100% Brakes, 50% Reverse)

As we desire to run the car at full throttle, Sport mode is being used. The frequency of the PWM signal fed to the servo motor is 100Hz. Based on the duty cycle set by the user, the car will go forward, reverse, or neutral.
PWM 10 to 14.9 for reverse.
PWM 15 for neutral.
PWM 15.1 to 20 for the forward.

Traxxas ESC

Traxxas Brushless DC Motor

Servo Motor

We are using Traxxas 2075 for this project which came with the car and it is responsible for steering the car. It takes the 6V power directly from ESC. The servo motor is controlled directly from the SJ2 micro-controller board. The PWM signal is supplied at a frequency of 100 Hz. Based on the duty cycle of the signal sent to the servo, the direction of servo motor can be changed:

PWM 10 to 14.9 for turning left.
PWM 15 for straight.
PWM 15.1 to 20 for turning right.

Traxass Servo Motor(2075)

RPM Sensor

The RPM sensor is used as an input to maintain a constant speed of the vehicle. The sensor we are using is Traxxas RPM sensor which using hall effect to detect the movement of the DC motor.
Mounting the sensor:
There are two parts to the RPM sensor - one is the trigger magnet and the other is the sensor. The sensor mounts on the inside of the gear cover, the trigger magnet mounts on the DC motor shaft. The gear cover and motor shaft need to be removed using the toolkit provided along with the RC car. The mounting process can be found on youtube.
How the sensor works:
The trigger magnet attaches to the spur gear. The sensor uses the DC voltage of the motor to trigger a pulse on the sensor for every rotation of the spur gear. These pulses are sent as hardware interrupt to the SJ2 board. The number of pulses are counted for every half second and that is converted into RPM and KMPH. The RPM sensor has 3 wires, the white wire is the output wire that provides the pulses to the SJ2 Board, and the other wires are Supply(3.3V) and GND.

Traxxas RPM Sensor

Trigger Magnet

Software Design

At startup the motor is initialized by giving a neutral PWM signal for 3s and the interrupt for the rpm sensor input is setup as well.

The motor receives angle for steering and speed in a single CAN message from the driver ECU. After receiving the command the speed value is converted into corresponding value of PWM by increasing or decreasing neutral PWM value in steps of 0.01. The physical value of the motor speed is compared to the speed received from the driver and it is reduced or increased to match with the desired speed. For reverse a PWM of 14.5 is given to smoothly reverse the car.

The direction of the car is set according to the value of ENUM received from the driver ECU. For navigation the car takes soft turns and when and obstacle is detected it takes hard turns to avoid collisions.

The period_callbacks__initialize() function calls the following functions:

• can_bus_initializer: Initializes CAN buffers and sets baud rate
• initialize_speed_sensor_interrupts: sets up GPIO pin as hardware interrupt
• motor_init_pwm: initializes pwm pin.

The period_callbacks__1Hz() function calls the following function:

• can_handler__handle_all_incoming_messages_1hz: handles the incoming messages based on mesg ID.
• can_handler__transmit_messages_1hz: sends the motor speed to Driver controller.

The period_callbacks__10Hz() function calls the following functions:

• pwm1__set_duty_cycle: to calibrate the ESC by sending neutral signal for few seconds.
• clear_rotations: clears interrupt counter every 0.5 seconds
• can_handler__handle_all_incoming_messages: receives any message frame sent on the CAN bus.

Speed Control Flowchart

Technical Challenges

• ESC calibration: The ESC controlling the DC motor goes out of calibration again and again. We had to connect it to the receiver of the RC car and re-calibrate it again. Finally I added a neutral signal in for the first 3 seconds in the initialization sequence of the motor so that the ESC can be calibrated every time the controller is reset or powered on.
• Changing PWM: PWM value of the motor will change sometimes and depends on the weight of the car and also a faster speed might not give enough time for the sensor to detect an obstacle. Hence keeping a slow and steady speed and relying on the RPM sensor is necessary to ensure the car keeps moving and doesn't stop on any inclines.
• Receiving steer commands at a higher frequency(50Hz) helped in reducing the response time in obstacle avoidance compared to previously when it was being received at 10Hz.

Geographical And Bridge Controller

Hardware Design

The Geographical controller does the processing for compass data and GPS data. After processing the data for heading ,bearing and distance to destination , the controller sends these data over can bus to the Driver node. The GPS module is interfaced with SJ2 board using UART. SJ2 board gets the data (NMEA string) for GPS coordinates processing. The controller sends the command to GPS module to filter the string and only send GPGGA string. The Compass module is interfaced over I2C to find the heading for car navigation. The CAN transceiver uses port 0 (can1) of the SJ2 board.

3 Axis Magnetometer (eCompass)

GPS Module

Software Design

The GEO controller consisted of 4 main parts which are:

• 1. GPS
• 2. Compass
• 3. Waypoints
• 4. Geo Logic

Overview

These code modules, calculate compass heading degree, bearing, parse GPS coordinates, calculate the checkpoints the RC car has to go through when navigating to a destination, send distance to destination to driver node, and handle messages received on the CAN bus.

The period_callbacks__initialize() function calls the following functions:

• can_bus_initializer__init(): initializes the CAN bus to handle MIA and messages(CAN).
• gps__init(): initializes the GPS interface(UART).
• geo_compass__setup_magnetometer(): initializes the compass interface(I2C).

The period_callbacks__1Hz() function calls the following function:

• can_handler__handle_all_incoming_messages_1hz(): handles the incoming messages based on mesg ID.
• gps__setup_command_registers(): sends command to GPS module to receive only GPGGA string.
• can_handler__transmit_messages_10hz(): sends the heading ,bearing and distance to Driver controller.

The period_callbacks__10Hz() function calls the following functions:

• gps_run_once(): parses the NMEA string to get current coordinates

Geo Logic Flowchart

GPS

• In the initialization process of the GPS, the line buffer module is configured to parse the GPS messages, the GPIOs P0.15(Tx) and P0.16(Rx) are configured, UART interrupt queues enabled, and the UART is configured at a baudrate of 9600(GPS standard).

• Configuration

In the gps__run_once_10Hz() the GPS is initially configured once to disable all NMEA messages except GPGGA which is message chosen to parse the coordinates and GPS lock.

• Parsing NMEA GPGGA messages

The GPS module constantly transmits NMEA GPGGA messages over UART to the SJ2 MCU. These messages which come in the form of a string are stored character by character in the line 
buffer until a new line character which indicates the end of string. The stored string is then extracted from the line buffer. The extracted line is then tokenized to parse the 
latitude, latitude direction, longitude, longitude direction, and fix quality. South and West directions are also properly handled to make the latitude and longitude negative 
values.

• GPS lock

Although the GPS module has fix indication , but GPGGA string has field for FIX status also. Getting the Fix/Lock status using the string is much easier than using GPIO pins to get 
the Lock status using FIX led of the GPS module. The Lock status/flag was used as a condition to calculate the bearing and checkpoints only when the GPS had a lock meaning that the 
current coordinates were valid.

Compass

• Initialization

The compass initialization configures the LSM303DLHC magnetometer and accelerometer registers over I2C bus to default settings using default gain and single mode.

• Heading degree computation

The compass heading degree is computed by using the tilt compensation algorithm and the pitch and roll values of LSM303DLHC accelerometer. The tilt compensation algorithm ensures 
that the values of the compass heading are precise. The formulae used to calibrate the compass are mentioned below:

• Pitch and Roll:
  

 pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) 

 roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

• Tilt compensated magnetic sensor values:
  

 mag_x = mag_x * cos(pitch) + mag_z * sin(pitch)
 mag_y = mag_y * cos(roll) + mag_x * sin(roll) * sin(pitch) - mag_z * sin(roll) * cos(pitch)
 mag_z = -mag_x * cos(roll) * sin(pitch) + mag_y * sin(roll) + mag_z * cos(roll) * cos(pitch)

Luckily our module had no offset but it might need to be compensated for the offset if there is any.

• Heading angle

heading = atan2(mag_y, mag_x) * r2d 
r2d is radian to degree conversion function

This heading is calculated in radians since atan2 returns a value between -π and +π. Therefore, before converting the heading into degrees the value needs to be normalized to put 
it in the range from 0 to 360 degrees.

Checkpoints

In real world, the source and destination are not on a straight line. The car has to find the best possible and smallest route to its final destination. In this project keeping that in mind we have used checkpoint algorithm. These waypoints are known coordinates which are given according to the destination and source path. The car needs to follow the route determined by the waypoints from source to destination.

We choose 10 points over a known location and hardcoded these coordinates in GEO node logic. Once our car gets the destination coordinates from Bridge and Sensor controller, it starts giving Heading , Bearing and Distance values to Driver Node. This waypoint must satisfy the below conditions:

• It is the closest waypoint to the current location of the car.
• Waypoint to destination distance is less than the current coordinate to the final coordinate distance.

So when the algorithm finds the destination coordinates, then bearing is calculated with that particular coordinate, so that car can be further instructions to move towards that particular point. As shown in the figure below, our algorithm keeps finding new coordinates with time (orange ones) and at last go to the final destination coordinates. The algorithm is mentioned below in the form of flowchart and code:

The way point calculation determines the nearest way point continuously by computing the distance using Haversine formula and current location using GPS. The heading and bearing is also computed using the Haversine formula and is sent over the CAN bus for heading correction.* Alternatively, once the car is within the threshold distance, next way point is selected and the car heads to the next way point.

To calculate the geographical distance between the two points the haversine formula was used which is called periodically from the waypoints.c module. Below is the formula used:

a = sin²(ΔlatDifference/2) + cos(lat1) * cos(lt2) * sin²(ΔlonDifference/2)
c = 2 * atan2(sqrt(a), sqrt(1−a))
d = R * c 

• where:
  • ΔlatDifference = latitude 2 - latitude 1 (difference of latitude)
  • ΔlonDifference = longitude 2 - longitude 1 (difference of longitude)
  • R = 6371000.0 meters = radius of earth
  • d = distance computed between two points
  • a and c are intermediate steps

• Bearing Angle computation

The bearing which is the angle towards our desired destination is computed using the formulas below referenced at this link.

X = cos θb * sin ∆L
Y = cos θa * sin θb – sin θa * cos θb * cos ∆L

β = atan2(X,Y)

• where:
  • θa = current latitude
  • θb = destination latitude
  • ∆L = destination longitude - current longitude
  • β = heading degree in radians

The bearing is also calculated in radians since atan2 returns a value between -π and +π. Therefore, before converting the heading into degrees the value needs to be normalized to put it in the range from 0 to 360 degrees. The calculated bearing is then sent to the driver node which use the compass heading degree and the bearing to align the car toward the target destination.

Technical Challenges

• Adafruit GPS
  • Problem: The data from the GPS was being refreshed every second which was causing issues for the controller.
    • Solution: Send the command to the GPS module only send the SJ2 board GPGGA data.
  • Problem: It would take way too long for the GPS to have a fix causing a 3-5 minute way when indoors and over 45 seconds when outside
    • Solution: Utilize the external antenna. It was able to get a fix inside in under a minute while outside within 25 seconds. Using separate battery can reduce the fix time.

• Compass
  • Problem: Standalone testing of the controller gave correct data but when integrated with all modules the data was inaccurate (not 0 to 360 degrees).
    • Solution: When mounting the compass module on RC car, mount it away from Motor controller and mount it on some height to avoid any interference with other nodes.

• General
  • Problem: The Geo node needs extensive testing with other nodes, if not unit tested and integration tested, it is not going to work properly.

Driver Node

Driver Node is the master controller. It receives input from sensor and bridge node, processes it to make right decision for controlling the speed and steering direction of the car and then commands the motor node to drive accordingly. This node is also interfaced to the LCD, which acts as dashboard of the car and displays information such as car speed and distance to destination on the screen.

Hardware

LCD is interfaced with the SJ2 board and it communicates over UART. P4.28 and P4.29 which is UART3 on board is used. Headlights and Tailights are also connected to the driver node using four GPIOs.

Sjtwo-board

LCD Display

Pinouts

Software Architecture Driver Logic

Obstacle Avoidance Logic

if (obstacle_on_all_front_sides()) {
          stop_the_car();
          reverse_car_and_steer();
        } else if (obstacle_on_left() && obstacle_in_right() && (!obstacle_on_front())) {
          drive_forward();
        } else if (obstacle_on_left() && (!obstacle_in_right())) {
          obstacle_on_right = false;
          get_steering_range(obstacle_on_right); // right steer
        } else if (obstacle_in_right() && (!obstacle_on_left())) {
          obstacle_on_right = true;
          get_steering_range(obstacle_on_right); // left steer
        } else if (obstacle_on_front() && (!obstacle_on_left() && !obstacle_in_right())) {
          stop_the_car();
          reverse_car_and_steer();
          obstacle_on_right =
              (internal_sensor_data.SENSOR_SONARS_right < internal_sensor_data.SENSOR_SONARS_left) ? true : false;
          get_steering_range(obstacle_on_right);

        } else if (obstacle_on_rear() && (!obstacle_on_all_front_sides())) {
          obstacle_on_right =
              (internal_sensor_data.SENSOR_SONARS_right < internal_sensor_data.SENSOR_SONARS_left) ? true : false;
          get_steering_range(obstacle_on_right);
          debug_values.car_driving_status = FORWARD;
          debug_values.car_steering_status = STRAIGHT;
        } else {
          stop_the_car();

          debug_values.car_driving_status = STOPPED;
          debug_values.car_steering_status = STRAIGHT;
        }

Steer Left and Right

  if (obstactle_on_right == true) {
    motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_HARD_LEFT;
    motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
    if (obstacle_in_right_far()) {
      motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_SOFT_LEFT;
      motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
    } else if (obstacle_in_right_near()) {
      motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_HARD_LEFT;
      motor_signal.DRIVER_TO_MOTOR_speed = reduced_speed;
    }

  } else {
    motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_HARD_RIGHT;
    motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
    if (obstacle_on_left_far()) {
      motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_SOFT_RIGHT;
      motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
    } else if (obstacle_on_left_near()) {
      motor_signal.DRIVER_TO_MOTOR_direction = MOTOR_direction_HARD_RIGHT;
      motor_signal.DRIVER_TO_MOTOR_speed = reduced_speed;
    }
  }
  motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
  // motor_signal.DRIVER_TO_MOTOR_speed = ideal_speed;
}

Reverse and Steer

  if (!obstacle_on_rear()) {
    motor_signal.DRIVER_TO_MOTOR_direction = 0;
    motor_signal.DRIVER_TO_MOTOR_speed = reverse_speed;
    update_lights(10, taillight_left);
    update_lights(10, taillight_right);
  } else {
    stop_the_car();
  }

Navigation to Destination

Driver receives raw heading and bearing from the Geo node and in order to calculate the turning direction, it first computes the difference between heading and bearing. Then based on which quadrant the difference lies and where the destination lies, take navigation decisions to steer left, right or straight.

if (heading_difference >= 350 && heading_difference <= 10) {
    gps_navigation_direction = straight;
    heading_difference = fabs(heading_difference);

    debug_values.car_driving_status = FORWARD;
    debug_values.car_steering_status = STRAIGHT;
  } else if (heading_difference > 180) {
    gps_navigation_direction = left;
    heading_difference = 360 - heading_difference;

    debug_values.car_driving_status = FORWARD;
    debug_values.car_steering_status = LEFT;

  } else if (heading_difference < 0 && heading_difference > -180) {
    gps_navigation_direction = left;
    heading_difference = fabs(heading_difference);

    debug_values.car_driving_status = FORWARD;
    debug_values.car_steering_status = LEFT;
  }

  else if (heading_difference < -180) {
    gps_navigation_direction = right;
    heading_difference = fabs(heading_difference + 360);

    debug_values.car_driving_status = FORWARD;
    debug_values.car_steering_status = RIGHT;
  } else if (heading_difference > 0 && heading_difference <= 180) {
    gps_navigation_direction = right;

    debug_values.car_driving_status = FORWARD;
    debug_values.car_steering_status = RIGHT;
  }

Periodic Callbacks

The period_callbacks__initialize() function calls the following functions:

  can__bus_initializer(can1);
  lcd__init();
  head_tail_lights_init();
  debug_led_init();

The period_callbacks__1Hz() function calls the following function:

  can_bus_handler_tx_debug_messsages(can1);
  static uint8_t count = 0;
  if (count == 0) {
    lcd__communication_init();
  }
  count = 1;
  print_info_on_lcd();

The period_callbacks__10Hz() function calls the following functions:

  can_bus_handler__process_all_received_messages(can1);
  can_bus_handler__manage_mia();
  can_bus_handler_tx_messages(can1);

Technical Challenges

• Driver receives data from sensor and geo node, so mainly the issue was sometimes not getting data accurate data from sensors or receiving late. This has made the obstacle avoidance quite slow. Make sure the sensor is transmitting data fast enough and driver is also receiving fast.
• Driver Node has the least hardware interfacing compared to other nodes, so there were not many challenges on hardware front. If the LCD communicates over UART, remember to connect the gnd of both lcd and board otherwise the data printed on LCD could be gibberish.
• High speed of car can also cause to problem for sensors, we noticed that they cannot accurately detect obstacles on high speed.
• Compass calibration was also issue sometimes, if not properly calibrated the car will have trouble navigating to gps location.

Mobile Application

The MIT App inventor 2 is an open-source web application available for free use to develop basic android mobile applications. It circumvents the need to program and develop applications using Java or Kotlin by providing block-based coding and UI development features. It uses a Graphical user Interface (GUI) like the Scratch programming language. Anyone using the web-app would just need to drag and drop blocks to design the UI and use functional blocks to develop logic, functions and flow control.

MIT App inventor for android was originally developed by Google and released in 2010. The development team was led by Hal Abelson and Mark Friedman. “In the second half of 2011, Google released the source code, terminated its server, and provided funding to create The MIT Center for Mobile Learning, led by App Inventor creator Hal Abelson and fellow MIT professors Eric Klopfer and Mitchel Resnick. The MIT version was launched in March 2012.”

App Inventor has a mobile application called the MIT AI Companion app which can be used to download a server cached version of your app under development. This makes it extremely easy and convenient to test intermediate functions and bug testing as changes can be observed in real-time. Once done with the development, users can download a “.apk” file after building. This is an installable file for the android OS which allows the user to test their app as a standalone android app.

The Web app provides two important sections for mobile app development:

User Interface

App User Interface

Flow of the App

UI development page - the “Designer page”

Function and flow development page - the “Blocks page”

Bluetooth Block

The firebolt app uses the bluetooth client block to establish a connection with the HC-05 bluetooth module onboard the car. It is necessary to establish connection and connect to a bluetooth pair to send and receive messages.

MIT App inventor block to connect and disconnect from a bluetooth devic

Map and Marker Blocks

The map block is used to create and display a 2D map of the world for location, navigation and other map functions. It uses an open-source map library which is very similar to Google Maps. The Map bloc has several functions including display, zoom, direction, distance, coordinate calculation. Fireblot uses this block to locate a destination location for the car and send the corresponding latitude and longitude values. This is made possible by the marker block. Markers can be placed on any location on the map and the pinpointed location coordinates can be received as floating point integers. These values are displayed on the app and also used to send as a bluetooth message to the HC-05 module when required.

Map and Marker blocks used in the firebolt app.

Testing and Downloading

MIT App inventor projects can be accessed for testing on the MIT AI companion app or built into a downloadable APK file. It can also be exported as a file to be later imported. The file extension for an app inventor project is “.aia”.

Bluetooth

The HC-05 module is an easy to use bluetooth module that can be used to interface with devices using its Serial Port Protocol. Bluetooth is used for wireless network transmission of data.

Technical Challenges

• The main challenge that we faced while integrating Bluetooth with sensor node is that it needs to be disconnected and reconnected again before sending new destination location every time. Also it happened for start stop button as well. The problem was resolved by calling most of the Bluetooth handler functions in periodic callbacks at 1Hz and some at 10Hz.

• Another challenge we faced was that Bluetooth can only transmit float values so we had figure out a way to send latitude and longitude values as a string to the SJ2 board.

Conclusion

This is not a project where only writing best code for our controller is not good enough. This project tests overall personality. As a team we were not prepared to spend more time on this and due to some mismanagement we were always falling behind. But we tried our best to complete the project with few team members. We learnt different aspect of a product development:

• People Management: We were more focused on our node but review is equally important. Well defined roles and responsibilities will contribute to the success and timely completion of the project.
• Finance Management: We bought components just by referring the previous years project. Before ordering we should have read the proper descriptions and then order according to requirement. There was another mistake which should have been avoided was we should have ordered some spare components like voltage regulators, batteries, SJ2 board. Few components got damaged and without figuring out problems we were only ordering and repeating the same mistake.
• Software skills: We learnt CAN protocol and Unit testing. The Unit tested modules gave us the confidence. The most important aspect that we learnt, don't trust the software which failed even one time out of hundred times, it has potential to bring you back to the starting point.
• Time Management: Well defined agenda for every week to test and develop could have made our tasks easier. Doing some home work before coming for the team meeting may have helped us to complete the project before time giving us time for more integration testing. Team meetings are meant to discuss problems and do integration.

Looking back, we could have probably created a better plan earlier on. Defining milestones for different nodes, and if they were not reached, shift our attention to get them done to progress the overall project. We overlooked a lot of the mechanical aspects of the RC car and how it would impact the compass and accelerometer. Improving our mounting and spending more time refining the process of determining heading would have likely helped a lot. Refining driver logic to deal with some variability in steering, that we did not notice until integration testing near the final weeks, earlier on could also have helped in the performance of the car in the final demo. These are learning points that we will keep in mind for future projects and add to the takeaways from the course.

We did our hardware setup much later, we wasted a lot of time in doing connections again and again. A better strategy would have been to get familiar with hardware connections and make a prototype setup to complete the milestones. We were waiting for PCB, which till the end was not completed and had some issues. It was a complete hassle to finalize our hardware in the end and test individual modules again. We got very less time for integration testing, our Geo navigation could have done much better if we would have done proper integration testing.

Project Video

https://youtu.be/lGZTV-ZGHd8

Project Source Code

https://gitlab.com/ritupatil1/firebolt/-/tree/master

https://gitlab.com/Ritika_Beniwal_/firebolt/-/tree/master

Advise for Future Students

• Get started early and make your hardware stable as early as possible so that you have enough time for extensive testing of the software. Because without on field testing corner cases and potential problems in the code can't be determined.
• Make use of the holidays and spring break. If you have your basic framework of the software and hardware is complete by the end of spring break you can start testing ASAP.
• Start researching as soon as possible and collect all the information related to the module that has been assigned to you, as there is no single book or manual to refer to. Go through all the problems faced by previous teams as they are a treasure trove of information. If you are facing a problem, it is very likely that some team in previous semesters has faced it. It will save you some precious days.
• Make sure to get a power supply which gives a steady 5V and 1A current so you don't lose boards due to sudden power surge. When all the car's subsystems are running, the current draw may be higher than expected. Make sure to have a common ground for all the components related to a single ECU.
• The most critical hardware connection is for motor node. We used the receiver , which we used to calibrate the ESC for Servo, DC and RPM power supply. We did that 1 week before our demo, and the motor node was fine.
• Do not overlook any software bug or hardware connection, It can cost you very badly. Be responsible for your node to send reliable data on bus.
• Can Transceiver: Do not trust what you read in the project reports , they might be lucky and have not faced the problems. Our Can bus data was not coming on Bus Master but every node was receiving the data, we were using same module which previous groups used. Later we found out the termination was the problem . Each Can transceiver had 120 ohm resistor. Debugging without Bus Master was a nightmare.
• It is always better to buy new and quality components. The RC Car performance depends on what components you are using. The better and reliable components makes your life easier.

Acknowledgement

We want to express our gratitude to Professor Preetpal Kang for sharing valuable inputs and knowledge throughout the duration of the project. We would also like to thank the project groups of previous years, which helped us to avoid the mistakes made by them which that we saved some time to understand the concepts better.

References

http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus

Bridge Sensor ECU

• HCSR-04

Motor ECU

• https://www.youtube.com/watch?v=-26ZSgDqwQQ&ab_channel=Traxxas
• https://www.youtube.com/watch?v=ix-J85uRFjE&ab_channel=Traxxas

Geographical ECU

• Bearing Formula
• Haversine Formula
• https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
• Compass Heading Tilt Compensated

Mobile Application

• https://developer.android.com/training/basics/firstapp
• https://www.youtube.com/watch?v=_xNkVNaC9AI&t=480s