Difference between revisions of "S20: Canster Truck"

Revision as of 18:18, 21 May 2020

CAN-STER TRUCK LOGO

Abstract

The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.

Introduction and Objectives

The project was divided into 7 modules:

• Bridge and Sensor Controller
• Motor Controller
• Geological Controller
• Driver and LCD Controller
• Hardware Integration
• Android Application
• Testing & Code Review

RC Car Objectives

     1. Driver and LCD Controller - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
     2. Geological Controller - Recieves coordinates from GPS and Heading from Compass for navigation 
     3. Motor Controller - Controls movements of the RC Car 
     4. Bridge and Sensor Controller - Detects surrounding objects and interfaces android application to controller via bluetooth

Team Objectives

High Level System Diagram

Team Members and Responsibilities

Gitlab Project Link - Canster Truck

• Niket Naidu LinkedIn Gitlab
  • Geological Controller
  • Driver and LCD Controller
  • Testing & Code Review
  • Android Application

• Ganesh Ram Pamadi LinkedIn Gitlab
  • Hardware Integration
  • Testing & Code Review
  • Driver Controller
  • Motor Controller

• Nikhil Pabbisetty LinkedIn Gitlab
  • Bridge and Sensor Controller
  • Motor Controller

• Akhil Cherukuri LinkedIn Gitlab Github
  • Android Application
  • Geological Controller
  • Hardware Integration

• Ashish Anant Ladage LinkedIn Gitlab
  • Driver and LCD Controller
  • Hardware Integration
  • Motor Controller

• Jesus De Haro De Reza LinkedIn Gitlab
  • Bridge and Sensor Controller
  • Motor Controller

Administrative Responsibilities

• Team Lead - Niket Naidu
• Git Repository Manager - Niket Naidu
• Bill Of Materials Manager - Akhil Cherukuri
• Wiki Report Manager - Akhil Cherukuri

Schedule

Bill Of Materials

Printed Circuit Board

Design And Architecture

The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

Power Section

We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).

• Power bank #1 - Subset 2

• Power bank #2 - Subset 1, Subset 3, Bluetooth

NOTE:

Subset 1:

1. LIDAR
2. LCD
3. Compass

Subset 2:

1. Motor node
2. Driver node
3. BS node

Subset 3:

1. Geo node
2. Back ultrasonic sensor

Fabrication

• PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.

DRC elements

• Track Width = 12
• Clearance = 10
• Via Diameter = 24
• Via Drill Diameter = 12

Challenges

• Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
• We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
• The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

PCB Layout Design in EasyEDA

PCB Schematic

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

DBC FILE: Gitlab

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_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
 SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
 SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
 SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
 SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
 SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
 SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
 SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
 SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
 SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
 SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
 SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
 SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
 SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
 SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
 SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
 SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
 SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
 SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
 SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
 SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
 SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
 SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
 SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
 SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
 SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
 SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";

Motor Controller

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>

Geological Controller

<Picture and link to Gitlab>

Messages

• GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

• GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

• GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

• GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

• GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

• CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

Hardware Design

Geological Diagram

Software Design

Overview

Inside the `periodic_callback__initialize` - Initialize the CAN BUS - Initialize the GPS

Inside the `periodic_callback__1hz` - Handle all MIA (from other Nodes) - Update GPS LED when init and in case of failure - Compute the GEO LOGIC for Waypoints algorithm once every second (1000 ms)

Inside the `periodic_callback__10hz` - Handle CAN Incoming messages (Decode) - Transmit CAN Geo messages (Encode and send) - Compute the GPS Coordinate

GPS Initialization

GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

GPS Data Parsing

The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module. Inside its computation loop, the Line Buffer module checks if a newline character has been received. When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens. For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

GPS LED Indication for debugging

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

GEO Logic Module Computation

The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

Bearing Angle:

Formula: θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ ) where φ1,λ1 is the start point, φ2,λ2 the endpoint (Δλ is the difference in longitude) Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo. For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate. The Steering of the Canster Truck depends on the above-computed angle values.

Haversine Distance Formula:

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!). a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2) c = 2 ⋅ atan2( √a, √(1−a) ) d = R ⋅ c where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km); note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate. Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

Waypoints Algorithm

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm. 3 values were calculated before the final computation - Distance between source and final destination (DISTsd) - Distance between source and each individual checkpoint (DISTsc) - Distance between each individual checkpoint and the final destination. (DISTcd) If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination. If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source. The minimum value was set initial that was equal to DISTsd. If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function. In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction. This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

CAN Decode Destination Coordinates

Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module. This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

CAN Encode and Send

The main messages that were transmitter are

1. Geo Degree
2. Geo Destination Reached
3. Distance from Destination Debug and Checkpoint Index debug

Geo Degree Computation as per Waypoints Algorithm

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint. Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

Geo Destination Reached

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached. This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS. Having an area of 4 meters was very accurate for all of our test runs.

Geo Distance from Destination Debug and Checkpoint Index Debug

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly. The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it. The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

Technical Challenges

1. DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
2. Creating an efficient algorithm for Waypoints, O(n) complexity.
3. Getting appropriate fixes for GPS when not in a completely open space.
4. GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

Sensor [Bridge and Sensor Controller]

<Picture and link to Gitlab>

Ultrasonic Sensor

Hardware Design

This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node. Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

Ultrasonic Sensor Diagram

Software Design

• Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
• Attach the interrupt on the ECHO input port.
• Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
• Take the system_clock_count at the instant of receiving the interrupt.

Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

Lidar Sensor

Hardware Design

Software Design

In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

Lidar Flow

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

Data Packet Structure

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.

Right sector: 11°-30° Rear sector: 170°-190° Left sector: 330°-349° Front sector: 350°-370° (or 10°) The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

Technical Challenges

Ultrasonic

Lidar

• Datasheet not 100% clear: The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

• UART Buffer Overflow: When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

• Proper Parsing of Measurement Data: After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

• Object Detection with Received Data: Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

• Bugs in Code: When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

Bridge [Bridge and Sensor Controller]

<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

Bridge Diagram

Software Design

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

Technical Challenges

<List of problems and their detailed resolutions>

Driver [Driver and LCD Controller]

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>

LCD [Driver and LCD Controller]

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>

Android Application

Gitlab

Software Design

The application consists of a total of 5 Activities:

• Main Activity:
  • This is the app launch display screen
  • It will check for all the required permission onStart().
  • Has search button for connecting from a paired device list view
  • Once device is clicked, an intent will start the Map Activity
• Map Activity:
  • For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
  • Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
  • When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
  • When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
• Info Activity:
  • Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
  • The received string is parsed and categorizes the data to store it in the required textView to be displayed.
  • Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
• Debug Activity:
  • The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
• Bluetooth Connection Service Activity :
  • This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
  • Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
  • Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
  • Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
    • All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

• Receieved string:
  • A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
  • Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

Android Application Flowchart

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

Technical Challenges

Other hardware challenges:

• Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

Conclusion

CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

Project Video

Project Source Code

Advise for Future Students

GENERAL:

• Form your team and start the project as early as you can.
• Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
• Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.

HARDWARE:

• Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
• PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
• Make sure to expose some extra GPIO and GND pins for future use.

Acknowledgement

Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

References

Motor Controller

Geological Controller

Bridge and Sensor Controller

Driver and LCD Controller

Android

• Youtube Channel: Coding with Mitch
• Android Developers: WebsiteGithub
• Udemy Course: Complete Android Oreo Developer Course

PCB Design

• EDC Tool: EasyEDA