Difference between revisions of "S19: Tech Savy"

Revision as of 06:03, 12 May 2019

Tech Savy RC Car

Tech_Savy Side Open view

File:CMPE243 Tech Savy Car.jpg Tech_Savy front view

Tech_Savy Top Open view

Abstract

In this project our main aim to build a Self-Navigating Car named Tech Savy, that navigates from a source location to a selected destination by avoiding obstacles in its path using sensors and motors.

Main Building Blocks of Tech Savy

Introduction & Objectives

The key features support by the system are

1. A Google-map based Android application is developed which finds out the shortest distance path between current location and destination and connects to the self-driving RC car via Bluetooth to send the GPS Coordinates.

2. The car will be integrated with the GPS, Compass, Bluetooth, multiple sensors such as Ultrasonic sensors and RPM sensors to fulfill the purpose of navigation, obstacle detection, and avoidance

3. LIDAR used for obstacle recognition and avoidance.

4. Motor drives the car by Route Calculation and Maneuvering to the selected destination and Self- Adjusting the speed of the car on Ramp.

5. LEDs and LED Display are used for debugging and to get all relevant information about the status of the car, in real time and LCD Display is used to give more detailed information related to the car.

The system is built on FreeRTOS running on LPC1758 SJOne controller and Android application. The main building blocks of Tech Savy are the five controllers communicating through High Speed CAN network designed to handle dedicated tasks. The controllers integrate various sensors that are used for navigation of the car.

CAR Objectives

     1. Master Controller - Handles the Route Manuevering,Path Planning and Obstacle Avoidance 
     2. Sensor Controller - Detects the surrounding objects
     3. Geo Controller - Provides current location in the form of coordinates and navigate car using CMPS11
     4. Motor Controller - controls the movement of the Car.
     5. Bridge controller - Interfaces the system using Bluetooth to an Android application. 

Team Objectives

     1. Learn each and every module as much as possible, in order to develop an industrial product.
     2. Achieve 100% code coverage, during unit testing. 
     3. Document and track all the bugs encountered during development, unit testing, and field testing.

System Architecture

File:CmpE243 TechSavy Application.png Android Application

Team Members & Technical Responsibilities

• Git Project Link: Tech Savy

• Master Controller
  • Aakash Chitroda
  • Halak Vyas

• Motor Controller
  • Jay Parsana
  • Vatsal Makani

• Geographical Controller
  • Vidushi Jain
  • Prashant Gandhi

• Sensor Controller
  • Halak Vyas
  • Aakash Chitroda

• Communication Bridge Controller
  • Vidushi Jain
  • Akshata Kulkarni
  • Jay Parsana

• Android Application
  • Saumil Shah
  • Akshata Kulkarni

• LCD Interfacing & UI Designing
  • Aakash Chitroda

• Hardware PCB Integration
  • Vatsal Makani
  • Prashant Gandhi

• Testing
  • Jay Parsana
  • Vidushi Jain
  • Prashant Gandhi
  • Saumil Shah

Administrative Responsibilities

Team Deliverables Schedule

BILL OF MATERIALS (GENERAL PARTS)

Printed Circuit Board

Design And Architecture

We designed the custom PCB using DipTrace Software in which we implemented connections for all the controller modules(SJOne Board LPC1758) all communicating/sending data via CAN bus. The data is sent by individual sensors to the respective controllers. GPS and Compass is connected to Geographical Controller. RPM sensor, DC and Servo Motors are connected to Motor Controller. Ultrasonic and Lidar is connected to Sensor Controller. LCD is connected to Motor Controller. Bluetooth is connected to Bridge Controller. CAN Bus is implemented using CAN Transceievrs MCP2551 terminated by 120Ohms; with PCAN for monitoring CAN Debug Messages and Data.

Power Section

We implemented separate power modules for LIDAR and remaining modules of the PCB. The micro USB mini B supplies 5V to LIDAR Motor and Scanner (max current rating estimated @ 1A). Another power is supplied through USB 2.0 Type A connector with rating of 5V@2A. Since GPS requires 3.3V, we have used a linear regulator REG1117-3.3. All the parts are through-hole components.

Fabrication

PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 with the lead time of 1 week. We implemented 2 layers of PCB with most of the parts in top layer. We implemented rectangular header connector for SJOne boards, RPM sensor, DC & Servo Motor and GPS modules on the bottom layer.

Challenges

There were 2 iterations of this board. The first one was designed without validation and had problems with orientation of the SJOne board header & pin connections. We also need to change the header for LCD since it was having different pitch.This design lacked several necessary power connections and was limited by functionality. These problems were fixed in the 2nd iteration.

PCB Layout Design in DipTrace

PCB Top Layer

PCB Bottom Layer

CAN Communication

<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

Hardware Design

<Show your CAN bus hardware design>

DBC File

A Link to the DBC file that defines the CAN communication of the system is as follows: DBC link on GitLab

DBC is a format that enables fewer hassles while developing code to either interpret data received or send data over the CAN bus. This project used DBC effectively.

Shown below is the DBC implementation for this project.

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_: MASTER BRIDGE MOTOR SENSOR GPS


BO_ 103 BRIDGE_NODE: 1 BRIDGE
 SG_ BRIDGE_START_cmd : 0|1@1+ (1,0) [0|1] "" MASTER

BO_ 104 SENSOR_NODE: 5 SENSOR
 SG_ SENSOR_FRONT_cm : 0|10@1+ (1,0) [0|645] "cm" MASTER,MOTOR,BRIDGE
 SG_ LIDAR_Obstacle_FRONT : 10|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
 SG_ LIDAR_Obstacle_RIGHT : 13|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
 SG_ LIDAR_Obstacle_LEFT : 16|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
 SG_ LIDAR_Obstacle_BACK : 19|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE

BO_ 105 CAR_CONTROL: 1 MASTER
 SG_ MOTOR_DRIVE_cmd : 0|3@1+ (1,0) [0|0] "" MOTOR
 SG_ MOTOR_STEER_cmd : 3|3@1+ (1,0) [0|0] "" MOTOR

BO_ 106 MOTOR_NODE: 1 MOTOR
 SG_ MOTOR_SPEED_mph : 0|8@1+ (0.1,0) [0.0|15.0] "mph" MASTER,BRIDGE
 
BO_ 107 BRIDGE_CHECKPOINTS: 8 BRIDGE
 SG_ CHECKPOINT_LAT_deg : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" MASTER,GPS
 SG_ CHECKPOINT_LONG_deg : 28|29@1+ (0.000001,-180.000000) [-180|180] "Degrees" MASTER,GPS
 
BO_ 108 GPS_LOCATION: 8 GPS
 SG_ CURRENT_LAT_deg : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" MASTER,BRIDGE,MOTOR
 SG_ CURRENT_LONG_deg : 28|29@1+ (0.000001,-180.000000) [-180|180] "Degrees" MASTER,BRIDGE,MOTOR
 
BO_ 109 COMPASS: 8 GPS
 SG_ CMP_HEADING_deg : 0|12@1+ (0.1,0) [0|359.9] "Degrees" MASTER,BRIDGE,MOTOR
 SG_ CMP_BEARING_deg : 12|12@1+ (0.1,0) [0|359.9] "Degrees" MASTER,BRIDGE,MOTOR
 
BO_ 110 MASTER_HEARTBEAT: 1 MASTER
 SG_ MASTER_hbt : 0|1@1+ (1,0) [0|1] "" SENSOR,MOTOR,BRIDGE,GPS
   
BO_ 111 SENSOR_HEARTBEAT: 1 SENSOR
 SG_ SENSOR_hbt : 0|1@1+ (1,0) [0|1] "" MASTER
  
BO_ 112 MOTOR_HEARTBEAT: 1 MOTOR
 SG_ MOTOR_hbt : 0|1@1+ (1,0) [0|1] "" MASTER
       
BO_ 113 GPS_HEARTBEAT: 1 GPS
 SG_ GPS_hbt : 0|1@1+ (1,0) [0|1] "" MASTER
    
BO_ 114 BRIDGE_HEARTBEAT: 1 BRIDGE
 SG_ BRIDGE_hbt : 0|1@1+ (1,0) [0|1] "" MASTER



CM_ BU_ MASTER "The master controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ BRIDGE "The bridge controller of the car";
CM_ BU_ GPS "The gps controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";

BA_DEF_ "BusType" STRING ;
BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
BA_DEF_ SG_ "FieldType" STRING ;

BA_DEF_DEF_ "BusType" "CAN";
BA_DEF_DEF_ "FieldType" "";
BA_DEF_DEF_ "GenMsgCycleTime" 0;

BA_ "GenMsgCycleTime" BO_ 103 100;
BA_ "GenMsgCycleTime" BO_ 104 100;
BA_ "GenMsgCycleTime" BO_ 105 100;
BA_ "GenMsgCycleTime" BO_ 106 100;
BA_ "GenMsgCycleTime" BO_ 107 100;
BA_ "GenMsgCycleTime" BO_ 108 100;
BA_ "GenMsgCycleTime" BO_ 109 100;
BA_ "GenMsgCycleTime" BO_ 110 100;
BA_ "GenMsgCycleTime" BO_ 111 100;
BA_ "GenMsgCycleTime" BO_ 112 100;
BA_ "GenMsgCycleTime" BO_ 113 100;
BA_ "GenMsgCycleTime" BO_ 114 100;
BA_ "FieldType" SG_ 105 MOTOR_DRIVE_cmd "MOTOR_DRIVE_cmd";
BA_ "FieldType" SG_ 105 MOTOR_STEER_cmd "MOTOR_STEER_cmd";


VAL_ 105 MOTOR_DRIVE_cmd 2 "MOTOR_STOP" 1 "MOTOR_REV" 3 "MOTOR_FWD_SLOW" 4 "MOTOR_FWD_MED" 5 "MOTOR_FWD_FAST" ;
VAL_ 105 MOTOR_STEER_cmd 2 "MOTOR_DONT_STEER" 1 "MOTOR_STEER_SLIGHT_LEFT" 0 "MOTOR_STEER_FULL_LEFT" 3 "MOTOR_STEER_SLIGHT_RIGHT" 4 "MOTOR_STEER_FULL_RIGHT" ;

A screenshot of the Bus Master Application is as shown below:

Sensor Node

We used 2 sensor modules to achieve accurate and reliable obstrucle avoidance system.
1. Lidar - Main controller to detect obstucle. Giving 360 degree view with range up-to 6 meter in distance.
2. Ultrasonic Sensor (Maxbotix LV-MaxSonar-EZ0) - One Ultrasonic sensor with maximum range of 600 cm was used to detect very small objects at front that Lidar might miss because of it's leveled placement.

Sensor Node Code

GitLab link to Sensor Code

Hardware Design

The Lidar is communicating with SJOne board through UART, we have used UART 2 here as shown in Pin config below. Ultrasonic Sensor is simple Interrupt based, hence it connected through GPIO pins of SJOne board as shown in diagram.

File:Image1.jpg

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Unreliable sonor sensors

<Problem Summary> <Problem Resolution>

Motor ECU

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Unreliable Servo Motors

<Problem Summary> <Problem Resolution>

Geographical Controller

<Picture and link to Gitlab>

Hardware Design

The hardware interface details of GPS and Compass Module with SJOne board are given below:

GPS & CMPS11 Module Hardware Interfacing

GPS

GPS is a global navigation satellite system that provides geolocation and time information to a GPS receiver anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.

Compass

CMPS11 Compass Module

A Compass is an instrument used for navigation and orientation that shows direction relative to the geographic cardinal directions (or points). Compass is communicating over I2C with SJ One board. The register 2 and 3 of the compass provide the compass bearing angle (0- 360 range). Calibrating the compass is an important part. We are calibrating it on ‘horizontal calibration mode’, it works for us because the compass has tilt calibration.

Calibration process: First of all, you need to enter the calibration mode by sending a 3-byte sequence of 0xF0,0xF5 and then 0xF7 to the command register, these MUST be sent in 3 separate I2C frames. There MUST be a minimum of 20ms between each I2C frame.

The LED will then extinguish and the CMPS11 should now be rotated in all directions on a horizontal plane, if a new maximum for any of the sensors is detected then the LED will flash, when you cannot get any further LED flashes in any direction then exit the calibration mode with a command of 0xF8.

Note: Please make sure that the CMPS11 is not located near to ferrous objects as this will distort the magnetic field and induce errors in the reading. While calibrating rotate the compass slowly. Only the X and Y magnetometer axis is calibrated in this mode.

We are sending 3-byte sequence command of 0xF0,0xF5 and then 0xF7 on 4th switch press and 0xF8 command on 2nd switch press of the SJ One board. You can always restore factory calibration mode by sending the 3-byte sequence command of 0x20,0x2A,0x60. We are using switch 3 to restore factory calibration.

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Unreliable GPS lock

<Problem Summary> <Problem Resolution>

Bridge Controller Communication

<Picture and link to Gitlab>

Hardware Design

Bluetooth Module Hardware Interfacing:

We are using an HC-05 Bluetooth module to send and receive the data from our android application to Controller. The Bridge controller is connected to the Bluetooth module through the Serial interface(UART2) of SjOne board and we have configured HC-05 at 38400 baud rate 8-bit data and 1 stop bit using modules Communication Mode.

HC-05 Module Hardware Interfacing

HC-05 Bluetooth module

HC-05 Bluetooth Module is used to set up wireless communication between the Car and the Android phone. This module is based on the Cambridge Silicon Radio BC417 2.4 GHz BlueTooth Radio chip. This is a complex chip which uses an external 8 Mbit flash memory It includes the Radio and Memory chips, 26 MHz crystal, antenna, and RF matching network. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

• HC-05 PinOut

* EN:  In a case brought HIGH before power is applied, forces AT Command Setup Mode 
* VCC: 5V Power 
* GND: Ground 
* TXD: Serial Transmit pin connected to RXD2 of SJOne board
* RXD: Serial Receive  pin connected to TXD2 of SJOne board 
* STATE: States if connected or not

• LED Blinking signals

* Flashing RED Fast: Ready for Pairing with nearby Bluetooth device available
* Flashing RED Slow: Paired and Connected

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Insane Bug

<Problem Summary> <Problem Resolution>

Master Module

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Improper Unit Testing

<Problem Summary> <Problem Resolution>

Mobile Application

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Wifi Link Reliability

<Problem Summary> <Problem Resolution>

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 the 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 the exact code, but you may show pseudocode and fragments of code. Keep in mind that you are showing the DESIGN of your software, not the inner workings of it.

TechSavy High Level Software Architecture

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can is started from scratch again? Make a smooth transition to the 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

<Organized summary of the project>

<What did you learn?>

Project Video

Project Source Code

• Sourceforge Source Code Link

• Git Project Link: Tech Savy
  

Advise for Future Students

<Bullet points and discussion>

Acknowledgement

References

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.

Grading Criteria