F16: Spartan and Furious

From Embedded Systems Learning Academy
Revision as of 06:27, 13 December 2016 by Proj user10 (talk | contribs) (CAN Communication Table)

Jump to: navigation, search

Contents

Project Title

Android Application controlled Self-Driving Car using CAN bus.

Abstract

Embedded systems are unique, they tend to take real world inputs, such as light, and make meaningful applications of this data. A self driving car is the epitome of an embedded system, they take all kinds of information through various sensors and try to give results in the form of travelling from point A to point B. In this project, we attempt to create a self driving car with the aim of putting into practice the knowledge gained through the CMPE 243 course.

Objectives & Introduction

In this project, we aim to use the CAN bus to create a self-driving car that can travel between two pre-determined points. The path for the car is given through a mobile application based on the android operating system. The car then navigates between these points by taking location feedback through a GPS system and using ultrasonic sensors embedded on the car to avoid obstacles in the path of the car. IO systems present on the car give us pertinent information about the status of the car and the onboard processing.

The Objectives for this project are:
• The car must be able to interact with a Bluetooth enable mobile application and provide a path that the car must follow.
• Given the path to follow, the car must use a GPS module to gather location feedback and route the car toward its destination.
• The car must be able to determine obstacles in its path using ultrasonic sensors and avoid.
• The car must be able to control its speed in various terrain using a speed feedback mechanism.
• Provide meaningful information about the car’s present status using IO modules such as LEDs and LCD.
• A master board must be able to determine the correct action required for the data gathered through sensors and GPS feedback.
• All the modules must communicate with each other over the CAN bus.
• Document the findings in this report for future classes to reference so that they may improve this design.

Team Members & Responsibilities

Schedule

Legend:

Motor Controller , Master Controller , Android Controller, Geo Controller, Sensor and I/O Controller , Team Goal

Week# Date Task Actual Status
1 9/17/2016
  • Purchasing RC car.
  • Purchased RC car.
Complete.
2 9/24/2016
  • Individual module distribution.
  • Project report setup.
  • Git setup.
  • Order components for individual modules.
  • Members identified for modules.
  • Wikipage project report template and Git were setup.
  • Ordered GPS module and CAN transceivers.
Complete
3 10/01/2016
  • Define scope of each module.
  • Determine Git flow.
  • Follow up on component procurement.
  • Determining and analyzing the duty cycle for servomotor and DC motor of the car.
  • Implement basic CAN communication CAN between two SJ-One Boards.
  • Initial flow of each module defined.
  • Identified the branches and decided on merge process.
  • Ordered additional ultrasonic sensors and LCD.
  • Tested the car servo and DC motor using Digital Oscilloscope.
  • Observed and noted the duty cycle wave forms .
  • Successfully tested CAN communication between two SJ-One boards.
Complete
4 10/08/2016
  • Create branches in Git
  • Follow up on component procurement
  • Basic testing of Servo and DC motor.
  • Testing speed of car with variable PWM.
  • Research on the CAN bus, tasks and scheduling.
  • Decision regarding flow of the master controller.
  • Download software for LCD
  • Created Master branch on Git
  • All ordered parts received by 10/07.
  • Implemented test code to interface SJOne board with a servo motor to control the direction and verified the same on the car.
  • Speed testing in progress.
  • Learnt about the working of CAN bus and decided on flow for the master controller.
  • Installed 4D System Workshop4 IDE (for LCD).
Complete
5 10/15/2016
  • Developing drivers for both motors.
  • Android app prototype.
  • Parse GPS data and format the data to be transmitted.
  • Decision making regarding various messages to be sent on CAN bus.
  • Design basic sensor algorithm for range finding.
  • Algorithm developed for both the motors.
  • Basic App Screen layout designed.
  • GPS latitude & longitude coordinates extracted from NMEA format.
  • Identified various messages for different nodes.
  • Designed basic algorithm for range finding.
Complete
6 10/22/2016
  • Define CAN signals for each module.
  • Testing the car with developed drivers.
  • Interface Bluetooth module with SJ-One board.
  • Implement source code and fetch Magnetometer reading.
  • Design of CAN bus hardware.
  • Test basic working for IR.
  • CAN signals along with their priorities identified (DBC file format generated).
  • Testing for developed motor drivers in progress.
  • Testing of Bluetooth interface in progress.
  • Implemented the Magnetometer source code, Testing in progress.
  • Tested for hardware integrity.
  • Developed algorithm for obstacle detection.
Complete.
7 10/29/2016
  • Fine tuning motor control code.
  • Transmitting and receiving messages between Android App and SJ-One board.
  • Test the extracted GPS data for consistency and check the update rate.
  • Basic interfacing of master controller with motor module.
  • Integrate IR sensor for gauging speed.
  • Testing in Progress for the motor control code.
  • Successfully established communication interface between app and SJ-one board
  • Latitude and Longitude parsed data tested, observed few NMEA strings with wrong checksum values.
  • Testing in Progress of the interface over CAN bus.
  • Developed algorithm for obstacle detection.
  • Speed sensing was delegated to motor team as suggested by Preet.
Complete.
8 11/05/2016
  • Integration of modules for first demo.
Integration and Testing completed for the first demo. Complete.
9 11/12/2016
  • Design of Feedback Control mechanism for car.
  • Initial algorithm development of GPS module for heading calculation.
  • Integration of master module with bluetooth module .
  • Develop LCD code for displaying all sensor information and car vitals.
  • Decide upon additional I/O such as lights.
  • Developed algorithm for motor feedback mechanism.
  • Initial algorithm developed for GPS heading calculation and tested.
  • Communication between bluetooth and master module established successfully .
  • Created project in Workshop4 IDE for all elements to be displayed by LCD.
  • Found UART commands to control each element in the LCD display.
  • I/O hardware was decided upon.
Complete.
10 11/19/2016
  • Speed synchronization of car using speed sensor and testing.
  • Interfacing Android controller with the GPS module
  • Algorithm for distance and heading calculation.
  • Coding and Calibration of GPS module.
  • Interface of master module with I/O module and testing to ensure predicted output.
  • Integrate sensor and I/O code.
  • Integrated speed sensor for calculating the speed and controlling motor speed.
  • Interface of Android controller with the GPS module conducted successfully.
  • Algorithm implemented for distance and heading calculation.
  • Calibration of Magnetometer ongoing.
  • Communication between I/O module and master module established successfully .
  • LCD code completed and sensors adjusted to work in tandem with obstacle avoidance logic.
Complete
11 11/26/2016
  • Testing and debugging for second demo.

  • Integration and testing complete for second demo.
Complete
12 12/03/2016
  • Fine tuning, debugging and integration.
  • Fine tuning on Geo, Android and I/O module algorithm.
Complete
13 12/10/2016
  • Final testing and fine tuning
  • Report preparation
In Progress

Parts List & Cost

Item# Part Description Vendor Qty Cost
1 SJ One Board (LPC 1758) From Preet 6 $480
2 RC Car Sheldon Hobbyist 1 $309.99
3 Accelerometer/Magnetometer LSM303 Adafruit 2 $40.00
4 Bluetooth Module From Preet 2 $0
5 CAN Transceivers From Microchip. 10 $0 (Free Samples)
6 Battery Pack From Sheldon Hobbist 1 $49.99
7 Ultra Sonic Sensor From Maxbotix 5 $91.15 (at 40% student discount)
8 LCD Display From Digikey 1 $94.21
9 GPS Module From Adafruit 1 $43.34
10 General Components From HSC electronics - $83.17
11 DC Current Sensor From Adafruit 1 $14.39
12 PCB From Amazon 1 $10.66
13 Corrugated Sheet for chasis From Home Depot 1 $6.74
14 PCAN dongle From Preet 1 $0

Car Framework and Components

Stampede 4X4 is built on the advanced shaft-driven 4WD system and innovative modular design of the Slash 4X4. The chassis fully integrates the electronics and battery compartment for an efficient and compact layout, and maintains the high center ground clearance. It uses just three gear meshes to drive all four wheels, eliminating the need for a multi-gear transmission. The highly efficient drive train spins effortlessly on rubber-sealed ball bearings, and is integrated seamlessly into the unique chassis for optimum performance and easy maintenance. A single center driveshaft connects the front and rear drive assemblies for maximum power transfer. To harness the torque of the Titan 12-turn motor, Traxxas bolted in the high-performance, waterproof XL-5 electronic speed control. EZ-Set one-button setup makes it easy to adjust or change profiles.


Car Framework

CAN BUS Design

CAN 11-bit ID Format

SRC DST MSG
3 bits (10-8) 4 bits (7-4) 4 bits (3-0)

Controller ID Table

Controller ID Controller Type
0 System Command
1 Master Controller
2 Sensor Controller
3 BLE Controller
4 Geo Controller
5 Motor Controller
5 I/O Controller

CAN Communication Table

Sr. No Message ID Message function Message Data To
System Commands
1 10 System communication command 0 - Communication Stop
1 - Communication Start
Master
Master Controller Commands
2 100 Master System Command for the all modules to start or stop processing 0 - System Stop
1 - System Start
BLE, Geo, I/O, Motor, Sensor
3 151 Steer and Drive command for the Motor module Motor, I/O
4 162 Display the active state of each module BLE, I/O
Sensor Controller Commands
5 211 Obstacle Data Master, I/O
6 214 Heartbeat Master
BLE Controller Commands
7 314 Heartbeat Master
8 341 Checkpoints Geo
9 361 Start location of the car I/O
10 362 End location of the car I/O
Geo Controller Commands
11 411 Calculated Direction for the car Master
12 413 Destination Reached flag Master, I/O
13 414 Heartbeat Master
14 431 Start point Master
15 461 Compass data I/O
Motor Controller Commands
16 514 Heartbeat Master
17 561 Car speed I/O
I/O Controller Commands
18 614 Heartbeat Master

DBC File

Can Bus analyzer

The PCAN-USB adapter enables simple connection to CAN networks. Bus Master software has been used to read and debug CAN messages.

PCAN Dongle

ECUs

Motor Controller

Group Members

Design & Implementation

The motor controller is responsible for generating the driving and steering action of the car. For this purpose, we have two types motors viz DC motor for driving and Servo motor which is used for changing directions of the car. The motor controller is also interfaced with a speed encoder for generating a feedback mechanism to automatically control and monitor the speed of the car. Our car came equipped with a Servo motor and brushed DC motor which is connected Electronic Speed Control (ESC).

Hardware Design

Motor Hardware Schematics
  • Hardware Specifications
    • 1. DC Motor
DC Motor

Our car came with Titan 12T 550 brushed motor and waterproof ESC. The ESC drives the DC motor based on the Pulse Width modulation (PWM) applied to it. The power supply required for this motor is 8.4 V. Maximum speed of upto 30mph can be achieved. The rotational speed is proportional to the EMF generated in its coil and the torque is proportional to the current.The main connection pins driving the motor are VCC,GND and the Control pin (PWM). The pin P2.1 of SJ-one board is connected to supply the required PWM to the motor. The basic working principle of DC motor is illustrated in the following figure : Since the preprogrammed controller has to be replaced by using our design ,the DC motor is then tested with Digital Oscilloscope for getting the frequency of operation and equivalent PWM values for full throttle condition in the forward as well as backward condition. It was observed from the waveform that the frequency of operation is 100Hz. The range of operational duty cycle is 10% to 20% with 15% being the neutral value or the stop condition. In order to accelerate the car a PWM value in the range of 15.6%-20.0% is applied. The 15.6 is the minimum pickup PWM that should be supplied in order to get the car moving at full load.

    • 2. Servo Motor
Servo Motor

The servomotor used in the car is #2056 a waterproof all weather-action and double the steering power as compared to standard servos. The servo motor is responsible for controlling the steering action of right or left by applying a suitable PWM pulse. The servo motor can be driven with 3.3 V power supply. The pin P2.0 of SJ-one board is connected to supply the required PWM to the motor. After testing the servo motor, we found that the frequency of operation is 100Hz and the operational duty cycle range is 10.0%-20.0% with 15% being the neutral value. For a full right deflection, we provide input PWM pulse ranging from 15.0-20.0% and for full deflection to the left we apply 10.0-15.0% of PWM.

Digital Oscilloscope readings for the motors.
  • 3. Speed Sensor

The speed feedback is monitored through the speed encoder which works on the Hall-effect principle. The Hall-effect speed sensor works as a transducer whose output voltage varies in response to the magnetic field. The sensor is mounted on the Spur gear instead of the wheel. The sensor would detect the rotation of axle. The motor controller would detect whenever the magnet is aligned with the sensor. This would generate a pulse. The pulse is detected in the form of rising-edge interrupt. This gives the wheel rotation count. The wheel rotates for every 1/4th rotation of the spur gear. The rotation count can then be converted to rpm to calculate the speed of the car.

Traxxas RPM Telemetry Speed Sensor.

Hardware Interface

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

The motor controller receives all its signals from Master controller from the CAN bus. The motor controller receives the steer and drive command from the master. The motor controller receives the System start command which boots and decodes further drive signals to the motor controller. Upon receiving the drive command the motor controller decodes the steering action. Upon receiving suitable data about the obstacle from sensor controller the master controller relays appropriate steering action. To achieve better performance in steering, the turn is categorized as FULL and HALF. This gives better precision in turning.

  • Speed Regulation:

Upon detection of uphill the pulse received from the speed encoder reduces. This is detected and the motor feedback is designed such that the speed is increased by providing higher value of PWM value to drive the DC motor. Similarly, for downhill the pulse count received increases which is detected by the speed encoder and the speed is reduced by applying reduced PWM.

Testing & Technical Challenges

  • Wheel Alignment Error

Though the neutral value of PWM is 15% at which the servo is supposed to be aligned straight. In practice, however when we tested the car for straight run slight deflection towards right was observed when the PWM pulse width was set to 15.0 %. Thus, to correct this, we provided correction value of -0.98 giving a resultant PWM pulse width of 14.02%. Thus, we fixed the wheel alignment and obtained the desired straight path traversal.

Android and Communication Bridge

Group Members

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

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.

Geographical Controller

Group Members

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

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.

Sensor and I/O

Group Members

SENSOR


Design & Implementation

We are using Maxbotix LV-EZ Ultrasonic sensors (MB1000). The configuration of the sensor is 3:1 that is three sensors in the front separated by 60 degrees apart and one in the rear. The ultrasonic sensors mounted on the car are used to detect the obstacle on its route. These sensors are connected to the SJOne board and work with a 5.0V power supply. The SJ One board then sends the sensors message with the help of CAN bus.

The pin description of Maxbotix LV-EZ Ultrasonic sensors is as follows:

Pin 1-BW- Unused, leave disconnected or connect to circuit common ground.

Pin 2-PW- Digital Proximity Logic, outputs a High/Low logic voltage level depending on proximity detection. High means an object has been detected in the detection zone. Low means no object is present. There is a ~2.5 second delay on acquiring targets and a ~1.5 second delay for releasing a target once detected. This hysteresis improves sensor reliability.

Pin 3-AN- Unused, leave disconnected or connect to circuit common ground.

Pin 4-RX- This pin is internally pulled high. The LV-ProxSonar-EZ will continually measure proximity information and output send to data. Leave the pin disconnected or hold the pin high for proximity information. Hold low to stop all sensor activity and reset acquire timers. Upon returning to a high state, the sensor will initiate a calibration sequence.

Pin 5-TX- The TX output delivers asynchronous serial with an RS232 format, except voltages are 0-Vcc

Pin 6-+5V- Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.

Pin 7-GND- Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.

Hardware Design

The ultrasonic sensor is interfaced through GPIO, each sensor requires 2 pins, PW and RX, in addition to the two pins required for powering up the sensor. The PW pins for each sensor is configured as an interrupt. The following table and figure shows the pin connections for all the sensors to the SJOne board.

Sensor Schematic
Sr.No SJOne Pin Number Sensor Pin Function
1 P1.23 Middle Sensor PW
2 P 2.3 Middle Sensor Rx
3 P 1.28 Left Sensor PW
4 P 2.5 Left Sensor Rx
5 P1.22 Right Sensor PW
6 P 1.29 Rear Sensor Pw
7 P 2.7 Rear Sensor Rx











The figure below shows the design for the 3D mount for the front sensors.

SNF Ultrasonic Mount.png
3D design

Ultrasonic Sensor

There are three ultrasonic sensors for the front of the car positioned at different angles to provide a wide ultrasonic "vision" for the car. The mount for the sensors was 3D printed such that we have the flexibility to change the angle of the sensor at a later stage when debugging the sensor.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

The readings from the sensor is taken in the form of PWM signals with the help of interrupts. The following steps should be performed to take readings and calculating distance from the sensor

1) Configure the PW pin of sensor as input.

2) Configure RX pin of the sensor as output and set it high.

3) Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.

4) Start timer at the rising edge of the interrupt (time T1).

5) At falling Edge of the interrupt stop the timer (time T2).

6) The distance of the obstacle is = (T2-T1)/147 inches.

7) Apply average filter. That is take 3 readings of each sensor and perform average of it.

8) Send this average value in a 10Hz task on CAN bus to Master and IO controller.

CMPE 243 F16 SNF Sensor Flowchart.png

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

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.

I/O


Design & Implementation

The IO section for the car consists of two main components, an LCD screen and LED indicators.

CMPE 243 F16 SNF IO.pngCMPE 243 F16 SNF IO LED Connections.png

IO is integral to troubleshooting the working of the car. The team first decided upon the various important indicators that would be needed to troubleshoot the working of the car and then decided to translate them into either LED indicators or LCD screen elements. The table below summarizes the features for IO and which IO element was used to represent them on the car.

Sr.No LCD Element Sensor Pin Function LED Element Present
1 System Command (Start, Stop Resume) An on screen LED that turns off/on for each command Yes
2 Right Turn An on screen LED that turns off/on Yes
3 Left Turn An on screen LED that turns off/on Yes
4 Brake An on screen LED that turns off/on Yes
5 Forward An on screen LED that turns off/on Yes
6 Reverse An on screen LED that turns off/on Yes
7 Right Sensor Gauge No
8 Left Sensor Gauge No
9 Middle Sensor Gauge No
10 Rear Sensor An on screen LED that turns off/on Yes
11 System Status (Heatbeat) Gauge No
12 Speed. Meter. No
13 Battery Indicator Gauge No

Hardware Interface

The hardware interface for the LCD is through UART for pins it is through GPIO. LCD Hardware interface: In order to communicate with the LCD we used UART3 ports on the SJOne board.

CMPE 243 F16 SNF IO LCD Connections.JPG CMPE 243 F16 SNF LCD PROGRAMMING ADAPTER.JPG


CMPE 243 F16 LCD SnF FRONTVIEW.JPG CMPE243 F16 SNF LCD REAR VIEW.JPG

Software Design

CMPE 243 F16 SnF form 0.JPG CMPE 243 F16 SnF form 1.JPG CMPE 243 F16 SnF form 2.JPG CMPE 243 F16 SnF form 3.JPG

  • Form1: This is the home screen for Spartan and Furious which displays the logo of our team. This screen is displayed when there is no system command from the Master. As soon as the IO receives the master system command the IO displays all the relevant data using periodic callback function.
  • Form2: This is the screen which is being displayed after the home screen. This screen shows the sensor data, Speed indication, System command status and the direction in which the car is moving.. There are four different gauges for different sensor Data. Each gauge indicates obstacle proximity detected from ultrasonic sensors which are placed on left (L), centre (M), right (R) and rear sensor at back (B) of the car. The direction of the car is indicated using different LEDs for Front(F), Right(R), Left(L), Back(B) indication. The system command LED indicates that master is in sync with all the modules.
  • Form3: In this screen IO displays the System Status of all the modules and also the System status given by the master module to all the modules. System status consists of start, stop and Resume status. There are six different LED’s indication the Heartbeat of the modules. There is a battery indicator Gauge which displays the battery life.
  • Form4: This is the ‘Geo Status’ screen which shows different parameters such as GPS longitude and latitude, current compass direction and different modes of car.

Master Controller

Group Members

Introduction and Responsibilities

Master controller is like the brain of the car.
All the decisions are taken by the master module. Some of the major responsibilities of the master module are:

1. Obstacle avoidance : Based on the sensor values, master will decide the direction to be taken by the motor.
2. GPS data: Depending upon the GPS commuted direction sent by the geo module and obstacle data received from sensor module, master controlled will make a decision in regards to the steer and drive of the motor .
3. System command (Initial Start) : Upon successful connection with Android app, master command will send as system start command to all the other modules on the CAN bus. This command advises all the modules to start their processing(similar to wake up).


Master Controller Execution Flow

Hardware Design

  • Interface of CAN Bus with six SJ-One controller boards on PCB was designed.
  • Ribbon Cables were used instead of individual jumper wires to assist in designing less complex circuit.


CAN Hardware Block diagram

Software Design

The software design of master controller is such that there are two modes for the car:

Free Run mode

• For switching to free run mode, the “FREE RUN” button needs to be selected from the app.

• After the free run mode is selected, master controller will send SYSTEM_CMD= START command to all of the modules, which notifies them that the Bluetooth communication via app has been initiated.

• As per the sensor data, the movement of the car is decided by the master controller.

• The following table depicts the motor command send by master to the motor controller as per the sensor values.

Sr no Left sensor value Middle sensor value Right sensor value Critical value Rear sensor value Motor Command
0 0 0 0 0 X STRAIGHT
1 0 0 1 0 X HALF RIGHT
2 0 1 0 0 X LEFT
3 0 1 1 0 X RIGHT
4 1 0 0 0 X HALF LEFT
5 1 0 1 0 X STRAIGHT
6 1 1 0 0 X LEFT
7 1 1 1 0 0 REVERSE
8 1 1 1 0 1 STOP
9 X X X 1 0 REVERSE
10 X X X 1 1 STOP

• When STOP button is selected from the app,the BLE will advise the same to master controller and master will send SYSTEM_CMD= STOP to all the modules. This stop command notifies them that the Bluetooth communication via app has been deactivated.

GPS mode

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

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.

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

References

Acknowledgement

We would like to thank Preet for explaining the various Embedded Software concepts. The understanding of these concepts helped us in successful implementation of this project. Also, this project has helped us put into practice whatever we learned in the class.

References Used