F15: TopGun
Contents
- 1 Grading Criteria
- 2 Project Title
- 3 Abstract
- 4 Objectives & Introduction
- 5 Schedule
- 6 Parts List & Cost
- 7 Design & Implementation
- 8 Testing & Technical Challenges
- 9 Conclusion
- 10 References
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 |
|
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 |
|
Completed | 10/05/2015 |
| 3 | 10/05/2015 | 10/12/2015 |
|
Completed | 10/12/2015 |
| 4 | 10/12/2015 | 10/30/2015 |
|
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 |
|
Completed | 10/10/2015 |
| 3 | 10/10/2015 | 10/22/2015 |
|
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 |
|
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
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.
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;
- 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.
- 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.
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.
