Difference between revisions of "S23: Meh-sla Automotive"
(→System Hardware Design) |
(→Battery Management) |
||
| Line 668: | Line 668: | ||
===== Battery Management ===== | ===== Battery Management ===== | ||
| − | + | ||
| + | The system was equipped with a dual-battery configuration, comprising one battery exclusively for the motor and another dedicated to powering the SJTwo boards and peripherals. This deliberate arrangement ensured uninterrupted power supply to the controller boards, enabling them to function optimally under all circumstances. The primary power source consisted of a portable 20,000 mAh battery, delivering a consistent 5V output to energize the entire system. | ||
=== Software Design === | === Software Design === | ||
Revision as of 06:43, 25 May 2023
Contents
Project Title
¯\_(ツ)_/¯ Meh-Sla Automotive ¯\_(ツ)_/¯
Abstract
The ultimate goal of the project is to design an autonomous car which navigate from its current location to a destination. Along it's way it needs to avoid the obstacles and follow the waypoints. To achieve this we are using four SJ2 boards which communicates with each other via CAN bus along with required sensors and a mobile app which communicates with one of the SJ2 boards via Bluetooth. Through our experience, we knew that we wouldn't be the Worst-Sla. We say that we are Meh-Sla even though we know we are the Best-Sla.
Introduction
The project was divided into 5 modules:
1) Sensor and bridge controller:
- Interfaced with 4 ultrasonic sensors for obstacle detection.
- Interfaced with a Bluetooth module for the controller to mobile app communication.
2) Motor controller:
- Interfaced with vehicle motor to control its speed and steering.
- Interfaced with RPM sensors to get feedback about the vehicle's speed.
3) Geographical controller:
- Interfaced with a magnetometer to get the current heading of the vehicle.
- Interfaced with a GPS module to get the current location information.
4) Driver and LCD controller:
- Process information from the sensor and geological board, and send speed and steering to the motor board based on obstacle avoidance and path determination algorithm.
- Interfaced with an LCD module to display the vehicle status.
5) Mobile App:
- Communicates over Bluetooth.
- Sends destination location or start/stop signal to the car.
- Receives sensor and other navigation status and displays it.
Team Members & Responsibilities
- Team Lead
- Motor Board
- Geo Board
- Android App
- Driver and LCD Board
- Sensor Board
- Geo Board
- Hardware Design
- Software Testing
Schedule
| Week # | Start Date | End Date | Task | Status |
|---|---|---|---|---|
| 1 | 2/12/2023 | 2/18/2023 |
|
|
| 2 | 2/19/2023 | 2/25/2023 |
|
|
| 3 | 26/2/2023 | 3/4/2023 |
|
|
| 4 | 3/5/2023 | 3/11/2023 |
|
|
| 5 | 3/12/2023 | 3/18/2023 |
|
|
| 6 | 3/19/2023 | 3/25/2023 |
|
|
| 7 | 3/26/2023 | 4/1/2023 |
|
|
| 8 | 4/2/2023 | 4/8/2023 |
|
|
| 9 | 4/9/2023 | 4/15/2023 |
|
|
| 10 | 4/16/2023 | 4/22/2023 |
|
|
| 11 | 4/23/2023 | 4/29/2023 |
|
|
| 12 | 4/30/2023 | 5/6/2023 |
|
|
| 13 | 5/7/2023 | 5/13/2023 |
|
|
| 14 | 5/14/2023 | 5/19/2023 |
|
|
| 15 | 5/20/2023 | 5/26/2023 |
|
|
Parts List & Cost
| Item# | Part Desciption | Vendor | Qty | Cost |
|---|---|---|---|---|
| 1 | RC Car | Traxxas | 1 | $250.00 |
| 2 | SJ2 board | From Preet [1] | 4 | $50.00 |
| 3 | CAN Transceivers (SN65HVD230) | Waveshare [2] | 4 | Free Samples |
| 4 | RC Car RPM | Traxxas [3] | 1 | $8.23 |
| 5 | Adafruit Bluetooth BLE Friend | Adafruit [4] | 1 | $17.5 |
| 6 | GPS Module | Adafruit [5] | 1 | $29.95 |
| 7 | Compass Module | Adafruit [6] | 1 | $12.50 |
| 8 | Ultrasonic Sensors | Adafruit [7] | 4 | $3.95 |
| 9 | LCD Screen | Amazon [8] | 1 | $12.89 |
System Hardware Design
Block Diagram
Layout Diagram
Layout Description
The four SJTwo boards were placed facing upwards and poking out from underneath the PCB. Placing the boards in the orientation allowed for use of the on board LEDs and to have access to the Reset buttons on each board. We chose to sacrifice compactness of the design for the ability to use the LEDs early on in development. This setup also allowed for the PCB to be divided into four quadrants for the rest of the design.
The entire system was powered by a portable 20,000mAh power bank that connected to the PCB via a micro USB connector. From the connector, a 5V and GND bus were ran down the center of the PCB using bus wire to power the four SJTwo boards and other peripherals. Powering all boards from the same 5V line ensured that all voltages were relative to each other and, with the bus stretching down the length of the PCB, cleaned up the need for excessive wires because it gave multiple points for 5V and GND.
The four CAN transceivers were placed upright, to save PCB space, in a 2x2 formation between two of the SJTwo boards so that a CANH and CANL bus could be created nearby and be easily accessible for the PCAN dongle to easily reach. The CAN transceivers were powered via a 3.3V bus that was created by connecting all the 3.3V SJTwo outputs together ensuring that all voltages were relative to each other.
The four ultrasonic sensors were placed on daughter boards so that they could better be adjusted in the correct direction without affecting the rest of the system. Three were placed in the front of the car for the right, front and left sensors and one was placed in the rear as the rear sensor. The LCD screen was placed behind the front sensors to prevent any interference to the sensors and to prevent the LCD screens from moving in the case that it might become dislodged for any reason.
The compass was placed on a pole that limited the amount of interference it would receive from the other components in the system. A PVC pipe was used for the lightweight aspect and so that the wires could be run down through the PVC pipe giving a cleaner look.
The GPS and Bluetooth modules were placed next to the SJTwo board that was controlling them. The battery for the motor, the esc and the rpm sensor were all mounted on the chassis of the vehicle.
Each board had a red LED to signal CAN MIA. The two front yellow LEDs signaled obstacle avoidance. If an object on the right or left was detected then the corresponding side would light up and if an obstacle was detected in the front then both would light up. If neither was lit up then the car was running via path determination instead of obstacle avoidance. The green led under the PCB would light up when power was supplied and the blue LED on the back would blink while the GPS was trying to pair and stay lit up after the GPS locked on to a signal.
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_ : 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_: DBG DRIVER MOTOR SENSOR GEO BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR BO_ 101 MOTOR_SPEED: 1 DRIVER SG_ DC_MOTOR_DRIVE_SPEED_sig : 0|8@1+ (0.1,-10) [-10|10] "kph" SENSOR,MOTOR BO_ 102 MOTOR_ANGLE: 1 DRIVER SG_ SERVO_STEER_ANGLE_sig : 0|8@1+ (1,-45) [-45|45] "degrees" SENSOR,MOTOR BO_ 200 SENSOR_SONARS: 4 SENSOR SG_ SENSOR_SONARS_left : 0|8@1+ (1,0) [0|158] "inch" DRIVER SG_ SENSOR_SONARS_right : 8|8@1+ (1,0) [0|158] "inch" DRIVER SG_ SENSOR_SONARS_front : 16|8@1+ (1,0) [0|158] "inch" DRIVER SG_ SENSOR_SONARS_rear : 24|8@1+ (1,0) [0|158] "inch" DRIVER BO_ 202 GPS_DESTINATION_LOCATION: 8 SENSOR SG_ GPS_DEST_LAT_SCALED_1000000 : 0|32@1- (1,0) [0|0] "Degrees" GEO SG_ GPS_DEST_LONG_SCALED_1000000 : 32|32@1- (1,0) [0|0] "Degrees" GEO BO_ 203 GEO_STATUS: 8 GEO SG_ GEO_STATUS_COMPASS_HEADING : 0|12@1+ (1,0) [0|359] "Degrees" DRIVER,SENSOR SG_ GEO_STATUS_COMPASS_BEARING: 12|12@1+ (1,0) [0|359] "Degrees" DRIVER,SENSOR SG_ GEO_STATUS_DISTANCE_TO_DESTINATION : 24|16@1+ (0.01,0) [0|0] "Meters" DRIVER,SENSOR BO_ 204 GPS_CURRENT_INFO: 8 GEO SG_ GPS_CURRENT_LAT_SCALED_1000000 : 0|32@1- (1,0) [0|0] "degrees" DRIVER,SENSOR SG_ GPS_CURRENT_LONG_SCALED_1000000 : 32|32@1- (1,0) [0|0] "degrees" DRIVER,SENSOR BO_ 205 GPS_CURRENT_DESTINATIONS_DATA: 8 GEO SG_ CURRENT_DEST_LAT_SCALED_1000000 : 0|32@1- (1,0) [0|0] "Degrees" DRIVER SG_ CURRENT_DEST_LONG_SCALED_1000000 : 32|32@1- (1,0) [0|0] "Degrees" DRIVER BO_ 206 BRIDGE_APP_COMMANDS: 1 SENSOR SG_ APP_COMMAND : 0|2@1+ (1,0) [0|0] "" MOTOR BO_ 300 MOTOR_STATUS: 3 MOTOR SG_ MOTOR_STATUS_wheel_error : 0|1@1+ (1,0) [0|0] "" DRIVER,IO SG_ MOTOR_STATUS_speed_kph : 8|16@1+ (0.001,0) [0|0] "kph" DRIVER,IO BO_ 401 MOTOR_DEBUG: 1 MOTOR SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|256] "sec" DBG BO_ 402 COMPASS_RAW_DEBUG: 6 GEO SG_ COMPASS_RAW_X : 0|15@1- (1,0) [0|0] "" DBG SG_ COMPASS_RAW_Y : 16|15@1- (1,0) [0|0] "" DBG SG_ COMPASS_RAW_Z : 32|15@1- (1,0) [0|0] "" DBG BO_ 403 SENSOR_BEFORE_AVERAGE_DEBUG: 4 SENSOR SG_ SENSOR_BEFORE_AVG_left : 0|8@1+ (1,0) [0|0] "inch" DBG SG_ SENSOR_BEFORE_AVG_right : 8|8@1+ (1,0) [0|0] "inch" DBG SG_ SENSOR_BEFORE_AVG_front : 16|8@1+ (1,0) [0|0] "inch" DBG SG_ SENSOR_BEFORE_AVG_rear : 24|8@1+ (1,0) [0|0] "inch" DBG CM_ BU_ DBG "The debugging node for testing dbc with the car"; 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 geological Controller of the car"; CM_ BO_ 100 "Sync message used to synchronize the controllers"; CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver"; CM_ SG_ 101 DC_MOTOR_DRIVE_SPEED_sig "The speed in kph to set the motor speed. TODO: choose kph/mph"; CM_ SG_ 102 SERVO_STEER_ANGLE_sig "The direction in degrees to set the RC car servo direction."; 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 and Bridge Controller
Hardware Design
Ultrasonic Sensors
We used HC-SR04 ultrasonic sensors for obstacle detection. It could provide a range from 2 cm to 400 cm non-contact measurement. The ranging accuracy is approximately 3mm and the effectual angle is less than 15°. It needs to be powered by a 5V power supply. We are using 4 HC-SR04 sensors in the RC car(front, rear, left, and right).
HC-SR04 specifications
- Operating voltage: +5V
- Theoretical Measuring Distance: 2cm to 450cm
- Practical Measuring Distance: 2cm to 80cm
- Accuracy: 3mm
- Measuring angle covered: <15°
- Operating Current: <15mA
- Operating Frequency: 40Hz
The pinout and the timing diagram of the HC-SR04 sensor are shown in the following figures. The module includes an ultrasonic transmitter, a receiver, and a control circuit. The basic principle of work: When the trigger pin is set HIGH for at least 10us, the module automatically sends a 40 kHz ultrasonic wave from the Ultrasonic transmitter. This wave travels in the air and when it gets obstructed by any material it gets reflected back toward the sensor. This reflected wave is observed by the Ultrasonic receiver module. Once the wave is returned the Echo pin goes high for a particular amount of time which will be equal to the time taken for the wave to return back to the sensor. The amount of time during which the Echo pin stays high is measured by the SJ2 board as it gives the information about the time taken for the wave to return back to the Sensor. Using this information the distance is measured as explained in the above heading. From that duration, the distance at which the object is present can be measured using the formula, Distance = Speed × Time.
Bluetooth Module
For the communication between the mobile and the RC Car, we are using Adafruit Bluefruit LE UART Friend - BLE module. This module communicates with the SJ2 board through UART at a baud rate of 9600. It also has the capability of working in two modes (data mode and command mode). We can toggle between the two modes using the MOD pin through a GPIO signal or manually using the onboard switch. It supports AT command set, which can be used to control the device's behavior. In data mode, the data written to the UART in the form of a string will be sent through Bluetooth.
Adafruit Bluefruit specifications
- ARM Cortex M0 core running at 16MHz
- 256KB flash memory
- 32KB SRAM
- Transport: UART @ 9600 baud with HW flow control (CTS+RTS required)
- 5V-safe inputs
- On-board 3.3V voltage regulation
- Bootloader with support for safe OTA firmware updates
- Easy AT command set to get up and running quickly
Software Design
Ultrasonic Sensors
We read about the signal interference of adjacent sensors from many of the past projects. So we decided to avoid that interference by triggering two non-adjacent sensors at a time. The FRONT_REAR sensor pair is triggered first. Once both of the sensors compute the distance from the obstacle, then the next pair, RIGHT_LEFT is triggered. For the ultrasonic sensors, we used a separate task instead of the periodic callbacks since this task sleeps on a semaphore which might affect the other functions in the periodic callback function.
SONAR task
void sonar_task(void *p) {
sonar__init();
front_rear_echo_received = xSemaphoreCreateBinary();
left_right_echo_received = xSemaphoreCreateBinary();
lpc_peripheral__enable_interrupt(LPC_PERIPHERAL__GPIO, sonar__interrupt_dispatcher, "sonar_timing_handler");
NVIC_EnableIRQ(GPIO_IRQn);
while (1) {
sonar__send_trigger_for_10us(FRONT_REAR);
if (xSemaphoreTake(front_rear_echo_received, 100)) {
sonar_pair_info[0].distance_from_obstacle_sonar1 = sonar__compute_obstacle_distance_single_sensor(FRONT_SONAR);
sonar_pair_info[0].distance_from_obstacle_sonar2 = sonar__compute_obstacle_distance_single_sensor(REAR_SONAR);
}
vTaskDelay(10);
sonar__send_trigger_for_10us(LEFT_RIGHT);
if (xSemaphoreTake(left_right_echo_received, 100)) {
sonar_pair_info[1].distance_from_obstacle_sonar1 = sonar__compute_obstacle_distance_single_sensor(LEFT_SONAR);
sonar_pair_info[1].distance_from_obstacle_sonar2 = sonar__compute_obstacle_distance_single_sensor(RIGHT_SONAR);
}
sonar__averaging_sensor_values();
}
}
Bluetooth Module
Bluetooth module is used to send the debug information such as sensor values, current heading, bearing, distance to the destination, and current GPS location to the mobile app. Also, it receives the destination coordinates and start/stop signal from the mobile app. To differentiate between the coordinates and the start/stop signal we used the first char as '@' or '#'. If the starting char is '@', the message contains the destination coordinate. Similarly, "#0' represents the stop signal, and '#1' represents the start signal.
Bluetooth initialization
void bt_module__init(void) {
line_buffer__init(&line_buffer, line, sizeof(line));
gpio__construct_with_function(GPIO__PORT_4, 28, GPIO__FUNCTION_2);
gpio__construct_with_function(GPIO__PORT_4, 29, GPIO__FUNCTION_2);
uart__init(bt_module_uart_port, clock__get_peripheral_clock_hz(), 9600);
QueueHandle_t rxq = xQueueCreate(500, sizeof(char));
QueueHandle_t txq = xQueueCreate(500, sizeof(char));
uart__enable_queues(bt_module_uart_port, txq, rxq);
bt_pin__mod = gpio__construct_as_output(GPIO__PORT_0, 15);
bt_pin__cts = gpio__construct_as_output(GPIO__PORT_0, 18);
bt_pin__rts = gpio__construct_as_input(GPIO__PORT_2, 9);
gpio__reset(bt_pin__cts);
bt_set_mode(bt_data_mode);
}
Bluetooth data handler
static void bt_data_handler__parse_data(char *data) {
switch (data[0]) {
case '@':
bt_data_handler__parse_coordinates(data + 1);
break;
case '#':
bt_data_handler__parse_start_or_stop(data + 1);
break;
default:
break;
}
}
Technical Challenges
Sensor module
- Issue: Sometimes the front sensor was detecting some obstacles even though there was nothing in front.
- Solution: We included a delay of 10ms in between triggering the first and second pair of sensors.
- Issue: We see some noise in the sensor measurement which makes the car's steering very wobbly.
- Solution: We included a sensor value averaging logic which will return the average of the last 5 readings instead of a single value
Bluetooth module
- Issue: We faced a weird problem in the geo node when computing the distance between the origin and destination. It gave us bizarre values. First, we thought the problem was with the Geo node distance computation formula. But when we trace back the issue, it was with the line buffer initialization in the sensor board. We mistakenly initialized the line buffer with a size of 20 instead of 200. This truncates the coordinates of the destination received (sometimes sets longitude = 0) from the mobile which in turn, affects the distance computation at the Geo node.
- Solution: We initialized the line buffer with a bigger size.
Motor Controller
Hardware Design
PCB Design
Phil to talk about PCB design and choices for layout
Battery Management
The system was equipped with a dual-battery configuration, comprising one battery exclusively for the motor and another dedicated to powering the SJTwo boards and peripherals. This deliberate arrangement ensured uninterrupted power supply to the controller boards, enabling them to function optimally under all circumstances. The primary power source consisted of a portable 20,000 mAh battery, delivering a consistent 5V output to energize the entire system.
Software Design
<List the code modules that are being called periodically.>
RPM Module
Tony will write about how the RPM module was implemented using triggers.
void sonar_task(void *p) {
Test
}
Motor Module
Tony will write about the motor and how forward/reverse works
static float test_task(float lol) {
Just wanted to see if this is cool;
}
Steering Module
Tony will write about the motor and how forward/reverse works
static float test_task(float lol) {
Preet is cool;
if(Phil_is_reading) Phil is cooler;
else Tony is the coolest
}
Technical Challenges
< List of problems and their detailed resolutions>
Geological Controller
Hardware Design
Compass
The compass we used is from Adafruit, LSM303AGR breakout. It has both a magnetometer and an accelerometer. But, We didn't use the accelerometer which is also needed to properly calibrate the compass because the compass couldn't be aligned exactly parallel to the ground when mounting on a car(instead we used a simple trick - see technical challenges for a detailed description). The compass communicates with the SJ2 board via I2C. It operates on 3.3V. It is a triple-axis accelerometer/magnetometer compass module. The magnetometer is mounted on the car with the Z axis pointing away from the ground and X and Y axis pointing as shown in the image below (we can also switch the x and y, but the formula remains the same). The x and y values shown in the formula correspond to the raw x and y values of the magnetometer. The compass should be placed as much as away from all the electronics in the car. We used a PVC pipe to place the compass in an elevated position. Even after the elevated positioning, we faced interference that makes it necessary to calibrate the compass. For the compass calibration, we used a third-party calibration tool. Magneto.
We wrote a simple Python script to visualize how the calibration affects the compass output. The outputs of the Python script show how the compass raw data gets affected after mounting on the car and after calibration.
GPS
The GPS module we used is MTK3339-based breakout from Adafruit. It is interfaced with the SJ2 board through UART. It will output NMEA strings at a default baud rate of 9600. We parsed the latitude and longitude from the GPGGA data and used them to compute the bearing and distance to the destination.
Software Design
Waypoint Algorithm
Technical Challenges
< List of problems and their detailed resolutions>
Driver/LCD Controller
<Picture of LCD> <Picture of Block Diagram>
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
=== References ===
