Difference between revisions of "S22: Testla"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Abstract)
(Team Members & Responsibilities)
Line 26: Line 26:
 
[[File:DevinAlexander.jpeg|200px|middle]]
 
[[File:DevinAlexander.jpeg|200px|middle]]
 
*Devin Alexander '''''[https://gitlab.com/devin_alexander_sjsu Gitlab]'''''
 
*Devin Alexander '''''[https://gitlab.com/devin_alexander_sjsu Gitlab]'''''
** Leader
+
** Co-Leader
 
** Geographical Controller
 
** Geographical Controller
 
** Master Controller
 
** Master Controller
Line 36: Line 36:
 
[[File:MichaelHatzi.PNG|200px|middle]]
 
[[File:MichaelHatzi.PNG|200px|middle]]
 
* Michael Hatzikokolakis '''''[https://gitlab.com/mikehatzi8 Gitlab]'''''
 
* Michael Hatzikokolakis '''''[https://gitlab.com/mikehatzi8 Gitlab]'''''
 +
** Co-Leader
 
** Motor Controller
 
** Motor Controller
 
** Testing
 
** Testing

Revision as of 05:42, 28 May 2022

Testla

Bunch of handsome young men.jpeg




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

DevinAlexander.jpeg

  • Devin Alexander Gitlab
    • Co-Leader
    • Geographical Controller
    • Master Controller
  • Sinan Bayati Gitlab
    • PCB Design
    • Motor Controller

MichaelHatzi.PNG

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

Scott locascio.jpeg

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


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

BangNguyen.jpg

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






Schedule

Week # Start Date End Date Task Status
1 2/15/2022 2/21/2022 Read previous projects, gather information and discuss among the group members. Complete
2 2/22/2022 2/28/2022 Distribute modules to each team member. Complete
3 3/1/2022 3/7/2022 Purchase the RC Car
Purchase sensors
Complete
4 3/8/2022 3/14/2022 Learning to use CAN BUSMASTER Complete
5 3/15/2022 3/21/2022 DBC file discussed and implemented Complete
6 3/22/2022 3/28/2022 Discuss modules needed for PCB, any feature requests Complete
7 3/29/2022 4/4/2022 Finalize preparations and research Complete
8 4/5/2022 4/11/2022 Interface with RC car and hack steering and motor
Integrate the GEO sensor with the GEO controller
Complete the Driver sensor using analog readings
Write a basic implementation of the sensor controller
Interface ESP8266 for bridge controller
Begin testing with single vs dual power supplies
Complete
9 4/12/2022 4/18/2022 Install wheel encoder, implement, implement PID into velocity processing, and establish collaboration between the Motor and Sensor Controllers
Test alternate sonar sensor (I2C)
Configure GPS to run at 10Hz, 115200 baud and only parse $GPGGA strings on startup
Integrate compass
Setup NodeJS server to communicate with the Bridge controller via TCP/IP
Start Mobile Application development.
Finalize power supply choice
Finish PCB designs for each subsystem
Complete
10 4/19/2022 4/25/2022 Finish 1st vehicle prototype - include PCBs if possible
Complete basic mobile application
Write various motor test routines to define in mobile application
Verify timing and correctness of GEO controller messages. Produce debug messages for Geo controller
Generate debug messages for all controllers.
Finalize sensor choice and complete integration of all three sensors.
Complete
11 4/26/2022 5/2/2022 Identify first PCB design inefficiencies/failures and submit the second and final draft for production
Thoroughly test the motor's performance on sloped terrain and refine PID controller
Test message timing and propagation with Bus Master
Improve existing navigation algorithm with state estimation and localization
Integration testing Driver controller with Mobile App
Complete
12 5/3/2022 5/9/2022 Finished mobile application
More testing, update schedule as needed
Complete
13 5/10/2022 5/16/2022 Final prototype complete Complete
14 5/17/2022 5/25/2022 Last tests Incomplete


Parts List & Cost

Item# Part Desciption Vendor Qty Cost
1 Unassembled RC Car Traxxas [1] 1 $279.99
2 CAN Transceivers Amazon [2] 1 $8.99
2 CAN Transceivers Amazon [3] 1 $8.99
2 CAN Transceivers Amazon [4] 1 $8.99
2 CAN Transceivers Amazon [5] 1 $8.99
2 CAN Transceivers Amazon [6] 1 $8.99


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

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



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

Adafruit gps.jpg

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


Wt901 compass.jpg

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.

Geo flow.jpg

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

Haversine.PNG

Bearing

Bearing calculations.PNG

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.





Communication Bridge Controller & LCD

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



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

Advise for Future Students

<Bullet points and discussion>

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

References