Difference between revisions of "S19: Lightfury"

Revision as of 10:53, 22 May 2019

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

<Team Picture>

Project Link: Gitlab Link

• Driver_Master_Controller
  • Pradnya Bhangle
  • Pritam Gholap

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

• Motor Controller
  • Gaurav Yadav
  • Niraj Surati
  • Tanmay Jambhekar

• 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

Parts List & Cost

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.

CAN Communication

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 controller commands.

Hardware Design

<Show your CAN bus hardware design>

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

Reflection from 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

1. 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.
2. 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.
3. 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.
4. 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.
5. Pin 0.0 of SJOne board is configured as RD1 and is connected to RXD pin (Pin 4) of MCP 2551 (can transceiver).
6. Pin 0.1 of SJOne board is configured as TD1 and is connected to TXD pin (Pin 1) of MCP 2551 (can transceiver).

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

1. Initialize the CAN bus either on can1 or can2 with baud rate of 100 kbps and RX/TX queues of size 100
2. 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)
3. Enable the external interrupts for corresponding pins to detect rising and falling edge of the input pulse
4. Set the micro-controller pin connected to SIG pin as an output
5. 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
6. Set the corresponding pin on the controller as an input which is connected to SIG pin
7. Fetch the system uptime when rising edge interrupt occurs. The noted time can be considered as the "start_time" of the echo pulse.
8. Fetch the system uptime when falling edge interrupt occurs. The noted time can be considered as the "stop_time" of the echo pulse.
9. Calculate the distance from the obstacle. (Distance = ((start_time - stop_time)/147) in inches or Distance = ((start_time - stop_time)/57.14) in cm).
10. 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.

Motor ECU

Traxxas 550T

Hardware Design

The traxxas chassis came with ECU and servo controller. It has DC motor with servo control for turning. Working on 3.4 V/ 3000mAH power specifications it has axle to rotate all the four wheels. The feedback for PWM controlled speed attained is fed back through magnetic encoder. The front wheels have servo connection for turning. The chassis is placed on suspension unit for shock absorbing. An acrylic sheet is mounted over certain height on which the PCB and controller is placed. The motor controller sends signals for PWM and servo motor angles for driving the car.

Software Design

The motor gets signal from motor controller. The motor controller sends PWM signals for speed control of DC motor. Also it implements PID for uniform performance on ramp. For direction control, the servo has 2 levels of turning: soft and moderate. Depending on Driver Controller signal, the Motor Controller sends control signals to the motor. In case of communication loss from Master Controller, the Motor Controller displays CAN MIA condition on LED.

Technical Challenges

Finding PID constants

Problem Summary: For uniform speed over ramp, we implemented PID. However, calculating the constants for PID proved to be challenging due to oscillations of set speed.

Problem Resolution: Set discrete speed levels to prevent oscillations. Determined PID constants through trials and errors.

Determining RPM accurately

Problem Summary: No support available for motor encoder reed sensor.

Problem Resolution: After checking values on DSO, we noticed irregular output. We resolved it by using pull up resistor of 1k ohms.

Motor stop functioning before demo

Problem Summary: The motor stopped functioning even with correct power and signal input.

Problem Resolution: Had previously dismantled the chassis for encoder study. Re assembled the chassis to function correctly at demo.

Geographical Controller

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

<Bullet or Headings of a module>

Unreliable GPS lock

<Problem Summary> <Problem Resolution>

Communication Bridge Controller & LCD

<Picture and link to Gitlab>

Hardware Design

The bridge controller communicates with mobile SJ one board over Xbee. This mobile SJ one board and the mobile application communicate over Bluetooth (HC05). The bridge controller then sends start/stop and monitors heartbeat of Master controller. It sends sensor controller data(distance from obstacle from all three ultrasonic sensor), geo sensor data (source latitude and longitude) and motor controller (speed and servo turning data). In addition to this , it gives checkpoint details and destination details to the geo controller. The communication used by geo controller to communicate with remaining controller is CAN communication. It uses on board LEDs to indicate functionality of Master controller and Xbee transmission.

Software Design

The bridge controller being the controller to communicate with all the controller on the car has to adhere to the data formats send by the respective controllers. Especially when it communicates with mobile SJOne board, it receives data of location in string format, which has to be converted into longitude and latitude. The data from different modules is received in different frequency.

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 is connected to all the controllers through CAN bus. It uses on board LEDs to display funtioning controller. To display sent motor command it sets appropriate numeric value on LED segment.

Software Design

The master controller gets start-stop command from bridge controller which communicates the signal from the mobile application. From ultrasonic sensor it gets distance to obstacle and compares it to threshold value. Then it checks for direction and magnitude from geo sensor input to send motor controller commands for driving and steer control. Also it displays heartbeat for remaining controllers through on board LED.

Technical Challenges

Levels of turning

Problem Summary: For turning on detecting obstacle, the large servo turning value would result in oversensitive behaviour.

Problem Resolution: Set 2 discrete servo levels for turning based on how many ultrasonic sensors are triggered. A moderate turning angle command is sent if two sensors (front or any one of the side sensors) and a soft turn command is sent if only one of the side sensor detects obstacle closer than threshold.

Determining threshold

Problem Summary: The car kept crashing even after detecting obstacle.

Problem Resolution: Determined threshold values through trials and errors. For high speed, large clearance is required for stopping distance. Ideally keep higher threshold value for front sensor than side sensors.

Unresponsive to GEO sensor data

Problem Summary: The motor command responded only to ultrasonic commands and disregarded the geo information even after including it the geo data in motor command decision making.

Problem Resolution: This was a programming bug. Code restructuring and verifying the conditions helped solve this problem. The nested if structure had most frequently used command at the top of nested if, to reduce time lag. This proved unreliable as the frequently used command had ultrasonics default condition which overshadowed the geo data analysis part. Putting this condition to the end of the nested structure helped solve this default behaviour taking precedence everytime. Geo data had same conditions for stop and no data received from geo sensors. Hence the car stopped when no geo data was received. Remedying this with separate constants for each helped solve this problem.

Mobile Application

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

<Bullet or Headings of a module>

Wifi Link Reliability

<Problem Summary> <Problem Resolution>

Conclusion

<Organized summary of the project>

<What did you learn?>

Project Video

Project Source Code

Advise for Future Students

<Bullet points and discussion>

Acknowledgement

=== References ===