Difference between revisions of "F14: Self Driving Undergrad Team"
Proj user8 (talk | contribs) (→Master Controller Issue #4) |
Proj user8 (talk | contribs) (→Grading Criteria) |
||
(67 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Chi Lam == | == Chi Lam == | ||
<center> | <center> | ||
Line 26: | Line 15: | ||
== Objectives & Introduction == | == Objectives & Introduction == | ||
− | |||
+ | |||
+ | <br> | ||
[[File:CmpE243_F14_TUndergrad_HighLevelDiagram.jpg|700px|centre|thumb|Overall System Communication Diagram]] | [[File:CmpE243_F14_TUndergrad_HighLevelDiagram.jpg|700px|centre|thumb|Overall System Communication Diagram]] | ||
+ | |||
+ | |||
=== Team Members & Responsibilities === | === Team Members & Responsibilities === | ||
+ | |||
The team consisted of 15 undergraduate students taking a graduate level course, thus competing against the Master's level students. <br> | The team consisted of 15 undergraduate students taking a graduate level course, thus competing against the Master's level students. <br> | ||
<H1> | <H1> | ||
− | We are <br> | + | We are <br> |
+ | |||
[[File:CmpE243_F14_TeamUndergrad_TULogo.jpg|700px]] | [[File:CmpE243_F14_TeamUndergrad_TULogo.jpg|700px]] | ||
Line 50: | Line 44: | ||
| - Overall vehicle logic<br/>- Overall software vehicle Integration<br/>- CAN TX/RX messages architecture | | - Overall vehicle logic<br/>- Overall software vehicle Integration<br/>- CAN TX/RX messages architecture | ||
| - Vehicle hardware interfacing<br/>- Assistant to other teams<br/>- Module specific logic | | - Vehicle hardware interfacing<br/>- Assistant to other teams<br/>- Module specific logic | ||
− | | - Module specific logic<br/>- CAN RX processing | + | | - Module specific logic<br/>- CAN RX processing<br/>- GPS waypoint logic |
|- | |- | ||
|} | |} | ||
Line 153: | Line 147: | ||
| 11/7 | | 11/7 | ||
| Basic Vehicle Self-Driving Test | | Basic Vehicle Self-Driving Test | ||
− | | | + | | Complete |
|- | |- | ||
! scope="row"| 5 | ! scope="row"| 5 | ||
| 11/14 | | 11/14 | ||
| P2P testing and improved obstacle avoidance | | P2P testing and improved obstacle avoidance | ||
− | | | + | | Complete |
|- | |- | ||
! scope="row"| 6 | ! scope="row"| 6 | ||
| 11/31 | | 11/31 | ||
| Buffer time for previous tasks and increased vehicle speed | | Buffer time for previous tasks and increased vehicle speed | ||
− | | | + | | Complete |
|} | |} | ||
Line 418: | Line 412: | ||
! scope="row"| 5 | ! scope="row"| 5 | ||
| 10/29 | | 10/29 | ||
− | | | + | | Implement calibration algorithm |
| Complete | | Complete | ||
|- | |- | ||
Line 429: | Line 423: | ||
| 10/29 | | 10/29 | ||
| Compass use heading from GPS to improve accuracy | | Compass use heading from GPS to improve accuracy | ||
− | | | + | | N/A - Decided that magnetometer provides accurate enough reading |
|- | |- | ||
! scope="row"| 8 | ! scope="row"| 8 | ||
Line 444: | Line 438: | ||
| 11/12 | | 11/12 | ||
| Fine tune compass calibration technique for accuracy | | Fine tune compass calibration technique for accuracy | ||
− | | Complete - Compass still about | + | | Complete - Compass still about 20 degrees off, but well within usable margins. Offset likely due to nearby power source on car. |
|- | |- | ||
! scope="row"| 11 | ! scope="row"| 11 | ||
Line 451: | Line 445: | ||
| Complete | | Complete | ||
|} | |} | ||
− | |||
'''Master Controller Schedule''' | '''Master Controller Schedule''' | ||
Line 681: | Line 674: | ||
| | | | ||
| | | | ||
− | | $ | + | | $0.00 |
|- | |- | ||
! scope="row"| | ! scope="row"| | ||
Line 688: | Line 681: | ||
| | | | ||
| | | | ||
− | | $ | + | | $1199.66 |
|- | |- | ||
|} | |} | ||
== Design & Implementation == | == Design & Implementation == | ||
− | |||
=== Hardware Design === | === Hardware Design === | ||
Line 719: | Line 711: | ||
<b>SN65HVD230 CAN Board Transceiver:</b> | <b>SN65HVD230 CAN Board Transceiver:</b> | ||
<br> | <br> | ||
− | |||
− | |||
The SN65HVD230 CAN board transceiver is used to interface the microcontrollers logical signals to CAN electrical specifications. The SN65HVD230 CAN board transceiver was chosen specifically because not only did it work perfectly for CAN interfacing, but it came pre-built with the in-line resistors. Because there were fifteen people in our team, this was desired because a lot of work would be needed if we built each CAN board transceiver individually. The transceivers were purchased on eBay for $8.99 each. However, the item's location was in China, so ordering early would be best for future students. | The SN65HVD230 CAN board transceiver is used to interface the microcontrollers logical signals to CAN electrical specifications. The SN65HVD230 CAN board transceiver was chosen specifically because not only did it work perfectly for CAN interfacing, but it came pre-built with the in-line resistors. Because there were fifteen people in our team, this was desired because a lot of work would be needed if we built each CAN board transceiver individually. The transceivers were purchased on eBay for $8.99 each. However, the item's location was in China, so ordering early would be best for future students. | ||
</td> | </td> | ||
Line 1,224: | Line 1,214: | ||
<b>uLCD-35DT Intelligent Display Module:</b> | <b>uLCD-35DT Intelligent Display Module:</b> | ||
<br> | <br> | ||
− | |||
− | |||
The uLCD-35DT is an intelligent display module used to display information of the system, such as viewing the GPS destination, and a controller for the system, such as setting the car to indoor mode which tests for sensor only navigation. The uLCD-35DT system was chosen specifically because of its touch screen capabilities. | The uLCD-35DT is an intelligent display module used to display information of the system, such as viewing the GPS destination, and a controller for the system, such as setting the car to indoor mode which tests for sensor only navigation. The uLCD-35DT system was chosen specifically because of its touch screen capabilities. | ||
The display is driven by A DIABLO16 processor. The processor allows stand-alone functionality for the screen. In order to program the screen with an interactive GUI, the 4D Systems Workshop 4 IDE Software was used. | The display is driven by A DIABLO16 processor. The processor allows stand-alone functionality for the screen. In order to program the screen with an interactive GUI, the 4D Systems Workshop 4 IDE Software was used. | ||
Line 1,666: | Line 1,654: | ||
<b>Adafruit MTK3339 GPS:</b> | <b>Adafruit MTK3339 GPS:</b> | ||
<br> | <br> | ||
− | + | This GPS unit from Adafruit provides an all-in-one package for a myriad of location-based functions, all hardcoded into the package itself and interfaced via UART. The core functionality is GPS, providing latitude and longitude accurately up to 5-10 meters with a strong satellite fix. The package also supports a 10 Hz update rate, so it maintains usability in higher speed applications. Additionally, this package has a built-in antennae, along with a uFL connector to allow for an external antennae with higher sensitivity. It also has a built in voltage regulator that regulates inputs between 3 and 5.5 volts. It outputs NMEA 0183, 9600 baud default. | |
+ | |||
+ | We chose this part because it provided the base functionality we needed along with many other functions that would be fun to play with and try to include in the project. The antennae options and voltage regulator were also very enticing. | ||
</td> | </td> | ||
<td> | <td> | ||
Line 1,678: | Line 1,668: | ||
<br> | <br> | ||
The device provides access to both a Compass and 3-Axis accelerometer. The device is interfaced via I2C. By using the a Compass with an Accelerometer, it is possible to do tilt compensation, for increased accuracy. | The device provides access to both a Compass and 3-Axis accelerometer. The device is interfaced via I2C. By using the a Compass with an Accelerometer, it is possible to do tilt compensation, for increased accuracy. | ||
− | In the team's current design, however this feature was not used. | + | In the team's current design, however this feature was not used. Additionally, the compass has a very high update rate, which was important when choosing a component that could support split-second decisions. |
</td> | </td> | ||
<td> | <td> | ||
Line 1,766: | Line 1,756: | ||
=== Hardware Interface === | === Hardware Interface === | ||
− | |||
− | |||
− | |||
− | |||
==== Sensor Controller Team Hardware Interface ==== | ==== Sensor Controller Team Hardware Interface ==== | ||
Line 1,816: | Line 1,802: | ||
==== Geographical Controller Team Hardware Interface ==== | ==== Geographical Controller Team Hardware Interface ==== | ||
− | + | The GPS module is interfaced over UART and powered via 3.3 volt input, both over the SJOne board. Since there is a built-in voltage regulator, power sources anywhere between 3 and 5.5 volts can be used. Once the package is properly connected to power, it begins outputting various sentence formats that contains the data it has calculated. The getSentence() function captures these sentences using a gets() statement. Since the data is unfiltered and raw, filtering commands and a parser need to be applied to this hardware component. Using putline() statements, a specific string can be sent over UART to the GPS module. This is used to send the command telling the GPS to only provide RMC values, or Recommended Minimum Navigation Information. The RMC values are provided as a sentence of comma separated variables, so a parser was developed to retrieve the needed information. The following except of code is an example of part of the parser that retrieves the longitude value from the raw GPS output and converts it to a usable value. | |
− | + | ||
− | + | while(sscanf(ptr, "%31[^,]%n", field, &n) == 1){ | |
+ | a++; | ||
+ | if(a==6){ | ||
+ | for(int i=0; i<3; i++) | ||
+ | degField[i] = field[i]; | ||
+ | for(int j=3; j<10; j++) | ||
+ | minField[j-3] = field[j]; | ||
+ | deg = (float)atof(degField); | ||
+ | min = (float)atof(minField); | ||
+ | myLongitude = (deg + (min/60)) * (-1); | ||
+ | } | ||
+ | ptr += n; | ||
+ | if(*ptr != ',') | ||
+ | break; | ||
+ | while(*ptr == ',') | ||
+ | ++ptr; | ||
+ | } | ||
+ | |||
+ | Lastly, the bearing is calculated from these values, shown below. | ||
+ | |||
+ | bearing = atan2(sin(deltaLong)*cos(endLat),cos(Location.latitude)*sin(endLat)-sin( Location.latitude)*cos(endLat)*cos(deltaLong))*180/3.14159; | ||
+ | |||
+ | The compass module is interfaced over I2C and is powered via a 5 volt power source. Given the device's sensitivity to magnetic fields and angles, it was important to place the device on a level surface away from any magnetic disturbances. For this reason, the GPS antenna was placed on a tower. This is because the GPS antenna has a powerful magnet on the bottom to allow it to attach to metal surfaces. Furthermore, in hindsight, the package should also have been placed away from the power sources. The concentrated area of power cables could be inducing a magnetic field and interfering with magnetometer readings. The driver for this device simply receives the x, y, and z values from the magnetometer and accelerometer. The accelerometer ended up producing erratic values, so only the magnetometer values were utilized. These magnetometer values were input into a trig formula (shown below) to calculate the angle at which the device is pointing relative to magnetic north. | ||
+ | |||
+ | heading = (float)(atan((float)x_axis_m/(float)y_axis_m)*((float)180/M_PI)); | ||
+ | |||
+ | The SJOne board is connected to a CAN transceiver that converts voltage levels between UART and CAN so the board can communicate with other boards over the CAN bus. Geo listens for master's heartbeat message, 0x100, and then responds with an acknowledgement. Additionally, geo listens for message 0x140 from master, which indicates the destination coordinates that it has received from bridge. In return, geo broadcasts the following messages over CAN with the listed purposes. | ||
+ | |||
+ | 0x441 - Transmits Current GPS Coordinates<br> | ||
+ | 0x445 - Transmits Current Heading and Bearing<br> | ||
+ | 0x449 - Transmits Current GPS Heading<br> | ||
+ | |||
==== Master Controller Team Hardware Interface ==== | ==== Master Controller Team Hardware Interface ==== | ||
− | === Software Design=== | + | ===Software Design=== |
− | |||
− | + | ====Sensor Controller Team Software Design==== | |
− | + | Sensor software design is composed of three crucial tasks, which are to read GPIO based sonar, read ADC based sonar, and CAN TX. | |
− | ==== Sensor Controller Team Software Design==== | + | <br> |
− | + | <b>GPIO based read:</b> | |
− | + | [[File:CMPE243_F14_sensorFlow1j.jpg]] | |
+ | <br> | ||
+ | <b>ADC based read:</b> | ||
+ | <br> | ||
+ | [[File:CMPE243_F14_sonarFlow2.png]] | ||
+ | <br> | ||
+ | <b>CAN Frame write:</b> | ||
+ | <br> | ||
+ | [[File:CMPE243_F14_sonarFlow3.png]] | ||
==== Motor Controller Team Software Design==== | ==== Motor Controller Team Software Design==== | ||
Line 1,936: | Line 1,960: | ||
An Android application was created that would send messages to a selected paired device. This application would first display a list of paired devices and prompt the user to select a paired device to connect to: | An Android application was created that would send messages to a selected paired device. This application would first display a list of paired devices and prompt the user to select a paired device to connect to: | ||
− | [[File:CMPE243_F14_TeamUndergrad_Android1. | + | [[File:CMPE243_F14_TeamUndergrad_Android1.png|500px]] |
− | After successfully connecting, the application shows a Google Map on the left side and various buttons on the right side. There is always a floating pin in the center of the map | + | After successfully connecting, the application shows a Google Map on the left side and various buttons on the right side. There is always a floating pin in the center of the map. Upon setting a waypoint, the a pin is dropped at the specified location. Waypoints are cleared when turning the vehicle off. |
[[File:CMPE243_F14_TeamUndergrad_Android2.jpg|500px]] | [[File:CMPE243_F14_TeamUndergrad_Android2.jpg|500px]] | ||
Line 1,944: | Line 1,968: | ||
The functionality of the buttons is as follows: | The functionality of the buttons is as follows: | ||
− | Vehicle Off: Sends the message "bluecmd 056" over Bluetooth. | + | '''Vehicle Off:''' Sends the message "bluecmd 056" over Bluetooth. |
− | GPS Mode: Sends the message "bluecmd 051" over Bluetooth. | + | '''GPS Mode:''' Sends the message "bluecmd 051" over Bluetooth. |
− | Vehicle On: Sends the message "bluecmd 057" over Bluetooth. | + | '''Vehicle On:''' Sends the message "bluecmd 057" over Bluetooth. |
− | Set Waypoint: Sends the message "bluenav [latitude], [longitude]" over Bluetooth. | + | '''Set Waypoint:''' Sends the message "bluenav [latitude], [longitude]" over Bluetooth. |
− | Start Driving: Sends the message "bluecmd 055" over Bluetooth. | + | '''Start Driving:''' Sends the message "bluecmd 055" over Bluetooth. |
− | These messages are received by the XBee Bluetooth module and parsed by the terminal task. The terminal task then | + | These messages are received by the XBee Bluetooth module and parsed by the terminal task. The terminal task then sends the corresponding CAN messages. |
+ | ---- | ||
==== Geographical Controller Team Software Design==== | ==== Geographical Controller Team Software Design==== | ||
+ | The following diagram shows the software design we followed for the duration of this project. | ||
+ | |||
[[File:CmpE243_F14_TeamUndergrad_GEO_software_interface_design.jpg|600px]] | [[File:CmpE243_F14_TeamUndergrad_GEO_software_interface_design.jpg|600px]] | ||
− | + | All the tasks involved are initialized inside the board_init.cpp file underneath the FullInit() function. All this function does is add tasks to the scheduler in the program as shown in the following figure. | |
+ | [[File:BoardInit.png]] | ||
− | The master controller has a single receive task that fans out the messages into individual "modules". The modules then either store the data from the incoming messages into the module's variables, or call the vehicle logic API functions to alter the state of the vehicle. | + | ''' GPS_L_Task: ''' Uses the GPS API developed by one of our members to compute GPS location, heading, and time data as well as modify the relative can_msg_t types simultaneously. |
+ | |||
+ | ''' HeadingTask: ''' Uses Heading API developed by one of our members to retrieve information from the compass device regarding magnetometer and accelerometer readings. It also takes in data regarding the destination coordinates and computes bearing. | ||
+ | |||
+ | ''' CanRx_task: ''' Watches for any incoming messages meant for the GPS controller (filters by message ID). It also has this super-cool feature where it makes an LED on the host micro-controller blink when there is an incoming message. Function is called makeBlinkyLightGoWhenRx(). | ||
+ | |||
+ | ''' CanTx_task: ''' Transmits the can_msg_t types at the rate of the specified enum parameter. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Master Controller Team Software Design==== | ||
+ | |||
+ | The master controller has a single receive task that fans out the messages into individual "modules". The modules then either store the data from the incoming messages into the module's variables, or call the vehicle logic API functions to alter the state of the vehicle. | ||
[[File:F14_243_undergrad_master_arch.png]] | [[File:F14_243_undergrad_master_arch.png]] | ||
Line 1,970: | Line 2,010: | ||
=== Software Interface=== | === Software Interface=== | ||
− | |||
− | |||
==== Sensor Controller Team Software Interface ==== | ==== Sensor Controller Team Software Interface ==== | ||
Line 1,991: | Line 2,029: | ||
==== I/O Team Software Interface ==== | ==== I/O Team Software Interface ==== | ||
− | |||
[[File:CMPE243_F14_TeamUndergrad_IOSoftwareInterface.png]] | [[File:CMPE243_F14_TeamUndergrad_IOSoftwareInterface.png]] | ||
+ | |||
+ | |||
[[File:CmpE243 F14 TUndergrad IOFileLevel.jpg]] | [[File:CmpE243 F14 TUndergrad IOFileLevel.jpg]] | ||
==== Communication Bridge + Android Software Interface ==== | ==== Communication Bridge + Android Software Interface ==== | ||
− | [[File: | + | [[File:CmpE243_F14_TeamUndergrad_Bridge_Software_Interface.png]] |
− | + | [[File:CmpE243_F14_TeamUndergrad_Bridge_function_tree.png]] | |
+ | |||
+ | <br style="clear:both;" /> | ||
==== Geographical Controller Team Software Interface ==== | ==== Geographical Controller Team Software Interface ==== | ||
Line 2,102: | Line 2,143: | ||
|- | |- | ||
|} | |} | ||
− | |||
'''Geo CAN Communication Table''' | '''Geo CAN Communication Table''' | ||
Line 2,299: | Line 2,339: | ||
==== Sensor Controller Testing #1 ==== | ==== Sensor Controller Testing #1 ==== | ||
− | |||
− | |||
1. For individual sensors: Set a obstacle(36" x 48" poster board) in front of a sensor and sensor team verifies the sensor values with a ruler. Repeat this process with different distances (20cm, 40cm,and 60cm). | 1. For individual sensors: Set a obstacle(36" x 48" poster board) in front of a sensor and sensor team verifies the sensor values with a ruler. Repeat this process with different distances (20cm, 40cm,and 60cm). | ||
+ | <br> | ||
2. Detect any outlier: Set a obstacle and allow sensor to detect for period of time and sensor team verifies values within the period. If there were outliers, sensor team would verify the wiring or write a filtering algorithm. | 2. Detect any outlier: Set a obstacle and allow sensor to detect for period of time and sensor team verifies values within the period. If there were outliers, sensor team would verify the wiring or write a filtering algorithm. | ||
+ | <br> | ||
3. Integrated test: After all sensors are tested individually, sensor team tested collaboratively with master. Sensor team would sent CAN message (5 sensor values) to master team and check if master team can perform certain operations according to different sensor values. | 3. Integrated test: After all sensors are tested individually, sensor team tested collaboratively with master. Sensor team would sent CAN message (5 sensor values) to master team and check if master team can perform certain operations according to different sensor values. | ||
---- | ---- | ||
Line 2,347: | Line 2,387: | ||
==== Communication Bridge + Android Testing #1: Terminal Commands ==== | ==== Communication Bridge + Android Testing #1: Terminal Commands ==== | ||
Two new terminal commands were added to the existing terminal task: bluenav (for sending coordinates over CAN) and bluecmd (for sending other messages over CAN). In order to test the functionality of these commands, a logging function was built into each new function. Various commands were sent to the terminal, the log file was subsequently viewed, and it was confirmed that these two terminal tasks parsed the inputs properly and would send the expected messages. | Two new terminal commands were added to the existing terminal task: bluenav (for sending coordinates over CAN) and bluecmd (for sending other messages over CAN). In order to test the functionality of these commands, a logging function was built into each new function. Various commands were sent to the terminal, the log file was subsequently viewed, and it was confirmed that these two terminal tasks parsed the inputs properly and would send the expected messages. | ||
− | |||
==== Communication Bridge + Android Testing #2: Android Bluetooth messages ==== | ==== Communication Bridge + Android Testing #2: Android Bluetooth messages ==== | ||
The Android application's message sending functionality was tested. First, the Android device was paired with a laptop. After successful pairing, a serial terminal was opened between the laptop and Android device via Bluetooth. Buttons were pressed on the Android application, and it was confirmed that the expected messages were being sent from the Android application over Bluetooth, as they could be read in the serial terminal on the laptop. | The Android application's message sending functionality was tested. First, the Android device was paired with a laptop. After successful pairing, a serial terminal was opened between the laptop and Android device via Bluetooth. Buttons were pressed on the Android application, and it was confirmed that the expected messages were being sent from the Android application over Bluetooth, as they could be read in the serial terminal on the laptop. | ||
− | |||
==== Communication Bridge + Android Testing #3: Full System ==== | ==== Communication Bridge + Android Testing #3: Full System ==== | ||
After confirming operation of the Android application and the new terminal commands, the full system was tested. The bridge board was connected to the master board, and the Android device was paired with the SJOne board. Buttons were pressed on the Android application, and proper operation was confirmed in two ways: looking at the serial output of the master board and viewing sent GPS coordinates on the LCD screen. All messages were sent as expected. | After confirming operation of the Android application and the new terminal commands, the full system was tested. The bridge board was connected to the master board, and the Android device was paired with the SJOne board. Buttons were pressed on the Android application, and proper operation was confirmed in two ways: looking at the serial output of the master board and viewing sent GPS coordinates on the LCD screen. All messages were sent as expected. | ||
+ | |||
---- | ---- | ||
=== Geographical Controller Testing=== | === Geographical Controller Testing=== | ||
− | ==== Geographical Controller ==== | + | ==== Geographical Controller Testing - Overall System==== |
− | There are two devices interfaced with the Geographical Controller, the GPS and compass. The GPS is responsible for retrieving the coordinates of the device's location and the compass is responsible for producing magnetometer and accelerometer data. Therefore there are three things that must be tested: GPS, magnetometer, and accelerometer data. There are simple test cases that could be made to verify that the values produced by these modules are correct. Take the GPS module for example, by comparing the latitude and longitude from the module to the true values of | + | There are two devices interfaced with the Geographical Controller, the GPS and compass. The GPS is responsible for retrieving the coordinates of the device's location and the compass is responsible for producing magnetometer and accelerometer data. Therefore there are three things that must be tested: GPS, magnetometer, and accelerometer data. There are simple test cases that could be made to verify that the values produced by these modules are correct. Take the GPS module for example, by comparing the latitude and longitude from the module to the true values of its location (from Google maps), one can verify the functionality of the device. |
+ | |||
+ | ==== Geographical Controller Testing - GPS ==== | ||
+ | Testing the GPS module is straightforward. To verify that we can retain the values of the module's current location, we continuously physically changed locations and compared them to the values given by Google Maps. The printf() function was extensively used throughout the duration of this test to see what the module was producing so it could be compared with the true values provided by Google. | ||
+ | |||
+ | ==== Geographical Controller Testing - Compass ==== | ||
+ | We needed the compass for two things: accelerometer and magnetometer readings. The first thing to test is the accuracy of these values. Following a similar test case for the GPS module, we tested (and calibrated when necessary) the values for the accelerometer and magnetometer. Using printf statements, we observed the values returned by the module. This is where we first noticed that the accelerometer values were erratic at times and could not produce reliable results. Furthermore, this is also how we discovered that the magnetometer did not produce negative values when it should have been. Rather, it produced the negative value with 2^16 added to it. Knowing this, we were able to implement a correction algorithm. Once those values were verified, the algorithm to calculate heading was developed and tested. | ||
---- | ---- | ||
Line 2,390: | Line 2,435: | ||
'''FUTURE RECOMMENDATIONS:''' Before any software debugging, the hardware connections must be the first area to check because it is the easiest and fastest. | '''FUTURE RECOMMENDATIONS:''' Before any software debugging, the hardware connections must be the first area to check because it is the easiest and fastest. | ||
− | + | ---- | |
=== Motor Controller Team Issues === | === Motor Controller Team Issues === | ||
Line 2,416: | Line 2,461: | ||
'''FUTURE RECOMMENDATIONS:''' Prioritize mounting a hall sensor with magnetic strips as soon as motor module is able to control car movement. | '''FUTURE RECOMMENDATIONS:''' Prioritize mounting a hall sensor with magnetic strips as soon as motor module is able to control car movement. | ||
+ | ---- | ||
=== I/O Team Issues === | === I/O Team Issues === | ||
Line 2,446: | Line 2,492: | ||
Find areas for optimizations to better improve performance. If analyzed closer, there could be other areas which could improve performance, but the screen seemed sufficiently responsive now. | Find areas for optimizations to better improve performance. If analyzed closer, there could be other areas which could improve performance, but the screen seemed sufficiently responsive now. | ||
+ | ---- | ||
+ | |||
=== Communication Bridge + Android Team Issues === | === Communication Bridge + Android Team Issues === | ||
Line 2,461: | Line 2,509: | ||
'''PROBLEM:'''When testing to see if the terminal task received the expected messages, the values would not print to the terminal. | '''PROBLEM:'''When testing to see if the terminal task received the expected messages, the values would not print to the terminal. | ||
− | '''RESOLUTION:''' It was assumed that the terminal task was operating properly and receiving commands from Bluetooth but printing the information back over UART. The terminal command code was rewritten to log information received instead of | + | '''RESOLUTION:''' It was assumed that the terminal task was operating properly and receiving commands from Bluetooth but printing the information back over UART. The terminal command code was rewritten to log information received instead of printing it. It was confirmed that messages were being received and parsed properly by the terminal task. |
'''FUTURE RECOMMENDATIONS:''' Make extensive use of the built in logging function. | '''FUTURE RECOMMENDATIONS:''' Make extensive use of the built in logging function. | ||
Line 2,472: | Line 2,520: | ||
'''FUTURE RECOMMENDATIONS:''' Implement a watchdog function that will reboot the board upon termination of Bluetooth connections. | '''FUTURE RECOMMENDATIONS:''' Implement a watchdog function that will reboot the board upon termination of Bluetooth connections. | ||
+ | ---- | ||
=== Geographical Controller Issues === | === Geographical Controller Issues === | ||
Line 2,496: | Line 2,545: | ||
'''FUTURE RECOMMENDATIONS:''' | '''FUTURE RECOMMENDATIONS:''' | ||
Create code to calibrate all modules to make sure the data produced are the same data that you're looking for before piecing the components together. | Create code to calibrate all modules to make sure the data produced are the same data that you're looking for before piecing the components together. | ||
+ | ---- | ||
=== Master Controller Team Issues === | === Master Controller Team Issues === | ||
Line 2,511: | Line 2,561: | ||
'''FUTURE RECOMMENDATIONS:''' | '''FUTURE RECOMMENDATIONS:''' | ||
− | + | Assure the data being sent by sensors is filtered. If the issue cannot be resolved, work together with the Sensor Team to debug and solve the issue. | |
==== Master Controller Issue #2 ==== | ==== Master Controller Issue #2 ==== | ||
'''BACKGROUND''' | '''BACKGROUND''' | ||
− | Geo | + | The heading being sent by Geo over CAN should be at a 10hz periodic rate. |
'''PROBLEM:''' | '''PROBLEM:''' | ||
Line 2,522: | Line 2,572: | ||
'''RESOLUTION:''' | '''RESOLUTION:''' | ||
− | Ask geo team to calibrate their heading data | + | Ask geo team to calibrate their heading data/ refactor calibration code. |
'''FUTURE RECOMMENDATIONS:''' | '''FUTURE RECOMMENDATIONS:''' | ||
− | + | Assure that the heading data being sent by the Geo team is calibrated. If the issue cannot be resolved, work together with the Geo Team to debug and solve the issue. | |
==== Master Controller Issue #3 ==== | ==== Master Controller Issue #3 ==== | ||
'''BACKGROUND''' | '''BACKGROUND''' | ||
− | + | Valid GPS latitude and longitude information transmitted over CAN should be at a 10hz periodic rate. | |
'''PROBLEM:''' | '''PROBLEM:''' | ||
Line 2,539: | Line 2,589: | ||
'''FUTURE RECOMMENDATIONS:''' | '''FUTURE RECOMMENDATIONS:''' | ||
− | + | Assure that the GPS latitude and longitude priority and timing issues are fixed. If the issue cannot be resolved, work together with the Geo Team to debug and solve the issue. | |
==== Master Controller Issue #4 ==== | ==== Master Controller Issue #4 ==== | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
'''BACKGROUND''' | '''BACKGROUND''' | ||
Line 2,567: | Line 2,603: | ||
'''FUTURE RECOMMENDATIONS:''' | '''FUTURE RECOMMENDATIONS:''' | ||
− | + | When debugging, review the overall algorithms to assure the design is valid. | |
== Conclusion == | == Conclusion == | ||
Overall, the team can conclude this project to be a success. Advice to future students taking this class is to establish clear goals for each individual team member. For each subteam, tailor each team member's goal to their strengths to create an overall effective subteam. Even though the weather, GIT, hardware, and FreeRTOS may have been common obstacles everyone faced, the team was able to successfully create a self driving GPS RC car via 6 subsystems using CAN communication. The team learned other important skills as well, including: team dynamics, hardware interference, various protocols, algorithms, and team workflow. These skills that were gained through this project can be scaled into other projects within the field. | Overall, the team can conclude this project to be a success. Advice to future students taking this class is to establish clear goals for each individual team member. For each subteam, tailor each team member's goal to their strengths to create an overall effective subteam. Even though the weather, GIT, hardware, and FreeRTOS may have been common obstacles everyone faced, the team was able to successfully create a self driving GPS RC car via 6 subsystems using CAN communication. The team learned other important skills as well, including: team dynamics, hardware interference, various protocols, algorithms, and team workflow. These skills that were gained through this project can be scaled into other projects within the field. | ||
− | |||
− | |||
=== Project Video === | === Project Video === | ||
− | + | http://youtu.be/fvZmUlMSQwU | |
=== Project Source Code === | === Project Source Code === | ||
− | * [https:// | + | * [https://gitlab.com/cpham/undergrad243/ GitLab Source Code Link] |
== References == | == References == |
Latest revision as of 19:43, 5 March 2015
Contents
- 1 Chi Lam
- 2 Self-Driving Autonomous Car
- 3 Abstract
- 4 Objectives & Introduction
- 5 We are
- 5.1 Schedule
- 5.2 Parts List & Cost
- 5.3 Design & Implementation
- 5.3.1 Hardware Design
- 5.3.2 Sensor Controller Team Hardware Design
- 5.3.3 Motor Controller Team Hardware Design
- 5.3.4 I/O Team Hardware Design
- 5.3.5 Communication Bridge + Android Hardware Design
- 5.3.6 Geographical Controller Team Hardware Design
- 5.3.7 Master Controller Team Hardware Design
- 5.3.8 Hardware Interface
- 5.3.9 Software Design
- 5.3.9.1 Sensor Controller Team Software Design
- 5.3.9.2 Motor Controller Team Software Design
- 5.3.9.3 Motor Movement Commands
- 5.3.9.4 I/O Team Software Design
- 5.3.9.5 Communication Bridge + Android Software Design
- 5.3.9.6 Geographical Controller Team Software Design
- 5.3.9.7 Master Controller Team Software Design
- 5.3.10 Software Interface
- 5.3.10.1 Sensor Controller Team Software Interface
- 5.3.10.2 Motor Controller Team Software Interface
- 5.3.10.3 I/O Team Software Interface
- 5.3.10.4 Communication Bridge + Android Software Interface
- 5.3.10.5 Geographical Controller Team Software Interface
- 5.3.10.6 Master Controller Team Software Interface
- 5.3.10.7 CAN Communication Table
- 5.4 Testing
- 5.5 Technical Challenges
- 5.6 Conclusion
- 5.7 References
Chi Lam
In Memory of Chi Lam
June 7th, 1991 - October 27th, 2014
This project is dedicated to Chi Lam, a beloved friend, dedicated Computer Engineering student, and member of this team.
You will be missed, friend
Self-Driving Autonomous Car
Abstract
The objective of the project is to create a self-driving autonomous car in a 15 person team. The car utilizes several components and sensors in order to get from Point A to Point B. Implementation of the car involves multiple SJONE processor boards using FreeRTOS to communicate with each other via CAN bus.
Objectives & Introduction
Team Members & Responsibilities
The team consisted of 15 undergraduate students taking a graduate level course, thus competing against the Master's level students.
We are
Master Controller Team | ||
---|---|---|
Charles Pham | Joshua Ambion | Michael Schneider |
- Overall vehicle logic - Overall software vehicle Integration - CAN TX/RX messages architecture |
- Vehicle hardware interfacing - Assistant to other teams - Module specific logic |
- Module specific logic - CAN RX processing - GPS waypoint logic |
Motor Controller Team | |
---|---|
Nikko Esplana | Chi Lam |
- Motor/steering control via PWM signals - interface/test/attach wheel encoder |
- Rest in peace Chi! |
Sensor Controller Team | |
---|---|
Sanjay Maharaj | Wei-chieh "Andy" Lo |
- Vehicle hardware - Sensor implementation - CAN communication |
- Sensor implementation - Sensor values verification - CAN communication |
Geographical Controller Team | ||
---|---|---|
Carlos Fernandez-Martinez | Zach Baumgartner | Albert Chen |
- Compass calibration/integration & structure modelling | - GPS testing/integration & structure modelling | - CAN communication |
Bridge Controller Team | ||
---|---|---|
Robert Julius | Tim Martin | Joseph Bourne |
- Android Application | - Bluetooth Message Interface | - Board to CAN Communication |
IO Controller Team | |
---|---|
Devin Villarosa | George Sebastian |
- Receive Task - GUI Interface - Headlights Task - uLCD Library |
- Event Handle Task - GUI Interface - Headlights Task - uLCD Library |
Schedule
Final Product Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/12 | CAN Network Benchtest | Complete |
2 | 10/15 | Basic CAN Communication | Complete |
3 | 10/31 | Secure devices to R/C car | Complete |
4 | 11/7 | Basic Vehicle Self-Driving Test | Complete |
5 | 11/14 | P2P testing and improved obstacle avoidance | Complete |
6 | 11/31 | Buffer time for previous tasks and increased vehicle speed | Complete |
Sensor Controller Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/13 | Sensor Input Distance Calibration | Incomplete: Need sensor value "filtering" logic. (Completed ~12/2) |
2 | 10/17 | Off car CAN network test (full team) | Completed. Able to send raw sensor value to master. |
3 | 10/20 | Interface Sensors with CAN | Completed. Updates to the formatting of data being sent is ongoing. |
4 | 10/27 | Mount Sensors and test coverage | Completed. Still need to mount with actual brackets. |
5 | 10/31 | Mount Sensors with 3d printed brackets | Completed. IR brackets to be printed based on offset. |
6 | 11/1 | Implement diagnostic LED patterns | Completed. |
7 | 11/3 | Send obstacle avoidance decisions to master | Completed. Raw values sent to master for processing. |
8 | 11/4 | Add RJ11 cabling to all sensors | Completed. Still need to make neat and tidy. |
9 | 11/10 | Eliminate outliers (software) | Completed. |
10 | 11/13 | Eliminate outliers by strengthening sensor wiring (hardware) | Completed. |
12 | 11/24 | Continue testing and tuning as necessary | Completed. |
Motor Controller Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/12 | Open up servo and motor modules,
find a speed sensor |
Complete |
2 | 10/19 | Interface/test PWM bus to steering servo and DC motor | Complete |
3 | 10/26 | Allow self-driving capability with master/bridge/sensor teams | Incomplete, only partial self-driving achieved |
4 | 11/2 | Improve fine motor movements with master/sensor teams | Incomplete, still needs tweaking. |
5 | 11/9 | Once wheel encoder comes in, learn/test/implement onto car | Incomplete, wheel encoder cannot be implemented, scrapping. |
6 | 11/16 | Integrate wheel encoder with rest of car | Incomplete, scrapped wheel encoder. |
7 | 11/23 | Test for proper operation | Complete, added functionality for center steer and forward speed calibration. |
8 | 11/30 | Continue testing until proper operation | Complete, motor works as intended. |
I/O Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/4 | Create LCD Screen Library (create ability to set value, get value, and write string to LCD screen) | 10/4 (String function completed on ~10/18) |
2 | 10/4 | Create LCD Screen GUI (generate forms for debugging and general usage) | 10/4 |
3 | 10/11 | LCD Library Test (Do unit tests on individual functions for LCD library)
Ability to get value from gauge on screen. Ability to set value to gauge on screen. Ability to send a string value to screen. |
10/11 (Finished string function on ~10/18) |
4 | 10/11 | Interface LCD with CAN
Create task for LCD event loop. Create task for Receiving on CAN. |
Complete (Completed on 10/26/2014) |
5 | 10/18 | Test LCD with CAN
Process CAN Messages from system |
Complete (Completed on 10/25/2014) |
6 | 10/25 | Implement onto Final Product | Complete (Completed on 11/23/2014) |
7 | 11/2 | Headlights for car (hardware and software) + Aesthetics for GUI + Clean up code | Complete (Completed on 12/01/2014) *NOTE Headlights are lost in hardware land |
Communication Bridge and Android Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/13 | CAN Network Test | Complete. |
2 | 10/20 | Interface Bluetooth Module with CAN | Complete. |
3 | 10/27 | Mount PCB on car | Complete. |
4 | 11/3 | Create basic Android application | Complete (completed ~10/18). |
5 | 11/10 | Add map onto the Android application | Complete (completed ~10/25). |
6 | 11/17 | Send/receive CAN Messages via Android Application | Complete (sending completed ~10/18, receiving ~11/1). |
7 | 11/24 | Debug and Optimize Android Application | Complete. |
8 | 12/1 | Continue Debugging and Optimizing as Necessary | Complete. |
Geographical Controller Schedule
Week# | Date | Task | Actual |
---|---|---|---|
1 | 10/8 | Interface with GPS/Compass | Complete - receiving values |
2 | 10/15 | Finish core API | Complete |
3 | 10/22 | GPS get fix and receive raw data | Complete - raw data received, but need faster fix |
4 | 10/22 | Compass determine heading | Complete - heading may require additional calibration |
5 | 10/29 | Implement calibration algorithm | Complete |
6 | 10/29 | GPS parse raw data to extract needed data | Complete - returns latitude, longitude, and calculated heading |
7 | 10/29 | Compass use heading from GPS to improve accuracy | N/A - Decided that magnetometer provides accurate enough reading |
8 | 11/5 | Improve GPS satellite procurement (antennae?) | Complete - attached antennae to GPS unit |
9 | 11/12 | Improve boot up time of GPS module via warm start | N/A - EZ start fast fix mode cannot coincide with 10 Hz update rate (defaults down to 1 Hz) |
10 | 11/12 | Fine tune compass calibration technique for accuracy | Complete - Compass still about 20 degrees off, but well within usable margins. Offset likely due to nearby power source on car. |
11 | 12/3 | Buffer time for completion of previous tasks | Complete |
Master Controller Schedule
Line Item # | Expected End Date | Task | Status |
---|---|---|---|
1 | 10/15/14 | Decide on raw CAN struct architecture | Early Completion |
2 | 10/18/14 | Develop and layout general common CAN messages | On-time Completion |
3 | 10/20/14 | Design vehicle initialization procedure | Early Completion |
4 | 10/23/14 | Develop and layout Inter-Controller Communication - Each Module's CAN messages | Early Completion |
5 | 10/25/14 | Design vehicle initial running freed drive mode procedure - Controlled via Phone, no object detection and avoidance, no GPS, no Heading | Early Completion |
6 | 10/28/14 | Complete design on vehicle running free drive mode procedure | On-time Completion |
7 | 10/30/14 | Design vehicle initial running indoor drive mode procedure - Timed autonomous drive , object detection and avoidance, (possibly heading), and no GPS | Late Completion |
8 | 11/01/14 | All CAN message definitions complete | Early Completion |
9 | 11/02/14 | Design vehicle initial running gps drive mode procedure - Full autonomous drive , object detection and avoidance, heading and GPS | Late Completion |
10 | 11/05/14 | All CAN message receive processing complete | On-time Completion |
11 | 11/14/14 | All basic vehicle functionality state machines implemented and verified | On-time Completion |
12 | 11/15/14 | Complete design on vehicle running indoor drive mode procedure | Late Completion |
13 | 11/20/14 | Complete design on vehicle running gps drive mode procedure | Late Completion |
14 | 11/30/14 | Any additional advanced functionality implemented and verified | Late Completion |
Parts List & Cost
Line Item# | Part Desciption | Vendor | Part Number | Qty | Cost ($) |
---|---|---|---|---|---|
1 | CAN Board | Waveshare International Limited | SN65HVD230 | 15 | 92.00 |
2 | Traxxas Slash Pro 2WD Short-Course R/C Truck | Traxxas | 58034 Slash | 1 | 337.00 |
3 | Adafruit Ultimate GPS Breakout | Adafruit | MTK3339 | 1 | 39.95 + (4.685 Shipping) |
4 | Triple-axis Accelerometer+Magnetometer (Compass) Board | Adafruit | LSM303 | 1 | 14.95 + (4.685 Shipping) |
5 | GPS Antenna - External Active Antenna - 3-5V 28dB 5 Meter SMA | Adafruit | 960 | 1 | 12.95 + (4.735 Shipping) |
6 | SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable | Adafruit | 851 | 1 | 3.95 + (4.735 Shipping) |
7 | 3.5" Intelligent module w/ Touch | 4D Systems | uLCD 35DT | 1 | 89.00 |
8 | 2GB microSD Card | ||||
9 | uUSB-PA5 Programming Adaptor | ||||
10 | 150mm 5 way Female-Female jumper cable | ||||
11 | 5 way Male-Male adaptor | ||||
12 | Sharp Infrared Range Finder | 4D Systems | GP2Y0A21 | 2 | 9.95 + 3.32 Shipping |
13 | SainSmart Sonar Ranging Detector | Amazon | HC-SR04 | 3 | 5.59 |
14 | RC LED Headlights | Amazon Prime | 2 | 5.99 | |
15 | XBee Bluetooth | Amazon Prime | WLS04051P | 1 | 27.50 |
16 | SJONE Board | Preet Industries | 6 | 480.00 | |
17 | Traxxas XL5 ESC unit | dollarhobbyz.com | 2WDS ESC | 2 | 54.00 + (4.67 Shipping) |
Additional Shipping | $0.00 | ||||
Total Cost | $1199.66 |
Design & Implementation
Hardware Design
Overall Hardware Design Components
58034 Traxxas Slash RC Truck:
|
|
SN65HVD230 CAN Board Transceiver:
|
|
3D Printed Materials:
The first structure that was built was the main platform. This platform acted as a mount for the six SJOne boards and the six CAN transceivers. Then, several structures needed to be created to mount the ultrasonic and sonar sensors at the front and back of the vehicle. Next, the LCD required a mount so it could float freely on the car and be both usable and sturdy, in case of a crash. Finally, a tower was designed to keep the antennae high and away from other components, like the magnometer. This is because the antennae has a huge magnet on the bottom for mounting purposes and was interfering with the compass readings. The models of the different structures can be seen in this section.
|
Sensor Controller Team Hardware Design
Sensor Pin Connections
Line Item# | Node A Source | Node A Pin | Node B Source | Node B Pin | Description |
---|---|---|---|---|---|
1 | 3.3V Power Supply | 3.3V | SJOne Board | 3V3 | SJOne Power |
2 | 3.3V Power Supply | GND | SJOne Board | GND | SJOne Ground |
3 | CAN Transceiver | Tx | SJOne Board | P0.1 (Tx) | SJOne - CAN Tx |
4 | CAN Transceiver | Rx | SJOne Board | P0.0 (Rx) | SJOne - CAN Rx |
5 | CAN Transceiver | 3.3V | 3.3V Power Supply | 3.3V | SJOne - CAN Power |
6 | CAN Transceiver | Ground | 3.3V Power Supply | GND | SJOne - CAN Ground |
7 | HC-SR04 Ultrasonic Sensor (Front Left) | Vcc | 5V Power Supply | +5V | Front Left Sensor Power |
8 | HC-SR04 Ultrasonic Sensor (Front Left) | GND | 5V Power Supply | GND | Front Left Sensor GND |
9 | HC-SR04 Ultrasonic Sensor (Front Left) | Echo | SJOne Board | P2.0 | Front Left Sensor Echo |
10 | HC-SR04 Ultrasonic Sensor (Front Left) | Trig | SJOne Board | P2.1 | Front Left Sensor Trig |
11 | HC-SR04 Ultrasonic Sensor (Front Right) | Vcc | 5V Power Supply | +5V | Front Right Sensor Power |
12 | HC-SR04 Ultrasonic Sensor (Front Right) | GND | 5V Power Supply | GND | Front Right Sensor GND |
13 | HC-SR04 Ultrasonic Sensor (Front Right) | Echo | SJOne Board | P2.2 | Front Right Sensor Echo |
14 | HC-SR04 Ultrasonic Sensor (Front Right) | Trig | SJOne Board | P2.3 | Front Right Sensor Trig |
15 | LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle) | Vcc | 5V Power Supply | +5V | Front Middle Sensor Power |
16 | LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle) | GND | 5V Power Supply | GND | Front Middle Sensor GND |
17 | LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle) | Echo | SJOne Board | P2.4 | Front Middle Sensor Echo |
18 | LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle) | Trig | SJOne Board | P2.5 | Front Middle Sensor Trig |
19 | HC-SR04 Ultrasonic Sensor (Rear Left) | Vcc | 5V Power Supply | +5V | Rear Left Sensor Power |
20 | HC-SR04 Ultrasonic Sensor (Rear Left) | GND | 5V Power Supply | GND | Rear Left Sensor GND |
21 | HC-SR04 Ultrasonic Sensor (Rear Left) | Echo | SJOne Board | P2.6 | Rear Left Sensor Echo |
22 | HC-SR04 Ultrasonic Sensor (Rear Left) | Trig | SJOne Board | P2.7 | Rear Left Sensor Trig |
23 | HC-SR04 Ultrasonic Sensor (Rear Right) | Vcc | 5V Power Supply | +5V | Rear Right Sensor Power |
24 | HC-SR04 Ultrasonic Sensor (Rear Right) | GND | 5V Power Supply | GND | Rear Right Sensor GND |
25 | HC-SR04 Ultrasonic Sensor (Rear Right) | Echo | SJOne Board | P2.8 | Rear Right Sensor Echo |
26 | HC-SR04 Ultrasonic Sensor (Rear Right) | Trig | SJOne Board | P2.9 | Rear Right Sensor Trig |
27 | CAN Transceiver | CANL | CAN BUS | CANL | CANL to CAN BUS |
28 | CAN Transceiver | CANR | CAN BUS | CANR | CANR to CAN BUS |
Sensor Controller Hardware Design Components
HC-SR04 Ultrasonic Distance Sensor:
The HC-SR04 is a distance sensor which detects objects using ultrasonic signals. The sensor is capable of detecting distances within 2cm-500cm. The sensor runs off 5V DC. Four pins are used: Vcc, Ground, Trig, and Echo. These sensors are relatively inexpensive, so four sensors were purchased. The four HC-SR04 sensors were implemented on our car at the following locations: front-left, front-right, rear-left, and rear-right. |
|
LV-MaxSonar-EZ0 Ultrasonic Range Sensor:
|
Method of Operation
1. INPUT: The sensor is triggered by a 10uS pulse HIGH on the trig pin.
2. RANGING: The sensor sends out eight 40kHz sonar pulses.
3. OUTPUT: The sensor outputs a pulse HIGH with the pulse time depending on the distance of the object on the echo pin.
The the output from the echo pin can be seen below, as captured by an oscilloscope.
Motor Controller Team Hardware Design
As seen above, the car battery(accepts compatible Ni-MH, Li-Po, and Ni-Cad batteries) powers the ESC unit (XL-5), which in turn drives the Titan 12T-550 motor and also powers the steering servo. It is necessary for the ESC unit, steering servo and SJ One board to share a common ground in order for the PWM signals to have the same reference voltage.
The CAN transceiver requires the use of the SJ One Board's +3.3V and GND, as well as P0.0 (CAN RX) and P0.1 (CAN TX).
P2.0/P2.1 (PWM1/PWM2) controls the steering/motor via the SJ One board by sending out PWM signals that change the width of a 20ms period waveform. 1ms width represents a 0% duty cycle, 1.5ms width represents a 50% duty cycle, and 2ms width represents a 100% duty cycle.
Controlling motor and steering
In the photo above, a digital oscilloscope probes a PWM pin on the SJ One board and detects a signal with a 3.3 peak-to-peak voltage, a 100hz PWM frequency, and a width of 1.5ms (50% duty cycle). In terms of steering control, a width between 1ms to 1.499ms equates to left steering (1ms = max left angle) and a width between 1.501ms to 2ms equates to right steering (2ms = max right angle). The motor is similar, such that a width between 1ms to 1.499ms equates to a reverse throttle and a width between 1.501ms to 2ms equates to a forward throttle. For both steering and motor control, 1.5ms (50% duty cycle) represents a center steer or non-throttle.
Motor Controller Hardware Design Components
58034 Traxxas Slash RC Truck:
|
|
Traxxas XL-5 Electronic Speed Control (ESC) Unit:
|
|
Steering Servo:
|
Motor Pin Connections
Line Item# | Node A Source | Node A Pin | Node B Source | Node B Pin | Description |
---|---|---|---|---|---|
1 | 3.3V Power Supply | 3.3V | SJOne Board | 3V3 | SJOne Power |
2 | 3.3V Power Supply | GND | SJOne Board | GND | SJOne Ground |
3 | CAN Transceiver | CAN Tx | SJOne Board | P0.1 (Tx) | SJOne - CAN Tx |
4 | CAN Transceiver | CAN Rx | SJOne Board | P0.0 (Rx) | SJOne - CAN Rx |
5 | CAN Transceiver | 3.3V | 3.3V Power Supply | 3.3V | SJOne - CAN Power |
6 | CAN Transceiver | Ground | 3.3V Power Supply | GND | SJOne - CAN Ground |
7 | CAN Transceiver | CANL | CAN BUS | CANL | CANL to CAN BUS |
8 | CAN Transceiver | CANR | CAN BUS | CANR | CANR to CAN BUS |
9 | Steering Servo | PWM Port | SJOne Board | P2.0 PWM | Steering Control |
10 | Steering Servo | Ground | SJOne Board | GND | Common ground for reference voltage |
11 | ESC/Motor | PWM Port | SJOne Board | P2.1 PWM | Motor Control |
12 | ESC/Motor | Ground | SJOne Board | GND | Common ground for reference voltage |
I/O Team Hardware Design
I/O Design Components
uLCD-35DT Intelligent Display Module:
|
I/O Pin Connections
Line Item# | Node A Source | Node A Pin | Node B Source | Node B Pin | Description |
---|---|---|---|---|---|
1 | LCD | 1 (LCD +5V) | 5V Power Supply | 5V | uLCD 35DT LCD Power |
2 | LCD | 7 (LCD GND) | 5V Power Supply | GND | uLCD 35DT LCD Ground |
3 | LCD | 5 (LCD RX) | SJOne Board | RX3 | uLCD 35DT LCD Receive Pin |
4 | LCD | 3 (LCD TX) | SJOne Board | TX3 | uLCD 35DT LCD Transmit Pin |
5 | 3.3V Power Supply | +3.3V | SJOne Board | 3V3 | SJOne Power |
6 | 3.3V Power Supply | GND | SJOne Board | GND | SJOne Ground |
7 | UART2 RX | P2.9 | SJOne RX | ||
8 | UART2 TX | P2.8 | SJOne TX | ||
9 | +5V | +5V Power | SJOne Board | GPIO P2.0 | Active Low |
10 | +5V | +5V Power | SJOne Board | GPIO P2.1 | Active Low |
11 | +5V | +5V Power | SJOne Board | GPIO P2.2 | Active Low |
12 | +5V | +5V Power | SJOne Board | GPIO P2.3 | Active Low |
13 | CAN Transceiver | CAN Tx | SJOne Board | P0.1 (Tx) | SJOne - CAN Tx |
14 | CAN Transceiver | CAN Rx | SJOne Board | P0.0 (Rx) | SJOne - CAN Rx |
15 | CAN Transceiver | CAN 3.3V | 3.3V Power Supply | 3.3V | SJOne - CAN Power |
16 | CAN Transceiver | CAN Ground | 3.3V Power Supply | GND | SJOne - CAN Ground |
17 | CAN Transceiver | CANL | CAN BUS | CANL | CANL to CAN BUS |
18 | CAN Transceiver | CANR | CAN BUS | CANR | CANR to CAN BUS |
Communication Bridge + Android Hardware Design
The Bluetooth module is connected to the SJOne board through the XBee socket, with only the RX/TX data connections into the board.
Communication Bridge Pin Connections
Line Item# | Node A Source | Node A Pin | Node B Source | Node B Pin | Description |
---|---|---|---|---|---|
1 | 3.3V Power Supply | 3.3V | SJOne Board | 3V3 | SJOne Power |
2 | 3.3V Power Supply | GND | SJOne Board | GND | SJOne Ground |
3 | CAN Transceiver | CAN Tx | SJOne Board | P0.1 (Tx) | SJOne - CAN Tx |
4 | CAN Transceiver | CAN Rx | SJOne Board | P0.0 (Rx) | SJOne - CAN Rx |
5 | CAN Transceiver | CAN 3.3V | 3.3V Power Supply | 3.3V | SJOne - CAN Power |
6 | CAN Transceiver | CAN Ground | 3.3V Power Supply | GND | SJOne - CAN Ground |
7 | Bluetooth Bee | VCC | 3.3V Power Supply | 3V3 | Bluetooth Bee Power |
8 | Bluetooth Bee | GND | 3.3V Power Supply | GND | Bluetooth Bee GND |
9 | Bluetooth Bee | RX | SJOne Board | P2.9 (RXD2) | Bluetooth Bee RX |
10 | Bluetooth Bee | TX | SJOne Board | P2.8 (TXD2) | Bluetooth Bee TX |
11 | CAN Transceiver | CANL | CAN BUS | CANL | CANL to CAN BUS |
12 | CAN Transceiver | CANR | CAN BUS | CANR | CANR to CAN BUS |
Communication Bridge + Android Hardware Design Components
Bluetooth Bee Standalone:
The Bluetooth Bee Standalone Module by Seeed Studio Works allows for the connection of a bluetooth module onto the XBee Socket of the SJOne Board. This module contains an ATMEGA168 for reprogramming. Only the SJOne Board's UART2/3 pins are capable of transferring data to the module, depending on which UART the XBee Socket is connected to with a switch configuration. |
Geographical Controller Team Hardware Design
Geographical Pin Connections
Line Item# | Node A Source | Node A Pin | Node B Source | Node B Pin | Description |
---|---|---|---|---|---|
1 | 3.3V Power Supply | 3.3V | SJOne Board | 3V3 | SJOne Power |
2 | 3.3V Power Supply | GND | SJOne Board | GND | SJOne Ground |
3 | CAN Transceiver | Tx | SJOne Board | P0.1 (Tx) | SJOne - CAN Tx |
4 | CAN Transceiver | Rx | SJOne Board | P0.0 (Rx) | SJOne - CAN Rx |
5 | CAN Transceiver | 3.3V | 3.3V Power Supply | 3.3V | SJOne - CAN Power |
6 | CAN Transceiver | Ground | 3.3V Power Supply | GND | SJOne - CAN Ground |
7 | MTK3339 GPS | VCC | 5V Power Supply | +5V | MTK3339 GPS Power |
8 | MTK3339 GPS | GND | 5V Power Supply | GND | MTK3339 GPS GND |
9 | MTK3339 GPS | RX | SJOne Board | RXD2 | MTK3339 GPS RX |
10 | MTK3339 GPS | TX | SJOne Board | TXD2 | MTK3339 GPS TX |
7 | LSM303 Compass + Accelerometer | VIN | 5V Power Supply | +5V | Compass + Accelerometer Power |
8 | LSM303 Compass + Accelerometer | GND | 5V Power Supply | GND | Compass + Accelerometer GND |
9 | LSM303 Compass + Accelerometer | RX | SJOne Board | RXD2 | Compass + Accelerometer SCL |
10 | LSM303 Compass + Accelerometer | TX | SJOne Board | TXD2 | Compass + Accelerometer SDA |
11 | CAN Transceiver | CANL | CAN BUS | CANL | CANL to CAN BUS |
12 | CAN Transceiver | CANR | CAN BUS | CANR | CANR to CAN BUS |