S24: Team Falcons

From Embedded Systems Learning Academy
Revision as of 18:17, 18 May 2024 by 243 user1 (talk | contribs) (→‎Introduction)

Jump to: navigation, search

Project Title

Falcons


Abstract

The Falcon RC car project is the combined efforts of our team to create an autonomously RC Car that avoids all obstacles and follow GPS to reach the destination. Here, we have put in all our experience in software design, hardware design, unit testing, power systems, and mobile application development. Project development started in March of 2024 and ended in May 2024.

Introduction

The project was divided into 4 modules:

  • Sensor and Bridge Controller...
  • Driver Controller..
  • Geo Controller
  • Motor Controller

Team Members & Responsibilities

<Team Picture>

Gitlab Project Link - [1]

<Provide ECU names and members responsible> <One member may participate in more than one ECU>

  • Sensor
    • Link to Gitlab user1
    • Link to Gitlab user2
  • Motor
    • Link to Gitlab user1
    • Link to Gitlab user2
  • Geographical
    • Link to Gitlab user1
    • Link to Gitlab user2
  • Communication Bridge Controller & LCD
    • Link to Gitlab user1
    • Link to Gitlab user2
  • Android Application
    • Link to Gitlab user1
    • Link to Gitlab user2
  • Testing Team
    • Link to Gitlab user1
    • Link to Gitlab user2


Schedule

Week# Start Date End Date Task Status
1 02/22/2024 02/26/2024
  • Literature survey- previous year project reports, hardware used, algorithms, challenges, advice to future students.
  • Ordered CAN transceivers.
 Completed
2 02/26/2024 03/10/2024
  • Familiarize with the busmaster tool
  • Basic CAN tx, rx with DBC encode, decode
  • Discuss power management system
  • Compare sensors, RC cars, bluetooth modules and other relevant hardware.
  • Create project wiki page
  • Create a project schedule and updated wiki page
 Completed
3 03/10/2024 03/12/2024
  • Create a block diagram for project
  • Finalize on roles
  • Finalize and order the list of selected components.
  • Create remote Git Lab repository
  • Establish a process for creating pull requests, code review and merging to master.
  • Discuss Android app design and development challenges
 Completed
4 03/12/2024 03/19/2024
  • Write implementation for interfacing ultrasonic sensors with Sensor and Bridge Controller board along with Unit Tests
  • Write implementation for interfacing Bluetooth module with Sensor and Bridge Controller board along with Unit Tests
  • Write implementation for interfacing motor, steering and RPM module with Motor Controller board along with Unit Tests
  • Write implementation for interfacing GPS module with Geological Controller board along with Unit Tests
  • Write implementation for Interfacing magnetometer with Geological Controller board along with Unit Tests
  • Create dbc file for CAN communication
 Completed
5 03/19/2024 03/26/2024
  • Bringup of ultrasonic sensors with SJ2 board-
    • Connect the sensor with the board using header connectors.
    • Check sensor functionality, obstacle detection.
    • Create initial draft for PCB design.
  • Bringup of bluetooth module with SJ2 board-
    • Connect the bluetooth module with the board using header connectors.
    • Check functionality, tx, rx, range.
    • Create initial draft for PCB design.
  • Bringup of motor controller with SJ2 board-
    • Disassemble the RC car, understand internal electrical connections, derive connections to control steering and drive the motor.
    • Control the steering and drive motor via SJ2 board.
    • Connect the encoder(RPM module) to the wheel and measure distance traveled.
    • Create initial draft for PCB design.
  • Bringup of GPS and Magnetometer module with SJ2 board-
    • Interface GPS module with SJ2 board and send data via CAN
    • Interface magnetometer with SJ2 board and send data via CAN
    • Create initial draft for PCB design.
  • Bring up of LCD with SJ2 board
    • Interface LCD with SJ2 board
    • Create initial draft for PCB design.
 Completed
6 03/26/2024 04/02/2024
  • Bringup of entire system
    • Connect all the different modules together.
    • Validate CAN tx and rx among the modules.
    • Develop integration tests.
 completed
7 04/02/2024 04/09/2024
  • Design and code initial draft of obstacle avoidance algorithm
  • Design and code initial draft of Android app
  • Finalize on power management
 Completed
8 04/09/2024 04/16/2024
  • Prototype 1:
  • Integrate all HW with the custom designed PCB.
  • Validate initial draft of obstacle avoidance algorithm.
  • Validate initial draft of obstacle waypoint algorithm.
 Not completed
9 04/16/2024 04/23/2024
  • Prototype 2:
  • Release and validate obstacle avoidance version 2
  • Release and validate waypoint algorithm version 2
  • Fine tune sensors for accuracy
  • Outdoor testing
 Not completed
10 04/23/2024 04/30/2024
  • Prototype 3:
  • Release obstacle avoidance logic version 2
  • Release waypoint algorithm version 2
  • Outdoor testing version 2
 Not completed
11 04/30/2024 05/07/2024
  • Final project demo
 Not completed


Parts List & Cost

Item# Part Desciption Vendor Qty Cost
1 RC Car Traxxas 1 $265.00
2 CAN Transceivers MCP2551-I/P Microchip [2] 8 Free Samples


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

<Gitlab link to your DBC file> <You can optionally use an inline image>



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

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



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>


Driver Node

Gitlab Link: https://gitlab.com/jincyjose491/sjtwo-c/-/tree/master/projects/driver?ref_type=heads

LCD Display

Hardware Design

Driver node gives the interconnection between input and output. It receives input from geo node and sensor node and give commands to the motor node. The only hardware driver has is the LCD display and CAN transceiver. The LCD display used is a SunFounder IIC I2C TWI Serial 2004 20x4 LCD Module and is interfaced through an I2C bus through the I2C2 port. The module used and pin connections for LCD is shown below.

LCD Display
Table 6. LCD Display Pinout
SJTwo Board CAN Board
P0.11 SCL2
P0.10 SDA2
Vin 3.3
GND GND

Software Design

Driver has more software and less hardware. For navigation, there are two algorithms - obstacle avoidance and GPS navigation. Obstacle avoidance has precedence over GPS navigation. In case of any obstacle, car avoids obstacle. In other cases, it follows the path from geo node input. When the destination is reached, car slows down and stops.

Obstacle Avoidance

The obstacle avoidance code is written in the form of a truth table that has 4 bit input and one bit output. Inputs are four sensor values and output the motor commands. Bases on changes in sensor values, the motor command also changes. The logic that worked for us is given below

Table 6. Obstacle Avoidance Logic
left sensor right sensor middle sensor rear sensor motor command
0 0 0 X follow GPS navigation
0 1 0 X forward left
1 0 0 X forward right
0 1 1 0 reverse right
1 0 1 0 reverse left
X X 1 1 stop
1 1 0 0 reverse left

GPS Navigation

For GPS navigation the angle difference between heading and bearing is calculated and motor turn commands are generated based on this. Heading gives the current position in angle with respect to north. Bearing gives the angle to destination with respect to north. The logic that worked for our hardware is given below:

Table 6. GPS Logic
Angle difference = bearing - heading Turn Angle
0 to 180 left
180 to 360 right [angle = (360 - angle)]
-180 to 0 right
-360 to -180 left [angle = fabs(360 + angle)]

Technical Challenges

Since driver comes as the interconnect between all other nodes, the driver logic could be verified by outside testing only when we had stable input from geo and sensor node and motor nodes working as expected for given PWM. Unit testing can help in building of logic. But for actual test, we have to make sure all inputs are reliable. This can be verified with debug messages on bluetooth, CAN messages on busmaster, LCD display or LED indicators. The verification or debugging should be done in same frequency as which driver is processing.

  • Problem: LCD was not displaying anything.
    • Solution: Initially tried with 3.3V supply, then 5V supply and finally added level shifter to I2C pins. But the issue was slave address given in the datasheet was wrong. I got the correct slave address from web serial. After this was corrected, LCD worked well with 3.3V.
  • Problem: LCD flickered a lot when everything was connected together.
    • Solution: We initially connected all 5V supplies to a single 5V source. This included servo motor also. And it was causing the flicker. So, we powered up servo and rpm from ESC, all other sensors were powered separately from power bank and the issue was solved. This problem could have been avoided if more reports were read on how to power everything up.
  • Problem: Driver gave a reverse signal for one clock cycle when there was no obstacle.
    • Solution: Sensors gave random value for just one clock cycle and this caused driver to generate reverse command. After sensor inputs were corrected and made stable, the problem was solved.
  • Problem: Driver not able to correct turning commands to motor even after sensing obstacle on side. This happened in the clock cycle when there was obstacle on all three side and it took reverse.
    • Solution: We gave steps in angle changes in size of 5. Instead of direct 45 degree turn, car always turned in steps. So even though it sensed obstacle step sized turn angles took long clock cycles. So I finally reverted back to simple code logic of 45 degree turn and obstacle avoidance started working perfectly.
  • Problem: We thought driver was giving wrong commands to sensor values that was there on app.
    • Solution: Sensor values were updated at 1 Hz. Driver was working at 10Hz which is 10 times faster than what we see on app. So incorrect sensor value for just one cycle was not displayed. Finally debugged it in a hard way from all debugging sources listed above.


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

  • Make sure you have a clear idea on how to power up every modules in the project. This require careful distribution of power across the boards, sensors, motors. Connect everything together in the initial stage to see if entire module can work well when connected together. Doing this at an early stage helps to understand how to correctly power up everything. Again, you'll get an idea on which all modules should/should not be connected together, which module require additional power source, etc. from previous reports. Most of your problems could be solved from previous year reports. Don't limit yourself to 2-3 reports. Read more.. It'll be useful.
  • Try to interface everything and see if communication is reliable between the nodes. Do this early so that you can work on project requirements.
  • Find out your motor PWM for forward, neutral and reverse as soon as you get the car. You can save time here.
  • Simplify the wire connections to save time when you meet. When we met in the initial few weeks, most of the time was spent on connecting everything from scratch and figuring out why something is not working.
  • Get good quality hardware so that you don't have to invest more time here.

Acknowledgement

We would like to thank our instructor, Preet, for all his efforts in our class and all motivation and guidance lifelong. We have learnt so much about unit testing, C coding, software-hardware integration, team work, git and documentation, all because of Preet.

We also have to acknowledge all the teams who came before us, their reports helped us a lot.

References

Retrieved from "http://socialledge.com/sjsu/index.php?title=S24:_Team_Falcons&oldid=71403"