Difference between revisions of "S22: TBD"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Software Design)
(Technical Challenges)
Line 584: Line 584:
 
2. Ultrasonic sensor wiring not secure
 
2. Ultrasonic sensor wiring not secure
 
* One of the issues we faced was that the sensors would not be connected properly because the RC car was constantly being moved around. A solution was to clean up the wiring and using a PCB. Also, we would use CAN Busmaster to check which sensors were not connected.
 
* One of the issues we faced was that the sensors would not be connected properly because the RC car was constantly being moved around. A solution was to clean up the wiring and using a PCB. Also, we would use CAN Busmaster to check which sensors were not connected.
 +
3. Wheel Encoder Data Output Debouncing
 +
* We realized that the GPIO ISR was triggered multiple times when the wheel is moving slowly. This problem was not an issue when the wheel is moving at higher speeds.
 
<HR>
 
<HR>
 
<BR/>
 
<BR/>

Revision as of 22:09, 27 May 2022

Project Title

THE BEST DRIVER



Abstract

Our goal for this project is to use knowledge we gathered from lectures to design, implement, and test a self-driving RC car using a Controller Area Network (CAN) bus for controller communication. The project involves FreeRTOS and utilizes periodic tasks (running at 1Hz, 10Hz, and 100Hz) to gather, process, and display data from various embedded modules.

Introduction

The project was divided into 5 modules:

  • Sensor/Bridge Controller
  • Motor Controller
  • Geo Controller
  • Driver/LCD Controller
  • Web Application

Team Members & Responsibilities

Image: 580 pixels
From Left to Right: Jasdip Sekhon, Brian Ho, Justin Stokes, Billy Lai, Isaac Wahhab, William Hernandez

  • Sensor
    • Jasdip Sekhon
    • Brian Ho
    • Justin Stokes
  • Motor
    • Justin Stokes
    • Isaac Wahhab
  • Geographical
    • Brian Ho
    • William Hernandez
    • Jasdip Sekhon
  • Driver Logic & LCD & LED Ring
    • William Hernandez
    • Billy Lai
    • Isaac Wahhab
  • Web Application & Communication Bridge Controller
    • Isaac Wahhab
    • Billy Lai
  • Testing Team
    • The Best Driver Team


Schedule

Week# Start Date End Date Task Status
1 02/15/2022 02/21/2022
  • Discussed sensors for prototyping, and reviewed previous projects.
Completed
2 02/22/2022 02/28/2022
  • Ordered Parts
Completed
3 03/01/2022 03/07/2022
  • Looking at potential options for additional sensors
Completed
4 03/08/2022 03/14/2022
  • Learning to use CAN BUSMASTER
Completed
5 03/15/2022 03/21/2022
  • Made prototype for project .dbc file
Completed
6 03/22/2022 03/28/2022
  • Discuss and learn how to use Eagle for PCB fabrication
  • Modify projects/lpc40xx_shared_sconscripts to separate each node's periodic_callbacks files
Completed
7 03/29/2022 04/04/2022
  • Parts testing and prototyping
    • Configure and integrate LSM303 as 3-D compass
    • Initialize and configure GPS module
    • Configure and test ultrasonic sensors
Completed
8 04/05/2022 04/11/2022
  • List hardware requirements for the PCB fabrication
  • Start research on web application for interfacing with RC car
  • Finalize GPS and ultrasonic sensor testing
    • Verify sensor I2C addresses
    • Debug GPS configuration and interfacing to acquire a GPS lock
Completed
9 04/12/2022 04/18/2022
  • PCB Design and meeting to validate design
    • Design and review PCB prototype
    • Get GEO messages and SENSOR messages to the DRIVER node
  • Continue web application research
  • Test RC car interfacing
    • Verify wheel control motor on the RC car (can move forward and reverse at various speeds)
    • Verify steering control motor on the RC car (can steer left and right)
  • Integrate GPS and sensors on the CAN bus using GEO node and SENSOR node
    • Ultrasonic sensors tested and integrated with SENSOR node
  • Integrate ESP32 to BRIDGE node
  • Milestones:
    • Detect an obstacle and command the RC car motor to stop
Completed
10 04/19/2022 04/25/2022
  • Order first PCB prototype
  • Have a prototype for the web application
    • Test BRIDGE node receiving data from web application
  • Test interacting with the RC car wirelessly
    • Test RC car wheel control from wireless control
    • Test RC car steering control from wireless control
  • Test LCD peripheral and output debug messages
    • Configure and command LCD display
  • Interface with wheel encoder
  • Initial attempt to mount plexi-glass and boards to RC car
  • Add obstacle detection LEDs
  • MIA management for DRIVER node
  • Verify consistent and reliable sensor values
Completed
11 04/26/2022 05/02/2022
  • Receive PCB from distributor
    • Create a mount on the RC car to contain all the hardware
    • Solder parts to PCB
  • Fix unit tests for DRIVER, SENSOR, GEO, MOTOR nodes
  • Integrate sensor values with driver logic
    • Update motor steering on obstacles detected
    • Update motor speed on obstacles detected
  • Test PWM for RC car steering and motor movement
    • Update DBC file for DRIVER_TO_MOTOR steering values (update from [-2, 2] steering range)
  • Maintain GPS lock
    • Verify GPGGA message is parsed correctly
    • Validate GPS coordinates from GPS module
    • GPS lock indication LED
  • Finalize LCD display information
    • Display current compass heading
    • Display desired direction heading
    • Display distance to destination
  • MIA handling
    • GEO handles GPS DESTINATION LOCATION MIA
    • DRIVER handles SENSOR MIA and GEO STATUS MIA
    • MOTOR handles DRIVER_TO_MOTOR_COMMAND message MIA
Completed
12 05/03/2022 05/09/2022
  • Handle Invalid NODE operation
    • GEO compass with invalid i2c read_byte()
    • GPS not locked, GPGGA message with invalid data
    • SENSOR/BRIDGE with Wi-Fi bridge down
  • Add LCD debug menu to replace analyzing BusMaster messages and remove printf() calls
  • Clean up hardware
    • Wire wrapping, mounting, sensor placements
    • Power SJTwo Boards and peripheral from RC car battery using a buck converter
  • Stabilize compass readings by callibrating LSM303
  • Test ESPs for Wi-Fi communication
  • Test RPM wheel encoder sensor
    • Mount wheel encoder to RC car
    • Add RPM calculation code
    • Verify RPM values are accurate
  • Brainstorm collision logic for RC controller
    • Handle case for stair obstacle
    • Handle sensor data
  • Ring LED interfacing
    • Light up an LED for compass heading
    • Light up an LED for destination heading
Completed
13 05/10/2022 05/16/2022
  • Test collision logic for RC controller
    • Ensure external LED lights up when DRIVER logic is taking collision logic branch instead of driving towards destination
  • Finalize the collision logic
  • Validate SENSOR node
    • Use ESP32 Wi-Fi modules to send destination location to SENSOR/BRIDGE node
    • Test sensor readings given new sensor placements
  • Validate GEO node
    • Stabilize compass readings and ensure North, East, South, and West headings are accurate
    • Validate destination_heading calculation
    • Validate distance_to_destination calculation
    • Verify specific GPS coordinates for waypoint locations at the parking garage
  • Validate DRIVER node
    • MIA handling for messages from GEO node and SENSOR node
  • Validate MOTOR node
    • Verify appropriate PWM signals are applied to RC car motor/steering on receiving motor commands from DRIVER node
  • Update LCD screen to display debug information from DRIVER node
    • Display current location and destination location
    • Display RPM of wheels
  • Design and implement waypoints algorithm to handle ramp (deadzone) on 6th floor of North Garage
  • Turn off LED0-LED3 on all nodes after periodic_callbacks__initialize() function
    • Use this feature to visually observe if the LEDs flash red during testing to indicate if a board is resetting unexpectedly
Completed
14 05/17/2022 05/25/2022
  • Finalize and test Ring LED
    • Add North indication on ring LED
    • Add party mode when destination is reached
    • Checkpoint test: rotate the car in a 360 and verify the North LED indicator always points North
  • Integrate and test waypoints algorithm
  • Update mobile application
    • Send destination coordinates to SENSOR node
    • Expose debug messages to SENSOR node and then relay info to web app
    • Emergency stop from web app
  • Integrated headlights and taillights
    • Headlights are always on
    • Taillights are constantly on when the car is idle
    • Taillights are flashing when car is reversing
  • Integrate RPM in MOTOR node to adjust PWM for motor speed
  • Reverse logic in DRIVER node when front sensors cannot be avoided
  • Web app connected indication LED
  • Adjust DRIVER_TO_MOTOR steer values to create smooth steering
  • Final testing of full project
    • Verify the SENSOR/BRIDGE node receives data from web application
    • Verify the GEO node receives GPS destination from SENSOR/BRIDGE node
    • Verify the DRIVER node receives GEO status messages
    • Verify the DRIVER node receives SENSOR messages
    • Verify the MOTOR node sends DBG command messages
    • Verify waypoints algorithm by avoiding ramp area on 6th floor of North Garage
    • Verify obstacle detection and reverse logic
  • Finalize wiki report
    • Video for Proj Wiki
Completed


Parts List & Cost

Item# Part Desciption Vendor Qty Cost
1 RC Car Redcat Racing 1 $139.00
2 SJTwo Boards SJTwo Boards On Amazon 4 $200.00
3 CAN Transceivers (SN65HVD230) Waveshare 4 $40.00
4 LSM303 Triple-Axis Accelerometer and Magnetometer Adafruit 1 $15.00
5 Venus GPS with SMA Connector SparkFun 1
6 URM09 Ultrasonic Sensors DFRobot Gravity 4 $52.00
7 PCB JLCPCB 1 $5.00
8 Plexiglass 1
9 LCD Display SunFounder LCD Display 1 $12.99
10 APA102 Ring LED Sparkfun 1 $11.50
11 LEDs for obstacle detection, GPS lock status, and web app lock status 6
12 Rotary Encoder & Wheel Set Tinkersphere 2 $10.99
13 Set of Headlights and taillights eBay 1 $3.99
14 Logic Level Converters Sparkfun 1 $3.50
15 Buck Converters 1
16 Standoffs for mounting SJTwo boards, PCB, and raising compass 40


Printed Circuit Board

GitLab link to PCB board (.brd) files and schematic files (.sch) created in EAGLE PCB design software

We designed and implemented two PCBs: CAN Bus PCB and RC Car PCB.


CAN Bus PCB Schematic

Image: 150 pixels


CAN Bus PCB Board

Image: 250 pixels


RC Car PCB Schematic

Image: 800 pixels


RC Car PCB Board

Image: 500 pixels

CAN Communication

Our message IDs are arranged with priority given to the nodes in the following order: DRIVER, SENSOR, GEO, MOTOR. The following critical messages are transmitted at 100Hz:

  • SENSOR_TO_DRIVER_SONARS
  • GPS_DESTINATION_LOCATION
  • SENSOR_TO_DRIVER_WHEEL_ENCODER_MSG
  • GEO_STATUS
  • DRIVER_TO_MOTOR_CMD

The remaining debug messages are transmitted at 10Hz or 1Hz.

We decided to give 32 message IDs to each node and to separate the nodes' message IDs accordingly.

Node Message ID Range
1 DRIVER 32 - 63
2 SENSOR 63 - 95
3 GEO 96 - 127
4 MOTOR 128 - 159

Hardware Design

Image: 250 pixels

DBC File

Gitlab link to our master branch's DBC file

Our DBC file includes the SENSOR, DRIVER, MOTOR, and GEO nodes.

Below are the messages defined in the file:


BO_ 32 DRIVER_TO_MOTOR_CMD: 3 DRIVER
 SG_ DRIVER_TO_MOTOR_steer : 0|9@1+ (1,-180) [-180|179] "" MOTOR
 SG_ DRIVER_TO_MOTOR_speed : 9|5@1+ (1,0) [0|31] "RPM" MOTOR
 SG_ DRIVER_TO_MOTOR_current_rpm : 14|10@1+ (1,0) [0|1023] "RPM" MOTOR
BO_ 33 DRIVER_DEBUG_MSG: 1 DRIVER
 SG_ DRIVER_DEBUG_MSG_sensor_mia : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ DRIVER_DEBUG_MSG_geo_mia : 1|1@1+ (1,0) [0|0] "" DBG
BO_ 64 SENSOR_TO_DRIVER_SONARS: 4 SENSOR
 SG_ SENSOR_TO_DRIVER_SONARS_front_left : 0|8@1+ (1,0) [0|0] "" DRIVER
 SG_ SENSOR_TO_DRIVER_SONARS_front_middle : 8|8@1+ (1,0) [0|0] "" DRIVER
 SG_ SENSOR_TO_DRIVER_SONARS_front_right : 16|8@1+ (1,0) [0|0] "" DRIVER
 SG_ SENSOR_TO_DRIVER_SONARS_back : 24|8@1+ (1,0) [0|0] "" DRIVER
BO_ 65 GPS_DESTINATION_LOCATION: 7 SENSOR
 SG_ GPS_DESTINATION_LOCATION_latitude : 0|28@1+ (0.000001,-134.217727) [-134.217727|134.217728] "" GEO,DRIVER
 SG_ GPS_DESTINATION_LOCATION_longitude : 28|28@1+ (0.000001,-134.217727) [-134.217728|134.217728] "" GEO,DRIVER 
BO_ 66 SENSOR_TO_DRIVER_WHEEL_ENCODER_MSG: 2 SENSOR
 SG_ SENSOR_TO_DRIVER_WHEEL_ENCODER_MSG_rpm : 0|10@1+ (1,0) [0|0] "RPM" DRIVER,DBG
BO_ 67 SENSOR_TO_DRIVER_APP_CONNECTION_MSG: 1 SENSOR
 SG_ SENSOR_TO_DRIVER_APP_CONNECTION_MSG_app_connected : 0|1@1+ (1,0) [0|0] "" DRIVER 
BO_ 96 GEO_STATUS: 5 GEO
  SG_ GEO_STATUS_compass_heading : 0|9@1+ (1,0) [0|359] "Degrees" SENSOR,DRIVER
  SG_ GEO_STATUS_destination_heading : 9|9@1+ (1,0) [0|359] "Degrees" SENSOR,DRIVER
  SG_ GEO_STATUS_distance_to_destination : 18|16@1+ (0.1,0) [0|0] "Meters" SENSOR,DRIVER
BO_ 97 GEO_DEBUG_MSG: 1 GEO
  SG_ GEO_DEBUG_MSG_lock_status : 0|1@1+ (1,0) [0|0] "" DRIVER,DBG
  SG_ GEO_DEBUG_MSG_num_satellites : 1|4@1+ (1,0) [0|15] "" DRIVER,DBG
BO_ 98 GEO_CURRENT_LOCATION_DEBUG: 7 GEO
  SG_ GEO_CURRENT_LOCATION_DEBUG_latitude : 0|28@1+ (0.000001,-134.217727) [-134.217727|134.217728] "" DRIVER,DBG
  SG_ GEO_CURRENT_LOCATION_DEBUG_longitude : 28|28@1+ (0.000001,-134.217727) [-134.217728|134.217728] "" DRIVER,DBG
BO_ 99 GEO_CURRENT_DESTINATION_LOCATION_DEBUG: 7 GEO
  SG_ GEO_CURRENT_DESTINATION_LOCATION_DEBUG_latitude : 0|28@1+ (0.000001,-134.217727) [-134.217727|134.217728] "" SENSOR,DBG
  SG_ GEO_CURRENT_DESTINATION_LOCATION_DEBUG_longitude : 28|28@1+ (0.000001,-134.217727) [-134.217728|134.217728] "" SENSOR,DBG
BO_ 128 MOTOR_DEBUG_MSG: 3 MOTOR
 SG_ MOTOR_DEBUG_MSG_echo_steer : 0|3@1+ (1,-2) [-2|2] "" DBG
 SG_ MOTOR_DEBUG_MSG_echo_speed : 3|5@1+ (1,0) [0|31] "RPM" DBG
 SG_ MOTOR_DEBUG_MSG_echo_rpm : 8|10@1+ (1,0) [0|1023] "RPM" DBG

MIA Management

Since the DRIVER node is our main controller, we conducted MIA management in the driver_logic code module. Our MIA management is serviced at 10Hz and ensures that the expected messages are received within a time limit set by threshold values. If a message goes "missing" past set threshold times, a default replacement value is used.
The MIA threshold values and replacement structures are found in the can_mia_configurations.c file.

SENSOR_TO_DRIVER_SONARS

  • Default value in the DRIVER node is to set the sensor values to 0. This will result in the driver_logic simulating obstacles detected at 0cm in the front and back, and the car will not move.

GPS_DESTINATION_LOCATION

  • Default value in the GEO node is to set the current coordinates and destination coordinates to 0. This will result in a 0 distance_to_destination calculation, and the DRIVER node will subsequently send an IDLE speed to the MOTOR node.

GEO_STATUS

  • Default value in the DRIVER node is to set compass heading, destination heading, and distance to destination to 0. This will result in the ring LED not lighting up (to show an invalid state) and the DRIVER will send an IDLE speed to the MOTOR node.

DRIVER_TO_MOTOR_CMD

  • Default value in the MOTOR node is to set the motor speed and steering to IDLE and 0, respectively. Without updated driver to motor commands, the RC car should not move.


Sensor Controller

Sensor Node GitLab

Ultrasonic.png Wheel encoder photo.png

Hardware Design

We used 4 Gravity DFRobot URM09 ultrasonic sensors. These ultrasonic sensors are used by the RC car for the purpose of obstacle avoidance. Three sensors were placed on the front side of the RC car and one on the back. They use I2C communication to send distance data to the SJ2 microcontroller. On the SJ2 microcontroller, P0.10 was used for SDA, and P0.11 was used for SCL. The measurement range is 300cm. It takes in 3.3V supply voltage. Using the I2C driver, the registers on the ultrasonic sensors were configured and the distance was read from the specified registers in the datasheet.

Sensor connection.png
The wheel encoder is interfaced using 3 pins: VCC, GND, and OUT. The voltage input requires 4.5-5.5V and the data pin outputs 5V. The 5V output is converted to 3.3V using a level converter, and then used as a GPIO input to P0.22 on the SENSOR node.
Image: 250 pixels
The rotary wheel has 20 slits spaced evenly. An infrared beam and sensor is used to detect when the beam is blocked. When the beam is blocked, the data OUT pin outputs 0V. When the beam is unblocked, the data OUT pin outputs 5V.

Software Design

The ultrasonic sensors use the I2C driver available in the project. The implementation is done in the 100Hz periodic callback function. After writing to the control register address of the ultrasonic sensors, the distance values are read from the appropriate distance. Each sensors periodically sends sound waves according to the callback_count variable. To prevent signal interference, only one sensor sends pulses for each iteration of the periodic_callback. After the distance values were read, they were sent to the driver for obstacle avoidance.

The wheel encoder uses a GPIO pin (P0.22). To measure the speed of rotation, we enabled GPIO interrupts by adding a gpio_isr module to dispatch GPIO interrupts to associated handler methods. On rising edges, a GPIO interrupt service routine (ISR) increments a wheel encoder rising edge counter. In the 100Hz periodic callback, the wheel encoder counter is used to calculate the measured rotations per minute (RPM). This RPM value is sent from the SENSOR node and is relayed through the DRIVER node to the MOTOR node. After sending out the RPM value, the wheel encoder rising edge counter is reset.

Technical Challenges

1. Ultrasonic sensor interference

  • Since we had 3 ultrasonic sensors on the front side sending sound waves, there was interference between them. As a result, the values being read from the sensors were incorrect. To resolve this issue, instead of sending sound waves at once from all the front sensors in the periodic callbacks function, we decided to send them at different times.

2. Ultrasonic sensor wiring not secure

  • One of the issues we faced was that the sensors would not be connected properly because the RC car was constantly being moved around. A solution was to clean up the wiring and using a PCB. Also, we would use CAN Busmaster to check which sensors were not connected.

3. Wheel Encoder Data Output Debouncing

  • We realized that the GPIO ISR was triggered multiple times when the wheel is moving slowly. This problem was not an issue when the wheel is moving at higher speeds.


Motor Controller

Motor Controller GitLab

Hardware Design

The hardware design for the motor controller was determined by the hardware of the car. We knew that the cars motors were controller through an electronic speed controller(ESC) and just had to interface the SJ2 with this. The top of the receiver revealed 12 pins, in 4 rows of 3. Each row had the following according the the sticker: GND, VCC, and signal. The signal pin would be hooked up to the pins which are firmware configured to output PWM.

Motor Controller Schematic

Software Design

Controlling the motors was done through firmware generating PWM signals. We decided to begin by hooking up the car's receiver to a Saleae Logic Analyzer to see the waveforms generated when using the remote control that came with the car. This was helpful in many ways. First, we were able to see which channel was used for the steering servo, and which was used for the actual motor. Second, we were able to see the maximum, minimum, and neutral PWM duty cycles required and the period period of the waveform. Lastly, we were able to visually see the different sequences necessary to run the motors.

Technical Challenges

< List of problems and their detailed resolutions>



Geographical Controller

Compass and Accelerometer

Image: 200 pixels

Hardware Design

LSM303DLHC Magnetometer

For the compass heading we used the lsm303DLHC compass + accelerometer from Adafruit. The compass was interfaced using I2C with a speed of 100KHz. The data output rate was set to 220HZ. The gain was left as the default +-1.3 gauss. The operation mode was switch to continuous conversion mode. The compass was placed at a safe distance above all of the other hardware components to minimize the magnetic disturbance.

Software Design

Compass Implementation and Calibration

Once the required registers have been initialized, the compass will return uncalibrated x, y, and z values. For its calibration we used the software Magneto v1.2. Magneto requires a txt file of raw magnetometer values and our locations magnetic field. Magneto will then provide the bias and scaling factor matrix needed for calibration. Those values are then plug into the equation Matrix^-1((raw/gain*100)-bias), where gain is 1100 gauss for the x and y values and 980 gauss for the z value. Those calibrated x and y values are used to find the radians of the compass heading. The radians are then converted and returned as degrees. By flipping the compass upside down, the compass was able to reduced tilt factor to provide accurate readings.


Magneto1.2v Calibration

Image: 350 pixels

Waypoints Algorithm

Image: 350 pixels Image: 400 pixels

Technical Challenges

1. Compass calibration

  • Use magnetic field of current position
  • Use Magneto software

2. Reliable compass readings

  • Flip the compass upside down for more accurate readings


Driver Controller

Code for Driver Logic Debug Menu State Machine for Menu Navigation
Code for LCD I2C Initialization and Configuration
Lcd-display-photo.png

Hardware Design

Software Design

Inside periodic_callbacks_DRIVER.c, driver_logic__manage_debug_menu_10hz is periodically called at 10Hz rate. The definition for this method is shown below:

 void driver_logic__manage_debug_menu_10hz(uint32_t callback_count) {
   display_debug_menu_on_lcd(callback_count);
   handle_debug_menu_navigation();
 }

This snippet of code is responsible for maintaining the LCD debug menu state machine. It periodically updates the LCD to display menu navigation screens or debug information.

Technical Challenges

1. LCD display is limited to 4 lines of 20 characters. Having this limit creates a challenge for efficiently using the screen for debugging.

  • To resolve this issue, we designed and implemented a finite state machine to update the LCD display according to a debug menu state. This solution is beneficial for its scalability. New debug information can be easily included as additional options in the menu navigation.

2. I2C bus speed was configured too high

  • We saw issues with the LCD screen resetting unexpectedly during testing. This was due to our I2C bus speed being configured to run at 400KHz. After reviewing the datasheet, we found that using 100KHz for the I2C bus speed is the correct configuration.


Master Module

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

< List of problems and their detailed resolutions>



Mobile Application

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

< List of problems and their detailed resolutions>






Conclusion

<Organized summary of the project>

<What did you learn?>

Project Video

Youtube Link <-- temporary video, will be updated

Project Source Code

GitLab Project Link

Advice for Future Students

  • Add a mobile kill-switch to stop the car
    • The car may drive at high speeds and not behave as expected. It is helpful to be able to wirelessly stop the car.
  • Add plenty of LED indicators on the RC car
    • GPS lock, app connection, obstacle detection, destination reached, etc
    • Turn off on-board LEDs for each controller at the end of periodic_callbacks__initialize(). The current base code will light the on-board LEDs in peripherals_init(). By turning off the LEDs after initialization, it will be convenient to use the LEDs to indicate whether the board is resetting unexpectedly
  • Stabilize your compass readings
    • Calibrate your compass
    • Verify tilting the car will not drastically affect magnetometer readings
    • Mount the compass module away from metals and any hard/soft iron that may cause the readings to be inaccurate
  • Unit test code modules to verify expected behavior
  • Once your car can move, test outside on the garage.
    • Ultrasonic sensors give incorrect readings at steep angles, making testing in the hallway somewhat difficult.
    • Compass readings are also more accurate outside the building where there is less interferance.

Acknowledgement

We would like to acknowledge our instructor, Preet, for encouraging us to gather knowledge and to tackle difficult problems.

References

1. Ultrasonic Sensor Project Wiki
2. GPGGA Message Definition
3. LSM303DLHC Datasheet
4. Venus638FLPx GPS Receiver Datasheet
5. LCD Display Initialization and Configuration Example Tutorial
6. APA102 Ring LED Datasheet
7. Logic Level Converter Datasheet