S19: Lightfury

1 LightFury
2 Abstract
- 2.1 Introduction
- 2.2 Team Members & Responsibilities
3 Schedule
4 Parts List & Cost
5 Printed Circuit Board
6 CAN Communication
- 6.1 DBC File
7 Sensor ECU
8 Motor ECU
9 Geographical Controller
10 Communication Bridge Controller & LCD
11 Master Module
12 Mobile Application
13 Conclusion

LightFury

Ultrasonic and Geo Sensor Based Self-Navigating Autonomous Car using CAN communication bus.

Abstract

LightFury is an autonomous electric car project that aims to bring different embedded system paradigms together and consolidate them with industry level sophistication and robustness. This project will feature an RC car which will employ different sensors and motors to navigate the track without human assistance. Every sensor and motor combined with a dedicated functionality is managed and processed by a controller. Such different controllers will communicate with the master node using the CAN bus protocol. Real time interaction with the car for communicating destination and getting car updates is possible with bridge controller and mobile application. The autonomous car navigation is a result of all electronic module functioning harmoniously to reach the destination location.

The navigation is based on destination position and car position. The autonomous car navigates with the help of GPS and compass along the checkpoints. Also, upon detecting obstacle, the car effectively navigates away from obstacle coming into its path. The motor controller effectively controls speed at turning and on ramp. Using the communication bridge and on board LED indicators we can have interpretation of the controller decisions. Also, the CAN bus communication can be used to observe the messages and sensor output on GUI or graphs. Thus we can observe the navigation decisions taken by the autonomous car.

Introduction

The project is divided into 7 modules:

Master Controller
Motor Controller
Ultrasonic Sensor Controller
GPS Controller
Android application and Bluetooth Connectivity
Hardware (PCB designing and Electronic layout)
Testing and Verification

The system has five SJOne Boards that run FreeRTOS and communicate with CAN bus. The car uses low power source for Boards and Sensory Units and high power source for Motor Driving Unit. The LEDs on each board are used to indicate status of controllers. The system is mounted and arranged on Traxis chassis. The final autonomous car is functional and compact unit.

Team Members & Responsibilities

Project Link: Gitlab Link

Driver_Master_Controller
- Pradnya Bhangle
- Pritam Gholap

Sensors
- Ultrasonic
  - Pritam Gholap
- Compass
  - Pradnya Bhangle
  - Akshay Ghodke

Motor Controller

Geographical Controller
- Akshay Ghodke
- Siddharth Chawla

Communication Bridge Controller & LCD
- Kaustubh Jawalekar
- Siddharth Chawla

Android Application
- Siddharth Chawla

PCB Design
- Tanmay Jambhekar

Testing, Integration & Repository Maintenance
- Gaurav Yadav
- Niraj Surati

Schedule

Week#	Start Date	Task	Status	Completion Date
1	02/12/2019	Form Teams and decide group name. Also look up past projects and learn about the autonomous car design.	Completed	02/12/2019
2	02/19/2019	Setup Gitlab Order CAN Transceivers. Study CAN communication. Commit and raise merge request by each member to get hold over Gitlab basics	Completed	02/19/2019
3	02/26/2019	Setup Gitlab master branch for Project Light Fury. Create and merge branches for development tracking.	Completed	02/26/2019
4	03/05/2019	Read previous projects, gather information and discuss among the group members. Distribute modules to each team member. Divide the applications in different module for independent development. Identify the baseline application.	Completed	03/09/2019
5	03/12/2019	Identify components required for the project Allocated budget for the project Order Components	Completed	03/19/2019
5	03/19/2019	Sensor: Perused the datasheet to get started with development GPS: Went through the datasheet and circuitry details for GPS module(no.) Compass & LCD: Read the respective datasheets and manuals Motor: Getting hold of the specification and the user manuals Android: Design the basic template of the Application BLE: Thorough understanding of the module	Completed	03/26/2019
6	03/26/2019	Sensor: Successful interfaced ultrasonic with LPC to get raw data GPS & Compass: Acquire data from GPS and Compass Motor: Basic motor controlled vehicle orientation Android: Interfacing with other modules Unit-testing for each module	Completed	04/02/2019
7	04/02/2019	----SPRING BREAK-----	Completed	04/09/2019
8	04/09/2019	Sensor: Parsed the raw data to achieve useful data GPS & Compass: Parsing of raw data to get meaningful values Motor: Take motor feedback through encoder and speed control on ramp Android: Basic Android app BLE: Bridge to receive Driver Heartbeat	Completed	04/16/2019
9	04/16/2019	Sensor: Design mounts and stabilize sensor input GPS & Compass: Acquire GPS coordinate after GPS lock, Compass calliberation Motor: Speed control and angle control precision testing Android: Develop User Interface for data display BLE: Interfacing bridge to Android app PCB designing	Completed	04/23/2019
10	04/23/2019	Sensor: Analysis for jitters in sensor value Obstacle avoidance logic on Master Controller GPS & Compass: Range and bearing calculation Motor: Implemented LCD to display motor parameters Android: Adding UI for destination coordinates BLE: Send checkpoints to GeoSensors Master: Testing Sensor Obstacle Distance Limits PCB Designing	Completed	04/30/2019
10	04/23/2019	Add Geo Navigation logic on Master Controller Integration testing with obstacle avoidance Order designed PCB	Completed	04/30/2019
11	04/30/2019	Outdoor testing and GPS navigation	Completed	05/07/2019
12	05/07/2019	Outdoor testing and Checkpoints tracking	Completed	05/14/2019
12	05/22/2019	----DEMO DAY----	Completed	05/22/2019

Parts List & Cost

Item#	Part Desciption	Vendor	Qty	Cost
1	RC Car	Traxxas	1	From Prof. KaiKai Liu
2	CAN Transceivers MCP2551-I/P	Microchip	15	Free Samples
3	Semtec GPS	Microchip	1	Free Samples
4	Tilt Compensated Magnetic Compass	Amazon	1	$29
5	LIPO Batteries + Charger		1	with car package
6	7" LCD		1
7	RPM 6520 Traxxas	Amazon	1	$11.67
8	UltraSonic Sensor	Maxbotix	4	$150
9	PCB	PCBWay	1	$40.00 (estimated)

Printed Circuit Board

Initial prototyping was done on wire wrapping board for a common CAN bus and power input to all the controllers. Over time on finalizing the layout and components, we designed a PCB to have a compact and stable connections for our electronic and mechanical components. Planned a single PCB to place and route CAN transceivers and eliminate dangling wires. The PCB was designed with Eagle CAD software tool. Components were placed on the design after careful consideration for compactness and routing constraints. The design was modified multiple time to cater for new requirement. Finally, the designed PCB was placed on the chassis for stable and compact car design.

CAN Communication

Controlled Area Network or CAN is broadcast bus used in modern autonomous car systems for reliably communicating between devices. Here we use CAN bus to communicate between different controllers and debug with CAN messages. An errorneous node goes in bus off mode and other node keep communicating over CAN bus. This is why CAN is preferred over other communication protocols. Using PCAN dongle we can debug CAN communication on the bus in real time. These messages have helped in developing the navigation algorithm after observing the system in real time and monitoring CAN communication channel.

The CAN Bus physical design and communication is described in this section. The CAN controller present over SJOne board communicates to external transceiver over Rx and Tx. CAN transceiver transmit the message to CAN bus using differential signals. 0 is the dominant bit. This means that message with lower CAN message ID wins the bus arbitration and transmits its message on the bus. The other transceiver stops transmitting and waits for the next clock cycle to begin arbitration. Hence CAN message ID also acts as priority indicator. This arrangement is terminated with 2 terminal resistors of 120 Ohm. This removes signal reflection from the node end for combating echo from the signal. Due to differential means of transmitting the signal, the CAN bus is immune to noise loss and interference. All transceivers receive the CAN message. Only the intended terminal decodes the message. In case the message is not received by the terminal it goes into MIA state and consequent action can be decided by the user. This makes CAN convenient to be used in any applications.

The CAN follows certain data formatting method known as DBC. With the help of CAN transceivers, each sensor module sends data in DBC format to the controller. The data from ultrasonic sensor helps in obstacle detection. The GPS and Compass Module helps with navigation. The LCD gives live information of component status and values. Finally there is motors and control unit for navigating the car as per the commands from controller. All this controllers share information over CAN bus.

The CAN DBC file is unique format for information storage into structure and recording sender and receiver of the CAN network. It include the different message IDs along with message format and scale offset operations if any. Also there can be debugging node which keeps note of all the node data and can be used to observe the CAN communication. The DBC file comes handy while observing CAN operations in action with the help of Peak CAN. This became really helpful while observing sensor values in graph to detect false triggering.

PeakCAN dongle

Can DB9 connections

CAN Hardware

DBC File

Git Link to DBC file

Sensor ECU

Parallax Ultrasonic Sensor

The sensor ECU is consist of SJOne board interfaced with four Parallax ping ultrasonic sensors. The primary objective of sensor ECU is to detect the obstacles and provide the corresponding information to the master controller in order to avoid those obstacles. According to beam angles, each sensor is mounted in such a way that the car can avoid the obstacles present in front and rear of the car. Based on the acquired information from sensors, distance is calculated and forwarded to the master controller over CAN bus. Based on the previous project reports, Parallax ping sensors were decided for this project as they provided reliable outputs with better range.

Parallax ping

The Parallax ping sensor works on 5V supply voltage. It provides precise distance measurement ranging from about 2 cm to 3 meters. Beyond the mentioned range, the measurement provided by the sensor is not accurate. The sensor operates at 40 kHz. Blinking of LED provided on the sensor depends on triggering frequency. It has only one pin called "Signal" pin for triggering and listening to the echo pulse, which reduces hardware complexity. The distance from the obstacle is calculated by measuring the width of echo pulse and multiplying it with a constant (speed of sound in air). Also, there are some scenarios under which these sensors won't give proper readings such as:

Object is too small to reflect enough sound back to the sensor
Obstacle with the reflective surface will reflect sound at a shallow angle ( < 45 degrees), which won't be reflected back towards the sensor
The sound pulse gets reflected off the floor when the sensor is mounted low on the device

Distance greater than 3 m

Shallow angle ( < 45 degrees) reflection

Unable to detect small object

Hardware Design

Four ultrasonic sensors are used to detect obstacle on left, front, right and rear of the car. The sensor has 124 inches (3.1m) detection range for an obstacle in line of sight. All ultrasonic sensors are mounted upright with an upward tilt to avoid ground reflection. The sensors have a minimum overlap of detection area and have a blind spot too close to the car. All the sensors are interfaced with SJOne board on port 2. Four GPIO pins are used for each sensor and external interrupts are enabled for those pins. The measured distance is transmitted over CAN bus using CAN transceiver (MCP 2551).

Hardware Interface

Pin 2.1 of SJOne board is configured as GPIO and is connected to the signal pin (SIG) of the left sensor. External interrupt for rising and falling edge is enabled to calculate the distance from an obstacle if any.
Pin 2.2 of SJOne board is configured as GPIO and is connected to the signal pin (SIG) of the front sensor. External interrupt for rising and falling edge is enabled to calculate the distance from an obstacle if any.
Pin 2.3 of SJOne board is configured as GPIO and is connected to the signal pin (SIG) of the right sensor. External interrupt for rising and falling edge is enabled to calculate the distance from an obstacle if any.
Pin 2.4 of SJOne board is configured as GPIO and is connected to the signal pin (SIG) of the rear sensor. External interrupt for rising and falling edge is enabled to calculate the distance from an obstacle if any.
Pin 0.0 of SJOne board is configured as RD1 and is connected to RXD pin (Pin 4) of MCP 2551 (can transceiver).
Pin 0.1 of SJOne board is configured as TD1 and is connected to TXD pin (Pin 1) of MCP 2551 (can transceiver).

Sensor Hardware Interface

Software Design

Sensor_ECU_SW_flowchart

Sensor triggering is implemented in the 100Hz periodic task. Sensors are triggered in sets instead of all the sensors triggering at the same time. This technique helped in minimizing signal interference between two adjoining sensors. The front and back sensors are triggered first and then the left and right sensors. Each sensor is fed with a 5us high pulse from the host controller and it emits a short ultrasonic burst and then starts listening for the echo. After sending out the pulse, the SIG pin becomes high and it goes low when the obstacle is detected. To sense this pulse, external interrupts are enabled. The maximum duration of this pulse is 18.5ms which denotes that there is no obstacle in front of the sensor. Given this time period, left and right sensors are triggered 20ms after front and back sensors are triggered. Each sensor is triggered at 20Hz, i.e., after 50ms.

After collecting the data from sensors, distance is calculated and it is transmitted over CAN bus. CAN transmission also takes place 100Hz task only so that updated values are sent at the faster speed. A heartbeat message is sent to the master controller indicating that the sensor controller is up and running. This message is sent using 10Hz periodic task.

Implementation

Initialize the CAN bus either on can1 or can2 with baud rate of 100 kbps and RX/TX queues of size 100
Configure the host controller pins 2.1, 2.2, 2.3 and 2.4 as GPIO pins (These pins are connected to SIG pin of left, front, right and rear sensor respectively)
Enable the external interrupts for corresponding pins to detect rising and falling edge of the input pulse
Set the micro-controller pin connected to SIG pin as an output
Triggering the sensors:
1. Send low signal from the controller to SIG pin (for a clean high pulse)
2. Insert delay of 2us
3. Send high signal from the controller to SIG pin
4. Insert delay of 5us
5. Send low signal from the controller to SIG pin
Set the corresponding pin on the controller as an input which is connected to SIG pin
Fetch the system uptime when rising edge interrupt occurs. The noted time can be considered as the "start_time" of the echo pulse.
Fetch the system uptime when falling edge interrupt occurs. The noted time can be considered as the "stop_time" of the echo pulse.
Calculate the distance from the obstacle. (Distance = ((start_time - stop_time)/147) in inches or Distance = ((start_time - stop_time)/57.14) in cm).
Send the calculated distance to the master controller over the CAN bus.

Steps 4 to 10 are executed within the 100Hz periodic task.

Technical Challenges

Unreliable sonor sensors values

Problem Summary: Observed lots of false detection for sensor over CAN bus resulting in unwanted motor turning.

Problem Resolution: Reduced noise with the help of mounts to reduce vibration from car.

Reduced range when mounted on car

Problem Summary: Max detection range reduced when mounted on car with mounts.

Problem Resolution: Increased ampere to entire circuit to support complete functionality of sensors.

False triggering due to proximity

Problem Summary: All the sensors transmitted pulse at the same time which caused interference among adjoining sensors.

Problem Resolution: Revised sensor placement and triggered non-overlapping sensors at the same time to have minimum overlapping detection range and reduced interference among sensors.

Calculation Error

Problem Summary: Calculated distance in ISR which provided random results.

Problem Resolution: ISR should be kept simple and it should take less time for execution. So for distance calculation other function was created which was called in the 100Hz task.