|
|
| Line 405: |
Line 405: |
| | == '''Design & Implementation''' == | | == '''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. | | 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 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. |
| | | | |
| | [[File:CmpE243_F17_T1_HWDesign_Board.png|centre|1200px|thumb|Board]] | | [[File:CmpE243_F17_T1_HWDesign_Board.png|centre|1200px|thumb|Board]] |
| Line 410: |
Line 413: |
| | [[File:CmpE243_F17_T1_HWDesign_Schematic.png|centre|1200px|thumb|Schematic]] | | [[File:CmpE243_F17_T1_HWDesign_Schematic.png|centre|1200px|thumb|Schematic]] |
| | Discuss your hardware design here. Show detailed schematics, and the interface here. | | 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''' === | | === '''Software Design''' === |
Revision as of 00:56, 3 December 2017
Project Title
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller
Abstract
This section should be a couple lines to describe what your project does.
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
- Android App, Bluetooth/App Interface
Schedule
Legend:
Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal
| Week#
|
Date
|
Planned Task
|
Actual
|
Status
|
| 1
|
9/23/2017
|
- Decide roles for each team member
- Read FY16 project reports and understand requirements
- Setup Gitlab project readme
- Ordered CAN Tranceivers and get R/C car
|
- Team roles are decided and module owners are assigned
- Gitlab project is set
- Ordered CAN tranceivers and got R/C Car
|
Complete.
|
| 2
|
9/30/2016
|
- Design software architecture for each module and design signal interfaces between modules
- Setup Wiki Project Report template
- Design Hardware layout of system components
- Create component checklist and order required components for individual modules.
- Setup Gitlab project code for each modules
|
- Overall project requirements are understood
- Wiki Project report setup is done
- Odered components for Geo controller module
- Initial commit of project base is done
|
Complete
|
| 3
|
10/14/2016
|
- Major Feature: Implement Free run mode
- Implement heartbeat messages and initial system bootup sync between modules
- Interface the RPLidar to SJOne board via UART
- Achieve basic communication such as obtaining the device and health info.
- Study of Android Toolkit for Bluetooth Adapter connections and APIs
- Study of HC-05 Bluetooth Module
- Creating APIs for Start/ STOP button requests to write to output-Stream buffers
- Creating RFComm SPP Connection socket and the rest of UI for basic operation of Pairing, Connection
- Checking the AT Command sequence for Bluetooth Operation and Pairing
- Automating the AT Command sequence for Bluetooth HC-05 operation and Android App
- Run Motors via commands from SJOne Automatically
- Order the RPM sensor module for the Drive Controller
- Design and Order PCB
|
- Major Feature: Implemented Free run mode
- Added hearbeat messages from all controllers to master in can_db and implemented the handling functions in master controller
- Implemented speed steer command CAN msg transmission and handling in Master controller. Master-Drive integration phase-I
- Interfaced RPLidar to SJOne board and achieved basic communication via UART. Started obtaining data as well.
- Android:Android API for Bluetooth Adapter connections studied.
- Android:Learning of AT Command sequence for Bluetooth Operation and Pairing done.
- Android:Created Start/Stop API's for button requests to be Sent to HC-05 IC.
- Android:Basic Pairing Operation Working.
- Motor: ESC Traxxas XL-5 (Electronic Speed Control) interfaced to SJOne board
- Tested and identified duty cycles for different speeds required; Callibration and testing of ESC is over exteral switch at P0.1
- Ordered RPM sensor
|
Complete
|
| 4
|
10/21/2016
|
- Major Feature: Implement Basic Obstacle Avoidance in Free-run mode
- Add all modules CAN messages to DBC file
- Test steer and speed CAN commands between Master and Motor
- Implement Obstacle avoidance algorithm
- Obtain data from the lidar and process the data i.e. decide on the format in which the data has to be sent to the master
- Write unit test cases for the lidar.
- Interface compass module to SJOne board and calibrate the errors
- find the heading and bearing angle based on mocked checkpoint
- Test and verify GPS module outdoor to receive valid data and check for errors
- Calibrate the GPS module error
- Design and implement the DRIVE_CONTROLLER STEER/SPEED interface with Master (TDD)
- Install the new RPM sensor module for the Drive Controller
- Operating motors based on the CAN messages from the Master
|
- Major Feature: Implemented Free-run mode w/o obstacle avoidance
- Added all modules basic CAN messages in can_db
- Implemented interface files in master controller to handle CAN messages from all nodes to master
- Implemented Master-Drive controller Integration
- Implemented Master-Bluetooth controller integration
- Added all modules basic CAN messages in can_db
- GPS integrated to SJONE board
- Added all modules basic CAN messages in can_db
- Wrote unit test cases for the LIDAR.
- Wrote logic for dividing the information obtained from the lidar into sectors and tracks.
- MASTER_SPEED_STEER_CMD was defined to use 8-bits for speed control (neutral, forward, and reverse); 9-bits for steer control (straight, left, and right)
- Designed glue code: DriveManager and hardware interface code: DriveController using TDD (test code in _MOTOR/_cgreen_test/)
- Got the Traxxas #6520 RPM sensor; installed the same with the slipper clutch; Observed the RPM sensor trigger over an oscilloscope and found the minimum distance of magnet to RPM sensor is not achievable with the stock slipper clutch. Ordered Traxxas #6878 new slipper clutch and ball-bearings
- Master - Drive Controller Interface implemented and tested over CAN; Check "drive" terminal command on Master controller
|
complete
|
| 5
|
10/28/2016
|
- Major Feature: Implement maneuvering in Master controller
- Implement maneuvering algorithm to drive steering angle of the servo
- Implement maneuvering algorithm to control ESC speed
- Test and validate the information obtained from the sensor.
- Send the Lidar data and heartbeat over CAN.
- LIDAR should be fully working.
- Identify the basic speed(s) at which the car shall move; the min, max and normal forward speeds, and the min and normal reverse speeds
- Interface the RPM sensor over ADC and validate the readings
- Writing PID Algorithm for Motor Control
- Calibrating PID constants according to the Motors
- Testing the Bluetooth Range and multiple pairing option to establish security of the Master device
- Testing the accuracy of GPS while moving
- Made the code modular and added the wrapper function for all the important modules
- Worked on android app which will dump the lattitude and longitude information for checkpoints
- Test the accuracy of GPS while moving
- Get the code review done and do the testing after that
- Worked on the Android app that will dump the checkpoints into a file
- Finish PCB design and place order
|
- Major Feature: Implemented maneuvering in Master-Geo controller
- Major Feature: Implemented Basic Obstacle Avoidance in Free-run mode
- Implement maneuvering algorithm in android app is moved to next week schedule
- Implemented maneuvering algorithm in Master to drive steering angle of the servo
- Implement maneuvering algorithm in Master to control ESC speed
- Tested and validated the sensor data by plotting graphs in an EXCEL sheet.
- Sending the obstacle information and heartbeat over CAN.
- LIDAR fully working and sending obstacle information.
- Completed PCB Design
- Identified basic speeds, slow, normal, and turbo for forward and reverse
- Interfaced the RPM sensor over GPIO and validated; but the clutch gear with magnet was far apart from the RPM Sensor
- Wrote the PID code keeping future integration in mind; Have pushed the code
- Failed to use RPM sensor - new clutch gear also did not work (magnet is too far away - validated with Oscilloscope); Have to consider using IR sensor for feedback
- Android:Tested successfully individual and multiple Device pairing.
- Android:Android app updated with Navigation and Drawer Modules with Detecting NAV points.
- Tested the accuracy of GPS while moving
- Made the GPS and compass code modular and checked the functionaity after the changes
- Worked on the Android app that will dump the checkpoints into a file
|
Complete
|
| 6
|
11/07/2016
|
- Major Feature: Implement maneuvering with mocked GEO checkpoints
- Collect mock checkpoints using the Android Data Collector application
- Collect mock checkpoints using the GEO module and compare for any discrepancies
- Identify I/O on-board Display information; Currenly identified are documented below:
- Health status like GPS Lock status, etc.
- Identify hardware to check battery-status and procure the same; update PCB as well
- Display bluetooth pairing status
- Test on-board I/O module for bluetooth pairing status
- In case RPM installation/usage fail, Identify new mechanism for feedback and order components; Update PCB as well to include new hardware
- Implement simple feature additions on steer control to handle reverse; basically steering rear-left and rear-right has to be practically implemented on motor/drive controller
- Receive GEO Controller's Turning-angle message and compute target steer
- Use GEO Controller's distance to next-checkpoint information to compute target speed
- Mock checkpoint navigation testing using different possible obstacle heights and forms possible
- Identify advertisement messages on the DBC file and add documentation in Wiki; Currently identified advertisements: a) current GEO location, b) SENSOR radar map
- Shall define the BLE Controller to android message structure and message generation-intervals (classify on-demand advertisements and periodic advertisements)
- Implement marker for current location display - which is an on-demand advertisement
- Implement feature for the user to enter destination - a Google Map View shall be shown to the user to confirm route from source(current car location) to destination
- Android app (once on the new device) shall download the entire offline map information of the SJSU campus and store it on a SQLite database
|
- Major Feature: Implemented maneuvering with mocked GEO checkpoints
- Provided Mock checkpoints and used the heading and bearing angle logic to get the turning angle
- Collected mock checkpoints and check for the error with different places
- Interfaced the Sparkfun Seven segment display with the SJOne Board.
- Implemented interface method to receive GEO Controller's Turning-angle message and set target steer
- Target speed is not changed between checkpoints.So geo feedback for distance to destination is not used in design
- Android:Implemented Marker for current position Display.
- Android:User entry for setting up destination on MAP done.
- RPM Installation failed, but could get auxiliary hardware (motor pinion) from local shop and get it working
- Implemented basic motor feedback using hall sensor (RPM sensor); tested working on ramps
- Steer left and right on reverse now follows natural order; Could not finish literal reverse-left and reverse-right implementation; Moved this task forward; Had to test and implement motor feedback this week
|
Ontrack
|
| 7
|
11/14/2016
|
- Major Feature: Implementing maneuvering with Android app supplied GEO checkpoints with on-board I/O
- Use mock data from file to compute: a) Heading b) Bearing -> use Haversine's algorithm to compute turning angle
- Advertise distance to the next checkpoint (again using Haversine's algorithm)
- Save the proper checkpoints for one route (Clark's to SU) to SDCARD on GEO Controller
- Implement the battery-status DBC Message advertisement
- Indicate checkpoint proximity using backlight indicators
- Create 2 CAN messages for Disgnostic and I/O data to transmit it to BLE module
- Receive the diagnostic CAN message and decode to transmit it to Android App
- [Android I/O:] Design Android app views for visualizing Diagnostic and I/O data
- Test and validate success/fail cases for on-board I/O display information(as defined above)
- Update PWM pulses to match MASTER's target speed with proper feedback from the identified feedback-mechanism
- Identify PID constants kp, ki, kd and evaluate performance against the basic feedback implementation
- Finalize feedback algorithm and fine-tuning
- Collect all advertisement messages (check above Wiki documentation) and send them to the android application at a defined interval
- Implement (use Google APIs) to calculate route-path between given source and destination checkpoints; Shall indicate error where either source/destination is entered outside campus
- Come up with template for practical testing; Identify all possible ground-scenarios and test cases like: a) Incluned planes, b) Grass / sand, c) Between buildings, etc
|
|
Planned.
|
| 8
|
11/21/2016
|
- Major Feature: Complete maneuvering implementation with Android app and Android I/O
- [Android I/O:] Implement display of Sensor Obstacle Information on a RADAR map
- [Android I/O:] Dynamically update car's Current location on the map's route path
- [Android I/O:] Health information from BLE Controller, namely battery, GPS lock status, and motor speed shall be updated
- Test achievable target speeds with different possible obstacle heights and forms possible, and ground conditions
|
|
Planned.
|
| 9
|
11/28/2016
|
- Major Feature: Full feature integration test
- Execute the test plan created above [Planned for 11/14] (check Testing documentation in Wiki)
- Execute the test plan created above [Planned for 11/14]; Phase 1: Test all identified cases for ground-conditions (grass, inclines, etc)
- Execute the test plan created above [Planned for 11/14]; Phase 2: Test all identified cases for GPS routes and obstacle forms
|
|
Planned.
|
| 10
|
12/5/2016
|
- Major Feature: Full feature integration test
- Execute the test plan created above [Planned for 11/14]; Phase 3: Test all identified cases for speed levels and on-board I/O validation
- Execute the test plan created above [Planned for 11/14]; Phase 4: Test all identified cases for [Android I/O] validation
|
|
Planned
|
| 11
|
12/12/2016
|
- Major Feature: Full feature integration test
- Execute the test plan created above [Planned for 11/14]; Phase 5: Test all identified cases for desired Turbo mode(s)
- Update Wiki Complete Report
|
|
Parts List & Cost
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
CAN Communication
DBC File
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc
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 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.
Discuss your hardware design here. Show detailed schematics, and the interface here.
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.
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.
Testing & Technical Challenges
Testing the car out on the grounds was the prime responsibility of the team.
Individual modules like Sensor (LiDAR), Motor (The ESC and Servo), GPS & Compass, the android application and the Bluetooth bridge were tested by respective team members.
But, the most important problems are being found with the Testing we do with the integrated whole.
Include sub-sections that list out a problem and solution, such as:
Unit Test Cases
Discuss the major unit test cases.
Technical Challenges
Drive (Motor) Controller
ESC Calibration
We messed up the callibration on the ESC.
"XL 5 had a long press option to calibrate the ESC, where the ESC shall:
a) After long press, glow green and start taking PWM signals for neutral (1.5).
b) Glow green once again where we shall feed in PWM signals for Forward (2ms).
b) Glow green twice again where we shall feed in PWM signals for Reverse (1ms)."
-We wrote code to calibrate using EXT-INT (EINT3) over P0.1 - switch to calibrate the ESC this way!
ESC Reverse
"The ESC was not activating reverse if we directly - as in the datasheet (no formal datasheet - only XL 5 forums - talked about 1ms pulse width at 50Hz for reverse).
We figured out that Reverse is actually 3 steps:
a) goNeutral()
b) goReverse()
c) goNeutral()
d) goReverse()
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.
