Difference between revisions of "S24: Team Falcons"
(→Technical Challenges) |
(→Advise for Future Students) |
||
| Line 494: | Line 494: | ||
=== Advise for Future Students === | === 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 === | === Acknowledgement === | ||
=== References === | === References === | ||
Revision as of 01:32, 18 May 2024
Contents
Project Title
Falcons
Abstract
<2-3 sentence abstract>
Introduction
The project was divided into N modules:
- Sensor ...
- Motor..
- ...
- Android
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 |
|
Completed |
| 2 | 02/26/2024 | 03/10/2024 |
|
Completed |
| 3 | 03/10/2024 | 03/12/2024 |
|
Not completed |
| 4 | 03/12/2024 | 03/19/2024 |
|
Not completed |
| 5 | 03/19/2024 | 03/26/2024 |
|
Not completed |
| 6 | 03/26/2024 | 04/02/2024 |
|
Not completed |
| 7 | 04/02/2024 | 04/09/2024 |
|
Not completed |
| 8 | 04/09/2024 | 04/16/2024 |
|
Not completed |
| 9 | 04/16/2024 | 04/23/2024 |
|
Not completed |
| 10 | 04/23/2024 | 04/30/2024 |
|
Not completed |
| 11 | 04/30/2024 | 05/07/2024 |
|
Not completed |
Parts List & Cost
| Item# | Part Desciption | Vendor | Qty | Cost |
|---|---|---|---|---|
| 1 | RC Car | Traxxas | 1 | $250.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
<Picture>
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.
|
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
|
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:
|
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.
