Difference between revisions of "S19: Automophiles"
Proj user13 (talk | contribs) (→Unreliable GPS lock) |
Proj user13 (talk | contribs) (→Technical Challenges) |
||
| Line 531: | Line 531: | ||
<Bullet or Headings of a module> | <Bullet or Headings of a module> | ||
| − | ==== | + | ==== Lost transmission ==== |
| − | + | '''Summary:''' Even while using a start of frame byte to essentially tell the Android app what information it's getting and how many bytes to expect for that information, some information is lost or garbled. This data loss/corruption seems to depend on the frequency of which the bridge is running at. The faster the bridge runs at, the more non-sense seems to be sprinkled into the transmission, which can cause issues with debug panels. For instance, as sensor values are constantly getting transmitted to the app, the app's debug panel might show rapidly changing but accurate values, there are occasionally abnormally large values sprinkled in. | |
| − | + | ||
| + | '''Resolution:''' A resolution to this fix can be done on the Android side where received bytes are put through a filter to make sure they make sense before they are displayed. For instance, since sensor values are always between 0 and 8190 meters, any value outside of that range can be simply discarded and the previous accurate value is preserved until the next sensor frame comes in. While this may reduce the update rate of debug and other information, it provides a somewhat cleaner interface on the app. | ||
<HR> | <HR> | ||
Revision as of 18:12, 15 May 2019
Contents
Project Title
Automophiles
Abstract
Automophiles is a an autonomous RC car capable of obstacle detection and GPS navigation along certain routes on the SJSU campus. The embedded system driving the car is essentially a distributed system of isolated nodes each focusing on a specific task such as polling sensor data or monitoring GPS location data. These nodes are then integrated into a functional vehicle on the CAN bus.
Introduction
The project was divided into 7 modules:
- Sensor Controller: This unit initializes and constantly reads the three front-facing laser sensors using I2C. These unfiltered readings are then immediately sent over the CAN bus to the Master controller for processing.
- Motor Controller: This unit directly interfaces with the Electronic Speed Controller (ESC) for the DC motors as well as the servo motors. The two PWM interfaces for each of the respective motors are controlled depending on commands sent from the Master controller.
- Master Controller: This unit is responsible for implementing a state machine and determining the current behavior of the vehicle depending on the various inputs fed from the four other support controllers.
- Geographical Controller: This unit is responsible for interfacing with a digital compass and GPS and determining the current location state of the vehicle at all times. GPS checkpoints are also defined and handled here for the purposes of route calculation. This information is then fed to the Master and Bridge controllers over the CAN bus.
- Bridge Controller: This unit acts as the central communication module for the vehicle. All interactions with the Android application back and forth are handled here.
- Android Application: The application works as the entry point for users to interact with the vehicle. Critical interactions like setting destination as well as viewing debug information are handled through the application.
- PCB/Hardware Integration: Hardware integration over PCB/protoboard is done to reduce the likelihood of potential failures coming from hardware connections/interfaces
Team Members & Responsibilities
<Team Picture>
- Geographical
- Bridge
- Android Application
- Integration/Repository Management Team
Schedule
| Week# | Date | Task | Status | Completion Date |
|---|---|---|---|---|
| 1 | 02/12/19 |
|
Completed |
02/12/19 |
| 2 | 02/19/19 |
|
Completed |
02/19/19 |
| 3 | 02/26/19 |
|
Completed |
02/26/19 |
| 4 | 03/05/19 |
|
Completed |
03/11/19 |
| 5 | 03/12/19 |
|
Completed |
03/18/19 |
| 6 | 03/19/19 |
|
Completed |
03/25/19 |
| 7 | 03/26/19 |
|
Completed |
04/01/19 |
| 8 | 04/02/19 |
|
Completed |
04/08/19 |
| 9 | 04/09/19 |
|
Completed |
04/15/19 |
| 10 | 04/16/19 |
|
Completed |
04/22/19 |
| 11 | 04/23/19 |
|
Completed |
04/29/19 |
| 12 | 04/30/19 |
|
Completed |
05/06/19 |
| 13 | 05/07/19 |
|
Completed |
05/07/19 |
| 14 | 05/14/19 |
|
In Progress |
|
| 15 | 05/22/19 |
|
Parts List & Cost
| Item# | Part Desciption | Vendor | Qty | Cost |
|---|---|---|---|---|
| 1 | RC Car | Traxxas | 1 | $240.00 |
| 2 | RC Car Charger Wall Adapter | Traxxas | 1 | $25.00 |
| 3 | CAN Transceiver PCB Board | Waveshare | 7 | $48.03 |
| 4 | HC-06 Bluetooth Module | eBay | 1 | $10.51 |
| 5 | PCB | Bay Area Circuits | 2 | $250 |
| 6 | Laser Sensors | Amazon | 4 | $29.97 |
| 7 | LCD | Preet | 1 | Free |
| 8 | DB9 Connector Breakout | Amazon | 1 | $6.99 |
| 9 | Adafruit GPS Breakout | Amazon | 1 | $43.61 |
| 10 | External GPS Antenna | Amazon | 1 | $14.99 |
| 11 | Mini-PCI to RP-SMA Antenna Cable | Amazon | 1 | $4.99 |
Printed Circuit Board
<Picture and information, including links to your PCB>
CAN Communication
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management etc.>
Hardware Design
<Show your CAN bus hardware design>
DBC File
VERSION "" NS_ : BS_: BU_: MASTER GPS BRIDGE MOTOR SENSOR BO_ 100 MOTOR_CMD: 3 MASTER SG_ STEER_CMD_enum : 0|8@1+ (1,0) [0|0] "" MOTOR SG_ SPEED_CMD : 8|8@1+ (0.1,0) [0|0] "m/sec" MOTOR SG_ MASTER_INIT_DEBUG : 16|1@1+ (1,0) [0|0] "" MOTOR SG_ MASTER_SEND_LEFT : 17|1@1+ (1,0) [0|0] "" MOTOR SG_ MASTER_SEND_STRAIGHT : 18|1@1+ (1,0) [0|0] "" MOTOR SG_ MASTER_SEND_RIGHT : 19|1@1+ (1,0) [0|0] "" MOTOR BO_ 105 RPM_VALUE_CMD: 4 MOTOR SG_ RPM_VALUE : 0|8@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ CAN_INIT_MSG : 8|8@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ RECEIVED_STEER_CMD : 16|8@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ MOTOR_HEARTBEAT : 24|1@1+ (1,0) [0|0] "" BRIDGE,MASTER BO_ 110 COMPASS_CMD: 4 GPS SG_ HEADING : 0|32@1+ (0.1,0) [0|0] "" BRIDGE,MASTER BO_ 115 COMPASS_INIT_DEBUG: 1 GPS SG_ INIT_DEBUG : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 120 GPS_CURRENT_LAT_LONG: 8 GPS SG_ CUR_LAT : 0|32@1+ (0.000001,0.000000) [36.000000|38.000000] "degrees" BRIDGE,MASTER SG_ CUR_LONG : 32|32@1+ (0.000001,-123.000000) [-123.000000|-120.000000] "degrees" BRIDGE,MASTER BO_ 125 GPS_INIT_DEBUG: 1 GPS SG_ INIT_DEBUG : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 130 GPS_FIX_DEBUG: 1 GPS SG_ GPS_FIX_DEBUG : 0|1@1+ (1,0) [0|0] "" BRIDGE,MASTER BO_ 135 COMPASS_MAN_CAL_DEBUG: 1 GPS SG_ IS_CAL_DEBUG : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 140 GPS_HEARTBEAT: 1 GPS SG_ GPS_HEARTBEAT : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 145 GPS_TARGET_HEADING: 8 GPS SG_ TARGET_HEADING : 0|32@1+ (0.1,0) [0.00|360.00] "degrees" BRIDGE,MASTER SG_ DISTANCE : 32|32@1+ (0.1,0) [0|0] "meters" BRIDGE,MASTER BO_ 150 GPS_CHECKPOINT_INDEX: 1 GPS SG_ CHECKPOINT_INDEX : 0|8@1+ (1,0) [0|0] "" BRIDGE BO_ 200 SENSOR_STATUS: 7 SENSOR SG_ SENSOR_FRONT : 0|16@1+ (1,0) [0|0] "milimeters" BRIDGE,MASTER SG_ SENSOR_LEFT : 16|16@1+ (1,0) [0|0] "milimeters" BRIDGE,MASTER SG_ SENSOR_RIGHT : 32|16@1+ (1,0) [0|0] "milimeters" BRIDGE,MASTER SG_ SENSOR_LEFT_BLOCKED : 48|1@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ SENSOR_CENTER_BLOCKED : 49|1@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ SENSOR_RIGHT_BLOCKED : 50|1@1+ (1,0) [0|0] "" BRIDGE,MASTER SG_ SENSORS_HEARTBEAT : 51|1@1+ (1,0) [0|0] "" BRIDGE,MASTER BO_ 300 BRIDGE_STOP: 1 BRIDGE SG_ BRIDGE_STOP : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 310 BRIDGE_GO: 1 BRIDGE SG_ BRIDGE_GO : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 315 BRIDGE_INIT_DEBUG: 1 BRIDGE SG_ INIT_DEBUG : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 320 BRIDGE_HEARTBEAT: 1 BRIDGE SG_ BRIDGE_HEARTBEAT : 0|1@1+ (1,0) [0|0] "" MASTER BO_ 325 BRIDGE_DEST: 8 BRIDGE SG_ DEST_LAT : 0|32@1+ (0.000001,0) [36.000000|38.000000] "degrees" GPS SG_ DEST_LNG : 32|32@1+ (0.000001,-123) [-123.000000|-120.000000] "degrees" GPS CM_ BU_ MASTER "The master controller driving the RC car"; CM_ BU_ SENSOR "The obstacle avoidance sensor module"; CM_ BU_ MOTOR "The motor module driving the car"; CM_ BU_ GPS "The GPS module"; CM_ BU_ BRIDGE "The main communications module between car and app"; BA_DEF_ SG_ "FieldType" STRING ; BA_DEF_DEF_ "FieldType" ""; BA_ "FieldType" SG_ 100 STEER_CMD_enum "STEER_CMD_enum"; VAL_ 100 STEER_CMD_enum 2 "steer_straight" 1 "slight_left" 3 "slight_right" 0 "stop" 6 "steer_right" 4 "steer_left" 8 "reverse" 7 "left_reverse" 9 "right_reverse";
Sensor ECU
<Picture and link to Gitlab>
Hardware Design
Software Design
<List the code modules that are being called periodically.>
Technical Challenges
<Bullet or Headings of a module>
Unreliable sonor sensors
<Problem Summary> <Problem Resolution>
Motor Controller & LCD
<Picture and link to Gitlab>
Group Members
- Uma Nataraj
- Alisha Jean Patrao
- Sanjana Devegowdanakoppalu Swamy Gowda
Hardware Design
Software Design
<List the code modules that are being called periodically.>
Technical Challenges
<Bullet or Headings of a module>
Unreliable Servo Motors
<Problem Summary> <Problem Resolution>
Geographical Controller
<Picture and link to Gitlab>
Group Members
- Kevin Gadek
- Nivedita Shiva Murthy
- Alisha Jean Patrao
Hardware Design
Software Design
<List the code modules that are being called periodically.>
The Geographical Controller's software design consists of several main periodic tasks, gps_1Hz(), gps_50Hz(), and compass_50Hz().
Technical Challenges
Unreliable Compass heading
Summary: The LSM303D as well as many other compasses used for this kind of project is subject to big fluctuations depending on factors such as "magnetic noise" and movement. This can cause a whole host of issues which scale depending on the magnitude of fluctuations. For instance, since the master controller relies on current compass bearing and tries to steer the vehicle towards a target bearing, having fluctuations of greater than 10 degrees can cause erratic and inaccurate behavior for the vehicle.
Resolution:This fluctuation issue can be reduced by measures to reduce the impact of outside forces such as the DC motor's magnetic fields. Tin foil is wrapped around the motor and the compass breakout is physically lifted higher from the car. In addition, the master module also takes measures to reduce the impact of erroneous compass headings by simply dividing the heading received by 10 and then measuring its difference from the target heading that's also divided by 10. This could act to reduce the amount of rapid steer actions by a measurable factor.
Unreliable GPS lock
Summary: The time-to-first-fix interval is largely inconsistent regardless of whether a battery backup is attached to the GPS breakout. Sometimes, it may take several minutes to get a fix while at other times, almost instantaneously. Once it gets a fix, it may also take an inconsistent amount of time to report accurate locations. Location at first fix may be a kilometer off and then the GPS will take some time to slowly correct itself. Even after some time, the GPS might be slightly inaccurate as in it believes it's inside a building when it's actually a few dozen feet outside of it. This can cause issues when calculating target bearing and distance as an accurate understanding of the car's current location needs to be established to figure out where to go.
Resolution:
Communication Bridge Controller
<Picture and link to Gitlab>
Group Members
- Kevin Gadek
- Uma Nataraj
Hardware Design
Software Design
<List the code modules that are being called periodically.>
Implementation
- In 1 Hz periodic
- Reset CAN bus if bus off
- Send heartbeat to master
- In 10 Hz
Technical Challenges
<Bullet or Headings of a module>
Lost transmission
Summary: Even while using a start of frame byte to essentially tell the Android app what information it's getting and how many bytes to expect for that information, some information is lost or garbled. This data loss/corruption seems to depend on the frequency of which the bridge is running at. The faster the bridge runs at, the more non-sense seems to be sprinkled into the transmission, which can cause issues with debug panels. For instance, as sensor values are constantly getting transmitted to the app, the app's debug panel might show rapidly changing but accurate values, there are occasionally abnormally large values sprinkled in.
Resolution: A resolution to this fix can be done on the Android side where received bytes are put through a filter to make sure they make sense before they are displayed. For instance, since sensor values are always between 0 and 8190 meters, any value outside of that range can be simply discarded and the previous accurate value is preserved until the next sensor frame comes in. While this may reduce the update rate of debug and other information, it provides a somewhat cleaner interface on the app.
Master Module
<Picture and link to Gitlab>
Hardware Design
Software Design
<List the code modules that are being called periodically.>
Technical Challenges
<Bullet or Headings of a module>
Improper Unit Testing
<Problem Summary> <Problem Resolution>
Mobile Application
<Picture and link to Gitlab>
Group Members
- Kevin Gadek
- Uma Nataraj
The Android application was the main gateway for user interaction with the vehicle and as such is crucial to the overall utility of the project. Critical elements such as setting destination and verifying debug values such as sensor values and current GPS coords without having to physically hook up the vehicle to Busmaster are all facilitated through the application. The app was designed for Android 8.1 (API level 27) with a minimum support requirement of Android 5.0 (API level 21).
Software Design
The application uses UI fragments to allow for better modularity and flexibility when building the application. In our case, all Google Map related activity could be constrained to MainActivity.java, all Bluetooth UI related activity to BluetoothFragment.java and Bluetooth background service activity to BluetoothService.java. Various UI layouts that are used such as activity_main.xml, bluetooth_fragment.xml and debug_popup.xml are subsequentially hooked up to these source files. This view-controller setup ensures a somewhat more focused interaction between Java source code and the various UI elements being hooked up.
MainActivity.java
The main focus of this code module is to hook up and interact with the Google Maps fragment as well as the toolbar at the top of the screen. activity_main.xml and debug_popup.xml are hooked up to this code module with the latter layout being displayed only when the debug button's onClickListener is invoked.
BluetoothFragment.java
BluetoothService.java
Technical Challenges
<Bullet or Headings of a module>
Connecting over Bluetooth
Summary: Application was was only connecting at startup and not continually trying to connect to car.
Resolution: When connect thread fails, simply restart the thread repeatedly until connection succeeds.
Conclusion
<Organized summary of the project>
<What did you learn?>
Project Video
Project Source Code
https://gitlab.com/cmpe-243-group/cmpe-243-self-driving-car
Advise for Future Students
<Bullet points and discussion>
