F15: TopGun

From Embedded Systems Learning Academy
Revision as of 22:23, 24 November 2015 by 243 user3 (talk | contribs) (Abstract)

Jump to: navigation, search

Grading Criteria

  • How well is Software & Hardware Design described?
  • How well can this report be used to reproduce this project?
  • Code Quality
  • Overall Report Quality:
    • Software Block Diagrams
    • Hardware Block Diagrams
      Schematic Quality
    • Quality of technical challenges and solutions adopted.

Project Title

Abstract

The GPS-controlled automated RC car will consistes of 5 different LPC 1758 controllers. Each controller will have a specific major tasks required to drive the car. The naming convention goes as:- Motor & I/O controller - this will control the motors of the car and will also connected with a LCD display to show the car's status, Sensor controller - It will be connected to the obstacle detecting sensors on the car, Communication Bridge - It will be connected to an Android mobile phone so as to provide co-ordinates, GEO controller - This will give the exact orientation of the car e.g., heading & bearing, etc. and finally the Master controller - This will collect the data from other controllers and will guide the motor controller. These controllers are connected using CAN bus. After the final implementation, this car will be capable of driving by itself using the destination co-ordinates set by us avoiding every obstacles, overcoming slopes thereby reaching the destination safely!

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

Motor & I/0 Controller:

  • Anuj Korat
  • Dhruv Kakadiya

Communication Bridge & Android Controller:

  • Anush Shankar
  • Aditya Devaguptapu

Geographical Controller:

  • Chitrang Talaviya
  • Navjot Singh

Master Controller:

  • Hemanth Konanur Nagendra
  • Akshay Vijaykumar

Sensor Controller:

  • Divya Dodda
  • Dhruv Kakadiya

Treasurer:

  • Anuj Korat

Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Team Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/15/2015 09/27/2015
  • Understanding the requirements and having initial team discussions on approach to be followed to carry out project
  • Forming sub-teams and assigning individual modules to each sub-team
Completed 09/27/2015
2 09/27/2015 10/30/2015 Following up on RC car and other component procurement through team discussions Completed 10/30/2015
3 10/30/2015 10/06/2015 Hardware design of the car including discussions on component placement, soldering and wiring. Completed 10/06/2015
4 10/06/2015 10/17/2015 CAN message ID's, priorities, data size and format proposals for all the possible CAN messages on the bus Completed 10/20/2015
5 10/20/2015 11/05/2015 Discussions and proposals on basic obstacle avoidance algorithm with sensor integration, hands on and testing Completed
6 11/05/2015 11/25/2015 Integrating other modules and components to the RC car, development of autonomous driving algorithm and finalize on hardware layout of the car Incomplete
7 11/25/2015 12/15/2015 Testing the RC car in real world environments Incomplete


Motor & I/O Controller Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/20/2015 09/27/2015 Researching and ordering the LCD module to be used in the project Completed 9/27/2015
2 09/27/2015 10/05/2015
  • Studying data sheets(LCD and motor) to get understanding of basic concepts and working of components
  • Understanding and proposing driving mechanisms for LCD and motors(DC and servo)
Completed 10/05/2015
3 10/05/2015 10/12/2015
  • Interfacing motors to SJOne board and developing drivers for the same
  • Interfacing LCD module to SJOne board and developing drivers to display basic texts and symbols
Completed 10/12/2015
4 10/12/2015 10/30/2015
  • Implementation of basic power on RC car run with motors(DC and servo) interfaced to SJOne board
  • Collaborating with other teams to develop basic obstacle avoidance and testing it
Completed
5 10/30/2015 11/12/2015 Proposals related to speed controls and sensors for the same and integration of LCD module(with data display) Incomplete
6 11/12/2015 11/25/2015 CAN bus communication from motor and I/O controller to other boards Completed
7 11/25/2015 12/15/2015 Debugging issues during trial runs and testing out fault cases Incomplete


Communication bridge & Android Controller Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/20/2015 09/30/2015 Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API Completed 09/30/2015
2 09/31/2015 10/10/2015
  • Placement of buttons on the app activity page to switch on and off bluetooth on the phone
  • Marker placement on Google maps for source and destination
Completed 10/10/2015
3 10/10/2015 10/22/2015
  • Creating input and output streams for bluetooth for sending and receiving data
  • Performing straight line routing between source and destination on google maps
Completed 10/22/2015
4 10/22/2015 10/30/2015 Interfacing bluetooth module to SJOne board through UART and receive data on SJOne board sent by the bluetooth application Incomplete
5 10/30/2015 11/10/2015 Relay commands and CAN messages from SJOne to android application and test correctness of data Incomplete
6 11/10/2015 11/22/2015 Performing correct routing between source and destination, have a complete working application, basic testing of application and bridge interface Incomplete
7 11/22/2015 12/15/2015 Extensive Testing of application during final phases, modifying code in cooperation with other teams and optimization of android application Incomplete


Geographical Controller Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/20/2015 09/27/2015 Researching and ordering the parts Completed 9/27/2015
2 09/27/2015 10/05/2015 Studying module data sheets and writing code sketches to be used when modules are procured(GPS and compass) Completed 10/05/2015
3 10/05/2015 10/15/2015 Interfacing GPS module and compass to SJOne board and get consistent filtered readings Incomplete
4 10/15/2015 10/30/2015 Proposals for heading and distance calculation, unit testing and integrating modules Incomplete
5 10/30/2015 11/10/2015 Calibration of compass and GPS readings, CAN bus communication from geo controller to other boards Incomplete
6 11/10/2015 11/25/2015 Android application connection with data reception and transmit Incomplete
7 11/25/2015 12/15/2015 Final phase testing and optimization, collaborating with android team to get better reliable outcomes Incomplete


Sensor Controller Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/20/2015 09/27/2015 Researching and ordering the sensors to be used in the project Completed 9/27/2015
2 09/27/2015 10/03/2015
  • Studying sensor data sheets and preparing code sketch to be used after components are procured
  • Interface ADC ultrasonic sensor to SJOne board(available spare sensors), reading sensor values and filtering the readings
Completed 10/03/2015
3 10/03/2015 10/10/2015 Interfacing ADC ultrasonic sensor to SJOne board, reading sensor values and filter the readings Completed 10/10/2015
4 10/10/2015 10/20/2015 Understanding inertial measurement unit sensor, interfacing it to SJOne board to get filtered readings Completed 10/20/2015
5 10/20/2015 11/05/2015 Integrating multiple sensors to the SJOne board, testing the sensors and debugging issues Incomplete
6 11/05/2015 11/25/2015 Preparing sensor values to be sent over CAN bus and testing out the correctness of sensor can messages Incomplete
7 11/25/2015 12/15/2015 Testing of code during final phases, modifying code in cooperation with other teams and optimization of code Incomplete

Parts List & Cost

Item# Part Desciption Vendor Web link Qty Cost
1 RC Car From Preet http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm 1 Free
2 RC Car Battery Amazon http://www.amazon.com/dp/B000HKKZN0/ref=rr_xsim_1_1?ie=UTF8&qid=1443933750&sr=0 1 $24.72
3 Core CPU Supply Amazon http://www.amazon.com/gp/product/B002BHXYSK?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00 1 $12.70
4 CAN Transceiver MCP2551 Microchip http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405 15 $20.00
5 Printed Circuit Boards Amazon http://www.amazon.com/Prototyping-Tinned-Universal-Printed-150x200mm/dp/B00N3WTROC/

http://www.amazon.com/Double-Protoboard-Prototype-Printed-Circuit/dp/B00NQ3A50S/

4 $20.13
6 M-F,F-F,M-M Jumper Wires Amazon http://www.amazon.com/Kalevel%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B00M5WLZDW/ 120 $8.75
7 Servo Motors Amazon http://www.amazon.com/RioRand-TowerPro-micro-Helicopter-Arduino/dp/B00M8RGGFG/ 5 $12.89
8 Ultrasonic Sensors Amazon http://www.amazon.com/gp/product/B00NG8TJ6E?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s02 5 $10.45
9 9 DOF Razor IMU module SparkFun https://www.sparkfun.com/products/10736 1 $74.95
10 FTDI Basic Breakout SparkFun https://www.sparkfun.com/products/9873 1 $14.95
11 LCD Display uLCD-32PTU 4D systems http://www.4dsystems.com.au/product/uLCD_32PTU/ 1 $111.00
12 Bluetooth Module Amazon.com http://www.amazon.com/KEDSUM%C2%AE-Arduino-Wireless-Bluetooth-Transceiver/dp/B0093XAV4U/ 1 $9.99
13 Wire Cutter Amazon http://www.amazon.com/Hakko-CHP-170-Stand-off-Construction-21-Degree/dp/B00FZPDG1K 1 $2.99
14 GPS Sensor Adafruit http://www.adafruit.com/products/746 1 $39.95
15 7-Segment Display From Preet https://www.sparkfun.com/products/retired/9765 1 Free
Total Cost $450

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

CAN Message ID Table

Message ID Task associated with ID Data bit-fields
0x00 Kill Switch No Data
0x01 Reset
  reset_motorio:8;   // Acknowledge motorio controller
  reset_sensor:8;    // Acknowledge sensor controller
  reset_geo:8;       // Acknowledge geo controller
  reset_bluetooth:8; // Acknowledge bluetooth module  
0x02 Master Sync Ack
 ack_motorio:8;		// Acknowledge motorio controller
 ack_sensor:8;		// Acknowledge sensor controller
 ack_geo:8;			// Acknowledge geo controller
 ack_bluetooth:8;		// Acknowledge bluetooth module
0x03 MotorIO Controller Sync No Data
0x04 Sensor Controller Sync No Data
0x05 Bluetooth Controller Sync No Data
0x06 Geo Controller Sync No Data
0x07 MotorIO controller Heart-beat No Data
0x08 Sensor controller Heart-beat No Data
0x09 Bluetooth controller Heart-beat No Data
0x0A Geo controller Heart-beat No Data
0x0B Run mode mode:8;
0x0C Distance Sensor Data
 front_left:8;		// Front left sensor reading
 front_right:8;		// Front right sensor reading
 front_center:8;	        // Front centre sensor reading
 left:8;			// Left sensor reading
 right:8;			// Right sensor reading
 back:8;			// Back sensor reading
0x0D MotorIO Direction Data
 speed:8;			// Indicate speed for DC motor
 turn:8;			// Indicate turn angle for servo motor
0x0E Check-point Request Message No Data
0x0F Check-point Start Message
 num_of_points;	// Number of check-points to be loaded
0x10 Check-point Data
 float latitude;
 float longitude;
0x11 Geo-Controller New Destination Data
 float latitude;
 float longitude;
0x12 Geo-Controller Speed and Angle message
 speed:8;		// Speed as measured by the GPS sensor
 heading:16;		// Heading from the Geo controller
 bearing:16;		// Bearing calculated by the Geo controller
0x13 Geo-Controller Location Data
 float latitude;
 float longitude;
0x14 Light and Battery Sensor Data
 light_sensor:8;	// Light sensor reading
 batt_sensor:8;	// Battery level sensor reading

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Sensor Testing

HCSR04 Sensor Testing

  • As shown in the figure below, HC-SR04 ultrasonic sensor requires an external 5V DC supply.
  • When in the initial testing stage we just connected one sensor for testing the accuracy and the range of the sensor.
  • The values we received were very stable and neat.
HC-SR04 sensor circuit diagram

Finalizing distance sensors

  • Both sensors being pretty accurate, we were confused while finalizing one. So we were using both sensors, for front we were using Parallax and for left,right and back sensors we were using HCSR04 sensor.
  • HCSR04 sensor was better option because as it was much cost efficient than the Parallax Ping Sensor (Where one Parallax Ping costs $30, one HCSR04 costed us only $2)
  • Its only drawback is, the cheaper one sensor needed good filter to remove some spikes and Parallax sensor was working pretty good without any filtering.

Switching to Hardware Timer

  • Previously, all sensor were triggered using software timers. We declared a soft timer for each sensor which kept track of the time between trigger and echo for that particular sensor.
  • If we see the declaration of software timer as shown below, we come to know that the timer returns a value in milliseconds.
   inline uint64_t getTargetTimerValueMs(void) const { return mTargetMs; }
  • If we apply the before mentioned distance formula to this timer value in milliseconds, we will always get the distance in multiples of 17.
  • Let's work out an example for better understanding;
Software Timer Distance Calculation
  • As the return return type of this function is an integer, we always get the distance in multiples of 17, which compromises the accuracy by a large factor.
  • Because of this reason we switched to hardware timers.
  • The declaration of hardware timer is as shown below, and this return value of time is in micro-seconds.
   uint32_t lpc_timer_get_value(const lpc_timer_t timer)
   {
       return (lpc_timer_get_struct(timer)->TC);
   }
  • Let's work out the same example for the return value being 1usec.
Hardware Timer Distance Calculation
  • Hence, even if the timer value is an integer, as it is in microseconds, we have improved the accuracy.
  • As there are only three hardware timers in LPC 1768 we cannot allot individual timer for each sensor. Hence, we use just one hardware timer which runs regardless any individual sensor.
  • All sensors get the current timer value during trigger and echo from this single timer, and do the further processing individually.

Sequentially Triggering of Sensors

  • We used to trigger all the sensors at the same time, which caused interference between adjacent sensors, which in turn caused mis-firing of echo.
  • This resulted in incorrect distance values from all the sensors.
  • Thus to solve this issue, we implemented sequential triggering.
  • Under this logic, each sensor will be triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 60msec.
  • This implementation solved the issue at hand but gave rise to a new issue which is mentioned in the next section.

Limiting the Scope to Improve Frequency

  • As discussed in the previous section, if we implement sequential triggering for each sensor, if there is no obstacle, then the worst case delay would be 360 msec(60msec*6sensors) to update all sensor values to the master.
  • Means the frequency of communicating these values to the master will be, 2.8Hz.
  • For proper obstacle avoidance, we need to provide the sensor data to the master atleast 10 times per second, i.e. at 10Hz.
  • Which means data from all six sensors must be calculated within 100msec.
  • Even if we consider limiting the time allotted to a sensor to time required for maximum distance (400cms), we will require 23.5msec each sensor i.e. 141msec to update the values of all six sensors. This increases the frequency to 7.1Hz.
  • This led is to the solution to this problem, if we limit the scope of each sensor then we can update the sensor values more frequently to the master.
  • To overcome this issue, we limited the maximum scope of the sensor to 170 cms, limiting the time required to get the echo to 10msec. Which makes the total time required to calculate all six sensors' data about 60msec.
  • Hence, as shown in the flowchart, each sensor waits 10msec for an echo. If we get an echo within 10msec, we calculate the distance; if we don't, we assume the obstacle is at 170cms or further.

Misfiring of Sensor

  • At times the sensor used to mis-fire. Which means; in a stable condition, if the obstacle is at a constant distance of 150cms, 1 out of 50 continuous values will be 60cms.
  • This value being false, misguides the master.
  • To overcome this issue, we introduced a threshold value called DELTA (say, 10cms). Which defines the acceptable range from the previous value.
  • In this algorithm, an abrupt change in the distance value should be constant for at least two consecutive reads to be considered genuine.
  • If the current value from the sensor is in the range of the previous value's +/- 10cms, then this value is considered to be correct, and is provided to the master. Then this current value will be copied in the previous value register.
  • If the current value is not is the previous value's +/- DELTA range then it is considered as a misfire and hence is not provided to the master. But this sudden change might be because of a sudden obstacle; hence, the value is copied in the previous value register, and if the same value repeats, it will be considered genuine and provided to the master.
  • The code for this algorithm is as shown below;
       if(temp-DELTA<current && current<temp+DELTA){
           distance = current;
       }
       temp = current;
  • Hence, this algorithm will overcome the abrupt mis-firing of the sensor and make the data provided to the master more reliable.

Media:_can_dbc.zip

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

My Issue #1

Discuss the issue and resolution.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.