Difference between revisions of "F15: TopGun"

Revision as of 00:18, 25 November 2015

Grading Criteria

Project Title

This is Top Gun - The super car that drives by itself!

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

Motor & I/O Controller Schedule

Communication bridge & Android Controller Schedule

Geographical Controller Schedule

Sensor Controller Schedule

Master Controller Schedule

Parts List & Cost

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.

CAN Message ID Table

  reset_motorio:8;   // Acknowledge motorio controller
  reset_sensor:8;    // Acknowledge sensor controller
  reset_geo:8;       // Acknowledge geo controller
  reset_bluetooth:8; // Acknowledge bluetooth module  

 ack_motorio:8;		// Acknowledge motorio controller
 ack_sensor:8;		// Acknowledge sensor controller
 ack_geo:8;			// Acknowledge geo controller
 ack_bluetooth:8;		// Acknowledge bluetooth module

 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

 speed:8;			// Indicate speed for DC motor
 turn:8;			// Indicate turn angle for servo motor

 num_of_points;	// Number of check-points to be loaded

 float latitude;
 float longitude;

 float latitude;
 float longitude;

 speed:8;		// Speed as measured by the GPS sensor
 heading:16;		// Heading from the Geo controller
 bearing:16;		// Bearing calculated by the Geo controller

 float latitude;
 float longitude;

 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 Controller

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.

Master Controller

Design

Software Architecture

Overall Architecture with Block Diagram

Communication between Controllers

Heart Beat Implementation Powerup Sync Implementation Data Communication

Driving Algorithm

Overview

Obstacle Avoidance Algorithm

Navigation Algorithm

DBC File Implementation

• This section explains DBC file implementation of the project. The DBC implementation contains the python based DBC file parser, a DBC file and auto generated C code for the five CAN nodes. These five nodes include driver(master), sensor, motor, geo and bluetooth node. The DBC file is a input to the python DBC parser script. The python script will generate a C file for the specific node given by the user at the command line argument. The python script goes through this DBC file and generates code to marshal (covert to raw CAN) and unmarshal (convert from raw CAN) using the provided API that you can enclose in a header file.

• The following file is some portion of the DBC file of the project.

     VERSION ""
      NS_ : 
           NS_DESC_
           CM_
           BA_DEF_
           BA_
           VAL_
           CAT_DEF_
           CAT_
           FILTER
           BA_DEF_DEF_
           EV_DATA_
           ENVVAR_DATA_
           SGTYPE_
           SGTYPE_VAL_
           BA_DEF_SGTYPE_
           BA_SGTYPE_
           SIG_TYPE_REF_
           VAL_TABLE_
           SIG_GROUP_
           SIG_VALTYPE_
           SIGTYPE_VALTYPE_
           BO_TX_BU_
           BA_DEF_REL_
           BA_REL_
           BA_DEF_DEF_REL_
           BU_SG_REL_
           BU_EV_REL_
           BU_BO_REL_
           SG_MUL_VAL_
BS_:

BU_: NOONE SENSOR DRIVER MOTORIO BLUETOOTH GEO

BO_ 0 DRIVER_KILL_SWITCH: 0 DRIVER
 SG_ DRIVER_KILL_SWITCH_cmd 		: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO

BO_ 1 DRIVER_RESET: 0 DRIVER
 SG_ DRIVER_RESET_cmd 				: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO

BO_ 2 DRIVER_SYNC_ACK: 0 DRIVER
 SG_ DRIVER_SYNC_ACK_cmd 			: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO

BO_ 3 MOTORIO_SYNC: 0 MOTORIO

SG_ MOTORIO_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 4 SENSOR_SYNC: 0 SENSOR

SG_ SENSOR_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 5 BLUETOOTH_SYNC: 0 BLUETOOTH

SG_ BLUETOOTH_SYNC_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 6 GEO_SYNC: 0 GEO

SG_ GEO_SYNC_cmd 					: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 7 MOTORIO_HEARTBEAT: 0 MOTORIO

SG_ MOTORIO_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 8 SENSOR_HEARTBEAT: 0 SENSOR

SG_ SENSOR_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 9 BLUETOOTH_HEARTBEAT: 0 BLUETOOTH

SG_ BLUETOOTH_HEARTBEAT_cmd 		: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 10 GEO_HEARTBEAT: 0 GEO

SG_ GEO_HEARTBEAT_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER

BO_ 11 MOTORIO_RUNMODE: 1 DRIVER

SG_ MOTORIO_RUNMODE_cmd 			: 0|8@1+ (1,0) [0|3] "" MOTORIO

BO_ 12 SENSOR_SONARS: 6 SENSOR

SG_ SENSOR_SONARS_front_left 		: 0|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
SG_ SENSOR_SONARS_front_right 		: 8|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
SG_ SENSOR_SONARS_front_center 	: 16|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
SG_ SENSOR_SONARS_left 			: 24|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
SG_ SENSOR_SONARS_right 			: 32|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
SG_ SENSOR_SONARS_back 			: 40|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO

BO_ 13 MOTORIO_DIRECTION: 2 DRIVER

SG_ MOTORIO_DIRECTION_speed_cmd 	: 0|8@1+ (1,0) [0|4] "" MOTORIO
SG_ MOTORIO_DIRECTION_turn_cmd 	: 8|8@1+ (1,0) [0|5] "" MOTORIO

BO_ 14 DRIVER_CHECKPOINT_REQ: 1 DRIVER

SG_ DRIVER_CHECKPOINT_REQ_cmd 		: 0|8@1+ (1,0) [0|3] "" BLUETOOTH,MOTORIO

BO_ 15 BLUETOOTH_CHECKPOINT_SEND: 1 BLUETOOTH

SG_ BLUETOOTH_CHECKPOINT_SEND_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO

BO_ 16 BLUETOOTH_CHECKPOINT_DATA: 1 BLUETOOTH

SG_ BLUETOOTH_CHECKPOINT_DATA_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO

BO_ 17 DRIVER_LOC_UPDATE: 8 DRIVER

SG_ DRIVER_LOC_UPDATE_LAT_cmd 		: 0|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
SG_ DRIVER_LOC_UPDATE_LONG_cmd 	: 32|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO

BO_ 18 GEO_SPEED_ANGLE: 5 GEO

SG_ GEO_SPEED_cmd 					: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTORIO
SG_ GEO_ANGLE_heading_cmd 			: 8|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
SG_ GEO_ANGLE_bearing_cmd 			: 24|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO

BO_ 19 GEO_LOC_DATA: 8 GEO

SG_ GEO_LOC_LAT_cmd 				: 0|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
SG_ GEO_LOC_LONG_cmd 				: 32|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO

BO_ 20 SENSOR_LIGHT_BAT: 2 SENSOR

SG_ SENSOR_LIGHT_cmd 				: 0|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
SG_ SENSOR_BAT_cmd 				: 8|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO

CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one"; CM_ BU_ DRIVER "The driver controller driving the car"; CM_ BU_ SENSOR "The sensor controller of the car"; CM_ BU_ MOTORIO "The motor_io controller of the car"; CM_ BU_ BLUETOOTH "The bluetooth controller of the car"; CM_ BU_ GEO "The geo controller of the car"; CM_ BO_ 2 "Sync message used to synchronize the controllers";

BA_DEF_ "BusType" STRING ; BA_DEF_ SG_ "FieldType" STRING ; BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;

BA_DEF_DEF_ "BusType" "CAN"; BA_DEF_DEF_ "FieldType" "";

BA_ "GenMsgCycleTime" BO_ 7 1; BA_ "GenMsgCycleTime" BO_ 8 1; BA_ "GenMsgCycleTime" BO_ 9 1; BA_ "GenMsgCycleTime" BO_ 10 1; BA_ "GenMsgCycleTime" BO_ 11 1; BA_ "GenMsgCycleTime" BO_ 12 10; BA_ "GenMsgCycleTime" BO_ 13 10; BA_ "GenMsgCycleTime" BO_ 17 10; BA_ "GenMsgCycleTime" BO_ 18 10; BA_ "GenMsgCycleTime" BO_ 19 10;

• Let's understand the above portion of the DBC file. The first line tells the python parser that the user has five nodes in the CAN implementation. In the TopGun project, we have total five nodes -> SENSOR, DRIVER(master), MOTOR, BLUETOOTH, GEO.

• Execute the following commands in the command line argument to generate the API for the motor controller node.
  • $python dbc_parse.py -i TopGun_12_38am_11_16_2015.dbc -s MOTORIO > generated_code_MOTORIO.c
• The above command will generate the code for the generated_code_MOTORIO.c file

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.

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

• Sourceforge Source Code Link
• Gitlab Source Code Link

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.