Embedded Systems Learning Academy - User contributions [en]

F24: Brick Breaker

2024-12-20T01:32:42Z

Proj user9: /* Schedule */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
The Brick Breaker game project served as an excellent opportunity to apply and expand our knowledge of embedded systems, specifically in hardware-software integration and real-time application development. Throughout the project, we faced several challenges, including collision detection issues with block corners and the difficulties associated with debugging real-time game logic. By addressing these problems with a combination of structured design and innovative solutions, such as standardizing collision handling and leveraging modular code, we were able to deliver a functional and engaging game.

Testing was both a critical and challenging aspect of the project. While print statement debugging helped identify and resolve issues, it became evident that this method is not scalable for larger or more complex projects. This realization underscored the importance of implementing robust unit testing frameworks in future endeavors to streamline the debugging process and improve code reliability.

Through this project, we not only deepened our understanding of the SJ2 board and its peripherals but also gained valuable insights into designing interactive systems with real-time constraints. We learned the significance of modular programming, effective problem-solving, and the practical challenges of integrating multiple hardware components. Moreover, this project reinforced the importance of designing for scalability and maintainability, skills that are critical for larger and more complex systems.

Ultimately, this project has enhanced our ability to think critically about embedded system design and implementation, providing a strong foundation for tackling similar challenges in future endeavors. The lessons learned and skills developed here will undoubtedly inform and improve our approach to future projects, whether they involve gaming systems, embedded controls, or other interactive applications.

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
We'd like to thank Preet for giving us the opportunity to develop and learn through an interactive team project. We would also like to acknowledge the TA Shailja Jain for their feedback throughout the semester.

F24: Brick Breaker

2024-12-20T01:31:04Z

Proj user9: /* References */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
The Brick Breaker game project served as an excellent opportunity to apply and expand our knowledge of embedded systems, specifically in hardware-software integration and real-time application development. Throughout the project, we faced several challenges, including collision detection issues with block corners and the difficulties associated with debugging real-time game logic. By addressing these problems with a combination of structured design and innovative solutions, such as standardizing collision handling and leveraging modular code, we were able to deliver a functional and engaging game.

Testing was both a critical and challenging aspect of the project. While print statement debugging helped identify and resolve issues, it became evident that this method is not scalable for larger or more complex projects. This realization underscored the importance of implementing robust unit testing frameworks in future endeavors to streamline the debugging process and improve code reliability.

Through this project, we not only deepened our understanding of the SJ2 board and its peripherals but also gained valuable insights into designing interactive systems with real-time constraints. We learned the significance of modular programming, effective problem-solving, and the practical challenges of integrating multiple hardware components. Moreover, this project reinforced the importance of designing for scalability and maintainability, skills that are critical for larger and more complex systems.

Ultimately, this project has enhanced our ability to think critically about embedded system design and implementation, providing a strong foundation for tackling similar challenges in future endeavors. The lessons learned and skills developed here will undoubtedly inform and improve our approach to future projects, whether they involve gaming systems, embedded controls, or other interactive applications.

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
We'd like to thank Preet for giving us the opportunity to develop and learn through an interactive team project. We would also like to acknowledge the TA Shailja Jain for their feedback throughout the semester.

F24: Brick Breaker

2024-12-20T01:30:42Z

Proj user9: /* Acknowledgement */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
The Brick Breaker game project served as an excellent opportunity to apply and expand our knowledge of embedded systems, specifically in hardware-software integration and real-time application development. Throughout the project, we faced several challenges, including collision detection issues with block corners and the difficulties associated with debugging real-time game logic. By addressing these problems with a combination of structured design and innovative solutions, such as standardizing collision handling and leveraging modular code, we were able to deliver a functional and engaging game.

Testing was both a critical and challenging aspect of the project. While print statement debugging helped identify and resolve issues, it became evident that this method is not scalable for larger or more complex projects. This realization underscored the importance of implementing robust unit testing frameworks in future endeavors to streamline the debugging process and improve code reliability.

Through this project, we not only deepened our understanding of the SJ2 board and its peripherals but also gained valuable insights into designing interactive systems with real-time constraints. We learned the significance of modular programming, effective problem-solving, and the practical challenges of integrating multiple hardware components. Moreover, this project reinforced the importance of designing for scalability and maintainability, skills that are critical for larger and more complex systems.

Ultimately, this project has enhanced our ability to think critically about embedded system design and implementation, providing a strong foundation for tackling similar challenges in future endeavors. The lessons learned and skills developed here will undoubtedly inform and improve our approach to future projects, whether they involve gaming systems, embedded controls, or other interactive applications.

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
We'd like to thank Preet for giving us the opportunity to develop and learn through an interactive team project. We would also like to acknowledge the TA Shailja Jain for their feedback throughout the semester.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

F24: Brick Breaker

2024-12-20T01:30:24Z

Proj user9: /* Acknowledgement */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
The Brick Breaker game project served as an excellent opportunity to apply and expand our knowledge of embedded systems, specifically in hardware-software integration and real-time application development. Throughout the project, we faced several challenges, including collision detection issues with block corners and the difficulties associated with debugging real-time game logic. By addressing these problems with a combination of structured design and innovative solutions, such as standardizing collision handling and leveraging modular code, we were able to deliver a functional and engaging game.

Testing was both a critical and challenging aspect of the project. While print statement debugging helped identify and resolve issues, it became evident that this method is not scalable for larger or more complex projects. This realization underscored the importance of implementing robust unit testing frameworks in future endeavors to streamline the debugging process and improve code reliability.

Through this project, we not only deepened our understanding of the SJ2 board and its peripherals but also gained valuable insights into designing interactive systems with real-time constraints. We learned the significance of modular programming, effective problem-solving, and the practical challenges of integrating multiple hardware components. Moreover, this project reinforced the importance of designing for scalability and maintainability, skills that are critical for larger and more complex systems.

Ultimately, this project has enhanced our ability to think critically about embedded system design and implementation, providing a strong foundation for tackling similar challenges in future endeavors. The lessons learned and skills developed here will undoubtedly inform and improve our approach to future projects, whether they involve gaming systems, embedded controls, or other interactive applications.

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
We'd like to thank Preet for giving us the opportunity to develop and learn through an interactive team project. We would also like to acknowledge the TA Shilja Jain for their feedback throughout the semester.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

F24: Brick Breaker

2024-12-20T01:29:20Z

Proj user9: /* Conclusion */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
The Brick Breaker game project served as an excellent opportunity to apply and expand our knowledge of embedded systems, specifically in hardware-software integration and real-time application development. Throughout the project, we faced several challenges, including collision detection issues with block corners and the difficulties associated with debugging real-time game logic. By addressing these problems with a combination of structured design and innovative solutions, such as standardizing collision handling and leveraging modular code, we were able to deliver a functional and engaging game.

Testing was both a critical and challenging aspect of the project. While print statement debugging helped identify and resolve issues, it became evident that this method is not scalable for larger or more complex projects. This realization underscored the importance of implementing robust unit testing frameworks in future endeavors to streamline the debugging process and improve code reliability.

Through this project, we not only deepened our understanding of the SJ2 board and its peripherals but also gained valuable insights into designing interactive systems with real-time constraints. We learned the significance of modular programming, effective problem-solving, and the practical challenges of integrating multiple hardware components. Moreover, this project reinforced the importance of designing for scalability and maintainability, skills that are critical for larger and more complex systems.

Ultimately, this project has enhanced our ability to think critically about embedded system design and implementation, providing a strong foundation for tackling similar challenges in future endeavors. The lessons learned and skills developed here will undoubtedly inform and improve our approach to future projects, whether they involve gaming systems, embedded controls, or other interactive applications.

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

F24: Brick Breaker

2024-12-20T01:26:31Z

Proj user9: /* Testing & Technical Challenges */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
A significant technical challenge during the implementation of the Brick Breaker game was ensuring accurate collision detection, especially when the ball interacted with multiple bricks or hit a corner. The issue arose when the ball's next position overlapped with a corner shared by two or more blocks. This led to inconsistencies in how collisions were detected and resolved. For instance, if two bricks were stacked vertically or placed side by side, the ball's direction could behave unpredictably, leading to unexpected bounces. Initially, our collision logic treated corners as part of either a row or a column based on the ball's direction of travel. While this approach worked in simple cases, it failed when multiple blocks were involved.

To address this, we standardized the handling of corners by treating all corners as part of a column rather than a row. This change provided a consistent logic flow for detecting and handling collisions, ensuring the ball's trajectory behaved predictably even in complex scenarios. Testing this approach revealed that treating corners as rows led to erratic bounces and breaks in the gameplay flow, while treating them as part of columns yielded a smoother and more intuitive experience. This adjustment significantly improved the game's performance and user experience, resolving an issue that had initially seemed insurmountable.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

F24: Brick Breaker

2024-12-20T01:16:31Z

Proj user9: /* Design & Implementation */

=== Grading Criteria ===
<font color="green">
* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.
</font>

== Brick Breaker ==

== Abstract ==
Brick Breaker is a classic arcade-style game focused on quick reflexes and survival, reminiscent of retro gaming experiences. This project aims to recreate the intense and fast-paced gameplay using the SJ-2 board and an LED matrix display. In this game, players control a character (or an object) that must dodge incoming obstacles from multiple directions, with the speed and frequency of obstacles increasing over time. The objective is to survive as long as possible, setting high scores based on survival time. Players will use buttons or a joystick to maneuver, with core implementation focusing on responsive controls, real-time collision detection, and adaptive difficulty for sustained challenge.

== Objectives & Introduction ==
The project is split into a few sub-topics that could be worked by individuals:

*Main "clock" task for updating the LED matrix.
*Main gameplay loop task that would update the position of the ball, paddle, and blocks.
*Design of various game screens via a state machine.
*Game logic to determine the ball's bounce relative to its current trajectory.
*MP3 background track during gameplay.

=== Team Members & Responsibilities ===
* Manoj
** Game logic
** Block generator
* Kevin
** Hardware connections
** Game page switching logic
** Game page switching logic
** Led testing , button testing
* Harbans
** Accerometer and paddle
** Block generator

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/20/2024
* 10/27/2024
|
* 10/20/2024
* 10/27/2024
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project - TO_BE_UPDATED
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
|
*10/27/2024
|
*11/02/2024
|

*Order necessary parts - LED Matrix , Speaker , Accelerometer
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
*11/02/2024
|
*11/08/2024
|
*Read and familiarize with LED Matrix Datasheet
|
* <span style="color:green">Completed</span>

|-
! scope="row"| 4
|
* 11/02/2024
|
* 11/08/2024
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
*11/09/2024
*11/09/2024
*11/09/2024
*11/09/2024
|
*11/10/2024
*11/15/2024
*11/15/2024
*11/15/2024
|
* Finalize wiki schedule
* Order circuit components
* circuit and component assembly
* Circuit testing
* Additional accessories if required and finalization of hardware
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
*11/16/2024
|
*11/22/2024
|
*Integration of circuit and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/23/2024

|
* 11/29/2024
|
* Integrate game logic code with LED matrix
|
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 11/30/2024
|
* 12/06/2024
|

* Integrate subsystem
* Finalizing the video game
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/07/2024
|
* 12/13/2024
|
* Work on game page switching
* Update the wiki page.
|
* <span style="color:orange">In progress</span>
* <span style="color:orange">In progress</span>
|-
! scope="row"| 10
|
*12/16/2024
*12/14/2024
*12/14/2024
*12/14/2024
|
*12/16/2024
*12/16/2024
*12/16/2024
*12/16/2024
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
* <span style="color:red">Not started</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|- style="background-color:#34ff34;"
! Part
! Link
! Price
! Quantity
|-
| LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| $80
| 1
|-
| Power Supply
| [https://www.adafruit.com/product/658 Adafruit]
| $30
| 1
|-
| Button
| [https://www.adafruit.com/product/3489 Adafruit]
| $2.50
| 1
|-
| Quick connect wires
| [https://www.adafruit.com/product/1152 Adafruit]
| $4.95
| 1
|-
| MP3 Module
| [https://www.adafruit.com/product/1788 Adafruit]
| $34.95
| 1
|-
| Speakers
| [https://www.adafruit.com/product/1669 Adafruit]
| $7.50
| 1
|-
| SJ2 Development Board
| [https://www.amazon.com/Generic-SJTwo-SJ2-SJSU/dp/B08G9LRPZ8/ref=sr_1_2?keywords=SJ2&qid=1639798706&sr=8-2 Amazon]
| $50
| 1
|}

== Design & Implementation ==
For the design and implementation of the Brick Breaker game, the SJ2 board serves as the central controller to interface with a 64x64 LED matrix, control buttons, and an accelerometer. Each of these components plays a crucial role in the functionality of the game, enabling dynamic gameplay and interactivity.

=== Hardware Design ===
In the hardware setup for this project, we outlined a few high-level connections that were necessary to implement the Brick Breaker game. These connections can be visualized in the top-level schematic shown below. The schematic was designed using draw.io.

Hardware Interconnects:
*SJ2 Connection to the LED Matrix
*SJ2 Connection to Buttons
*SJ2 Connection to Accelerometer

SJ2 Board Connection to LED Matrix:
The SJ2 board controlled the 64x64 LED matrix, which served as the primary visual interface for the game. The matrix required a range of GPIO pins for row, column, and color control. It did not use standard communication protocols like I2C or UART but relied on GPIO switching to drive the display. The key pin connections are as follows:
{| class="wikitable"
|- style="background-color:#34ff34;"
! Address Pins
! Color Pins
! Control Pins
|-
| A, B, C, D, E
| R1, G1, B1 | R2, G2, B2
| OE, CLK, LAT
|}
*Address Pins: Allowed selection of specific rows for updating pixel data (rows 0 - 31).
*Color Pins: Enabled 8 distinct colors through combinations of red, green, and blue.
*Control Pins:
** OE (Output Enable): Controlled when the display was active.
** CLK (Clock): Synchronized data transfer for row and pixel updates.
** LAT (Latch): Locked data into the display.

SJ2 Board Connection to Buttons
The buttons served as an input interface for the player to control the paddle in the game. The buttons were connected to GPIO pins on the SJ2 board and configured to trigger on falling-edge interrupts. Each button press caused an interrupt, which was handled by a software ISR to update the paddle’s position on the LED matrix.

Key features of the button setup:

*Interrupt-Driven Design:
**Each button press generated an interrupt to ensure immediate responsiveness.
*Debouncing:
**Software debouncing eliminated the effects of mechanical noise in button presses.

SJ2 Board Connection to Accelerometer
The accelerometer provided an alternative input method by allowing the player to control the paddle through tilting. It was connected to the SJ2 board via the I2C interface, which facilitated real-time reading of the accelerometer's X-axis data. This data was processed to move the paddle proportionally to the tilt.

Key features of the accelerometer setup:

*I2C Communication:
**Enabled efficient data transfer between the accelerometer and the SJ2 board.
*Real-Time Input:
**X-axis readings were mapped to paddle movement for smooth control.
*Calibration:
**Initial calibration ensured accurate and stable readings, compensating for noise or offsets.

=== Hardware Interface ===
The 64x64 LED matrix acts as the primary display for the game, rendering all visual elements such as the paddle, ball, and bricks. The SJ2 board interfaces with the matrix using GPIO pins, which are configured to drive the rows, columns, and colors.

*GPIO Configuration:

**The matrix requires GPIO pins for address selection (A, B, C, D, E), color data (R2, G2, B2), and control signals (OE, CLK, LAT).
**The pins are switched at high frequencies to refresh the display and maintain smooth animations.
*Driving the Display:

**Row Selection: Address pins are used to select a specific row on the matrix for updating pixel data.
**Pixel Data Transfer: Color pins determine the intensity of red, green, and blue for each pixel, enabling up to 8 colors.
**Control Signals:
***OE (Output Enable): Controls when the LEDs are active.
***CLK (Clock): Synchronizes data transfer to the display.
***LAT (Latch): Locks the updated data into the matrix for display.

=== Software Design ===
The Brick Breaker game was implemented using a state machine design, which allowed for modular and organized control over the game's logic. The main function driving the game, game_state_machine__run_game(), transitions through different states based on user interactions and game events. These states, such as INIT, GAME, PAUSE, and GAME_OVER, provide a clear structure to the game flow. A state machine design was chosen for its ability to simplify complex logic by dividing it into smaller, well-defined states, making the code easier to understand and maintain. Transitions between states occur based on specific triggers, such as a button press to pause the game or the ball falling out of bounds. By using a state machine, redundant operations were minimized, particularly in the GAME state, where initialization functions were executed only once during transitions to ensure optimal performance.

The LED matrix was updated dynamically within the GAME state to display the paddle, ball, and bricks. Instead of rewriting the entire display buffer, only the portions of the matrix affected by the game elements were updated. This approach ensured smoother animations and reduced computational overhead. For instance, paddle movement involved modifying only the row where the paddle resided, while ball updates modified the ball's current and next positions. This optimization kept the gameplay visually responsive without overloading the system's resources. The main gameplay loop also called specialized functions to handle game elements like the paddle, ball, and brick states, ensuring modularity and scalability for future enhancements.

The ball movement and collision logic, handled within game_state_machine__update_ball_position, formed the core of the game’s mechanics. The ball's trajectory was calculated based on its current velocity and direction. Collisions with walls, the paddle, and bricks were detected and resolved in real time. Wall collisions caused the ball to bounce, while paddle collisions adjusted its angle of reflection based on the contact point, giving players greater control. Brick collisions were handled by checking the corresponding coordinates in the matrix buffer. If a collision occurred, the brick's state was updated, and the ball's direction was adjusted. Special cases, such as corner collisions with multiple bricks, were also addressed by updating all affected bricks and recalculating the ball’s trajectory.

To enhance gameplay, bricks were designed with varying levels of durability represented by their color. Each brick color indicated its "life," with red bricks having one life and higher durability bricks represented by colors like green, blue, and purple. When a brick was hit, its life was decremented, and the LED matrix was updated to reflect the new state. Scoring was integrated into this system, with players earning points for each hit or destroyed brick. To add a competitive aspect, a high-score table was maintained, tracking the top five scores. Although the high scores were stored in a sorted array for this implementation, future plans include saving them to the SJ2 board’s flash memory to ensure persistence across power cycles.

Player input was managed through buttons and an accelerometer, providing intuitive and responsive control. The buttons allowed precise left or right movement of the paddle, while the accelerometer offered an alternative control method, enabling the paddle to move based on the tilt of the SJ2 board. This dual-input system enhanced player engagement and added variety to the gameplay experience. Additionally, dynamic game elements, such as increasing ball speed and additional levels of difficulty, kept the game challenging as players progressed. The game state transitions were smooth and well-optimized, with the state machine ensuring clear separation of responsibilities and efficient execution of tasks.

== Testing & Technical Challenges ==
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

=== <Bug/issue name> ===
Discuss the issue and resolution.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

F24: Brick Breaker

2024-12-20T00:47:00Z

Proj user9: /* Team Members & Responsibilities */

F24: Brick Breaker

2024-12-19T23:59:26Z

Proj user9: /* Parts List & Cost */

F24: Brick Breaker

2024-12-19T23:55:19Z

Proj user9: /* Project Title */

F24: Brick Breaker

2024-12-19T23:54:38Z

Proj user9: /* Objectives & Introduction */

F24: Brick Breaker

2024-12-10T01:06:04Z

Proj user9: /* Schedule */

F24: Brick Breaker

2024-12-10T01:04:59Z

Proj user9: /* Schedule */

Realtime OS on Embedded Systems

2024-11-05T19:53:06Z

Proj user9: /* Fall 2024 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: <br/>
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

<BR/>
== Senior Design Projects ==

<BR/>
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects:<BR/>
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

<BR/>
<HR>
=== Appendix ===

=== [[Fall 2024 | Fall 2024]] ===

* [[F24: Dodge Cars]]
* [[F24: Rival Rush]]
* [[F24: Space 6]]
* [[F24: Bounce Tales]]
* [[F24: Tilt Maze]]
* [[F24: Jardinains]]
* [[F24: Survival Dodge]]
* [[F24: Brick Breaker]]
* [[F24: Space Fire]]
* [[F24: Brick Breaker]]

=== [[Fall 2022 | Fall 2022]] ===

* [[F22: DDRTOS]]
* [[F22: xGameCreate]]
* [[F22: Embedded Gamers]]
* [[F22: Bob Burgers]]
* [[F22: Space Warriors]]
* [[F22: Thunder Flash]]

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: ACE MARIO]]
* [[F21: Skeh-lleybones]]
* [[F21: Sons of Ultron]]
* [[F21: Juvenile Jumpers]]
* [[F21: Treasure Dive]]
* [[F21: FollowMe]]
* [[F21: Flame Over]]
* [[F21: Space Rage]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

<BR/>

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
<BR/>

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
<br/>
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

<br/>
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

<br/>
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

<br/>
* Senior Project: [[Project Advising: Remote Security System]]

<br/>
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

<br/>

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

F24: Brick Breaker

2024-11-04T22:59:41Z

Proj user9: Created page with "=== Grading Criteria === <font color="green"> * How well is Software & Hardware Design described? * How well can this report be used to reproduce this project? * Code Quali..."

Realtime OS on Embedded Systems

2024-11-04T22:57:19Z

Proj user9: /* Fall 2024 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: <br/>
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

<BR/>
== Senior Design Projects ==

<BR/>
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects:<BR/>
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

<BR/>
<HR>
=== Appendix ===

=== [[Fall 2024 | Fall 2024]] ===

* [[F24: Dodge Cars]]
* [[F24: Rival Rush]]
* [[F24: Space 6]]
* [[F24: Bounce Tales]]
* [[F24: Tilt Maze]]
* [[F24: Jardinains]]
* [[F24: Survival Dodge]]
* [[F24: Brick Breaker]]

=== [[Fall 2022 | Fall 2022]] ===

* [[F22: DDRTOS]]
* [[F22: xGameCreate]]
* [[F22: Embedded Gamers]]
* [[F22: Bob Burgers]]
* [[F22: Space Warriors]]
* [[F22: Thunder Flash]]

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: ACE MARIO]]
* [[F21: Skeh-lleybones]]
* [[F21: Sons of Ultron]]
* [[F21: Juvenile Jumpers]]
* [[F21: Treasure Dive]]
* [[F21: FollowMe]]
* [[F21: Flame Over]]
* [[F21: Space Rage]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

<BR/>

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
<BR/>

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
<br/>
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

<br/>
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

<br/>
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

<br/>
* Senior Project: [[Project Advising: Remote Security System]]

<br/>
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

<br/>

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

S22: Firebolt

2022-05-28T07:45:30Z

Proj user9: /* Project Source Code */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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.
[[File:Checkpoint.jpg]]

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|center|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:40:21Z

Proj user9: /* Software Design */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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.
[[File:Checkpoint.jpg]]

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|center|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

File:Checkpoint.jpg

2022-05-28T07:38:17Z

Proj user9:

S22: Firebolt

2022-05-28T07:37:56Z

Proj user9: /* Checkpoints */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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.
[[File:Checkpoint.jpg]]

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:37:22Z

Proj user9: /* Checkpoints */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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.
[[File:Example.jpg]]

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:32:19Z

Proj user9: /* Checkpoints */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:30:42Z

Proj user9: /* Checkpoints */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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 as shown in the image below. These waypoints form a grid of points (all black and orange dots). 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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:29:59Z

Proj user9: /* Checkpoints */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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 car the source and destination are not on straight lines. 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 as shown in the image below. These waypoints form a grid of points (all black and orange dots). 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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:21:39Z

Proj user9: /* Advise for Future Students */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T07:09:11Z

Proj user9: /* Conclusion */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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

=== 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.

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:55:21Z

Proj user9: /* Introduction */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
The controllers for the project are divided in 5 parts. Each controller has different tasks and communicate with each other over CAN bus.
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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.

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:52:35Z

Proj user9: /* Conclusion */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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.

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:52:10Z

Proj user9: /* Conclusion */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== 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:
*1. 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.
*2. 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.
*3. 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.
*4. 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.

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:24:27Z

Proj user9: /* References */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

Motor ECU
* None used

Geographical ECU
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:23:30Z

Proj user9: /* References */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
<Br>
<Br>
====Bridge Sensor ECU====
*[https://www.mpja.com/download/hc-sr04_ultrasonic_module_user_guidejohn.pdf HCSR-04]

====Motor ECU====
* None used

====Geographical ECU====
*[https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ Bearing Formula]
*[https://www.igismap.com/haversine-formula-calculate-geographic-distance-earth/ Haversine Formula]
*https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
*[https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf Compass Heading Tilt Compensated]

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

S22: Firebolt

2022-05-28T06:20:24Z

Proj user9: /* References */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
<Br>
https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.pdf
<Br>

S22: Firebolt

2022-05-28T06:19:04Z

Proj user9: /* Acknowledgement */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== 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
<Br>

S22: Firebolt

2022-05-28T06:15:23Z

Proj user9: /* Project Video */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

https://youtu.be/lGZTV-ZGHd8

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T06:14:10Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T06:13:48Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* ''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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T06:13:23Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* '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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T06:12:25Z

Proj user9: /* GPS */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T06:12:00Z

Proj user9: /* GPS */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== Periodic Callbacks ===

The period_callbacks__initialize() function calls the following functions:
<pre>
can__bus_initializer(can1);
lcd__init();
head_tail_lights_init();
debug_led_init();
</pre>

The period_callbacks__1Hz() function calls the following function:
<pre>
can_bus_handler_tx_debug_messsages(can1);
static uint8_t count = 0;
if (count == 0) {
lcd__communication_init();
}
count = 1;
print_info_on_lcd();
</pre>

The period_callbacks__10Hz() function calls the following functions:
<pre>
can_bus_handler__process_all_received_messages(can1);
can_bus_handler__manage_mia();
can_bus_handler_tx_messages(can1);
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
<li>The Designer page</li>
<li>The Blocks page</li>

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:51:25Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:50:20Z

Proj user9: /* Hardware Design */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* Adafruit GPS
** Problem: The data from the GPS was being refreshed every second which was causing issues for the RC car. It was swerving too much because of the stale data.
*** 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 by 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.
* Best suggestion would be to 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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:50:01Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|300px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>
* Adafruit GPS
** Problem: The data from the GPS was being refreshed every second which was causing issues for the RC car. It was swerving too much because of the stale data.
*** 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 by 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.
* Best suggestion would be to 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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:32:16Z

Proj user9: /* Technical Challenges */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|300px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
*The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

*For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>

== 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.
* Best suggestion would be to 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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:31:22Z

Proj user9: /* Hardware Design */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|400px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|300px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>

== 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.
* Best suggestion would be to 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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>

S22: Firebolt

2022-05-28T04:30:55Z

Proj user9: /* Hardware Design */

[[File:First_Image.JPG|500px|thumb|right| The RC Car]]

== Abstract ==
Firebolt is battery powered autonomous RC car. The car uses four microcontrollers for communication between the nodes- driver node, motor node, bridge & sensor node, and geological node over the CAN bus. It is interfaced to the mobile application which sends GPS coordinates for the destination location to the driver node and reaches the destination by avoiding any obstacles that comes in the path. For obstacle detection and avoidance it uses Ultrasonic Sensor and makes the decision of steering and maintaining speed after performing calculations based on the bridge and sensor node's data.

== Objectives & Introduction ==
=== Objectives ===
The objective of this project is to get hands on experience of application of embedded systems in autonomous vehicles, have understanding of CAN bus communication, CAN database files, TDD and other related tools such as PCAN dongle and Busmaster.

====Software side ====
* The car communicates with an Android application
* Receive coordinates from gps to drive itself to the destination while avoiding obstacles
* Display useful information on the LCD
* Take care of elevation and make correct speed decisions
* DBC file for all the nodes

====Hardware side ====
* Design PCB for four controllers and other necessary components
* Choose good options for mounting the ultrasonic sensors on the car
* Make a good GUI Android application for interfacing with the microcontroller

<div><ul>
<li style="display: inline-block;">[[File:High_Level_Implementation2.png|600px|thumb|Center|High Level Hardware]] </li>
</ul></div>

==== Introduction ====
Four Nodes of the RC Car are:
# Driver Node
# GEO Node
# Sensors and Bridge Node
# Motor Node
# Mobile Application

=== Team Members & Responsibilities ===
<div><ul>
<li style="display: inline-block;">[[File:Team_Photo_2.jpg|600px|thumb|Right|Team FireBolt]] </li>
<li style="display: inline-block;">[[File:Team_Photo_Final.jpeg|500px|thumb|Left|Team FireBolt]]</li>
</ul></div>
<font color="black"> '''Priyanka Rai [https://www.linkedin.com/in/priyanka-rai-009ba975/ LinkedIn]''''''
* Geo Controller
* GPS and Compass Interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritu Patil [https://www.linkedin.com/in/ritu-patil/ LinkedIn]''''''
* Motor Controller
* RPM Sensor
* Integration Testing
* Wiki Page Update

<font color="black"> '''Ritika Beniwal [https://www.linkedin.com/in/ritikabeniwal03/ LinkedIn]''''''
* Driver Node
* LCD interfacing
* Motor Controller
* Integration Testing
* Wiki Page Update

<font color="black"> '''Utsav Savaliya [https://www.linkedin.com/in/utsav-savaliya-7383ab15b/ LinkedIn]''''''
* Sensor Controller
* Integration Testing
* Wiki Page Update
* Bluetooth integration with Sensor

<font color="black"> '''Dhanush Babu [https://www.linkedin.com/in/dhanushsbabu/ LinkedIn]''''''
* Bluetooth module interfacing
* Motor Controller
* Android App
* Integration Testing

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| Target Date
! scope="col"| Task
! scope=:col"| Completion Date
! scope="col"| Status
|-
! scope="row"| Week 1
|
* 03/06
* 03/08
* 03/12
|
* 03/10
* 03/10
* 03/12
|
* Study and discuss previous project reports
* Brainstorm on the requirements for the project
* Identify and order/purchase the required components
|
* 03/10
* 03/10
* 03/12
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 2
|
* 03/13
* 03/13
* 03/14
|
* 03/14
* 03/18
* 03/18
|
* Distribute initial roles among the team members
* Study the datasheets and manual of acquired components
* Create and setup Gitlab Repository
|
* 03/14
* 03/18
* 03/18
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 3
|
* 03/20
* 03/22
* 03/20
|
* 03/25
* 03/26
* 03/24
|
* Write basic driver for ultrasonic sensor
* Analyze and decide the hardware placement of the RC Car
* Create SENSOR and DRIVER nodes to transmit and receive data
|
* 03/26
* 03/23
* 03/25
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 4
|
* 03/27
* 03/27
* 03/27
|
* 04/04
* 04/01
* 03/28
|
* Create the GEO node to get coordinates and cardinal directions from GPS and Compass
* Create the MOTOR node to drive the RC Car
* Design DBC file and create CAN signals for every node
|
* 04/02
* 04/04
* 04/01
|
*<font color = "Green"> Completed
*<font color = "Green"> Completed
*<font color = "Green"> Completed
|-
! scope="row"| Week 5
|
* 04/02
* 04/02
* 04/02
* 04/02
|
* 04/08
* 04/08
* 04/08
* 04/08
|
* Finalize the DBC file
* Design obstacle avoidance and steering logic on the DRIVER node
* Design motor driving logic on the MOTOR node with the encoder
* Start and design the Bluetooth app xml for destination.

|
* 04/09
* 04/09
* 04/09
* 04/09
|
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
*<font color = "green"> Completed
|-
! scope="row"| Week 6
|
* 04/09
* 04/09
* 04/09
* 04/09
* 04/09
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
* Integrate GPS module with compass to get the current location.
* Write UART interface for Bluetooth integration on sensor node.
* Get raw sensor data from the ultrasonic sensor.
* Integrate GEO node to DRIVER node for navigation. Check whether the DRIVER node is receiving the coordinates.
* Backend development for android app. Should be able to scan BT devices and connect.
|
* 04/15
* 04/15
* 04/15
* 04/15
* 04/15
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 7
|
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
* 04/16
|
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
* 04/23
|
* Communicate to the GEO node over Bluetooth via Android app
* Complete Driver obstacle logic
* Design driving decision logic based on the navigation data
* Lay out basic PCB Board design for mounting the ECUs
* Filtering ultrasonic sensor data and sending processed data to Driver
* RPM Sensor logic and testing.
|
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
* 04/26
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 8
|
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
* 04/25
|
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
* 04/30
|
* Design a dashboard on the LCD to display the values
* Driver logic for sensor data and geo data on busmaster.
* Add functionality for pinning location on maps and extracting latitude and longitude
* Improve obstacle avoidance logic
* Break and ramp logic for the motor.
* '''Collective Test 1''':<font color = "DarkGreen">''' Drive the car to a hardcoded GPS destination'''</font color>
|
* 04/29
* 04/27
* 04/30
* 04/30
* 04/30
* 05/06
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 9
|
* 05/01
* 05/01
* 05/01
* 05/01
* 05/01
|
* 05/07
* 05/07
* 05/07
* 05/07
* 05/07
|
* Design individual architecture diagrams and algorithms for documentation
* Make any necessary improvements based on previous test results
* Complete the final version of the Android app
* Get the PCB printed
* '''Collective Test 2''':<font color = "DarkGreen">''' Test the car driving with navigation data from the Android app'''</font color>

|
* 05/10
* 05/07
* 05/01
* 05/07
* 05/11
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "Green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 10
|
* 05/09
* 05/09
* 05/09
* 05/09
|
* 05/14
* 05/14
* 05/14
* 05/14
|
* Replace the circuits with their corresponding PCBs and assemble
* Complete the RC Car structure and assembly with the 3D printed parts - Prototype 1
* Refactor the code modules with necessary improvements
* '''Collective Test 3:'''<font color = "DarkGreen">''' Test car on various terrains and slopes'''</font color>
|
* 05/20
* 05/20
* 05/20
* 05/20
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 11
|
* 05/16
* 05/16
* 05/16
* 05/16
|
* 05/21
* 05/21
* 05/21
* 05/21
|
* Revise and improve the wiki report to cover all the aspects of design and implementation
* Fix all the errors and make improvements
* Final testing of all the modules and car
* '''Collective Test 4:'''<font color = "DarkGreen">''' Have the final version of the project tested with all the functionalities'''</font color>
|
* 05/22
* 05/22
* 05/22
* 05/22
|
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
*<font color = "green">Completed
|-
! scope="row"| Week 12
|
* 05/25
* 05/25
|
* 05/27
* 05/27
|
* Demo
* Final Wiki Page Update with addition of all the problems faced during the development
|
* 05/25
* 05/26
|
*<font color = "green"> Completed
*<font color = "green"> Completed
|}

<HR>
<BR/>

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Price($)
|-
! scope="row"| 1
| RC Car
| Traxxas [https://www.amazon.com/gp/product/B07DFXN118/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1]
| 1
|280
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Comimark [https://www.amazon.com/Comimark-Transceiver-TJA1050-Controller-Schnittstelle/dp/B07W4VZ2F2/ref=sr_1_4?crid=L6PXVWD9BFTN&dchild=1&keywords=can+transceiver&qid=1621786818&sprefix=can+trans%2Caps%2C566&sr=8-4]
| 5
| 8.99
|-
! scope="row"| 3
| Ultrasonic Sensors
| Max Botix[https://www.amazon.com/gp/product/B07Q588SBP/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1]
| 4
| 24.95
|-
! scope="row"| 4
| GPS Breakout Board
| Adafruit[https://www.adafruit.com/product/746]
| 1
| 29.95
|-
! scope="row"| 5
| GPS Antenna
| Adafruit[https://www.adafruit.com/product/960]
| 1
| 19.95
|-
! scope="row"| 6
| RPSMA female to mhf4
| Superbat[https://www.amazon.com/dp/B08N6C7XGD/ref=cm_sw_r_cp_api_i_THK732JGSBBCCZFEPF58?_encoding=UTF8&psc=1]
| 1
| 7.99
|-
! scope="row"| 7
| HC05 bluetooth RF Transceiver
| HiLetgo[https://www.amazon.com/HiLetgo-Bluetooth-Transceiver-Integrated-Communication/dp/B07VL725T8/]
| 1
| 15.99
|-
! scope="row"| 8
| Triple-axis Accelerometer
| Adafruit[https://www.adafruit.com/product/1120]
| 1
| 14.95
|-
! scope="row"| 9
| Traxxas RPM Sensor
| Traxxas[https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM]
| 1
| 13.76
|-
! scope="row"| 10
| Traxxas Battery and Charger
|Traxxas[https://www.amazon.com/Traxxas-Battery-Charger-Completer-2-amp/dp/B074FXXP5J/ref=asc_df_B074FXXP5J/?tag=hyprod-20&linkCode=df0&hvadid=312136795426&hvpos=&hvnetw=g&hvrand=9135382788468531733&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9032144&hvtargid=pla-493010666784&psc=1]
|1
|62.95
|-
! scope="row"| 11
| Voltage Regulator
|Valefod[https://www.amazon.com/dp/B076H3XHXP?ref_=cm_sw_r_cp_ud_dp_5HTAVWPZJ2QS6AMXTM93]
|6
|10.99
|-
! scope="row"| 12
| Headlights
|Hobbypark[https://www.amazon.com/dp/B01GY8VFIM?ref_=cm_sw_r_cp_ud_dp_PK32ZA2HM4DRWMGV55YC]
|1
|7.96
|-
|}

<HR>
<BR/>

== Printed Circuit Board ==

Initially we started our testing with mounting all our hardware on the breadboard (yes, it was messy and unstable!).
<div><ul>
<li style="display: inline-block;">[[File:Initial_Car.jpeg|400px|thumb|Centre|Initial_Hardware]] </li>
</ul></div>

<h4>PCB Schematic</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Sch.png|500px|thumb|Left|Schematic]] </li>
<li style="display: inline-block;">[[File:Final_PCB.png|500px|thumb|Right|Final_Board]] </li>
</ul></div>

<h4>PCB Board</h4>

<div><ul>
<li style="display: inline-block;">[[File:Final_Top_Side.png|500px|thumb|Left|Top_Side]]</li>
<li style="display: inline-block;">[[File:Final_Bottom_Side.png|500px|thumb|Right|Bottom_Side]] </li>
</ul></div>

<h4>Challenges </h4>
* Since there are four controllers and a significant number of components (gps, sensors, can transceivers, volt regulator etc.) it was difficult for us to keep our hardware stable because every time we go for field testing some will get disconnected and we were kind of stuck up in the hardware setup.
* We decided to get the PCB printed but there were some issues and resolving them and getting a new PCB would take time.

<h4>Solution </h4>
* Finally we decided to use the prototype board for mounting all the components and stabilizing our hardware.
<div><ul>
<li style="display: inline-block;">[[File:Final_Hardware_Physical.jpeg|500px|thumb|Left|Protoype_Board]]</li>
</ul></div>

== CAN Communication ==
We used controller area network to communicate data between four nodes. All nodes are connected to each other through a physically conventional two wire bus CANH and CANL. The wires are a twisted pair with 120 Ω termination resistors at each end of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference).
A CAN frame has the following contents:
* Data Length Code (4bits)
* Remote Transmission Request.
* ID extend bit.
* Message ID (11 bit or 29 bit)
* Data bytes( depends on DLC)
* CRC

'''Arbitration''': No two nodes will transmit at the same time because of arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

'''Bit Stuffing''': CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
[[File:High level diagram.png|thumb|600px|middle|center|Project Can Bus Diagram]]

=== DBC File ===
The DBC file is a simple text file that consists of information for decoding raw CAN bus data to physical values or in human readable form.

{| class="wikitable"
|-
! scope="col"| Sr. No
! scope="col"| Message ID
! scope="col"| Message function
! scope="col"| Receivers
|-
|-
|-
|-
! colspan="4"| Driver Heartbeat
|-
|-
|1
|100
|Driver Heartbeat
|Motor, Sensor, Geo
|-
! colspan="4"| Start Stop signal from Android app to Driver
|-
|-
|1
|101
|Bridge Sensor
|Driver
|-
! colspan="4"| Ultrasonic sensors data transmit
|-
|-
|2
|101
|Sensor sonars from front, back, left ,right sensor
|Driver
|-
! colspan="4"| Destination Location
|-
|-
|4
|250
|Bridge Sensor
|Geo
|-
|-
! colspan="4"| Driver to Motor Command
|-
|-
|5
|300
|Speed and steering direction for the motor
|Motor
|-
|-
! colspan="4"| Geo Controller
|-
|-
|6
|400
|Bearing, Heading and Distance
|Driver
|-
|-
! colspan="4"| Motor Controller
|-
|-
|7
|600
|Motor speed
|Driver
|-
|-
! colspan="4"| Debug messages
|-
|-
|8
|700
|Driver Debug
|BRIDGE_SENSOR,MOTOR,GEO
|-
|-
|9
|750
|Geo Debug
|BRIDGE_SENSOR,MOTOR,DRIVER
|-
|-
|}

<pre>
VERSION ""
NS_ :
BA_
BA_DEF_
BA_DEF_DEF_
BA_DEF_DEF_REL_
BA_DEF_REL_
BA_DEF_SGTYPE_
BA_REL_
BA_SGTYPE_
BO_TX_BU_
BU_BO_REL_
BU_EV_REL_
BU_SG_REL_
CAT_
CAT_DEF_
CM_
ENVVAR_DATA_
EV_DATA_
FILTER
NS_DESC_
SGTYPE_
SGTYPE_VAL_
SG_MUL_VAL_
SIGTYPE_VALTYPE_
SIG_GROUP_
SIG_TYPE_REF_
SIG_VALTYPE_
VAL_
VAL_TABLE_
BS_:

BU_: DRIVER MOTOR BRIDGE_SENSOR GEO DEBUG

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" BRIDGE_SENSOR,MOTOR,GEO

BO_ 101 DRIVE_STATUS: 1 BRIDGE_SENSOR
SG_ DRIVE_START_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_SONARS: 5 BRIDGE_SENSOR
SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 250 DESTINATION_LOCATION: 8 BRIDGE_SENSOR
SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" GEO
SG_ DEST_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" GEO

BO_ 300 DRIVER_TO_MOTOR: 2 DRIVER
SG_ DRIVER_TO_MOTOR_speed : 0|8@1+ (0.1,-10) [-10|10] "kmph" MOTOR, BRIDGE_SENSOR
SG_ DRIVER_TO_MOTOR_direction : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR, BRIDGE_SENSOR

BO_ 400 GEO_CONTROLLER_COMPASS: 8 GEO
SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER, BRIDGE_SENSOR
SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE_SENSOR
SG_ DISTANCE_TO_DESTINATION: 24|32@1+ (0.01,0) [0|359.9] "meters" DRIVER,BRIDGE_SENSOR

BO_ 600 MOTOR_SPEED: 2 MOTOR
SG_ MOTOR_SPEED_info : 0|8@1+ (0.1,-10) [-10|10] "kmph" DRIVER, BRIDGE_SENSOR

BO_ 700 DRIVER_DEBUG: 2 DEBUG
SG_ car_driving_status: 0|8@1+ (1,0) [0|0] "" DEBUG
SG_ car_steering_status: 8|8@1+ (1,0) [0|0] "" DEBUG

BO_ 750 GEO_CONTROLLER_DEBUG_MESG: 10 DEBUG
SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "degrees" DEBUG
SG_ CURR_LONGITUDE : 28|28@1+ (0.000001,-180.000000) [-180|180] "degrees" DEBUG
SG_ RAW_HEADING : 56|12@1+ (0.1,0) [0|359.9] "degrees" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BU_ GEO "To provide raw GPS and compass heading";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

VAL_ 700 car_steering_status 2 "RIGHT" 1 "LEFT" 0 "STRAIGHT";
VAL_ 700 car_driving_status 2 "BACKWARD" 1 "FORWARD" 0 "STOPPED";
</pre>

=== Technical Challenges ===
* The CAN transceivers that we bought had inbuilt 120 ohm resistor each, which we didn't notice. And every time we interfaced all the four nodes the data won't show up in the busmaster software. We found this very late and until then we thought it's hardware/dbc file issue and wasted potential amount of time in debugging.So we de-soldered those termination resistors and we were able to see our data smoothly on busmaster.
* As an advice, make sure at the end of all four nodes after adding termination resistors of 120 ohm on both sides, the resultant resistance is 60 ohms. Only then all four nodes can communicate over CAN bus.

== Sensor and Bluetooth ECU ==
=== Hardware Design ===

The obstacle detection sensors used here are Ultrasonic sensors. The HRLV-MaxSonar-EZ1 sensors from MaxBotix are used here. In these sensors there is membrane which needs to be triggered in order to generate and send ultrasonic waves every few seconds. When ultrasonic waves collide and come back and strikes with this membrane a pulse is generated which is used for sensing.

[[File:Sensor_Node.png|left|600px|thumb|Sensor Controller Diagram]]

[[File:Ultrasonic99.png|center|400px|thumb|Sensor Pins]]

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Pin connections between board and sensor:
|-
! scope="col"| Sl No.
! scope="col"| SJ2 board Pin No.
! scope="col"| Ultrasonic sensor Pin No.
! scope="col"| Function
|-
! scope="row"| 1.
| ADC Pin 1.30
| AN(Front left sensor)
| Input to ADC channel 4
|-
! scope="row"| 2.
| ADC Pin 1.31
| AN(Front right sensor)
| Input to ADC channel 5
|-
! scope="row"| 3.
| ADC Pin 1.26
| AN(Front sensor)
| Input to ADC channel 3
|-
! scope="row"| 4.
| ADC Pin 1.25
| AN(Rear sensor)
| Input to ADC channel 3
|-
! scope="row"| 5.
| GPIO Pin 0.6
| Rx(Front left sensor)
| Triggering pulse for left sensor
|-
! scope="row"| 6.
| GPIO Pin 0.8
| Rx(Front right sensor)
| Triggering pulse for right sensor
|-
! scope="row"| 7.
| GPIO Pin 0.9
| Rx(Front sensor)
| Triggering pulse for front sensor
|-
! scope="row"| 8.
| GPIO Pin 0.7
| Rx(Rear sensor)
| Triggering pulse for rear sensor
|-
|}

Apart from the pin connections for the Sensor node the important thing is to mount the sensors at particular angles. The angle placement is critical for left and right sensor as we faced lot of problems while detecting the walls. We chose the angle by error and trial method by simply placing the sensors at different angles. We tried keeping the angle above the 45 degrees so that to provide wider angle for the obstacles to detect.

=== Software Design ===

The sensor node has to receive values from all the sensors and send the distance values on the CAN bus for the driver to run the obstacle avoidance logic.

====== Receive sensor values ======

Four sensors are used here. Three in the front and one at the rear side. We need four ADC channels to address the receiving from all sensors. In order to use four pins on the SJ2 board we need to set the pins to analog mode. In the adc.h file and adc.c file there are only three channels initialized, so one needs to add ADC channel 3 in these files. On how to use these sensors, the datasheet of helped a lot. It addresses every aspect of how to use this particular sensor and the solution to most of the problem that can arise. All the sensor raw values are digitally converted in the range of 0 to 1024( 10 bit ADC). These value is in inches as mentioned in the datasheet. So, one needs to convert it into centimeter by applying some formula. The formula can be different based on the configuration used to setup the ADC channel even if same sensor is used.

====== Sending sensor values in terms of distance to CAN ======

The raw values coming from the sensor needs to be filtered before sending on the CAN bus. The more information about filtering is mentioned in the techical challenges section. The below diagram shows the detailed flowchart of software design implemented for the sensor node.

[[File:f8.png|center|6600px|thumb|Sensor Controller Diagram]]

=== Technical Challenges ===
The main challenge while using ultrasonic sensor with this particular project is of crosstalk. While detecting objects in the front all the front sensors waves are interfering with each other giving false values in the left or right sensor while the object is in the front only. The datasheet addresses this issues and what to do when multiple sensors are used in a system. It says that trigger each sensor are different time period in order to avoid crosstalk. So we triggered the front and rear at one particular time and left and right at one particular time. One sequence is triggered at particular 10Hz and other sequence is triggered at another 10Hz. There is a division of callbacks counts in 100Hz and a lock mechanism is used in order to used different 20Hz period out of 100Hz.

For frequency noise measurements like when the values suddenly change or vary between certain range sometimes, a filter is implemented. The most common filter for this type of use is median filter where a series of values are stored in a array and median is taken of all the values stored in that array.

<HR>
<BR/>

== Motor ECU ==
The Motor ECU acts as an encoder for the DC motor (used for propulsion) and Servo motor (used for turning the axle and changing direction of the car). The car is a two wheel drive with DC motor connected to the rear wheels and the servo motor is connected to the front wheels. The DC motor is controlled by Electronic Speed Control. The ECU supplies PWM signal to the ESC and the ESC powers the DC motor. The Servo motor is powered by the car battery as well and gets its PWM signal from the ECU.
The RPM sensor sends its output to motor ECU by which the actual speed of the wheels is calculated.
=== Hardware Design ===
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File: Motor_HW_design.jpg|center|600px|thumb|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:'''
<br/>
Sport mode(100% Forward, 100% Brakes, 100% Reverse)
<br/>
Racing mode(100% Forward, 100% Brakes, No Reverse)
<br/>
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.
<br/>
PWM 10 to 14.9 for reverse.
<br/>
PWM 15 for neutral.
<br/>
PWM 15.1 to 20 for the forward.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ESC Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.1)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Output
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:ESC.jpg|center|300px|thumb|Traxxas ESC]]
|
|[[File:DCMotor.jpg|center|300px|thumb|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.
<br/>
PWM 15 for straight.
<br/>
PWM 15.1 to 20 for turning right.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Servo Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| PWM(P2.0)
| Takes PWM input from SJ2-Board
| WHITE
|-
! scope="row"| VDD(6V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

{| style="margin-left: auto; margin-right: auto; border: none;"
[[File:Servotrx.jpg|300px|centre|thumb|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.
<br/>
'''Mounting the sensor:'''
<br/>
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.
<br/>
'''How the sensor works:'''
<br/>
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.

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+RPM Pinout
|-
! scope="col"| Wires on ESC
! scope="col"| Description
! scope="col"| Wire Color
|-
! scope="row"| GPIO(P0.6)
| Provides pulses to Motor SJ2-Board
| WHITE
|-
! scope="row"| VDD(3.3V)
| Power Input
| RED
|-
! scope="row"| GND
| Ground
| BLACK
|-
|}

<br/>
{| style="margin-left: auto; margin-right: auto; border: none;"
|[[File:Rpm_sensor.jpg|center|300px|thumb|Traxxas RPM Sensor]]
|
|[[File:Trigger_magnet.jpg|center|300px|thumb|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.

<br/>
[[File: Motor_SW_design.jpg|center|700px|thumb|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.
<br/>
<HR>
<BR/>

== 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.

<li style="display: inline-block;"> [[File:Geo_Node_Schematic.jpg|500px|thumb|centre|]] </li>
<li style="display: inline-block;">[[File:compass_Firebolt.jpg|300px|thumb|center|3 Axis Magnetometer (eCompass)]] </li>

<li style="display: inline-block;"> [[File:GPS_Firebolt.jpg|300px|thumb|centre|GPS Module]] </li>

{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Geographical Node Pinout
|-
! scope="col"| SJTwo Board
! scope="col"| GPS/Compass Module
! scope="col"| Description
|-
| P0.15 (TX3)
| RX
| Adafruit GPS Breakout
|-
| P0.16 (RX3)
| TX
| Adafruit GPS Breakout
|-
| P0.10 (SDA)
| SDA
| Adafruit Magnetometer
|-
| P0.11 (SCL)
| SCL
| Adafruit Magnetometer
|-
| P0.1
| CAN transceiver (Tx)
| CAN transmit
|-
| P0.0
| CAN transceiver (Rx)
| CAN receive
|-
| Vcc 3.3V
| Vcc
| Vcc
|-
| GND
| GND
| Ground
|-
|}

<BR/>

=== 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
[[File:FlowChart_Geo_Logic.jpg|center|700px|thumb|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 GNGGA which is message chosen to parse the coordinates and GPS lock.

*Parsing NMEA GNGGA messages
The GPS module constantly transmits NMEA GNGGA 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:<br/>

pitch = asin(-acc_x / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) <br/>
roll = asin((acc_y / sqrt(acc_y * acc_y + acc_z * acc_z + acc_x * acc_x)) / cos(pitch))

*Tilt compensated magnetic sensor values:<br/>

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====

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 [https://www.igismap.com/formula-to-find-bearing-or-heading-angle-between-two-points-latitude-longitude/ 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 ===

<HR>

== 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.

<li style="display: inline-block;">[[File:SJTWO.jpg|400px|thumb|Left|Sjtwo-board]] </li>
<li style="display: inline-block;">[[File:LCD_DIS.jpg|400px|thumb|Right|LCD Display]] </li>
<li style="display: inline-block;">[[File:Final_Sch2.png|400px|thumb|Right|Pinouts]] </li>

=== Software Architecture Driver Logic===

<div><ul>
<li style="display: inline-block;">[[File:Driver_logic.png|600px|thumb|Left|Basic_Logic]] </li>
<li style="display: inline-block;">[[File:OAL.png|600px|thumb|Center|Obstacle Avoidance Logic]] </li>
<li style="display: inline-block;">[[File:Reverse_func.png|600px|thumb|Right|Reverse Functionality]] </li>
</ul></div>

=== Obstacle Avoidance Logic ===

<pre>
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;
}
</pre>

'''''Steer Left and Right'''''
<pre>
if (obstactle_on_right == true) {
//steer left
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction <= 40)
? motor_signal.DRIVER_TO_MOTOR_direction + offset_to_angle
: max_angle_threshold;
motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_left);

} else {
//steer right
motor_signal.DRIVER_TO_MOTOR_direction = (motor_signal.DRIVER_TO_MOTOR_direction >= -40)
? motor_signal.DRIVER_TO_MOTOR_direction - offset_to_angle
: -max_angle_threshold;

motor_signal.DRIVER_TO_MOTOR_speed = slow_speed;
update_lights(10, headlight_right);
}
</pre>

'''''Reverse and Steer'''''
<pre>
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();
}
</pre>

=== 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.

<pre>
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;
}
</pre>

=== 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.
<HR>
<BR/>

== Mobile Application ==
Through the app we first scan for available devices and connect to the Bluetooth present on the RC car. After the connection is successful the destination is pinned on the map and by clicking on the "Send Destination to Car" button and the car is notified of the destination. After this we can control the start and stop of the car with the two buttons present on the application.

===User Interface===
<br/>
<li style="display: inline-block;"> [[File: App UI.jpeg|center|300px|thumb|App User Interface]]</li>
<br/>

=== Software Design ===
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.”

The Web app provides two important sections for mobile app development:
The Designer page
The Blocks page

<br/>
<li style="display: inline-block;">[[File: MIT_app_inventor.jpeg|left|600px|thumb|MIT App Inventor]] </li>

<li style="display: inline-block;">[[File: MIT_app_inventor_backend.jpeg|right|600px|thumb|Backend development]] </li>
<br/>

<li style="display: inline-block;">[[File: App_flowchart.jpeg|right|300px|thumb|Flow of the App]] </li>
<br/>

===Bluetooth===

We have used the HC05 bluetooth module for this project. This is interfaced using UART on the sensor node. It uses TX pin to transmit the messages received from mobile application. It provides approximately 5 meters range and is transmitting values at proper intervals without any disconnection.

=== 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.
<BR/>
<HR>
<HR>
<BR/>

== Conclusion ==

=== Project Video ===

=== Project Source Code ===
https://gitlab.com/ritupatil1/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.
* Best suggestion would be to 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.

=== Acknowledgement ===

=== References ===
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
<Br>