Difference between revisions of "S19: Hot Wheels"

Revision as of 22:48, 22 May 2019

TEAM HOTWHEELS

Project Title

Self-driving car

Abstract

Embedded Systems are used to take real world input and covert it into the data that can be processed to monitor,control or obtain desired results. In this project , we aim to design and develop a self-driving car that autonomously navigates from the current location to the destination which is selected through an Android application, avoiding all the obstacles in the path. The car comprises of 5 control units communicating with each other over the CAN Bus, each having different functionality that helps the car to navigate to its destination successfully.

Introduction

The project was divided into 5 modules:

Team Members & Responsibilities

<Team Picture>

Gitlab Project Link - [1]

• Master Controller
  • Kailash Chakravarty

• Sensor Controller
  • Rishabh Sheth

• Motor Controller
  • Kriti Hedau
  • Tahir Rawn

• Geographical Controller
  • Harmeen Joshi
  • Nandini Shankar

• Communication Bridge Controller & Android Application
  • Swanand Sapre
  • Aquib Mulani

• Code Review & Commit Approvers
  • Rishabh Sheth
  • Nandini Shankar
  • Kailash Chakravarty

Schedule

Parts List & Cost

Printed Circuit Board

<Picture and information, including links to your PCB>

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

Gitlab link to your DBC file [3]

VERSION "0.1.0"

BU_: MASTER SENSOR MOTORIO GEO APP

BO_ 220 MOTORIO_CMD: 4 MASTER

SG_ MOTORIO_CMD_Direction : 0|8@1+ (1,0) [0|2] "" MOTORIO

BO_ 210 ULTRA_CMD: 4 SENSOR

SG_ SENSOR_SONARS_FrontDistance : 0|8@1+ (1,0) [2|100] "" MASTER

BO_ 250 DISTANCE: 4 GEO

SG_ DISTANCE_FinalDistance : 0|16@1+ (0.1,0) [0|0] "" MASTER

BO_ 102 BLUETOOTH: 4 APP

SG_ DISTANCE_FinalDistance : 0|16@1+ (0.1,0) [0|0] "" MASTER

CM_ BU_ MASTER "The Master controller of the car";

CM_ BU_ MOTOR "The motor controller of the car";

CM_ BU_ SENSOR "The sensor controller of the car";

CM_ BU_ GEO "The Geo controller of the car";

CM_ BU_ APP "The Bluetooth/App controller of the car";

Sensor ECU

<Picture and link to Gitlab>

Motor Controller

Group Members

• Tahir Latif Rawn
  
• Kriti Hedau
  

Design & Implementation

Hardware Design

Motor Module Schematic

Hardware Specifications

ESC and DC Motor

ESC and DC Motor

The Traxass Slash 4x4 has XL-5 Electronic Speed Controller (ESC) and Titan 12T DC Motor installed in it. The ESC is powered by LiPo Battery which further controls the DC motor. The ESC comes with the feature of calibrating the DC motor using the EZ set button that is present on ESC. It comes with three modes

• Sport mode (100% Forward, 100% Brakes, 100% Reverse)
• Training mode (100% Forward, 100% Brakes, No Reverse)
• Racing mode (50% Forward, 100% Brakes, 50% Reverse)

For our project we used Sport mode because we needed full capability of the motor for uphills and rough terrains. Also we used our ESC in Low-Voltage Detection activated mode. In order to know more about ESC profiles, Battery modes and how to calibrate them, refer to Traxxas official link here [4].

Servo Motor

Traxxas Servo Motor

Servo Motor is responsible for steering the car. Traxxas Slash 4x4 has Servo Motor 2075 pre-installed in it. It controls the front two tires of the car.

RPM Sensor

Traxxas RPM Sensor

RPM sensor is used to calculate speed of the car. A magnet is placed inside the spur gear with the help of magnet holder and every time a tire completes one rotation, RPM sensor detects a pulse. RPM sensor it self is placed in the gear cover. In order get the RPM Sensor working, following Telemetry items from Traxxas are required

• Traxxas RPM Sensor 6522
• Traxxas Magnet Holder 6538
• Traxxas Gear Cover 6537

To install these, there is very detailed step by step tutorial by Steve Jones (Cstoneav) on Youtube which can be found here [5]

Hardware Interface

Software Design

Technical Challenges

Geographical Controller

<Picture and link to Gitlab>

Bold text=== Hardware Design ===

Module Interface

The GEO module primarily consists of two independent hardware modules: the GPS module and the compass module. The GPS module provides the current location of the car as it moves and the compass module provides the heading angle of the car with respect to true north. For the GPS module, we are using Adafruit's "Ultimate GPS Breakout V3" and for the compass module, we are using "CMPS14" module from Robotshop. CMPS14 module uses I2C interface to connect with the SJ-One board whereas, the GPS module is interfaced to SJ-One using UART.

Module Selection

Selecting the appropriate module for both the compass and the GPS sensing were difficult decisions. We initially ordered "GPS - Readytosky Ublox NEO-M8N GPS Module" from Amazon as it came with a stand and an inbuilt compass module. This would have been cheaper as we would save money on the compass module. However, we later found out that the inbuilt compass values were not reliable enough and the GPS in this module was not original Ublox. Original Ublox GPS has an inbuilt flash memory to update its firmware for GPS calibration. We would thus have to rely on the factory calibration for the GPS. After considering all this, we decided to move to better modules as navigation was key for our project's success.

Compass modules are very sensitive to magnetic interference. We selected CMPS14 module as our compass as it has commands to dynamically check the calibration status of the module at runtime. We mapped this calibration status value to the 7-segment display on the SJ-one board which proved to be very useful in detecting magnetic interference across the campus and take decisions accordingly. Note however that CMPS14 does not return the current gyro calibration status. This is a bug which is mentioned in its data sheet. For the GPS module, we went with Adafruit's Ultimate GPS breakout module as it is known for its reliable GPS values.

CMPS14 Commands

CMPS14 Start Calibration Process

To start the compass calibration, write the following to the command register 0x98, 0x95, 0x99 with a 20 millisecond delay after each byte. You can then send the setup byte to the command register. It takes the form:

Switch 1 dedicated for this purpose.

CMPS14 End Calibration Process

To end the calibration and store the updated calibration profile in CMPS14, write the following byte sequence to the command register with a 20 millisecond delay after each of the three bytes: 0xF0, 0xF5, 0xF6 Switch 4 dedicated for this purpose.

CMPS14 Erase Calibration Profile

To erase the stored calibration profile in CMPS14, write the following byte sequence to the command regiester with a 20 millisecond delay: 0xE0, 0xE5, 0xE2 . Switch 3 dedicated for this purpose.

Software Design

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

Technical Challenges and Solutions

1. Calibrating Compass module

   The compass module was not giving stable values on default calibration.
   
   The compass north changed every time the module powered off.
   
   The compass value would change after a full 360-degree rotation.
   
   The compass value moved up on tilting the module.

Solution:

   Step 1: Keep the compass stable on the ground to calibrate the gyro sensor.
   
   Step 2: Now, randomly move the module to calibrate the magnetometer.
   
   Step 3: After this, tilt the compass module in all directions and slowly move the module 360-degrees clockwise and anti-clockwise
           to calibrate the accelerometer.
   
   Make sure the calibration status of the respective in-built sensor reaches the maximum value of 3 on each of the above steps.
   
   Note: Compass is best calibrated in a non-magnetic environment. To check the magnetism in any area, use a mechanical (magnetic)compass.
   
   Note: There are underground electrical lines spread throughout the university which cause magnetic interference in the compass module.
         We found 10th street parking, 6th floor to be a good spot for testing and calibrating compass and GPS module.

2. Compass Calibration Unreliable

   After calibrating the compass, the calibration status was changing at runtime due to magnetic interference from the ground and shaking of the car.

Solution:

   Mapped system calibration status to on-board 7-segment display to keep track of the compass calibration at run-time and provided dedicated switches
   to start calibration, end calibration and erase calibration profile. This allowed us to perform instant re-calibration of the compass
   if the calibration is affected.
   
   Also provided dedicated switch to add offset to the compass value.
   This enabled us to set true North according to the mechanical compass in high magnetic interference areas.

3. Magnetic Interference from Motor

   Unlike interference from the ground and underground electrical lines, interference from car motors was causing the compass value to
   
   increment even when the car was not moving. This interference increased as the car speed increased.

Solution:

   To avoid this interference, we magnetically shielded the car's DC motor. To achieve this, we simply covered the motor with aluminum foil.
   This significantly reduced the magnetic interference to the compass from the motor.
   
   Note: There is no known material that blocks magnetic fields without itself being attracted to the magnetic force. Magnetic fields can only be redirected,
   not created or removed. The magnetic field cannot be completely blocked. Magnetic shielding can be done by any material which absorbs magnetism

Unreliable GPS lock

<Problem Summary> <Problem Resolution>

Communication Bridge Controller & LCD

User communicates with the car through the Communication Bridge Controller. This module consists of the LPC1758 communicating with the Android application on the phone via Bluetooth.The user selects the final destination on the google map to which the car should navigate, through an android application. The Android application also works as a display where it displays the recorded values of the ultrasonic sensors, the current latitude and longitude, the bearing angle, and the compass values for the car.

<Picture and link to Gitlab>

The Hardware and the Software details are given below:

Hardware Design

Software Design

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

get_gps_data(); compass_get_heading(); compass_get_heading()

Technical Challenges

<Bullet or Headings of a module>

Insane Bug

<Problem Summary> <Problem Resolution>

Master Module

<Picture and link to Gitlab>

Hardware Design

The Master controller only has the connections to the CAN bus apart from power supply. Below diagram describes the connections.

Software Design

• The Master control unit is the heart of the Self driving car as it takes all the critical decisions based on inputs it receives

from the other control units like App, Sensor, Geo and drives outputs which is the Motor control Unit.

• The Master control unit mainly performs Navigation of the car to the selected desination and Obstacle avoidance as and when they

come in the car's way.

• For navigation to the destination through numerous checkpoints, the bearing angle, heading angle and the distance to destination

is provided by the GEO control. The App control provides the start and stop command.

• The Sensor control provides the ultrasonic

sensor values of the 4 sensors

• The Master control unit algorithms - Navigation and Obstacle avoidance are run @25Hz. The detailed flowcharts are shown below.

Master control Algorithm

Obstacle avoidance Algorithm

Navigation Algorithm

Technical Challenges

<Bullet or Headings of a module>

Improper Unit Testing

Problem : It was tedious to tune the proximity thresholds for the 4 sensors for proper obstacle avoidance, because it involved changing them, build them, flash them and test again and again till we get fine tuned results. This was time and effort consuming.

Resolution : I placed a CAN debug message in the code to write directly into the threshold variables, via PCAN dongle and bussmaster whenever I want. So basically I change the thresholds anytime within seconds and immediately test.

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