Difference between revisions of "S19: Tech Savy"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Software Design)
(Software Design)
Line 774: Line 774:
  
 
=== Software Design ===
 
=== Software Design ===
<List the code modules that are being called periodically.>
+
<The dc motor and servo motor operation is fundamentally based on PWM (Pulse Width Modulation).>
 +
<>
  
 
=== Technical Challenges ===
 
=== Technical Challenges ===

Revision as of 06:11, 23 May 2019


LOGO


Contents

Tech Savy RC Car

Tech_Savy Side Open view
Tech_Savy 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 will update the live location of RC car given by GPS to Bridge over Bluetooth.Android app is used to get information from all the Modules and will show live data of MOTOR, SENSORS, GPS and COMPASS and we can set the final destination so that car can drive to the destination.

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 and Ultrasonic Sensor is used for obstacle detection and avoidance in all the angles in the view of 360 degrees.

4. Motor drives the car by Route Calculation done on GPS using the shortest distance path algorithm between current location and destination and connects to the self-driving RC car via Bluetooth to send the GPS Coordinates 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

Team Members & Technical Responsibilities

File:Team Pic.jpeg
TEAM TECH SAVY


Administrative Responsibilities

Administrative Roles
  • Team Lead
Aakash Chitroda
  • Finance Manager
Halak Vyas
  • Git Repository Manager
Vatsal Makani
  • Wiki Report Manager
Vidushi Jain
  • Bill of Materials Manager
Jay Parsana

Team Deliverables Schedule

WEEK

START DATE

END DATE

TASK DETAILS

STATUS

1 26 Feb 2019 4 March 2019
  • Create and establish GitLab repository
  • Establish slack channel and invite Preet
  • Look through previous years projects and study it
  • Distribute major roles among team members
Completed
Completed
Completed
Completed
2 05 March 2019 12 March 2019
  • Create a Bill of Materials.
  • Select and order an RC car.
  • Make Repo on Gitlab for all modules - Follow Naming Convention.
Completed
Completed
Completed
3 13 March 2019 19 March 2019
  • Select Part Number for Sensors (Halak, Akash)
  • Designing and deciding PCB tool(Prashant, Vatsal)
  • Finalizing GPS module by doing some research (Vidushi)
  • Finalize and order LCD (Akash, Vidushi)
  • Finalize Motor and Order it (Vatsal)
  • Environmental setup of Android (Saumil, Akshata)
Completed
Completed
Completed
Completed
Completed
Completed
4 20 March 2019 26 March 2019
  • Understand DBC and implement the DBC file compatible with all the controllers.
  • Test motor driving in different situations, begin to listen to CAN for controls.
  • Establish communication across all the CAN controllers over CAN bus based on the DBC file.
  • Verify the power-up interactions and configurations between Master and the other controllers.
  • 03/26/2019 DBC File
  • 03/26/2019 DEMO: CAN communication between controllers.
Completed
Completed
Completed
Completed
Completed
Completed
5 27 March 2019 09 April 2019
  • Check and Resolve power issue for RC Car.
  • Finalize high-level system block diagram and control scheme.
  • Circuit Simulation in Diptrace Tool.
  • PCB Layout Design in Diptrace Tool.
  • Finalize Components placement on PCB.
  • Establish a connection over Bluetooth and Android app.
  • Establish a communication between Bluetooth devices.
  • Interfacing of ultrasonic sensors to the SJOne board and check for basic functionality.
  • Interface and get the reading of Lidar sensor with SJOne over UART.
  • Chalk out the Message IDs based on the priority of the messages and the data to be sent across nodes.
  • Interface of Servo & DC motor to the SJOne board and check for basic functionality.
  • Interface Compass module with SJOne board using I2C serial bus.
  • Interface bluetooth HC-05 module with SJOne board using serial Communication.
  • Configure bluetooth HC-05 module name as Tech Savy using HC-05 Communication Mode.
  • Explore UI designing of LCD.
  • Finish motor controller API. Test motor driving in different situations, begin to listen to CAN for controls.
  • Add a TextView for displaying the Bluetooth connection status in Android App.
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
6 10 April 2019 16 April 2019
  • Parse data of Lidar Sensor depending on distance and angle and send it to master using dbc.
  • Implement basic obstacle avoidance algorithm based on sensor data and test the same.
  • Continue testing motor driver via commands from CAN bus.
  • Build in speed steps to reverse motor for reverse to work correctly.
  • Mount all the sensors and test for any dead band and modify their positions for maximum coverage.
  • Integrate the fusion of LIDAR and Ultrasound sensor to get overall feedback from all the directions.
  • Develop algorithm to avoid obstacles and plan the car's further navigation path.
  • Complete final prototype of the obstacle avoidance feature.
  • Calibrate Compass Module. Develop code for Compass module communication over CAN.
  • 16 April 2019 DEMO: Motors driven by wheel feedback and sensors, Basic obstacle avoidance.
  • Final Wiki Schedule.
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
7 17 April 2019 23 April 2019
  • Configure GPS device baud rate and interface it with SJOne board using UART.
  • Send and receive current location, destination and checkpoint coordinates to and from App and Geo module via BRIDGE.
  • Calibrate sensors readings and work on filtering algorithm with Master & Sensor
  • Begin work on LCD to show vehicle live status(speed, fuel-status, obstacles, distance to destination etc.) in a GUI.
  • Finish implementing speed control on motor (to make sure requested speed is met based on RPM read).
  • Work on Car reversing using Motor Controllers.
  • Integrate all modules with the Master to test the data flow.
  • Validation & Verification of obstacle avoidance, steering logic with rear sensor inputs and reversing.
  • Start incorporating GEO Controller information to Master module Steering logic.
  • Decide, implement and test data exchange between Geo Controller and BRIDGE.
  • Calculate and send simple bearing angle and destination status on CAN to figure out initial challenges.
  • Add a Google Map for setting the car's destination.
  • Send car location to app and check points received to Geo module.
  • Verify the stringent requirement of Start-up Sync, Periodic heart-beat messages.
  • Update Wiki Schedule with Test Reports.
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
In Progress
Completed
Completed
8 24 April 2019 30 April 2019
  • Testing & Validation of the LCD UI and display run time vehicle status and looking forward for feedback from team if any.
  • Improve & Validate Navigation logic with multiple checkpoints, bearing angle and destination information.
  • Identify and mitigate GPS locking, Location Accuracy and Number of Satellite-In-View coming.
  • Validate Accuracy of Compass Calibration with iPhone Compass.
  • Determine and add DBC Changes and finalized.
  • Implement the steering logic with bearing angle and status provided by GEO-Module.
  • Consistently Communicate current car location to App, get check points from App and relay them to Geo module.
  • Send additional vehicle status information from can bus to the App for display.
  • Send the request to Google for getting the checkpoints(use the Google Maps Directions API).
  • Field test and check for obvious issues in obstacle avoidance, navigation, maintaining speed (up/down hill).
  • Provide feed backs to each team on identified short comings.
  • Update Wiki with new details and information.
  • DEMO: GPS driving
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
9 1 May 2019 7 May 2019
  • FIELD TESTING - CRITICAL WEEK
  • Implement turning indicators, break lights and head light.
  • Check for Corner cases for steering logic under various conditions and locations.
  • Analyse field test results for GPS and CMPS and work on it if required.
  • Test the accuracy of check-points from the Blue-tooth controller, location data from the Geo-controller sensor and Navigation Algorithm.
  • Check overall robustness of the complete system.
  • Establish complete connection on PCB
  • Update wiki with details.
Completed
Completed
Completed
Completed
Completed
Completed
Completed
10 8 May 2019 21 May 2019
  • All hands on testing and final bug fixes.
  • Check for tuning or calibration of modules if required.
  • Complete end-to-end testing for various scenarios and conditions.
  • Create the semester long project activity video and upload to YouTube.
  • Update and finalize wiki.
In Progress
11 22 May 2019
  • DEMO: Final Project
  • SUBMISSION: Final Project Wiki
In Progress

BILL OF MATERIALS (GENERAL PARTS)

PART NAME

PART MODEL & SOURCE

QUANTITY

COST PER UNIT (USD)

  • Micro-Controller Eval-Boards
  • LPC 1758 (Purchased from Preet Kang)
  • 5
  • 80.00
  • RC Car
  • 1
  • 205.99
  • Lithium-Ion Battery
  • 1
  • 74.95
  • Lithium-Ion Battery 2
  • 1
  • 69.95
  • RC Car Battery Charger
  • 1
  • 49.95
  • Bluetooth Breakout Board
  • 1
  • 8.49
  • RC Car Display
  • 1
  • 79.00
  • Ultrasonic Sensors
  • 2
  • 30.00
  • RP-LIDAR Sensor
  • 1
  • 99.00
  • GPS Antenna
  • 1
  • 5.00
  • CAN Transreceivers
  • 20
  • FREE
  • Compass
  • 2
  • 30.00
  • RPM Sensor
  • 1
  • 10.00
  • GPS Breakout Board
  • 1
  • 43.00
  • PCB parts and other Miscellaneous parts
  • Anchor Electronics and Digikey
  • 1
  • 130.00
  • PCB Fabrication
  • 5
  • 29.53


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 are connected to Geographical Controller. RPM sensor, DC and Servo Motors are connected to Motor Controller. Ultrasonic and Lidar are connected to Sensor Controller. LCD is connected to Motor Controller. Bluetooth is connected to Bridge Controller. CAN Bus is implemented using CAN Transceivers 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 a 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 DBG


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

BO_ 104 CAR_CONTROL: 4 MASTER
 SG_ MOTOR_DRIVE_cmd : 0|2@1+ (1,0) [0|0] "" MOTOR,BRIDGE
 SG_ MOTOR_STEER_cmd : 2|15@1+ (0.1,-90.0) [-90|90] "" MOTOR,BRIDGE
 SG_ MOTOR_kph : 17|12@1+ (0.01,0) [0.00|20.00] "kph" MOTOR,BRIDGE
 
BO_ 105 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
 SG_ LIDAR_Obstacle_BACK_RIGHT : 22|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
 SG_ LIDAR_Obstacle_BACK_LEFT : 25|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE

BO_ 106 MOTOR_NODE: 2 MOTOR
 SG_ MOTOR_SPEED_kph : 0|12@1+ (0.01,0) [0.00|20.00] "kph" MASTER,BRIDGE
 
BO_ 107 BRIDGE_CHECKPOINTS: 8 BRIDGE
 SG_ CHECKPOINT_LAT_deg : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" MASTER,GPS,MOTOR
 SG_ CHECKPOINT_LONG_deg : 28|29@1+ (0.000001,-180.000000) [-180|180] "Degrees" MASTER,GPS,MOTOR
 
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
 SG_ CMP_DISTANCE_meters : 24|17@1+ (0.01,0) [0|0] "Meters" MASTER,MOTOR,BRIDGE
 
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

BO_ 115 SENSOR_DEBUG: 1 SENSOR
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_sensor_init : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_CAN_TX : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 3|1@1+ (1,0) [0|0] "" DBG
 
BO_ 116 MOTOR_DEBUG: 2 MOTOR
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_RPM_kph : 2|12@1+ (0.01,0) [0.00|20.00] "kph" DBG
 
BO_ 117 MASTER_DEBUG: 1 MASTER
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_drive_mode : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_HBT_FROM_ALL_CONTR : 3|1@1+ (1,0) [0|0] "" DBG

BO_ 118 GPS_DEBUG: 1 GPS
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_HBT_Transmit : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_GPS_rx : 3|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_GPS_Fix : 4|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_Compass_Rx : 5|1@1+ (1,0) [0|0] "" DBG

BO_ 119 BRIDGE_DEBUG: 1 BRIDGE
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_HBT_Transmit : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_Connected : 3|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_Bridge_rx : 4|1@1+ (1,0) [0|0] "" DBG 

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_ BU_ DBG "The debug node 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_ "GenMsgCycleTime" BO_ 115 100;
BA_ "GenMsgCycleTime" BO_ 116 100;
BA_ "GenMsgCycleTime" BO_ 117 100;
BA_ "FieldType" SG_ 104 MOTOR_DRIVE_cmd "MOTOR_DRIVE_cmd";


VAL_ 104 MOTOR_DRIVE_cmd 2 "MOTOR_STOP" 1 "MOTOR_REV" 0 "MOTOR_FORWARD" ;


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

Busmaster.jpg


Sensor Node

We used 2 sensor modules to achieve accurate and reliable obstacle avoidance system.
1. Lidar - Main controller to detect obstacle. Giving 360-degree view with a range up to 6 meters in distance.

  • RPLidar works on a mechanism known as laser triangulation ranging principle. The system measures distance data in more than 2000 times’ per second and with high-resolution distance output. RPLIDAR emits modulated infrared laser signal and the laser signal is then reflected by the object to be detected. The returning signal is sampled by vision acquisition system in RPLIDAR A1 and the DSP embedded in RPLIDAR starts processing the sample data and output distance value and angle value between object and RPLIDAR A1 through the communication interface.
Lidar Working Schematic

2. Ultrasonic Sensor (Maxbotix LV-MaxSonar-EZ0) - One Ultrasonic sensor with a maximum range of 600 cm was used to detect very small objects at the front that Lidar might miss because of it's leveled placement.

ultrasonic beam
  • Ultrasonic sensor uses a high-frequency beam to detect an object. It first throws light and reads the time taken for light to receive back, depending on the time calculated, it identifies the obstacle. It calibrates after it's first to read cycle, then it can continuously read data of light. The beam depending on the range is shown in figure.

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.
Sensor Pin connection


Implementation

Ultrasonic

LV Maxsonar ultrasonic sensor is used at the very front of the RC car to provide wide range sonar detection ranging from 0 to 645 cm. It supports LiDAR sensor to detect very small obstacles like stone that can hinder car from moving forward. so we have purposefully mounted it at a lower level than LiDAR.

LiDAR

RPLidar works on UART. We have used UART 2 of SJOne Board to establish communication between them.

  • Figure shows the several operation provided by RPLidar for better performance and reliable data.
Various Operations of RPLidar

Algorithm to establish communication through UART

  • In order to start the scanning of Lidar, first send the 0X20 via uart2.putchar(0x20). Before that, we can check the health status of RPLidar by sending 0x52. It waits for sometime (timeout = 500ms), and if return status is not true throws error indicating Lidar is not initialized properly and hence it gets reset.
  • As soon as correct scan command is received by Lidar, it starts sending data frames continuously on UART. The frame consist of 5 bytes including start bit, Angle, quality and distance, which are useful to identify the exact position of obstacle.
RPLidar data frame.png
  • This data is processed and divided into tracks of 25 cm each.
  • By looking at the track, we choose the sector value which depends on angle detected. Below figure shows the division of angle for respective sector value.
Figure shows the division of angles
  • The obstacle information is sent to Master Node through CAN.

Software Design

Ultrasonic

  • It works with the help of interrupt.
  • After configuring GPIO pins as RX and TX, set RX pin high.
  • PW pin gets the input, identify the type of interrupt
    • Rising edge interrupt.
    • Falling edge interrupt
  • Calculate distance to obstacle,
    • ultrasonic_data.distance = (stop_time - start_time)/147;

LiDAR

Below diagram shows the code flow of sensor module. A separate task was used to send sensor data over CAN, which continuously sends data in while(1) loop.

Sensor Flowchart

Technical Challenges

Ultrasonic

  • When mounted initially on CAR, ultrasonic was giving sometimes faulty readings as it was detecting ground as and obstacle.
    • We designed a 3D mount for it and adjusted it on such a angle that it gives perfect readings.
  • Initialization issue: Sometimes on power-up we noticed that Ultrasonic sensor was giving faulty readings(it was getting stuck on some fixed value).
    • After reading the datasheet accurately, I found that it calibrates itself during the first read cycle and so the obstacle should be at least 14 inches far from the sensor.
  • Ultrasonic Failure - When the CAR got crashed, Ultrasonic sensor failed and started giving incorrect data.
    • We replaced it's wired to get it working.

LiDAR

  • Identifying obstacle data and separating it.
    • Initially I lost a lot of time in figuring out the data frame as it consists of quality, angle, distance and start bit.
    • Dividing the frame bits appropriately and storing it separately in struct variables resolved the issue. Also after that depending on the angle, every 360 times data was fetched in a loop to cover each and every angle value.
  • Task overrun because of receiving a large number of data continuously over UART.
    • Used a separate task, that receives data continuously in a loop, i.e while(1).
    • Instead of receiving whole data in a single frame, took data character by character in a for loop 360 times, to get the value of obstacle at each degree.
  • Angle detection problem - When large angles were taken, for example, 30 degrees on the right, it was detecting nearer objects correctly but far objects were getting detected in some other range (for example in front instead of right) of angle because of angle spread. I divided the range into 10 degrees each and store it in the same variable to send it over CAN.
    For example, to get 30 degrees in right, 0-10,10-20 & 20-30 values are taken.
  • Received variable initialization problem.
    • I didn't initialize the character variable to get data from UART to 0 and hence it was taking garbage value.
      Thanks to Preet, at time of my code review he pointed out this problem and later I checked it with Unit Testing.
  • Some bugs here and there in the code.
    • I identified and resolved a few bugs after Unit testing the code.
  • Delay in sending data because of large CAN buffer size.
    • We were facing this issue with master, motor and sensor communication. The response time was slow as data was getting accumulated before sending because of large buffer size taken.


Motor Controller

Hardware Design

The hardware interface details of MOTOR Module with SJOne board are given below:

Motor Controller is one of the controllers in the project which is responsible to control the DC and Servo Motor movements, RPM Sensor measurements and LCD control

RPM Sensor, DC and Servo Motor Hardware Interfacing
LCD Hardware Connections



Software Design

<The dc motor and servo motor operation is fundamentally based on PWM (Pulse Width Modulation).> <>

Technical Challenges

<Bullet or Headings of a module>

Unreliable Servo Motors

<Problem Summary> <Problem Resolution>



Geographical Controller

  • GEO CONTROLLER Git Link: [1]

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

Hardware Design

Design and Implementation

  • As name suffice, Master Node acts as the brain of the RC car and gives controlled signals to every other module.
  • It manages the communication among all the modules, including Motor, Sensor, Geographical and Bridge Controller.
  • Master receives periodically data from CAN bus based on message ID of the sender module.
  • Below shows the connection of Master module on CAN bus, connected with CAN Transceiver.
Master-CAN Interfcaing

Software Design

  • Figure illustrates the bus flow from master to every module.
Master Control Flow


Technical Challenges

<Bullet or Headings of a module>

Improper Unit Testing

<Problem Summary> <Problem Resolution>



Mobile Application

Hardware Design

Software Design

1. Enable Bluetooth and Connect to bridge controller

Wireless communication with the car takes places with communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the car parameters.

The android app connects to the HC-05 BLE module of the bridge controller. The Bluetooth ask the user for permission to access location and prompts to enable Bluetooth if it's already OFF. Our app is designed to connect to only TechSavy Bluetooth module and no other Bluetooth device to ease the setup of Bluetooth communication. A Bluetooth adapter connects to the HC-05 module and opens a Bluetooth Socket over which read and write messages are sent. A thread runs in the background which checks for available data, reads it and the data can then be processed. Data is written via the same Bluetooth socket. Refer to the following link to get started with Bluetooth on Android app and connection to HC-05 module ([2]).

Bluetooth app.jpg Location1.jpg

2. Start/Stop Command and Log Sensor values

Start and Stop commands are sent to the RC car via the application. When Start/Stop button is pressed 1 or 0 commands are sent to the bridge controller when then transmits it to the CAN Bus for processing. Bluetooth status, Sensor Values, Motor parameters, GPS location, compass heading angle, distance to the checkpoint is displayed for debugging purpose. Sensor, GPS, motor Messages coming from CAN bus are decoded by the bridge controller and sent to the Android application as a string. The android app parses the string and categorizes the data to store it in appropriate variables. The data is then displayed as a text view in Bluetooth activity. To visit the Map Activity for setting destination and checkpoints a button is added. The map Activity opens on pressing the button.

App log2.jpeg App log.jpeg

3. Map Activity

The map activity is used in our app to show the current location of the car and set the destination marker which the car will navigate too. When map loads in the app the cars current location is indicated coming from the GPS as the source location (Red Marker). The desired location on the map can be set as the destination by long clicking on the map (Light Green marker). The destination can be changed as desired by long pressing again. When the start button is pressed command 1 is sent to the CAN bus via Bluetooth to start the car. A thread starts in the background to indicate the current position of the car when the car moves (light blue marker). Also, a polyline is drawn between the source and destination marker to indicate the direction in which the car will move. For adding Google map to app refer the following [3](Refer to Maps and geolocation section)

Map1.jpeg Checkpoint1.jpg

Technical Challenges

1. We faced the problem of adding Bluetooth functionality in the app. There is a lack of tutorials online which shows how to develop an android app with Bluetooth capability and communicating with the HC-05 module. Fortunately, we found this webpage [4] which helped us and Youtube videos of Coding with Mitch.

2. It was difficult to design the UI on the app with little java and Android experience. We designing UI from mainly two resources [5] [6]and searching online for problems faced by us.

3. Initially, we developed the app such that we had to manually connect to a paired device to use Bluetooth functionality. This gave us problems while sending commands to the bridge controller. We solved this problem by fixing the device connection only to our HC-05 module and adding only a single Bluetooth connection button on the app bar for Bluetooth connection.

4. When we received too much sensor, GPS data from the bridge controller the app crashes. We solved this problem by adding a 1000ms sleep time to limit the input data coming to the app.



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.


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


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

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