Difference between revisions of "S22: Testla"

Revision as of 06:29, 28 May 2022

Testla

Abstract

The Testla project is the culmination of our efforts to create an autonomously operated RC Car by pooling together our experience in software design, hardware design, power systems, and mobile application development. Project development started in February of 2022 and ended in May. (NOTE: One more sentence probably)

Introduction

The project was divided into 5 modules:

• Bridge and Sensor Information
• Motor Operation
• Geological Information
• Driver and LCD Manager
• Android Application

Team Members & Responsibilities

Gitlab Project Link

• Devin Alexander Gitlab
  • Co-Leader
  • Geographical Controller
  • Master Controller

• Sinan Bayati Gitlab
  • PCB Design
  • Motor Controller

• Michael Hatzikokolakis Gitlab
  • Co-Leader
  • Motor Controller
  • Testing

• Scott LoCascio Gitlab
  • Geographical Controller
  • Car Construction
  • Testing

• Thinh Lu Gitlab
  • Android Application
  • Sensor and Bridge Controller

• Bang Nguyen Gitlab
  • Sensor and Bridge Controller
  • LCD Display

Schedule

Parts List & Cost

Printed Circuit Board

The preliminary design consisted of neatly routes wires on a breadboard connecting all the various components. It still looked confusing due to the sheer amount of connections that had to be made, this complexity was to be handled by a custom PCB designed in EasyEDA.

Breadboard Wiring

Challenges

We found that some wires we used were faulty and did not conduct electricity, this led to alot of debug time which could have been avoided by using another wire. To avoid this type of scenario, you can do a continuity check with a multimeter to ensure wire integrity. We chose to design a PCB to have a clean on the car and have higher pin connection strength, since bread board connections are too loose.

PCB Schematic

PCB Layout showing traces (red are front side, blue are back side)

The design has many holes for mounting and pinouts for various peripherals (GPS, LCD, Buttons, etc.)

Steps to design PCB: Following this general guideline will help you avoid any blockers.

• Finish preliminary breadboard wiring and track changes along the way
• Identify desired mounting topology and make measurements
• Use pcb software to make schematic diagram (not PCB wiring)
• Make holes in the pcb for desired mounting locations (The more the merrier)
• Start positioning the components, then begin making traces

Pre-populated 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

DBC Link

VERSION ""

NS_ :
	BA_
	BA_DEF_
	BA_DEF_DEF_
	BA_DEF_DEF_REL_
	BA_DEF_REL_
	BA_DEF_SGTYPE_
	BA_REL_
	BA_SGTYPE_
	BO_TX_BU_
	BU_BO_REL_
	BU_EV_REL_
	BU_SG_REL_
	CAT_
	CAT_DEF_
	CM_
	ENVVAR_DATA_
	EV_DATA_
	FILTER
	NS_DESC_
	SGTYPE_
	SGTYPE_VAL_
	SG_MUL_VAL_
	SIGTYPE_VALTYPE_
	SIG_GROUP_
	SIG_TYPE_REF_
	SIG_VALTYPE_
	VAL_
	VAL_TABLE_

BS_:

BU_: DRIVER MOTOR SENSOR GEO DEBUG


BO_ 100 DRIVER_HEARTBEAT: 3 DRIVER
 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" DBG

BO_ 110 DRIVER_STEERING: 3 DRIVER
 SG_ DRIVER_STEERING_yaw : 0|12@1+ (0.001,-2) [-10|10] "radians" MOTOR
 SG_ DRIVER_STEERING_velocity : 12|12@1+ (0.01,-20) [-20|20] "kph" MOTOR

BO_ 120 MOTOR_HEARTBEAT: 5 MOTOR
 SG_ MOTOR_HEARTBEAT_speed_raw : 0|8@1+ (1,0) [0|0] "count" DEBUG
 SG_ MOTOR_HEARTBEAT_speed_rpm : 8|10@1+ (1,0) [0|0] "rpm" DEBUG
 SG_ MOTOR_HEARTBEAT_speed_kph : 18|10@1+ (0.1,-10) [-10|10] "kph" DEBUG
 SG_ MOTOR_HEARTBEAT_angle_duty : 28|10@1+ (0.001,-2) [-10|10] "duty" MOTOR


BO_ 125 MOTOR_DEBUG: 8 MOTOR
 SG_ MOTOR_DEBUG_speed_target : 0|26@1+ (0.1,-10) [-10|10] "kph" DEBUG
 SG_ MOTOR_DEBUG_speed_kph : 26|10@1+ (0.1,-10) [-10|10] "kph" DEBUG
 SG_ MOTOR_DEBUG_speed_duty : 36|10@1+ (0.1,0) [0|0] "duty" DEBUG
 SG_ MOTOR_DEBUG_integral_error : 46|10@1+ (0.1,-10) [-10|10] "error" DEBUG
 SG_ MOTOR_DEBUG_current_state : 56|3@1+ (1,0) [0|5] "state" DEBUG
 SG_ MOTOR_DEBUG_next_state : 59|3@1+ (1,0) [0|5] "state" DEBUG




BO_ 128 MOTOR_ESC_CALIBRATED: 1 MOTOR
 SG_ MOTOR_ESC_CALIBRATED_calibration_status : 0|4@1+ (1,0) [0|3] "esc_calibration_e" DRIVER
 SG_ MOTOR_ESC_CALIBRATED_start_calibration_ack_to_driver : 4|1@1+ (1,0) [0|1] "bool" DRIVER


BO_ 129 DRIVER_START_ESC_CALIBRATION: 1 DRIVER
 SG_ MOTOR_ESC_CALIBRATED_begin_esc_calibration : 0|1@1+ (1,0) [0|3] "bool" MOTOR

BO_ 130 MOTOR_ACK: 1 MOTOR
 SG_ MOTOR_ACK_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER


BO_ 200 SENSOR_SONARS: 8 SENSOR
 SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|800] "inch" DRIVER
 SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_back : 30|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_frame_id : 42|16@1+ (1,0) [0|0] "" DRIVER

BO_ 210 SENSOR_DESTINATION_LOCATION: 8 SENSOR
 SG_ SENSOR_DESTINATION_latitude : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" GEO
 SG_ SENSOR_DESTINATION_longitude : 28|28@1+ (0.000001,-180.000000) [-180|180] "Degrees" GEO

BO_ 218 NAVIGATION_MESSAGE: 1 GEO
 SG_ NAVIGATION_STATUS_navigation_status : 0|8@1+ (1,0) [0|3] "navigation_status_e" DRIVER

BO_ 219 CHECKPOINT_MESSAGE: 8 GEO
 SG_ CHECKPOINT_MESSAGE_compass_heading : 0|12@1+ (1,0) [0|359] "Degrees" DRIVER
 SG_ CHECKPOINT_MESSAGE_destination_bearing : 12|12@1+ (1,0) [0|359] "Degrees" DRIVER
 SG_ CHECKPOINT_MESSAGE_destination_distance : 24|16@1+ (0.1,0) [0|0] "Meters" DRIVER
 SG_ CHECKPOINT_MESSAGE_curr_checkpoint_num : 40|8@1+ (1,0) [0|255] "Integer" DRIVER
 SG_ CHECKPOINT_MESSAGE_total_checkpoint_num : 48|8@1+ (1,0) [0|255] "Integer" DRIVER
 SG_ CHECKPOINT_MESSAGE_checkpoint_status : 56|8@1+ (1,0) [0|3] "checkpoint_status_e" DRIVER

BO_ 220 GEO_STATUS: 8 GEO
 SG_ GEO_STATUS_compass_heading : 0|12@1+ (1,0) [0|359] "Degrees" DRIVER
 SG_ GEO_STATUS_destination_bearing : 12|12@1+ (1,0) [0|359] "Degrees" DRIVER
 SG_ GEO_STATUS_destination_distance : 24|16@1+ (0.1,0) [0|0] "Meters" DRIVER

BO_ 520 DEBUG_GPS_CURRENT_LOCATION: 8 GEO
 SG_ DEBUG_GPS_CURRENT_LOCATION_latitude : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" DEBUG
 SG_ DEBUG_GPS_CURRENT_LOCATION_longitude : 28|28@1+ (0.000001,-180.000000) [-180|180] "Degrees" DEBUG
 SG_ DEBUG_GPS_CURRENT_LOCATION_fix : 56|2@1+ (1,0) [0|2] "" DEBUG

BO_ 521 DEBUG_GEO_GPS_UPDATE: 8 GEO
 SG_ DEBUG_GEO_GPS_UPDATE_count : 0|16@1+ (1,0) [0|0] "" DEBUG
 SG_ DEBUG_GEO_GPS_UPDATE_max_period : 16|16@1+ (1,0) [0|0] "milliseconds" DEBUG
 SG_ DEBUG_GEO_GPS_UPDATE_min_period : 32|16@1+ (1,0) [0|0] "milliseconds" DEBUG
 SG_ DEBUG_GEO_GPS_UPDATE_average_period : 48|16@1+ (1,0) [0|0] "milliseconds" DEBUG

BO_ 522 DEBUG_GEO_COMPASS_UPDATE: 8 GEO
 SG_ DEBUG_GEO_COMPASS_UPDATE_count : 0|16@1+ (1,0) [0|0] "" DEBUG
 SG_ DEBUG_GEO_COMPASS_UPDATE_max_period : 16|16@1+ (1,0) [0|0] "milliseconds" DEBUG
 SG_ DEBUG_GEO_COMPASS_UPDATE_min_period : 32|16@1+ (1,0) [0|0] "milliseconds" DEBUG
 SG_ DEBUG_GEO_COMPASS_UPDATE_average_period : 48|16@1+ (1,0) [0|0] "milliseconds" DEBUG

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ GEO "the geographical controller of the car";
CM_ BU_ DEBUG "the debug topic that all controllers can publish to";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

BA_DEF_ "BusType" STRING ;
BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
BA_DEF_ SG_ "FieldType" STRING ;

BA_DEF_DEF_ "BusType" "CAN";
BA_DEF_DEF_ "FieldType" "";
BA_DEF_DEF_ "GenMsgCycleTime" 0;

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;

Sensor ECU

<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>

Motor ECU

Motor Controller Link

Hardware Design

A single SJ2-C board was placed in charge of handling all interactions with the Traxxas parts. This included an ESC (Electronic Speed Control) connected to a brushed DC motor, a servo motor for steering control, and a wheel encoder installed adjacent to the gear shaft (CHECK).

Defining Signals

While Traxxas does provide support for hobby RC car enthusiasts, they do not provide clear documentation on signal inputs and outputs to all of their electrical components. To understand what signals would need to be generated by the SJ2-C (CHECK), the output of the receiver box (CHECK) was intercepted. Manipulating the Traxxas remote would generate PWM signals at the output of the receiver box. By reading these signals on an oscilloscope, it was determined that both the ESC and servo motor both operated on a range of duty cycles between 10 - 20%.

• For the ESC: 10% DC = full reverse speed, 15% DC = idle/zero speed, 20% DC - full forward speed

• For the servo motor: 10% DC = wheels fully turned to the left, 15% DC = wheels turned straight ahead, 20% DC = wheels turned fully to the right.

Setting up the PWM channels

The PWM channels on pins P2.0 (CHECK) and P2.1 were both enabled on single edge mode at a frequency of 100 Hz with a duty cycle of 15%. Initial tests were conducted by mapping the buttons of the SJ2 (CHECK) to modifying the duty cycles on both PWM channels. These tests were successful in changing the motor speed and wheel direction.

RPM Sensor

In order to give real-time feedback on the speed the car is traveling at, an RPM sensor was installed. For ease of compatibility, the Traxxas 6520 RPM Sensor (long variant) was purchased for this task. It was installed by following this tutorial. The other part used is the Traxxas 6538 Telemetry Trigger Magnet Holder for Spur Gear>. While this was expected to provide proper signal output with no extra components, initial testing of the sensor yielded an 0.4 Vpp signal comprised of an unstable, noisy signal. Doing further research led us to find that a 1k-ohm (CHECK) pull-up resistor connecting the data pin to a 3.3V rail was required to pull the signal high instead of letting it float. This corrected the output signal to give the expected result.

SJ2-C LED Breakdown

Normal Operation:

• LED 0: Toggle on CAN receive
• LED 1: Toggle on CAN transmit
• LED 2: Unused
• LED 3: Driver signal Missing-in-Action

ESC Calibration

• LEDs 0-2: Used to detail current step in calibration process
• LED 3: Unused

SJ2-C Switch Breakdown

• SW 0: Start ESC Calibration Sequence
• SW 1: Disable Motor
• SW 2: Disable Steering
• SW 3: Enable both Motor and Steering

(Note: Motor and Steering are disabled on startup by default)

Software Design

CAN Bus Interactions

The Motor Controller receives two different values from the Driver Controller: an angle to turn the wheels to (DRIVER_STEERING__yaw) and the speed at which to drive (DRIVER_STEERING__velocity).

The Motor Controller sends a multitude of signals addressed to “Debug”, as well as one signal to the Driver pertaining to the status of ESC calibration. These debug signals include a variety of formats of the current speed given by the RPM sensor, the error calculation used in the PID logic, and the operations of the state machine within the motor logic handler.

RPM Sensor

With a proper data output from the sensor, the output was attached to pin CHECK for operation with Timer2. The initial plan was to measure the time between pulses and perform calculations to extrapolate the current speed, but another unexpected issue was experienced. When configuring the interrupt handler on the pin (CHECK) in either rising-edge or falling-edge detection, the interrupt handler would be triggered repeatedly on what appeared to be a steady low signal. This was observed by configuring Bus Master the interrupt count in combination with viewing a logic analyzer to see the signal state. This was especially concerning as it was noticed that if the car wheels stopped turning at a specific position, the sensor would permanently hold a low signal until further rotations, causing even further potential for inaccuracy in any given speed reading. After hours of trying different interrupt configuration settings, it was decided to work with the given conditions. A workaround was discovered by essentially disregarding any interrupts that were deemed to be physically too fast to have been caused by the actual rotation of the tires. This resulted in proper software operation of the interrupt handler, but it required a new method for ascertaining the speed. The final implementation revolved around counting the amount of sensor pulses within a 5 Hz window. This timing was specifically chosen as the proper middle ground for two choices (CHECK). A quicker window would allow for faster updates to the ESC, but a slower window would allow for more pulse data collection and higher accuracy.

PID Controller

While an objective of the car is to implement a “PID” controller, in reality a simple “P” controller is enough for an effective control system. This means that all that is needed is the target speed, the current speed, and a gain factor. If the current speed is far from the target speed, a higher error value is produced. When multiplied with the gain, this results in the car making larger changes to its speed to reach the target speed, while using smaller changes to modulate the speed as forces on the car change due to varying terrain or surface angle changes.

 // -------------Error Calculations-------------//
 if (next_state == FORWARD) {
   error = target_motor__kph - current_speed;
 } else if (next_state == REVERSE) {
   error = target_motor__kph + current_speed;
 }

 } else if (next_state == FORWARD) {
   speed_for_motor__kph += gain * error;
 }

ESC Calibration

When demoing the second prototype, the ESC fell out of calibration for the first time in operation. This created an undesirable situation where the Traxxas receiver had to be connected back to the motor so it could be calibrated with the Traxxas remote. This led to the need for the calibration sequence to be programmable from the board with no need to rewire components. It was observed that to calibrate the ESC, the remote trigger would need to follow a certain procedure: Neutral position Full forward speed Full reverse speed Neutral position This procedure was copied by the Motor Controller with a preparation delay inserted into the beginning of the sequence and can be activated by pressing switch 0 at any time. Note that the ESC should be placed in calibration mode just after pressing switch 0. Failure to do so could cause the car to attempt to reach its maximum speed and hold it for two seconds.

State Machine

The final version of the Motor Controller logic included a state machine. Each state is defined in the code below.

typedef enum {

 IDLE = 0,
 FORWARD = 1,
 BRAKING = 2,
 START_NEUTRAL_FOR_REVERSE = 3,
 NEUTRAL_FOR_REVERSE = 4,
 REVERSE = 5,

} CAR_MOTION_STATUS;

Things to note:

• Braking is the same as sending a reverse signal to the ESC. This is different from sending an idle signal that stops applying current to the motor and allows the car to coast to a halt.
• The START_NEUTRAL_FOR_REVERSE, NEUTRAL_FOR_REVERSE, and REVERSE states are all necessary for the car to perform reverse motion if the car had been moving forward just prior.

Technical Challenges

• RPM Sensor gave low voltage, improper signal (see: Hardware Design - RPM Sensor)
• Interrupt handler generated interrupts on stable signal (see: Software Design - RPM Sensor)
• ESC would require calibration on startup every time - Sending a neutral signal (15% Duty Cycle) to the ESC for the first three seconds gave the ESC a signal to lock on to and not require calibration

Geographical Controller

The geographical (geo) controller is used to provide the vehicle with a sense of location. To do this, the controller is interfaced to a compass which provides a heading, and a GPS module which provides a latitude, longitude, and GPS fix. GPS fix indicates that the GPS unit is connected to enough sattelites to provide accurate location data. The controller reads a destination off the CAN bus and calculates the distance from its current position. Additionally, it calculates a bearing, which is the degrees from north that the car must point to be facing the destination. If the car aligns its heading with the bearing and drives in a straight line for the number of meters described by the distance calculation, then the car will arrive at its destination.

However, the vehicle will not be driving in a straight line because of obstacle avoidance. To deal with this, the distance and bearing are updated regularly at a rate of 10Hz. When an obstacle forces the vehicle to deviate from the desired course, it will recalculate the bearing and distance from its new location. This distance and location is then broadcast on the CAN bus, and digested by the driver controller.

Hardware Design

An Adafruit Ultimate GPS breakout module using the MTK3339 chipset is interfaced over UART to the Geographical controller to provide latitude and longitude updates.

A Witmotion WT901 IMU is connected over I2C to provide access to the vehicles heading.

Software Design

The general software flow is shown in the diagram below. This loop is run in a 10Hz periodic callback set up in FreeRTOS.

Initialization

On startup the GPS module is configured. The GPS module sends data at 9600 bps after powering on but must be set to 115200 bps to support 10Hz updates. The controller must send a command to increase the GPS module's baud rate then change the baud rate on its own UART interface. Initially, the GPS sends out several different NMEA strings on every update. The vehicle only needs latitude , longitude and GPS fix data so the GPS is configured to only send GPGGA strings. This prevents the geo controller from wasting time to intake data that it is uninterested in. Finally, the GPS module is configured to send updated data at a rate of 10Hz. After this process is complete, the controller enters its main loop.

Main Loop

The geo controller runs at a frequency of 10Hz. A FreeRTOS task uses vTaskDelayUntil() to define a finite period of 100 milliseconds between invocations of the periodic callback.

The GPS module is read by reading characters out of the UART into a line buffer. If a full line has been deposited into the buffer then the latitude, longitude and GPS Fix are updated. Additionally, a min and max time between GPS updates field is filled in as well as a count of updates. This debug information is published on the bus to analyze fidelity of the module.

Next, the compass is read over an I2C interface to acquire the heading. The WT901 is an IMU which actually has a good deal more information available besides heading. Currently we are only reading the compass heading but can expand expand in the future to read acceleration and orientation. This module does need to be calibrated one time to ensure it is correctly reporting the heading. The module has a UART interface which can be used to interface between a TTL to USB converter to a software suite. This software can also be used for debugging and calibration.

After reading the position the CAN interface checks if there are any changes to the destination being published by the bridge controller. After obtaining the most recent desired destination, the geographical module is invoked to calculate a distance and bearing. The section below goes into more detail on the geo calculation. After a distance and bearing are calculated, they are published onto the bis along with the current heading and dubug information.

Geo process

The desired and current position are used to calculate a distance and bearing using the haversine formula shown below.

Distance

Bearing

Moveable Type Scripts: Calculate distance, bearing and more between Latitude/Longitude points

Technical Challenges

There were several challenges in developing a reliable geographical controller.

Initially, connecting to the GPS was a challenge because the format of the ASCII lines were not well understood.

Expected string

$GPGGA,064951.000,2307.1256,N,12016.4438,E,1,8,0.95,39.9,M,17.8,M,,*65

Actual string

$GPGGA,,,,,,,5,,,,M,,*65

There were also issues with verifying that the command strings being sent were achieving their desired results

Both these problems were solved by attaching the tx line of the GPS to an oscilloscope and decoding the UART messages. This allowed us to fully characterize the output of the GPS and its response to command strings.

LCD, Sonar Sensor & Communication Bridge Controller

• Sensor Gitlab

• LCD Gitlab

Sensor Hardware Design

Block Diagram

Ultrasonic Sensor

• Ultra-Sonic Sensor URM09 (I2C Protocol)

• Supply Voltage: 3.3~5.5V DC • Operating Current: 20mA • Operating Temperature Range: -10℃～＋70℃ • Measurement Range: 2cm～500cm (can be set) • Resolution: 1cm • Accuracy: 1% • Frequency: 50Hz Max • Dimension: 47mm × 22 mm/1.85” × 0.87”

Sensor Mount

Sensor Software Design

• Low level - peripheral driver
  • Peripheral Initialize function
    • I2C Clock 100KHz
    • I2C Pin:
      • SCL: P0_10
      • SDA: P0_11
  • I2C single byte read function
    • Input parameter
      • Slave address (7-bit + R/W-bit)
      • Register address (1 byte)
    • Output parameter
      • Register value (1 byte)
    • Return true if success else return false
  • I2C single byte write function
    • Input parameter
      • Slave address (7-bit + R\W bit)
      • Register address (1 byte)
      • Written value (1 byte)
    • Return true if success else return false

• Mid-level -sensor
• Defined data struct
  • Sonar_sensor__sample_sum_s
    • Left
    • Middle
    • Right
    • Back
  • Sonar_sensor__sample_queue_s
    • Left
    • Middle
    • Right
    • Back
  • Sonar_sensor__address_e
    • Left (7-bits - 0x26)
    • Middle (7-bits – 0x22)
    • Right (7-bits – 0x24)
    • Back (7-bits – 0x20)
  • Sonar_sensor_measure_mode_e
    • Automatic
    • Passive
  • Sonar_sensor__measure_range_e
    • 150 cm
    • 300 cm
    • 500 cm

• Initialize sensor function
  • Init I2C peripheral
  • Init all the sensors with the following configurations:
    • Passive measure mode
    • 150 cm range
• Sensor collects sample function
  • To avoid the sensor's crosstalk, we implement the following sequence
    • Start the measurement left sensor
    • Delay 25ms
    • Collect data from the left sensor
    • Start the measurement right sensor
    • Delay 25ms
    • Collect data from the right sensor
    • Start the measurement back and middle
    • Delay 25ms
    • Collect data from the back and middle sensor

Sensor Technical Challenges

• Issue: we cannot read or write on the default address.
• Reason: After using the logical analyzer, we realize the init clock at 400Khz was too fast for this sensor even though the datasheet did not mention it.
• Solution: we reduce the I2C Clock speed to 100kHz

• Issue: These nearby ultra-sonic sensors receive each other’s bounce-back signal.
• Reason: We config the sensor in automatic mode, and it causes the sensors to crosstalk.
• Solution: we config the sensor in passive mode and tested them with many test cases to come up with the best sequence, and the sensor must operate at 10hz frequency.

• Issue: Sensor noise is getting worse with bad mounting
• Reason: the sensors are mounted with the bean down to the ground.
• Solution: we come to design a mechanical mount with the ability of 60 degrees horizontal and vertical adjustment

LCD Hardware Design

LCD Circuit

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

Project Source Code

https://gitlab.com/testla_sjsu/autonomous_vehicle

Advise for Future Students

This is a car project, so the best way to phrase advice for future students is through a car metaphor.

This project is a destination that you are a reasonable distance away from. You can race and drive recklessly towards your destination to try and get there on time but at the end of the day, leaving earlier is what puts you farther ahead on the road. Take the project seriously from day one and make realistic progress every week and you will have a great experience. Leave late and the journey will be a stressful catch-up game.

Acknowledgement

First and foremost we have to acknowledge all the teams who came before us. The largest source of information and inspiration came from them. There are an immense amount of well documented attempts at solving this problem. We truly in debt to the teams that came before us and hope we added something to the knowledge base here at Social Ledge.

Next, we have to acknowledge Professor Preetpal Kang. CmpE 243 is the product of a lot of hard work on his part. Preet makes himself available for all the students and shares his many years of experience and expertise. This is one of the most valuable part of the SJSU computer engineering masters program.

We also need to acknowledge the former students and others who work on the SJTwo repository and the Social Ledge website. This is another wealth of information and we could not have built this project without this resource.

Finally, We should (and do) acknowledge all of the teams in our class this semester. We were lucky to have an engaged group of teams working together and sharing knowledge and experiences.

References

https://www.movable-type.co.uk/scripts/latlong.html