Difference between revisions of "S19: Mystery Machine"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Implementation)
(Implementation)
Line 1,006: Line 1,006:
 
|[[File:Mystery_Android2.jpeg|thumb|250px|center|thumb|Marking a spot on map]]
 
|[[File:Mystery_Android2.jpeg|thumb|250px|center|thumb|Marking a spot on map]]
 
|[[File:Mystery_Android1.jpeg|thumb|250px|right|thumb|App waiting for connections]]
 
|[[File:Mystery_Android1.jpeg|thumb|250px|right|thumb|App waiting for connections]]
|[[File:Mystery_Android_GIF.gif|300px|right|thumb|Sending GPS data]]
+
|[[File:Mystery_Android_GIF.gif|300px|right]]
 
|}
 
|}
  

Revision as of 02:15, 24 May 2019

Mystery GIF


Team Car
Team Car

Abstract

Team Car


Recent advances in object scanning technologies and proliferation of self-navigating techniques have created new opportunities for developing autonomous vehicles which would reduce operation cost, improve safety and reliability enabling paratransit service. A cutting edge self-navigating vehicle consisting of several embedded system paradigms in coherence with each other has been presented by a team of avid automotive enthusiasts implemented using a highly Test Driven Development approach.

This project demonstrates plurality of concepts related to autonomous vehicles which are capable of precepting and reacting to ever-changing surroundings in real time. It comprises of several interconnected ECUs communicating over the CAN bus where each module has specific roles which are GPS navigation, perception, mobility cloud-based telemetry and master controller which will process data from all the modules and make intelligent decisions for enhanced control. This shall enable the car to navigate autonomously to the required destination which the user can remotely enter from the smartphone application. After which the car shall use the stipulated algorithm to calculate the shortest possible path to navigate towards the end point. While maneuvering through all kind of terrains the car will avoid any unexpected obstacles and notify the user on the smartphone application when it reaches the checkpoint and final destination.

Introduction

The objective of this project was to create an autonomous self-driving car which was able to reach the target destination while avoiding obstacles through the terrain. In order to accomplish this, five SJ One boards were used that handled separate functionality of the car:

  • Master Controller
  • Sensor Controller
  • Geo Controller
  • Bridge Controller
  • Android Application
  • Motor and Steering Controller

Team Members & Responsibilities

Gitlab Project Link

  • Sanket Patil
    • Bridge Controller [SPOC]
    • Hardware integration and PCB [SPOC]
  • Tarun Chawla
    • Motor and Steering Controller [SPOC]
    • Geo Controller
  • Rachit Mathur
    • Motor and Steering Controller
    • Documentation [SPOC]


Schedule

Week# Start Date End Date Task Status
1
  • 02/22/2019
  • 02/22/2019
  • 02/22/2019
  • 02/22/2019
  • 02/22/2019
  • 03/01/2019
  • Read previous projects, gather information and discuss among the group members.
  • Assign team responsibilities for each module.
  • Analysis of component required for each module
  • Completed
  • Completed
2
  • 03/01/2019
  • 03/01/2019
  • 03/01/2019
  • 03/01/2019
  • 03/01/2019
  • 03/01/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • Project plans and timelines discussed
  • Android Application: Upload Project to GitLab and Plot Route to destination with dummy location
  • Bridge Controller: Establish access point and STA mode on ESP8266
  • Motor Controller: Understand the working of Electronic Speed Controllers and study previous project reports
  • Sensor Controller: Decide and order the sensors required for Obstacle Avoidance
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
3
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/10/2019
  • 03/15/2019
  • 03/15/2019
  • 03/13/2019
  • 03/15/2019
  • Order the RC car and the required peripherals
  • Android Application: Create base android project with map and display activities
  • GPS Controller: Create an algorithm for the navigation system
  • Bridge Controller: Implementation of basic lightweight web server for WiFi configuration using GUI
  • Motor Controller: Work on the ESC of the RC car and develop algorithm for the Steering Control
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
4
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • 03/15/2019
  • Android: Get access tokens for Google API to enable maps in the application
  • GPS Controller: Get raw values from MPU9150 IMU sensor
  • Bridge Controller:Implementation of mDNS protocol for discovery of device on local subnet
  • Motor Controller: Tap into the servo motor controlling the steering
  • Completed
  • Completed
  • Completed
  • Completed
5
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/08/2019
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • Android: Embed Google maps onto the Android App and add the project to the git repository
  • GPS Controller: Implement driver to get filtered values from the IMU
  • Bridge Controller: Implementation of local MQTT Broker on ESP8266 and Cloud broker on EC2 Instance
  • Pin Layouts from all groups
  • Motor Controller: Tap into the in-built ESC and overclock
  • Completed
  • Completed
  • Completed
  • Completed
6
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • 03/22/2019
  • 03/29/2019
  • 03/29/2019
  • 03/29/2019
  • 03/24/2019
  • 03/29/2019
  • GPS Controller: Send and receive coordinates and other parameters between Car and application
  • PCB layout 1st Iteration
  • Bridge Controller: Configure ESP8266 (as Wifi-to-serial bridge) to receiver data over Wifi and push it on UART
  • Motor Controller: Find suitable Motor Driver Module and place an order
  • Sensor Controller: Experiment with the different sensors to check for which type works best for the RC Car
  • Completed
  • Completed
  • Completed
  • Completed
7
  • 03/29/2019
  • 03/29/2019
  • 03/29/2019
  • 03/29/2019
  • 04/05/2019
  • 04/07/2019
  • 04/05/2019
  • 04/05/2019
  • GPS Controller: Send and receive coordinates and other parameters between Car and appS
  • Bridge Controller: Program for MQTT Client to UART link on ESP8266 module
  • Motor Controller: Find optimal Frequency and PWM values to drive Steering and Rear Wheels
  • Sensor Controller: Obstacle detection with SJ One board
  • Completed
  • Completed
  • Completed
  • Completed
8
  • 04/05/2019
  • 04/05/2019
  • 04/05/2019
  • 04/05/2019
  • 04/05/2019
  • 04/05/2019
  • 04/09/2019
  • 04/09/2019
  • 04/12/2019
  • 04/12/2019
  • 04/12/2019
  • 04/10/2019
  • Android: Read the current position and get user input for the destination
  • GPS Controller: Get GPS and COMPASS readings and parse them
  • Bridge Controller: MQTT to UART to CAN Bus Link and Bridge Controller MQTT to Android application Connection Link
  • Master Controller: Define and acquire DBC messages intended for master
  • Motor Controller: Implementation of basic maneuvering of the RC car
  • Sensor Controller: Integration with the RC Car and distance calculation
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
9
  • 04/12/2019
  • 04/12/2019
  • 04/12/2019
  • 04/12/2019
  • 04/12/2019
  • 04/12/2019
  • 04/16/2019
  • 04/16/2019
  • 04/16/2019
  • 04/16/2019
  • 04/16/2019
  • 04/16/2019
  • Android: Configure the UI elements for live monitoring in the app.
  • GPS Controller: Get the destination and waypoints from the Bridge Controller
  • Bridge Controller: Define messages and MQTT topics for bridge to app communication
  • Master Controller: Create a simple program to instruct motor ECU to drive and acquire sensor values to send stop instruction to motor ECU
  • Motor Controller: Implementation of RPM Sensor and integration with CAN Bus
  • Sensor Controller: Final Testing
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
10
  • 04/19/2019
  • 04/19/2019
  • 04/19/2019
  • 04/19/2019
  • 04/19/2019
  • 04/23/2019
  • 04/23/2019
  • 04/23/2019
  • 04/23/2019
  • 04/23/2019
  • Android: Define the message parameters and packing format for communication between car and app and plot the waypoints for the given coordinates
  • GPS Controller: Calculate Bearing and send navigation instructions to the Master
  • Bridge Controller: Encapsulation and parsing the data from MQTT payload
  • Master Controller: Receive navigation instructions from the GPS Controller and move the car accordingly
  • Motor Controller: Fine tuning of Speed Control and Steering control using PWM duty cycle levels
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
11
  • 04/26/2019
  • 04/26/2019
  • 04/26/2019
  • 04/26/2019
  • 04/26/2019
  • 05/02/2019
  • 05/04/2019
  • 04/30/2019
  • 05/04/2019
  • 05/01/2019
  • Android: Send coordinates to Car
  • GPS Controller: Mount on the car and start testing on the field and make final changes accordingly
  • Bridge Controller: Update debug messages
  • Master Controller: Implement algorithm and avoid obstacles while maintaining bearing angles as provided by Geo Controller
  • Motor Controller: Optimize control by accelerating / decelerating as instructed by Master Controller
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
12
  • 05/03/2019
  • 05/03/2019
  • 05/03/2019
  • 05/03/2019
  • 05/03/2019
  • 05/06/2019
  • 05/17/2019
  • 05/10/2019
  • 05/06/2019
  • 05/06/2019
  • Android: Add additional commands to the app (stop, reset, reroute)
  • GPS Controller: Final system testing
  • Bridge Controller: Display interfacing and final Testing
  • Master Controller: Final testing and handling of corner cases
  • Motor Controller: Final Testing
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
13

05/10/2019

05/14/2019

Design and implementation of exterior body

Completed

14

05/17/2019

05/18/2019

Resolve any issues before Final Demo

Completed

15

05/22/2019

05/22/2019

FINAL DEMO

Completed

Parts List & Cost

Item# Part Desciption Vendor Qty Cost
1 RC Car Amazon 1 $90.00
2 CAN Transceivers MCP2551-I/P AliExpress 5 $1.13/piece

Design and Interface

Mystery Machine Design



CAN Communication

Hardware Design

Hardware-Interfacing


System Nodes: SENSOR, MOTOR, GEO, BRIDGE, MASTER


CAN(Controlled Area Network) is a Broadcast Bus which is heavily used in automotive industry. It defines protocol and hardware interface. It operates in standard baudrates like 100k, 125k, 250k, 500k or 1M bps. CAN uses half duplex communication over differential pair. The number of nodes affect the cable length because more CAN transeives add more capacitance to the bus.

An MCU can be interfaced to CAN bus using CAN transceiver and terminated on each end with 120 ohm resistors. Resisters are used to avoid signal reflexion. CAN is frame based communication where each frame contains ID, length(DLC), and up to 8 data bytes.Message ID field can be 11-bit or 29-bit. Only one transmitter can transmit at a time which has highest priority will go ahead first. Low priority message ID's will back-off.Lower message ID wins i.e zero is dominant.

Each node asserts an ACK if it receives a good frame. Software may or may not accept the frames. If no one ACKS, then the message is retransmitted. Depending on the CAN specifications retransmission error can be send and can eventually lead to "Bus off" state.

DBC File

DBC File

BU_: DBG DRIVER MASTER IO MOTOR SENSOR LIGHT BRIDGE GEO GATEWAY

BO_ 600 SONAR_SENSOR_VALUES: 4 SENSOR
 SG_ SONAR_SENSOR_VALUES_Left_Sensor : 0|9@1+ (1,0) [0|300] "cm" BRIDGE,MASTER
 SG_ SONAR_SENSOR_VALUES_Right_Sensor : 9|9@1+ (1,0) [0|300] "cm" BRIDGE,MASTER
 SG_ SONAR_SENSOR_VALUES_Front_Sensor : 18|9@1+ (1,0) [0|300] "cm" BRIDGE,MASTER

BO_ 601 DEMO_IR_SENSOR: 6 SENSOR
 SG_ LEFT_SENSOR : 0|16@1+ (1,0) [0|0] "LEFT_VALUES" MASTER
 SG_ RIGHT_SENSOR : 16|16@1+ (1,0) [0|0] "RIGHT_VALUES" MASTER
 SG_ FRONT_SENSOR : 32|16@1+ (1,0) [0|0] "FRONT_VALUES" MASTER

BO_ 602 SONAR_SENSOR_THRESHOLD: 3 BRIDGE
 SG_ UPDATE_THRESHOLD_VALUE_Left : 0|8@1+ (1,0) [0|0] "cm" MASTER
 SG_ UPDATE_THRESHOLD_VALUE_Right : 8|8@1+ (1,0) [0|0] "cm" MASTER
 SG_ UPDATE_THRESHOLD_VALUE_Front : 16|8@1+ (1,0) [0|0] "cm" MASTER

BO_ 603 STEER_CMD: 1 SENSOR
 SG_ SENSOR_STEER_DIRECTION : 0|8@1+ (1,0) [0|0] "DIRECTION" MASTER,BRIDGE

BO_ 604 SONAR_REVERSE_SENSOR: 2 SENSOR
 SG_ SONAR_REVERSE_SENSOR_value : 0|9@1+ (1,0) [0|300] "cm" BRIDGE,MASTER

BO_ 700 MOTOR_SPEED: 1 MASTER 
 SG_ MOTOR_SPEED_speed_in_mps : 0|8@1+ (0.01,0) [0|2] "mps" MOTOR,BRIDGE

BO_ 701 STEER_DIRECTION: 2 MASTER
 SG_ STEER_DIRECTION_ANGLE : 0|16@1- (1,0) [0|0] "ANGLE" MOTOR,BRIDGE

BO_ 702 DEMO_STEER_DIRECTION: 2 MASTER
 SG_ STEER_DUTY_CYCLE_VAL : 0|8@1+ (0.01,0) [0|0] "DUTY_CYCLE" MOTOR,BRIDGE

BO_ 703 DEMO_MOTOR_SPEED: 2 MASTER
 SG_ MOTOR_SPEED_DUTY_CYCLE : 0|8@1- (1,0) [-127|127] "DUTY_CYCLE" MOTOR,BRIDGE

BO_ 704 MOTOR_FLAG: 1 MOTOR
 SG_ REVERSE_FLAG : 0|8@1+ (1,0) [0|0] "MOTOR_FLAG" MASTER,BRIDGE

BO_ 740 COMPASS_DATA: 2 GEO
 SG_ COMPASS_HEADING_ANGLE : 0|9@1+ (1,0) [0|0] "DEGREES" MASTER,BRIDGE

BO_ 750 GPS_DATA: 8 GEO
 SG_ GPS_LOCK : 0|1@1- (1,0) [0|0] "" MASTER,BRIDGE
 SG_ CURRENT_GPS_COORDINATES_X : 8|28@1- (0.000001,0) [36.000000|38.000000] "" MASTER,BRIDGE
 SG_ CURRENT_GPS_COORDINATES_Y : 36|28@1- (0.000001,0) [-122.000000|-120.000000] "" MASTER,BRIDGE

BO_ 751 TELEMETRY: 8 GEO
 SG_ DISTANCE_TO_DEST : 0|8@1+ (1,0) [0|0] "" MASTER,BRIDGE

BO_ 790 MASTER_HEARTBEAT: 1 MASTER
 SG_ HEART_BEAT : 0|8@1+ (1,0) [0|0] "MASTER_HEARTBEAT" BRIDGE

BO_ 800 APP_CMD: 2 BRIDGE
 SG_ START_COMMAND : 0|8@1+ (1,0) [0|0] "" MASTER
 SG_ ABORT_COMMAND : 8|8@1+ (1,0) [0|0] "" MASTER

BO_ 805 WHEEL_ENCODER: 1 MOTOR
 SG_ WHEEL_ENCODER_data : 0|7@1+ (1,0) [0|0] "" MASTER,BRIDGE

BO_ 810 APP_DESTINATION_GPS: 8 BRIDGE
 SG_ DEST_GPS_COORDINATES_X : 0|28@1+ (0.000001,0) [0|0] "" GEO
 SG_ DEST_GPS_COORDINATES_Y : 28|28@1+ (0.000001,0) [0|0] "" GEO

BO_ 909 SENSOR_TRIGGER: 1 SENSOR
 SG_ SENSOR_TRIGGER_Trigger_status : 0|1@1+ (1,0) [0|1] "" BRIDGE

BO_ 908 SENSOR_INIT: 1 SENSOR
 SG_ SENSOR_INIT_init_Status : 0|1@1+ (1,0) [0|1] "" BRIDGE

BO_ 910 SENSOR_TIMEOUT: 1 SENSOR
 SG_ SENSOR_TIMEOUT_left : 0|1@1+ (1,0) [0|1] "" BRIDGE
 SG_ SENSOR_TIMEOUT_center : 2|1@1+ (1,0) [0|1] "" BRIDGE
 SG_ SENSOR_TIMEOUT_right : 3|1@1+ (1,0) [0|1] "" BRIDGE
 SG_ SENSOR_TIMEOUT_reverse : 4|1@1+ (1,0) [0|1] "" BRIDGE

BO_ 911 LEFT_SENSOR_ECHO_TIME: 2 SENSOR
 SG_ LEFT_SENSOR_ECHO_TIME_left_calculation_time : 0|16@1+ (1,0) [0|0] "us" BRIDGE

BO_ 912 RIGHT_SENSOR_ECHO_TIME: 2 SENSOR
 SG_ RIGHT_SENSOR_ECHO_TIME_right_calculation_time : 0|16@1+ (1,0) [0|0] "us" BRIDGE

BO_ 913 CENTER_SENSOR_ECHO_TIME: 2 SENSOR
 SG_ CENTER_SENSOR_ECHO_TIME_center_calculation_time : 0|16@1+ (1,0) [0|0] "us" BRIDGE

BO_ 917 REVERSE_SENSOR_ECHO_TIME: 2 SENSOR
 SG_ REVERSE_SENSOR_ECHO_TIME_reverse_calculation_time : 0|16@1+ (1,0) [0|0] "us" BRIDGE

BO_ 914 TOTAL_SENSOR_CALCULATION_TIME: 4 SENSOR
 SG_ TOTAL_SENSOR_CALCULATION_TIME_total_time : 0|32@1+ (1,0) [0|0] "us" BRIDGE

BO_ 915 PERIODIC_SCHEDULER_INIT: 1 SENSOR
 SG_ PERIODIC_SCHEDULER_INIT_scheduler_init_status : 0|1@1+ (1,0) [0|1] "" BRIDGE

BO_ 916 DBG_SENSOR_THRESHOLD: 4 MASTER
 SG_ THRESHOLD_VALUE_Left : 0|8@1+ (1,0) [0|0] "SONAR_DBG" BRIDGE
 SG_ THRESHOLD_VALUE_Right : 8|8@1+ (1,0) [0|0] "SONAR_DBG" BRIDGE
 SG_ THRESHOLD_VALUE_Front : 16|8@1+ (1,0) [0|0] "SONAR_DBG" BRIDGE
 SG_ THRESHOLD_VALUE_Reverse : 24|8@1+ (1,0) [0|0] "SONAR_DBG" BRIDGE

BO_ 921 SPEED_CMPS: 1 MOTOR
 SG_ SPEED_CMPS_car : 0|7@1+ (1,0) [0|0] "CAR SPEED IN CM/S" MASTER,BRIDGE

BO_ 926 MOTOR_DUTY: 1 MOTOR
 SG_ MOTOR_DUTY_CYCLE : 0|7@1+ (1,0) [0|1] "" MASTER,BRIDGE

BO_ 922 ROTATIONS_PER_SECOND: 1 MOTOR
 SG_ ROTATIONS_PER_SECOND_WHEELS : 0|7@1+ (1,0) [0|0] "CAR SPEED IN ROTATIONS/SECOND" MASTER,BRIDGE

BO_ 923 STEER_DUTY_LEFT: 1 MOTOR
 SG_ DUTY_CYCLE_LEFT : 0|7@1+ (1,0) [0|1] "" MASTER,BRIDGE

BO_ 924 STEER_DUTY_RIGHT: 1 MOTOR
 SG_ DUTY_CYCLE_RIGHT : 0|7@1+ (1,0) [0|1] "" MASTER,BRIDGE

BO_ 925 STEER_DUTY_CENTRE: 1 MOTOR
 SG_ DUTY_CYCLE_CENTRE : 0|7@1+ (1,0) [0|1] "" MASTER,BRIDGE


Bus Master


Bus Master Graph

Sensor ECU

Sensor ECU

Ultrasonic sensors are great tools to measure distance without actual contact. Basic principal of ultrasonic distance measurement is based on ECHO and Trigger pins. Trigger pin is used to TRIGGER the sonar wave to ECHO through deflection. ECHO goes high as soon as it sends Sonar wave. Once it receives the wave the ECHO pin will go low. We will measure this ECHO HIGH period and use to calculate the distance.

Sensor Timing Diagram
HC-SR04


Hardware Design

For object detection we are using ultrasonic sensors, three in the front (LEFT, RIGHT and CENTER) and one behind to measure the distance of each object. If an object is present in front of the sensors' general direction, sonor signals hits the object and reflects back. The sensor each have a specific threshold beyond which the car is supposed to react and avoid obstacles by altering the direction of travel.


Hardware Interface

The trigger pin is common since all the sensors are activated at the same time. Echo in are individual and processed in parallel.The CAN connections are same as every other module.

Hardware Interface
Physical connection


In order to raise the sensor at a height decent enough to detect obstacles directly ahead of the RC car, we designed custom 3D printed mounts for all the sensors. These stand provided a rigid support for these sensors as well as ensured that the sensors would survive an accidental head-on crashes.

Screenshots of these custom mounts can be seen along side.

Sensor Mount


Software Design

Sensors are calculated over in 10hz periodic task and sent to master module by use of the CAN connections between them every 20hz or 50ms period. All sensors are triggered simultaneously and calculated sequentially. GPIO protocols are used to set pins high or low. 8ms timeout is implemented for each sensors to avoid task overrun.

Software Design


Implementation

In 100 Hz, Through the GPIO pin TRIGGER signal is sent and waits fro the ECHO signal to be created . If the timeout function runs out before the Echo completes the minimum distance is said to be obstacle free. If not the time taken for the signal to go high and then low is calculated with respect to speed of sound.

In 20 Hz, the data is sent through the CAN messages from the sensor module to the master and Bridge module.

Pseudo Code:

void 10hz_task(int count){
    initialize the sensors;
    Reset_flags;
    Trigger each sensors;
    calculate the distance;
    if( timeout){
          capture current value;
          set flags;
    }
    send distance values over can;
}

Technical Challenges

Initially we went with sharp 2YOA21 IR sensor to obtain better precision. But the range of the sensor was 48cm which was not reliable distance for obstacle detection. We upgraded to an Ultrasonic sensor which had trouble with echo reception due to faulty firmware code.

Unreliable sonor sensors

We upgraded to an Ultrasonic sensor HC-SR04 which had a better range of around 200cm with reliable precision. There was some faulty firmware code in the ultrasonic sensor due to which echo pin did not receive the signal for a long duration of time. We had 3 Ultrasonic sensors working together and each received other's echo signals sometimes due to reflection.

Solution

To solve the reflection problem, we elevated the sensor position and changed the direction of the sensor. To solve the faulty firmware, we introduced a timeout of 8ms in the code and if we don't receive the echo pulse within the timeout, it will give a distance of 110cm corresponding to 8ms.



Motor ECU

Motor ECU

DC Motor

Our car arrived with an in-built Electronic Speed Controller(ESC) that was responsible for controlling the steering servo motor and running the DC motor attached to the rear wheels. Along with the motor control, the ESC was also embedded with a receiver for the remote control that shipped with the car.

We realized that the ESC could not be tapped into by providing an external signal to the pin-heads available on the exterior. This external signal from a function generator gave unsatisfactory results when passed through the ESC but we did conclude the optimal frequencies at which both the motors worked satisfactorily.

A motor controller module was used for driving the DC motor. We experimented with the frequency input to the motor driver to run the motor at and found that it operated best at a high frequency of 4KHz.

DC Forward Signal
DC Reverse Signal


Servo Motor

The servo motor was connected directly to the GPIO ports of the SJ One board.

PWM for Turning Left
PWM for Moving Straight


PWM for Turning Right


After applying an external PWM signal to the servo, we concluded that the servo motor was designed to work smoothly on 80Hz frequency. Accordingly, accurate values of the duty cycle were noted to get precise angles of the steering.

Encoder Sensor

As part of speed feedback, we designed a custom encoder wheel between an encoder sensor mounted on the rear wheel shaft.

3D printed Wheel Encoder
Motorola MOC-70T3


The wheel has a finite number of spokes which when intercepted by the encoder receiver, an interrupt signal is sent to denote one complete rotation.

These detected number of rotations were passed into a formula that calculates the wheel speed in cm/s.

As part of the feedback, if the calculated wheel speed was not equivalent to the constant speed the PWM duty cycle was either increased or decreased to match the target.

A special scenario was also taken into consideration. If the speed of the wheel continued to remain zero after increasing the PWM duty cycle to the Maximum defined limit, then a reverse logic was called.

This case helped us in overcoming obstacles that were underneath the car and were initially not detected by the sensors.

Hardware Design

Motor Hardware Interfacing

Software Design

Software Interface

Technical Challenges and Solutions

  • The primary challenge in the motor module was tapping into the ESC of the car but that was soon replaced by a Motor Driver module.
  • While trying to run the motor driver module at a lower frequency of around 500Hz, we faced an issue of 'heat lock' where after 10 minutes the motor driver module would cut off the supply to the DC motor due to excessive heating. To fix this, we concluded that the motor driver module that we ordered worked best at a higher frequency upwards of 1KHz.
  • We also learned about the limitation of the SJ One board in providing two PWM signals at different frequencies. To solve this, we temporarily attached the steering control with the Master Controller.




Geographical Controller

Geographical ECU

The Geographical controller is responsible for navigating the car in the direction of destination selected in the android app. It uses GPS module which gives the current location of the car and compass module for getting the heading angle of the car. After a destination location is selected in the android app, using the shortest path algorithm, the app generates a particular number of check points. These check points are then sent to Bridge controller. Now Bridge controller sends one check point at a time to the Geographical controller. Geo controller uses its current location and the destination location(check point) to calculate the bearing angle and the distance to the destination. Subsequently, heading angle and bearing angle are used to determine the angle that the car should turn, and is sent to the master module. On reaching destination, the car will stop.

Hardware Design

Two modules are used in Geograpgical controller: GPS and Compass

GPS

Ublox NEO-7M GPS Module is used for detecting the location of the car. This module returns NMEA string which need to be parsed to get lock, latitude and longitude values from the module. To use the GPS string first we need to get lock.

COMPASS

The MPU-9150 is the first integrated 9-axis MotionTracking device that combines a 3-axis MEMS gyroscope, a 3-axis MEMS accelerometer, a 3-axis MEMS magnetometer and a Digital Motion Processor hardware accelerator engine. The MPU9150’s 9-axis MotionFusion combines acceleration and rotational motion plus heading information into a single data stream for the application.

The MPU-9150 features three 16-bit analog-to-digital converters (ADCs) for digitizing the gyroscope outputs, three 16-bit ADCs for digitizing the accelerometer outputs and three 13-bit ADCs for digitizing the magnetometer outputs. For precision in tracking of both fast and slow motions, the parts feature a user programmable gyroscope full-scale range of ±250, ±500, ±1000, and ±2000°/sec (dps), a user programmable accelerometer full-scale range of ±2g, ±4g, ±8g, and ±16g, and a magnetometer full-scale range of ±1200µT.

Communication with all registers of the device is performed using I2C at 400 kHz.

GPS Module
MPU-9150

Hardware Design

GPS module is interface over UART:

GPS pins SJOne Board
TX P0.0
RX P0.0
GND GND
VCC 3.3v

Compass module is interfaced over I2C:

Compass pins SJOne Board
SDA P0.0
SCL P0.0

Software Design

Team Car

Flowchart

Mystery Geo.jpeg

Implementation

The current latitude and longitude position are obtained from GPS module and destination latitude and longitude should be received from the Bridge ECU over CAN bus. Then calculate the closest checkpoint with respect to the destination.We need to calculate the turn angle required so as to align with the checkpoint. Once the car is aligned with the destination, constantly check if the car is aligned with the destination using bearing and heading. Once the car is in 1 meter of range of checkpoint start moving towards the next checkpoint until the destination is reached.

The parameters required for navigation are:

Bearing Angle - the angle between the destination and our current location with respect to the North. The formula for the bearing is provided over here

Heading Angle- The angle with respect to the North in degrees. Received from compass module.

Angle to turn: We need to compute the angle that the car has to turn from its current heading to the bearing so as to align with the destination. Based on turn angle a steering value is selected so the car can align with the destination.

Distance Calculation- The distance between the destination and current coordinates by using the Haversine formula. The details about Haversine formula is available over here

Technical Challenges

Problem Summary:

  • GPS data parsing issue: the GPS data would not be parsed because of timing issues.
  • Compass values: The compass values were incorrect by 10 degrees or more.
  • Checkpoint navigation: Deciding which checkpoint to go first so as to reach the destination with minimum distance. The returned values were not always desired.

Problem Resolution

  • GPS data parsing issue: Calculate the time required to fill the UART buffer so that 10Hz task can use this buffer so as to parse it.
  • Compass values: Implemented tilt compensation algorithm. The values received were very accurate.
  • Checkpoint navigation: Took checkpoints every 15 meters.


Communication Bridge Controller

Bridge ECU

Design and Implementation

The main purpose of bridge controller is to establish communication from inter-modular CAN bus of the car to the smartphone application that connects to the bridge controller wirelessly via Wifi. After evaluating several options for communication module, ESP8266 was found to be most suitable to meet our practical requirements and usability for communication bridge. Wifi offers several advantages over bluetooth like better range, high speed and reliable communication without any data loss with low power consumption. It also supports multiple nodes with simultaneous connections where multiple users can monitor or control the car.

Hardware Interface

ESP8266 uses 3.3V DC power from SJone board. RX is connected to the TXD2 pin and the TX is connected to the RXD2 on the SJOne board for UART communication. It uses transmission rate of 115200bps that offers high speed communication capability.

ESP8266 Interface

ESP8266 Specifications

  • WiFi 2.4 GHz, support WPA/WPA2, 802.11 b/g/n
  • Integrated low power 32-bit MCU
  • Integrated TCP/IP protocol stack
  • Integrated TR switch, balun, LNA, power amplifier and matching network
  • Integrated PLL, regulators, and power management units
  • Support STA/AP/STA+AP operation modes
  • SDIO 2.0, (H) SPI, UART, I2C, I2S, IR Remote Control, PWM, GPIO
  • STBC, 1x1 MIMO, 2x1 MIMO
  • Deep sleep power <10uA, Power down leakage current < 5uA
  • Wake up and transmit packets in < 2ms
  • Standby power consumption of < 1.0mW (DTIM3)
  • +20 dBm output power in 802.11b mode
  • Operating temperature range -40C ~ 125C

Software Design

Flowchart

Bridge Flowchart


MQTT Protocol

MQTT protocol was chosen as the communication protocol between the android application since it is very light weight and is designed to support multiple nodes. For establishing the connection via MQTT an MQTT broker has to be implemented to which the clients can connect and start communicating. The MQTT protocol provides a lightweight method of carrying out messaging using a publish/subscribe model. Multiple clients can connect publish and subscribe to predefined topics to share data amongst each other. This makes it suitable for embedded systems application messaging like low power sensors or mobile devices such as phones, embedded computers or microcontrollers.

Server Setup

A local MQTT server was implemented using uMQTT library on the ESP8266 which allows the MQTT client to directly connect the car without any internet connection. The mobile application can connect directly to wifi module and establishes a connection to the MQTT server. Another cloud based server has been set up on Amazon EC2 instance using Eclipse mosquitto, an open source MQTT broker. This enable the user to remotely connect and operate the car from anywhere over internet. Additionally, local HTTP webserver has been implemented to make user operation smartphone platform agnostic.

Available network
Connected to network
AP mode

Messaging Scheme

The data transfer in MQTT is done via topic scheme, where when a client has to send a message it has to publish the message with a topic. The communication takes place by a set of predefined topics which each of the clients listen to and publish their message. The client has to subscribe to topics to be able to receive the messages. Whenever a client publishes a message on a topic, every client subscribed to that topic will receive the message. The clients are not directly connected but in turn connected via the MQTT broker. Following is the messging scheme used for communication between the bridge controller and smartphone application.

Message Format & Topics for Bridge & App

Message Format

Data received from the car:

  • Subscribe to Topic: HB
    • Heartbeat msg (Detect the connection status with 3 sec timeout) <HB:XXXX>
    • WHB : Wifi Heartbeat <WHB:XXXX>
    • MHB : Master Heartbeat <WHB:XXXX>
    • MTS : Motor Speed <MTS:XXXX>
    • STD : Steering Direction <STD:XXXX>
    • GPC : Current Location GPS Coordinates <GPC:XX.XXX|XX.XXX>
    • TX : All debug messages

Commands/Data to be sent from the App

  • Publish on Topic: RX
    • GO Command <GO1>
    • ABORT Command <GO0>
    • Destination GPS Coordinates <GPD:XX.XXX|XX.XXX>
    • Waypoints GPS Coordinates with waypoint number <GPW:XX|XX.XXX|XX.XXX>


The message inside each topic is again formatted as below: “<COMMAND:value1|value2|value3”> Here the COMMAND is formatted as shown above. Each of these messages can have n number of values in them depending upon the type. For example the “COMPASS” type has only one value while the “SENSOR” has 4 values - one for each sensor in the car.

SJone board checks for a CAN message periodically, decodes it and sends this message to ESP8266 over UART.ESP8266 module checks for UART message periodically which is encapsulated in the predefined format to MQTT payload and publishes the message to the desired MQTT topic. Simultaneously the ESP8266 module receives the MQTT payload from smartphone application and decapsulates the message received on those specified topics. The decoded message is sent to the SJone board via UART which then encodes and sends this message over CAN bus.

Master Module

Master ECU

Master Controller

The master controller is responsible for the handling motion of the car. The master controller decides how the car will move based on inputs from all the other ECUs. The master first waits to receive the start command from the Android app via Bridge ECU. When the app sends “START Command” the master controller takes the values of ultrasonic sensors from the Sensor Controller, also the master takes the direction angles from the Geo controller. The master controller first calculates if there are any obstacles, it will avoid those obstacles by giving out motor speed values to the motor controller and steer accordingly. Then the master starts following the steer instructions provided by the Geo Controller. The obstacle avoidance algorithm preempts the GEO controller navigation directions.

Obstacle Avoidance

The obstacle avoidance algorithm implemented is simple. The master controller receives values of the ultrasonic sensors from the Sensor Controller. The values which are distances in centimeters are received from the front, left, right and back sensor. When the car is supposed to move forward the master checks the values of the front, left and right sensors and checks if all the values are above the threshold.

Hardware Design

Wheel Master.png

Software Design

Master Module Software Design

The pseudocode of steering is as below:

if(left sensor < threshold){
    STEER RIGHT();
}
if(right sensor < threshold){
    STEER LEFT();
}
else{
    Follow GPS_directions();
}


The pseudocode for speed controlling as below:

if(front_sensor < threshold){
    REVERSE();
}
else if(left_sensor && right_sensor < threshold){
    REVERSE();
}


Technical Challenges

Problem Summary

  • Improper obstacle avoidance: obstacle avoidance would fail in narrow spaces.
  • Obstacles below sensor level: The obstacles that lied below the sensors were not being detected which made the car get stuck in them
  • Reverse steering logic: While the car had to reverse because of obstacles the steering during this time was wrong making it go in the obstacles again.
  • Late response to sensor values: The car would not get enough response time to avoid obstacles during fast speed.

Problem Resolution

  • Improper obstacle avoidance: Implemented a very simple algorithm with minimal if conditions for avoiding obstacles instead of multiple if,else-ifs conditions.
  • Obstacles below sensor level: If the car would get stuck in such obstacles the motor ECU would identify that this is not a ramp and it's actually an error condition and send an error flag. The master would check this flag periodically and whenever it's high the master would make a reverse.
  • Reverse steering logic: The steering logic must be mirrored how it is implemented in forward condition.
  • Late response to sensor values: The threshold at which the sensors should response will change with respect to the speed it is at.


Mobile Application

Mobile Application

The Android application(Mystery Mobile) allows the user to interface with the RC car. The connection between the car and the mobile is established via MQTT protocol. The app requires that the mobile is connected to the Mystery Machine wifi that is hosted by the wifi modules mounted on the car. Then the app automatically connects to the car via the MQTT broker.

Once connected the app takes part in a two-way communication that allows it to send commands to the car and to receive information from the car.

Since the mqtt client does not provide the connection details of the other clients that is connected to it, we are using a heartbeat message from the wifi module to ensure that the Android application can know the connection status of the car.

Transmission

  • App sends the GO and STOP commands that starts and stops the motor accordingly.
  • The messages are <GO0> for stop and <GO1> for start
  • Sends the destination coordinates can be set by the user in the Android application by placing the destination marker on the Google Maps in the app. The marker can be moved by clicking on the map where ever the user wishes to place the destination for the car and the destination can be send by use of the destination send button
  • The message is <GPS:latitude|longitude>

Reception

  • The current speed of the car
  • The direction the car is heading
  • The direction of the destination
  • RPS of the motor
  • Sensor values
  • Current location of the car
App data format

Software Design

Android Implementation


Implementation

App Overview
Marking a spot on map
App waiting for connections
Mystery Android GIF.gif


Technical Challenges and Solutions

  • Integrating the map onto the app was an issue.
  • Since the application was designed with fragments and the map view integration was tricky.
  • Solved it by converting everything into fragment including the map and a common fragment container.

Improvements

The app now connects directly to the car via the wifi hosted by the car. It can be improved by connecting the car to the cloud and there by the app can connect to the car from any where by connecting to the cloud.




Conclusion

The project gave us a platform to learn how to co-ordinate as a team, introduction to new technologies and meeting real time deadlines. Every individual who worked for this project had their own responsibilities and goals to accomplish. We got to know what team management is and how we can accomplish a goal by working as a team. We were more efficient and learnt more stuffs by working as a team. We faced many technical difficulties and failures throughout this project through which we learned a lot. We got to know how to manage the time and meet the deadlines. By designing and implementing a self driving RC car from the scratch, we realized that not every thing will go according to plan even if it is full-proof mistakes happen, we need to improvise and keep moving forward. We learned to realize that everyone in a team will have their own pros and cons and that we need to navigate between them if we need to accomplish something bigger than any single individual.When being accused of a module not working, we recognized not to ask for proof of it not working but instead to show the proof that it does work as intended.

Project Video

Project Video

Project Source Code

Gitlab link

Advise for Future Students

1. Start as soon as possible.
2. Don't go with cheap modules and cheap sensors. They might work but you will spend a lot of time trying to get them work.
3. Follow the guidelines that Preet provides, it will save your time.
4. Unit testing was critical. Unit test helped a lot with debugging and modularizing the code.
5. Keep it simple and modular. Don't create "GOD OBJECTS". Use meaningful and descriptive names for functions and variables. Don't make it too complex.
6. Code review sessions from Preet helped a lot. You will get a lot of insight about making your code better.
7. Never stop improving on any particular module just because it works.
8. Have a bigger picture of the whole design before beginning (Especially in Hardware design )
9. Keep team deadlines other than Preet's deadlines.
10.Celebrate even the smallest of accomplishments, it will help with the team moral.

Acknowledgement

Preetpal Kang
We would like to thank our professor, Preetpal Kang for his guidance and feedbacks along with prompt replies in slack. We had continuous feedback after ever demo and tips that helped us identify problems ahead of time. We would also like to thank the ISA Pratap Desai for his inputs as based on his current and previous experiences. We would also like show our gratitude for all the help presented by our classmates helping out each other when we were stuck.

References

HC-SR04 DataSheet
Ublox-7M Datasheet
MOC-70T3 Datasheet
MTU-9150 Reference sheet
ESP-8266 Datasheet