Embedded Systems Learning Academy - User contributions [en]

F24: Dodge Cars

2024-10-29T02:21:00Z

Preet: Created page with "=== Grading Criteria === * How well is Software & Hardware Design described? * How well can this report be used to reproduce this project? * Code Quali..."

=== Grading Criteria ===

* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.


== Project Title ==
Parking Frenzy

== Abstract ==
Parking Frenzy is car parking video game. The player will be able to move the car in right or left direction, the road itself will be descending towards the car and will also consist of obstacles such as other vehicles. The road will have lanes through which the car must navigate to ultimately be able to slot itself into the right parking spot alongside the road. The parking spots will be randomly generated along the edge of the LED matrix and the player must navigate the car into the spot at the right time or else it will result in a crash. The difficulty of the game will increase as the player reaches a certain amount of points. The difficulty will increase in terms of the speed of the car and the number of obstacles. The final score of the player will be displayed at the end of every game. a speaker attached to the board will generate the game sounds.

== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

=== Team Members & Responsibilities ===
* Shreyas
**
* Teja
**
* Navneet
**

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/12/2020
* 10/13/2020
|
* 10/18/2020
* 10/13/2020
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project
|
* Completed
* In progress
|-
! scope="row"| 2
|
*10/19/2020
|
*10/20/2020
|

*Order necessary parts
|
* In progress
|-
! scope="row"| 3
|
*10/26/2020
|
*11/01/2020
|
*Read and familiarize with LED Matrix Datasheet
|
* Not started

|-
! scope="row"| 4
|
* 11/02/2020
|
* 11/08/2020
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* Not started
|-
! scope="row"| 5
|
*11/09/2020
*11/09/2020
*11/09/2020
*11/09/2020
|
*11/10/2020
*11/15/2020
*11/15/2020
*11/15/2020
|
* Finalize wiki schedule
* Order circuit boards components and complete the design for printing
* circuit board and component assembly
* Circuit board testing
* Additional accessories if required and finalization of hardware
|
* Not started
* Not started
* Not started
* Not started
* Not started
|-
! scope="row"| 6
|
*11/16/2020
|
*11/22/2020
|
*Integration of circuit boards and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* Not started
* Not started
* Not started
|-
! scope="row"| 7
|
* 11/23/2020

|
* 11/29/2020
|
* Integrate game logic code with LED matrix
* Integrate game sounds with game logic
|
* Not started
* Not started
|-
! scope="row"| 8
|
* 11/30/2020
|
* 12/06/2020
|

* Integrate subsystem
* Finalizing the video game
* Update the wiki page.
|
* Not started
* Not started
* Not started
|-
! scope="row"| 9
|
* 12/07/2020
|
* 12/13/2020
|
* Address bugs during testing of integrated system
* Test pause/play functionality
|
* Not started
* Not started
* Not started
|-
! scope="row"| 10
|
*12/16/2020
*12/14/2020
*12/14/2020
*12/14/2020
|
*12/16/2020
*12/16/2020
*12/16/2020
*12/16/2020
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* Not started
* Not started
* Not started
* Not started
|-
|}

<HR>
 

== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components. Do not write long stories here.

== Design & Implementation ==
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

=== Hardware Design ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.

=== Software Design ===
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

=== Implementation ===
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

== Testing & Technical Challenges ==
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

=== <Bug/issue name> ===
Discuss the issue and resolution.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

Realtime OS on Embedded Systems

2024-10-29T02:19:34Z

Preet: /* Fall 2024 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2024 | Fall 2024]] ===

* [[F24: Dodge Cars]]
* [[F24: Rival Rush]]

=== [[Fall 2022 | Fall 2022]] ===

* [[F22: DDRTOS]]
* [[F22: xGameCreate]]
* [[F22: Embedded Gamers]]
* [[F22: Bob Burgers]]
* [[F22: Space Warriors]]
* [[F22: Thunder Flash]]

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: ACE MARIO]]
* [[F21: Skeh-lleybones]]
* [[F21: Sons of Ultron]]
* [[F21: Juvenile Jumpers]]
* [[F21: Treasure Dive]]
* [[F21: FollowMe]]
* [[F21: Flame Over]]
* [[F21: Space Rage]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Realtime OS on Embedded Systems

2024-10-29T02:19:14Z

Preet:

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2024 | Fall 2024]] ===

* [[F24: Dodge Cars]]

=== [[Fall 2022 | Fall 2022]] ===

* [[F22: DDRTOS]]
* [[F22: xGameCreate]]
* [[F22: Embedded Gamers]]
* [[F22: Bob Burgers]]
* [[F22: Space Warriors]]
* [[F22: Thunder Flash]]

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: ACE MARIO]]
* [[F21: Skeh-lleybones]]
* [[F21: Sons of Ultron]]
* [[F21: Juvenile Jumpers]]
* [[F21: Treasure Dive]]
* [[F21: FollowMe]]
* [[F21: Flame Over]]
* [[F21: Space Rage]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

S24: Team Zero

2024-03-05T04:40:46Z

Preet: Created page with "== Project Title == <Team Name> <HR> == Abstract == <2-3 sentence abstract> === Introduction === The project was divided into N modules: * Sensor ... * Motor.. * ......"

== Project Title ==
<Team Name>

<HR>
 
== Abstract ==
<2-3 sentence abstract>

=== Introduction ===

The project was divided into N modules:

* Sensor ...
* Motor..
* ...
* Android

=== Team Members & Responsibilities ===
<Team Picture>

Gitlab Project Link - [https://gitlab.com/...]
 

<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

<HR>
 
== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
| 09/15/2017
| 09/16/2017
|
* Read previous projects, gather information and discuss among the group members.
* Distribute modules to each team member.

| Completed
|-
! scope="row"| 2
| 09/17/2017
| 10/03/2017
|
|
|-
|}

<HR>
 
== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Cost
|-
! scope="row"| 1
| RC Car
| Traxxas
| 1
| $250.00
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Microchip [http://www.microchip.com/wwwproducts/en/en010405]
| 8
| Free Samples
|-
|}

<HR>
 
== Printed Circuit Board ==
<Picture and information, including links to your PCB>
 

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

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

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

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

<HR>
 

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

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

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

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

Industrial Application using CAN Bus

2024-03-05T04:40:06Z

Preet:

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2024 | Spring 2024]] ===
* [[S24: Team Zero]]

=== [[Spring 2023 | Spring 2023]] ===
* [[S23: Meh-sla Automotive]]
* [[S23: X Æ A-13]]
* [[S23: CAN CLAN]]

=== [[Spring 2022 | Spring 2022]] ===
* [[S22: Testla]]
* [[S22: TBD]]
* [[S22: Firebolt]]
* [[S22: Road Runner]]
* [[S22: Silver Arrow]]

=== [[Spring 2021 | Spring 2021]] ===
* [[S21: UTAH]]
* [[S21: exFAT]]
* [[S21: (RC)^2]]
* [[S21: Roadster]]

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimble]]
* [[S20: Bucephalus]]
* [[S20: Canster Truck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

S23: Meh-sla Automotive

2023-03-01T04:33:48Z

Industrial Application using CAN Bus

2023-03-01T04:33:00Z

Preet: /* Class Project Reports */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2023 | Spring 2023]] ===
* [[S23: Meh-sla Automotive]]

=== [[Spring 2022 | Spring 2022]] ===
* [[S22: Testla]]
* [[S22: TBD]]
* [[S22: Firebolt]]
* [[S22: Road Runner]]
* [[S22: Silver Arrow]]

=== [[Spring 2021 | Spring 2021]] ===
* [[S21: UTAH]]
* [[S21: exFAT]]
* [[S21: (RC)^2]]
* [[S21: Roadster]]

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimble]]
* [[S20: Bucephalus]]
* [[S20: Canster Truck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

F22: DDRTOS

2022-10-12T02:17:52Z

=== Grading Criteria ===

* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.


== Project Title ==
Parking Frenzy

== Abstract ==
Parking Frenzy is car parking video game. The player will be able to move the car in right or left direction, the road itself will be descending towards the car and will also consist of obstacles such as other vehicles. The road will have lanes through which the car must navigate to ultimately be able to slot itself into the right parking spot along side the road. The parking spots will be randomly generated along the edge of the LED matrix and the player must navigate the car into the spot at the right time or else it will result in a crash. The difficulty of the game will increase as the player reaches a certain amount of points. The difficulty will increase in terms of the speed of the car and the number of obstacles. The final score of the player will be displayed at the end of every game. a speaker attached to the board will generate the game sounds.

== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

=== Team Members & Responsibilities ===
* Scott LoCascio
**
* Naeem Mannan
**
* Rahul Ghadge
**

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/12/2020
* 10/13/2020
|
* 10/18/2020
* 10/13/2020
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project
|
* Completed
* In progress
|-
! scope="row"| 2
|
*10/19/2020
|
*10/20/2020
|

*Order necessary parts
|
* In progress
|-
! scope="row"| 3
|
*10/26/2020
|
*11/01/2020
|
*Read and familiarize with LED Matrix Datasheet
|
* Not started

|-
! scope="row"| 4
|
* 11/02/2020
|
* 11/08/2020
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* Not started
|-
! scope="row"| 5
|
*11/09/2020
*11/09/2020
*11/09/2020
*11/09/2020
|
*11/10/2020
*11/15/2020
*11/15/2020
*11/15/2020
|
* Finalize wiki schedule
* Order circuit boards components and complete the design for printing
* circuit board and component assembly
* Circuit board testing
* Additional accessories if required and finalization of hardware
|
* Not started
* Not started
* Not started
* Not started
* Not started
|-
! scope="row"| 6
|
*11/16/2020
|
*11/22/2020
|
*Integration of circuit boards and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* Not started
* Not started
* Not started
|-
! scope="row"| 7
|
* 11/23/2020

|
* 11/29/2020
|
* Integrate game logic code with LED matrix
* Integrate game sounds with game logic
|
* Not started
* Not started
|-
! scope="row"| 8
|
* 11/30/2020
|
* 12/06/2020
|

* Integrate subsystem
* Finalizing the video game
* Update the wiki page.
|
* Not started
* Not started
* Not started
|-
! scope="row"| 9
|
* 12/07/2020
|
* 12/13/2020
|
* Address bugs during testing of integrated system
* Test pause/play functionality
|
* Not started
* Not started
* Not started
|-
! scope="row"| 10
|
*12/16/2020
*12/14/2020
*12/14/2020
*12/14/2020
|
*12/16/2020
*12/16/2020
*12/16/2020
*12/16/2020
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* Not started
* Not started
* Not started
* Not started
|-
|}

<HR>
 

== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components. Do not write long stories here.

== Design & Implementation ==
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

=== Hardware Design ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.

=== Software Design ===
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

=== Implementation ===
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

== Testing & Technical Challenges ==
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

=== <Bug/issue name> ===
Discuss the issue and resolution.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

Realtime OS on Embedded Systems

2022-10-12T02:17:35Z

Preet:

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2022 | Fall 2022]] ===

* [[F22: DDRTOS]]

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: ACE MARIO]]
* [[F21: Skeh-lleybones]]
* [[F21: Sons of Ultron]]
* [[F21: Juvenile Jumpers]]
* [[F21: Treasure Dive]]
* [[F21: FollowMe]]
* [[F21: Flame Over]]
* [[F21: Space Rage]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

S22: TBD

2022-03-16T01:22:44Z

Industrial Application using CAN Bus

2022-03-16T01:22:22Z

Preet: /* Class Project Reports */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2022 | Spring 2022]] ===
* [[S22: TBD]]

=== [[Spring 2021 | Spring 2021]] ===
* [[S21: UTAH]]
* [[S21: exFAT]]
* [[S21: (RC)^2]]
* [[S21: Roadster]]

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimble]]
* [[S20: Bucephalus]]
* [[S20: Canster Truck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

F21: Sons of Ultron

2021-10-13T03:36:10Z

=== Grading Criteria ===

* How well is Software & Hardware Design described?
* How well can this report be used to reproduce this project?
* Code Quality
* Overall Report Quality:
** Software Block Diagrams
** Hardware Block Diagrams
**: Schematic Quality
** Quality of technical challenges and solutions adopted.


== Project Title ==
Parking Frenzy

== Abstract ==
Parking Frenzy is car parking video game. The player will be able to move the car in right or left direction, the road itself will be descending towards the car and will also consist of obstacles such as other vehicles. The road will have lanes through which the car must navigate to ultimately be able to slot itself into the right parking spot along side the road. The parking spots will be randomly generated along the edge of the LED matrix and the player must navigate the car into the spot at the right time or else it will result in a crash. The difficulty of the game will increase as the player reaches a certain amount of points. The difficulty will increase in terms of the speed of the car and the number of obstacles. The final score of the player will be displayed at the end of every game. a speaker attached to the board will generate the game sounds.

== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

=== Team Members & Responsibilities ===
* Scott LoCascio
**
* Naeem Mannan
**
* Rahul Ghadge
**

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
|
* 10/12/2020
* 10/13/2020
|
* 10/18/2020
* 10/13/2020
|
* Read previous projects, gather information and discuss among the group members.
* Create GitLab repository for project
|
* Completed
* In progress
|-
! scope="row"| 2
|
*10/19/2020
|
*10/20/2020
|

*Order necessary parts
|
* In progress
|-
! scope="row"| 3
|
*10/26/2020
|
*11/01/2020
|
*Read and familiarize with LED Matrix Datasheet
|
* Not started

|-
! scope="row"| 4
|
* 11/02/2020
|
* 11/08/2020
|
* Develop graphics driver for LED matrix and implement initial game objects
|
* Not started
|-
! scope="row"| 5
|
*11/09/2020
*11/09/2020
*11/09/2020
*11/09/2020
|
*11/10/2020
*11/15/2020
*11/15/2020
*11/15/2020
|
* Finalize wiki schedule
* Order circuit boards components and complete the design for printing
* circuit board and component assembly
* Circuit board testing
* Additional accessories if required and finalization of hardware
|
* Not started
* Not started
* Not started
* Not started
* Not started
|-
! scope="row"| 6
|
*11/16/2020
|
*11/22/2020
|
*Integration of circuit boards and microcontroller
* Game logic development
* Testing and debugging the game logic
|
* Not started
* Not started
* Not started
|-
! scope="row"| 7
|
* 11/23/2020

|
* 11/29/2020
|
* Integrate game logic code with LED matrix
* Integrate game sounds with game logic
|
* Not started
* Not started
|-
! scope="row"| 8
|
* 11/30/2020
|
* 12/06/2020
|

* Integrate subsystem
* Finalizing the video game
* Update the wiki page.
|
* Not started
* Not started
* Not started
|-
! scope="row"| 9
|
* 12/07/2020
|
* 12/13/2020
|
* Address bugs during testing of integrated system
* Test pause/play functionality
|
* Not started
* Not started
* Not started
|-
! scope="row"| 10
|
*12/16/2020
*12/14/2020
*12/14/2020
*12/14/2020
|
*12/16/2020
*12/16/2020
*12/16/2020
*12/16/2020
|

*Final Demo
*Update Gitlab repo with final code.
*Update test video.
*Update the wiki page.
|
* Not started
* Not started
* Not started
* Not started
|-
|}

<HR>
 

== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components. Do not write long stories here.

== Design & Implementation ==
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

=== Hardware Design ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.

=== Software Design ===
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

=== Implementation ===
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

== Testing & Technical Challenges ==
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

=== <Bug/issue name> ===
Discuss the issue and resolution.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

Realtime OS on Embedded Systems

2021-10-13T03:35:47Z

Preet: /* Fall 2021 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2021 | Fall 2021]] ===

* [[F21: Group Project Name]]
* [[F21: Sons of Ultron]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Realtime OS on Embedded Systems

2021-09-15T02:44:16Z

Preet:

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2021 | Fall 2021]] ===
* [[F21: Group Project Name]]

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Realtime OS on Embedded Systems

2020-12-21T00:52:25Z

Preet: /* Fall 2020 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2020 | Fall 2020]] ===
* [[F20: Jubeat]]
* [[F20: Flappy]]
* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]
* [[F20: Tom & Jerry]]
* [[F20: Hungry Snake]]
* [[F20: Son of a Gun]]
* [[F20: Corona Run]]
* [[F20: Maddening Marbles]]
* [[F20: Bubble Shooter]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

F20: Treasure Diver

2020-10-14T01:10:44Z

Realtime OS on Embedded Systems

2020-10-14T01:10:06Z

Preet:

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2020 | Fall 2020]] ===

* [[F20: Space Invaders]]
* [[F20: Treasure Diver]]

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Smacman]]
* [[F19: Tetris]]
* [[F19: Space Impact]]
* [[F19: Road Max Fury]]
* [[F19: T-Rex Run!]]
* [[F19: Infinity Mirror]]
* [[F19: Tower Defense in Space]]
* [[F19: Alien Wars]]
* [[F19: Pocket tank]]
* [[F19: M&B (Morph & Blend)]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Lab Assignments

2020-03-18T00:10:23Z

Preet: /* DBC File */

Lab Assignments

2020-03-18T00:10:07Z

Preet: /* Git */

Lab Assignments

2020-03-03T23:26:14Z

Preet: /* Wiki Schedule */

Lab Assignments

2020-03-03T17:21:33Z

Preet: /* CAN TX / RX using Auto-gen code */

Lab Assignments

2020-03-03T17:21:15Z

Preet: /* Assignment */

Autonomous RC Car Project Report Template

2020-03-03T17:18:20Z

Preet:

Autonomous RC Car Project Report Template

2020-03-03T17:14:44Z

Preet: /* Improper Unit Testing */

== Project Title ==
<Team Name>

== Abstract ==
<2-3 sentence abstract>

=== Introduction ===

The project was divided into N modules:

* Sensor ...
* Motor..
* ...
* Android

=== Team Members & Responsibilities ===
<Team Picture>

Gitlab Project Link - [https://gitlab.com/...]
 

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

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
| 09/15/2017
| 09/16/2017
|
* Read previous projects, gather information and discuss among the group members.
* Distribute modules to each team member.

| Completed
|-
! scope="row"| 2
| 09/17/2017
| 10/03/2017
|
|
|-
|}

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Cost
|-
! scope="row"| 1
| RC Car
| Traxxas
| 1
| $250.00
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Microchip [http://www.microchip.com/wwwproducts/en/en010405]
| 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>

<HR>
 

== Sensor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable sonor sensors ====
<Problem Summary>
<Problem Resolution>

<HR>
 

== Motor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable Servo Motors ====
<Problem Summary>
<Problem Resolution>

<HR>
 

== Geographical Controller ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable GPS lock ====
<Problem Summary>
<Problem Resolution>

<HR>
 

== Communication Bridge Controller & LCD ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Insane Bug ====
<Problem Summary>
<Problem Resolution>

<HR>
 

== Master Module ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
== Mobile Application ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Wifi Link Reliability ====
<Problem Summary>
<Problem Resolution>

<HR>
 

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

Industrial Application using CAN Bus

2020-03-03T17:12:53Z

Preet: /* Class Project Reports */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimbus]]
* [[S20: Bucephalus]]
* [[S20: Canster Ttruck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

Lab Assignments

2020-02-10T22:53:44Z

Preet: /* Periodic Scheduler */

Lab Assignments

2020-02-10T22:53:12Z

Preet: /* Unit Testing */

Lab Assignments

2020-02-10T22:53:04Z

Preet: /* Form Groups */

Lab Assignments

2020-02-10T22:52:55Z

Preet: /* LED Switch */

Lab Assignments

2020-02-10T22:52:41Z

Preet: /* CAN Communication */

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; left:0.25%; padding:0; margin:0;">
[[#top|Back to the Top]]
</div>

= Hello World =

=== Assignment ===
*Get the development environment from sourceforge.
: '''[https://sourceforge.net/projects/armdevpkg/files/: SourceForge SJSU Development Package]'''

*Compile a sample FreeRTOS sample project

*Load it onto the processor

*Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

= LED Switch =

=== Assignment ===

Work in groups of 2 and use existing API under '''gpio.hpp''':

* Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
* Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
* Connect the LED Board and SW Board together using "Port 2"
*: Example: P2.0 of LED board connects to P2.0 on the SW Board
*: Do not forget common ground
* LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
* On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
*: The callback should simply turn a flag (global variable) to true
*: The callback '''''MUST NOT POLL''''', and '''''MUST NOT DELAY''''', and '''''EXIT IMMEDIATELY''''' since it is an interrupt function
*: Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
* On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
*: Turn on the periodic scheduler at main.cpp
*: Deploy your code to periodic_callbacks.cpp (like 10Hz function)
* Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
*: Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
*: '''[https://www.youtube.com/watch?v=grXuVMttVuU: Binary Semaphores]'''

For the demo:
* The SW Board should detect its switch press by an external interrupt and toggle its P2.0
* The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp
Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

= Form Groups =

=== Assignment ===

Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in '''''zero points''''' for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

= Unit Testing =

Perform the "Lab 1" exercise here:
[https://gitlab.com/sibros_public/public/wikis/c/unit_tests#lab-1]

= Project Setup =

=== Assignment ===

Setup your Project Report Template:

* Go to your class webpage:
*: [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus CmpE 243 Home Page]
* There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
*: Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
*: Rename one of these bullet points to your project name (use a wise name for your project):
*: Tag your project with "F17" or similar, such as:
*: <nowiki>[[F17: Spartan and Furious | F17: Spartan and Furious]]</nowiki>
*: Click to save this page
* In a separate window, [http://socialledge.com/sjsu/index.php/Autonomous_RC_Car_Project_Report_Template browse to this page], click "Edit" and COPY the entire Wikipedia markup
*: Now click on the red link that belongs to your project
*: Paste this template for your project, and work on setting weekly goals in your schedule section.
*: Save the template
* Now go back to your project's Wiki page, click "EDIT"
*: Add information about the team members
*: Add a link to your GITLAB project and add users who can access your project:
*: My GITLAB username is simply, "'''preet'''"

= Wiki Schedule =

=== Assignment ===

Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

= Periodic Scheduler =

=== Assignment ===

INDIVIDUAL HOMEWORK:

Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

*Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
*Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
*Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
*: In the 10Hz callback, design a Software filter to filter the Light sensor readings
*: In the 1Hz callback, print out the filtered sensor reading.
*Do more experiments with the "Logging" capability
*: Log some data using LOG_INFO() or similar message from file_logger.h
*Use "info 5000" command to see CPU utilization for 5 seconds.
*Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

= CAN TX / RX using Auto-gen code =

=== Assignment ===

Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

*Define a DBC message that your controller sends (TX)
*Define a DBC message that your controller receives (RX)
*Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
*Send the TX message from BoardA at a fixed frequency, such as 10Hz
*Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
*Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
*Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

= Final Wiki Schedule =

= DBC File =

=== Assignment ===

Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

= CAN Communication Demo =

=== Assignment ===

Demonstrate that each ECU is able to communicate over the CAN Bus

*Code should utilize the auto-generated artifacts from the DBC file
*MIA handling should occur on the messages that are expected to be received
*: Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

= Producer / Consumer Tasks =

=== Assignment ===

*Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
*Create a queue, and have the first task send orientation values every second to the queue.
*: Print something BEFORE and AFTER sending the enumeration value to the queue.
*Create a task that is waiting on the orientation enumeration to be sent by the previous task.
*: Print something immediately after the second task receives the data from the queue.
*Use same priority for both tasks and note down the print-outs.
*Alter the priority of second task to use higher priority, and note down the print-outs
*: Note down your results, and submit it at the top of your code submission.

= Project Prototypes =

=== Assignment ===

Project prototypes are expected to demonstrate the following:

*Reliable CAN communication between different ECUs
*Basic obstacle avoidance (free-run mode)
*Reliable sensor inputs (PCAN will be used by class mentors to assess)
*Reasonable motor commands (PCAN will be used by class mentors to assess)
*Extra credit if you go above and beyond and show even more progress such as a working Android app

= Git =

=== Assignment ===

Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

= Individual Contribution =

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".

Example:

Name Letter Grade Notes
Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings.
Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

Lab Assignments

2020-02-10T22:52:28Z

Preet: /* Serial Communication */

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; left:0.25%; padding:0; margin:0;">
[[#top|Back to the Top]]
</div>

= Hello World =

=== Assignment ===
*Get the development environment from sourceforge.
: '''[https://sourceforge.net/projects/armdevpkg/files/: SourceForge SJSU Development Package]'''

*Compile a sample FreeRTOS sample project

*Load it onto the processor

*Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

= LED Switch =

=== Assignment ===

Work in groups of 2 and use existing API under '''gpio.hpp''':

* Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
* Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
* Connect the LED Board and SW Board together using "Port 2"
*: Example: P2.0 of LED board connects to P2.0 on the SW Board
*: Do not forget common ground
* LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
* On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
*: The callback should simply turn a flag (global variable) to true
*: The callback '''''MUST NOT POLL''''', and '''''MUST NOT DELAY''''', and '''''EXIT IMMEDIATELY''''' since it is an interrupt function
*: Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
* On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
*: Turn on the periodic scheduler at main.cpp
*: Deploy your code to periodic_callbacks.cpp (like 10Hz function)
* Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
*: Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
*: '''[https://www.youtube.com/watch?v=grXuVMttVuU: Binary Semaphores]'''

For the demo:
* The SW Board should detect its switch press by an external interrupt and toggle its P2.0
* The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp
Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

= Form Groups =

=== Assignment ===

Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in '''''zero points''''' for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

= Unit Testing =

Perform the "Lab 1" exercise here:
[https://gitlab.com/sibros_public/public/wikis/c/unit_tests#lab-1]

= Project Setup =

=== Assignment ===

Setup your Project Report Template:

* Go to your class webpage:
*: [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus CmpE 243 Home Page]
* There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
*: Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
*: Rename one of these bullet points to your project name (use a wise name for your project):
*: Tag your project with "F17" or similar, such as:
*: <nowiki>[[F17: Spartan and Furious | F17: Spartan and Furious]]</nowiki>
*: Click to save this page
* In a separate window, [http://socialledge.com/sjsu/index.php/Autonomous_RC_Car_Project_Report_Template browse to this page], click "Edit" and COPY the entire Wikipedia markup
*: Now click on the red link that belongs to your project
*: Paste this template for your project, and work on setting weekly goals in your schedule section.
*: Save the template
* Now go back to your project's Wiki page, click "EDIT"
*: Add information about the team members
*: Add a link to your GITLAB project and add users who can access your project:
*: My GITLAB username is simply, "'''preet'''"

= CAN Communication =

=== Assignment ===

You can work in groups of 2:

*Build and interface the CAN transceiver with another person's CAN transceiver.
*Initialize the CAN Bus (read can.h in the drivers directory).
*Use a simple periodic message (every 100ms) that is sent from BoardA to BoardB.
*: For example, if BoardA senses a switch pressed, send a 1-byte message with 0xAA, otherwise send 0x00 if button is not pressed
*For robustness, if the CAN Bus turns off, simply turn it back on at 1Hz (every 1000ms)
*On BoardB, simply light up an LED (or otherwise turn it off) based on the CAN message data

This assignment gives you an overview of practical use of the CAN Bus, and later, by utilizing the DBC file and auto-generation of code, sending and receiving data becomes very easy.

While this provides bare bones knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages' data encoding and decoding.

Although the real-time periodic scheduler was not discussed, it might be worth your time to simply turn it on (using #define) since it can help you send periodic messages fairly easily. This will also help you prepare in advance for the future lectures.

Only turn in the relevant source code, such as main.cpp for both boards.

= Wiki Schedule =

=== Assignment ===

Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

= Periodic Scheduler =

=== Assignment ===

INDIVIDUAL HOMEWORK:

Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

*Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
*Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
*Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
*: In the 10Hz callback, design a Software filter to filter the Light sensor readings
*: In the 1Hz callback, print out the filtered sensor reading.
*Do more experiments with the "Logging" capability
*: Log some data using LOG_INFO() or similar message from file_logger.h
*Use "info 5000" command to see CPU utilization for 5 seconds.
*Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

= CAN TX / RX using Auto-gen code =

=== Assignment ===

Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

*Define a DBC message that your controller sends (TX)
*Define a DBC message that your controller receives (RX)
*Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
*Send the TX message from BoardA at a fixed frequency, such as 10Hz
*Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
*Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
*Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

= Final Wiki Schedule =

= DBC File =

=== Assignment ===

Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

= CAN Communication Demo =

=== Assignment ===

Demonstrate that each ECU is able to communicate over the CAN Bus

*Code should utilize the auto-generated artifacts from the DBC file
*MIA handling should occur on the messages that are expected to be received
*: Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

= Producer / Consumer Tasks =

=== Assignment ===

*Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
*Create a queue, and have the first task send orientation values every second to the queue.
*: Print something BEFORE and AFTER sending the enumeration value to the queue.
*Create a task that is waiting on the orientation enumeration to be sent by the previous task.
*: Print something immediately after the second task receives the data from the queue.
*Use same priority for both tasks and note down the print-outs.
*Alter the priority of second task to use higher priority, and note down the print-outs
*: Note down your results, and submit it at the top of your code submission.

= Project Prototypes =

=== Assignment ===

Project prototypes are expected to demonstrate the following:

*Reliable CAN communication between different ECUs
*Basic obstacle avoidance (free-run mode)
*Reliable sensor inputs (PCAN will be used by class mentors to assess)
*Reasonable motor commands (PCAN will be used by class mentors to assess)
*Extra credit if you go above and beyond and show even more progress such as a working Android app

= Git =

=== Assignment ===

Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

= Individual Contribution =

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".

Example:

Name Letter Grade Notes
Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings.
Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

Lab Assignments

2020-02-10T22:52:20Z

Preet: /* Assignment */

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; left:0.25%; padding:0; margin:0;">
[[#top|Back to the Top]]
</div>

= Hello World =

=== Assignment ===
*Get the development environment from sourceforge.
: '''[https://sourceforge.net/projects/armdevpkg/files/: SourceForge SJSU Development Package]'''

*Compile a sample FreeRTOS sample project

*Load it onto the processor

*Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

= LED Switch =

=== Assignment ===

Work in groups of 2 and use existing API under '''gpio.hpp''':

* Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
* Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
* Connect the LED Board and SW Board together using "Port 2"
*: Example: P2.0 of LED board connects to P2.0 on the SW Board
*: Do not forget common ground
* LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
* On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
*: The callback should simply turn a flag (global variable) to true
*: The callback '''''MUST NOT POLL''''', and '''''MUST NOT DELAY''''', and '''''EXIT IMMEDIATELY''''' since it is an interrupt function
*: Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
* On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
*: Turn on the periodic scheduler at main.cpp
*: Deploy your code to periodic_callbacks.cpp (like 10Hz function)
* Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
*: Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
*: '''[https://www.youtube.com/watch?v=grXuVMttVuU: Binary Semaphores]'''

For the demo:
* The SW Board should detect its switch press by an external interrupt and toggle its P2.0
* The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp
Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

= Form Groups =

=== Assignment ===

Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in '''''zero points''''' for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

= Serial Communication =

= Unit Testing =

Perform the "Lab 1" exercise here:
[https://gitlab.com/sibros_public/public/wikis/c/unit_tests#lab-1]

= Project Setup =

=== Assignment ===

Setup your Project Report Template:

* Go to your class webpage:
*: [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus CmpE 243 Home Page]
* There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
*: Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
*: Rename one of these bullet points to your project name (use a wise name for your project):
*: Tag your project with "F17" or similar, such as:
*: <nowiki>[[F17: Spartan and Furious | F17: Spartan and Furious]]</nowiki>
*: Click to save this page
* In a separate window, [http://socialledge.com/sjsu/index.php/Autonomous_RC_Car_Project_Report_Template browse to this page], click "Edit" and COPY the entire Wikipedia markup
*: Now click on the red link that belongs to your project
*: Paste this template for your project, and work on setting weekly goals in your schedule section.
*: Save the template
* Now go back to your project's Wiki page, click "EDIT"
*: Add information about the team members
*: Add a link to your GITLAB project and add users who can access your project:
*: My GITLAB username is simply, "'''preet'''"

= CAN Communication =

=== Assignment ===

You can work in groups of 2:

*Build and interface the CAN transceiver with another person's CAN transceiver.
*Initialize the CAN Bus (read can.h in the drivers directory).
*Use a simple periodic message (every 100ms) that is sent from BoardA to BoardB.
*: For example, if BoardA senses a switch pressed, send a 1-byte message with 0xAA, otherwise send 0x00 if button is not pressed
*For robustness, if the CAN Bus turns off, simply turn it back on at 1Hz (every 1000ms)
*On BoardB, simply light up an LED (or otherwise turn it off) based on the CAN message data

This assignment gives you an overview of practical use of the CAN Bus, and later, by utilizing the DBC file and auto-generation of code, sending and receiving data becomes very easy.

While this provides bare bones knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages' data encoding and decoding.

Although the real-time periodic scheduler was not discussed, it might be worth your time to simply turn it on (using #define) since it can help you send periodic messages fairly easily. This will also help you prepare in advance for the future lectures.

Only turn in the relevant source code, such as main.cpp for both boards.

= Wiki Schedule =

=== Assignment ===

Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

= Periodic Scheduler =

=== Assignment ===

INDIVIDUAL HOMEWORK:

Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

*Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
*Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
*Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
*: In the 10Hz callback, design a Software filter to filter the Light sensor readings
*: In the 1Hz callback, print out the filtered sensor reading.
*Do more experiments with the "Logging" capability
*: Log some data using LOG_INFO() or similar message from file_logger.h
*Use "info 5000" command to see CPU utilization for 5 seconds.
*Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

= CAN TX / RX using Auto-gen code =

=== Assignment ===

Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

*Define a DBC message that your controller sends (TX)
*Define a DBC message that your controller receives (RX)
*Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
*Send the TX message from BoardA at a fixed frequency, such as 10Hz
*Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
*Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
*Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

= Final Wiki Schedule =

= DBC File =

=== Assignment ===

Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

= CAN Communication Demo =

=== Assignment ===

Demonstrate that each ECU is able to communicate over the CAN Bus

*Code should utilize the auto-generated artifacts from the DBC file
*MIA handling should occur on the messages that are expected to be received
*: Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

= Producer / Consumer Tasks =

=== Assignment ===

*Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
*Create a queue, and have the first task send orientation values every second to the queue.
*: Print something BEFORE and AFTER sending the enumeration value to the queue.
*Create a task that is waiting on the orientation enumeration to be sent by the previous task.
*: Print something immediately after the second task receives the data from the queue.
*Use same priority for both tasks and note down the print-outs.
*Alter the priority of second task to use higher priority, and note down the print-outs
*: Note down your results, and submit it at the top of your code submission.

= Project Prototypes =

=== Assignment ===

Project prototypes are expected to demonstrate the following:

*Reliable CAN communication between different ECUs
*Basic obstacle avoidance (free-run mode)
*Reliable sensor inputs (PCAN will be used by class mentors to assess)
*Reasonable motor commands (PCAN will be used by class mentors to assess)
*Extra credit if you go above and beyond and show even more progress such as a working Android app

= Git =

=== Assignment ===

Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

= Individual Contribution =

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".

Example:

Name Letter Grade Notes
Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings.
Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

F19: Tower Defense in Space

2019-12-21T23:33:53Z

Preet: /* Grading Criteria */

[[File:start_menu.jpg|thumb|500px|caption|right|Logo]]

== Abstract==
This project involves creating and developing a video game where output is displayed on a LED matrix. Development of the relevant hardware/software components and modules was divided among 4 team members. Each team member lead or significantly contributed to the development of multiple components. The project was focused on not only technical skills, but team building as well, and working with others towards a common goal.

This project provides us hands-on experience using freeRTOS in a real application. Our objective is to apply what we have learned in class and develop a video game using our SJtwo Board. In this project, we create different tasks for different modules, such as a display task for displaying the game objects on LED matrix, a tower task for detecting nearby enemies and shoot them, a stage task to manage each game stage etc. We need to use both cooperative scheduling and preemptive scheduling technique to make this video game run efficiently. In order to make this game run in a particular sequence, we also need to synchronize and sequentialize each task by setting the task priorities carefully and using binary semaphore correctly. 
 

== Introduction and Objectives ==
[[File:AlienInvasion.jpeg|300px|thumb|right|Alien Invasion]]
Like most traditional tower defense games, the player needs to defend our planet from the invasion of aliens. The gameplay can be split into 2 phases, Combat Phase and Intermission Phase. During the intermission phase, the player can place different kinds of towers strategically that will attack the invading aliens from entering into our homeland by shooting the enemies. During the combat phase, spaceships follow the path and try to land on our planet. If any enemy spaceship reaches the end of the path, then the player loses. If there are no more spaceships remaining in a wave, the player can build a stronger tower that has a longer attack range and can shoot a more powerful laser to the spaceships in the next wave. The player wins the game after surviving 5 waves of attack.

This game can be separated into 4 different modules:
#Game Logic: SJtwo Board - handles the game logic. (For example: detect and shoot nearby enemies, switch between intermission phase and combat phase)
#Display: Adafruit 64x64 LED matrix - displays the animation of the game.
#Gamepad Controller: The input of this game. The gamepad controller consists of a joystick and two buttons. The player can use the joystick to move the cursor and decide where to place the towers. After that, the user needs to press the black button to select and confirm the location of the towers. If the player knows that he/she has made a mistake in the middle of the game and will eventually lose the game, the player can press the red button and restart the game.
#Sound: MP3 Decoder and speaker. Players can enjoy cool music during the game. This is done on an additional SJtwo board, which will play the song on repeat.

== Team Members ==

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#000000;" |
 TEAM MEMBERS & RESPONSIBILITIES 
|-
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Team Members
! scope="col" style="text-align: center" style="background:#C0C0C0;" |
Administrative Roles
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Technical Roles

|-
|- style="vertical-align: top;"
! scope="row" style="text-align: left;" |
* [Ryan Zelek]
| style="text-align: left;" |
'''Team Lead''' 
| style="text-align: left;" |
* Game Design Lead 

|-
|- style="vertical-align: top;"
! scope="row" style="text-align: left;" |
* [https://www.linkedin.com/feed/ Zach Smith]
| style="text-align: left;" |
Git Repo Manager 
| style="text-align: left;" |
* Hardware Design Lead 

|-
|- style="vertical-align: top;"
! scope="row" style="text-align: left;" |
* [Chong Hang Cheong]
| style="text-align: left;" |
Wiki Report Manager 
| style="text-align: left;" |
* LED Matrix API 

|-
|- style="vertical-align: top;"
! scope="row" style=" text-align: left;" |
* [Polin Chen]
| style="text-align: left;" |
Bill of Materials Manager 
| style="text-align: left;" |
* Joy Sticker && Decoder API 

|}
 

== Schedule ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
! colspan="5" style="background:#000000;" |
TEAM MEETING DATES & DELIVERABLES
|-
! scope="col" style="background:#C0C0C0;" |
Week#
! scope="col" style="background:#C0C0C0;" |
Date Assigned
! scope="col" style="background:#C0C0C0;" |
Deliverables
! scope="col" style="background:#C0C0C0;" |
Status

|-
! scope="row"| 1
! scope="row"| 10/15/19
|
* Share team contact information 
* Create Git Repository 
* Set up group Slack channel 
* Invite Preet to Slack 
* Establish Code Guidelines and Standards 
|
* Complete 
* Complete 
* Complete 
* Complete 
* Complete 

|-
! scope="row"| 2
! scope="row"| 10/22/19
|
* Identify major hardware components (BOM) 
* Begin purchasing major items 
* Finalize game architecture 
* Have Git Repo Setup 

|
* Complete 
* Complete 
* Complete 
* Complete 

|-
! scope="row"| 3
! scope="row"| 10/29/19
|
* Solidify individual roles and responsibilities 
* Establish baseline software architecture design and guidelines going forward 
|
* Complete 
* Complete 

|-
! scope="row"| 4
! scope="row"| 11/5/19
|
'''Kelvin'''
* Verify functionality of LED matrix and gather resources for further understanding 
|
 
* Complete 

|-
! scope="row"| 5
! scope="row"| 11/12/19
|
'''Kelvin'''
* Find out feasibility of creating an LED matrix driver in C 
'''Polin'''
* Have APIs ready for joystick and buttons 
'''Ryan'''
* Have basic user interface for the game displayed through serial port 
'''Zach'''
* First controller PCB design complete 
* Specify any remaining hardware components and coordinate purchase 
|
 
* Complete 
 
* Complete 
 
* Complete 
 
* Complete 
* Complete 

|-
! scope="row"| 6
! scope="row"| 11/19/19
|
'''Kelvin'''
* Complete baseline API for LED matrix 
'''Polin'''
* Determine feasibility of MP3 decoding and integration into system
'''Ryan'''
* Complete first pass at basic tower defense level with straight pathway
'''Zach'''
* Controller PCB sent out for fabrication 
* Design break-out PCB for LED matrix + IO expander />
|
 
* Complete 
 
* Complete 
 
* Complete 
 
* Complete 
* Complete 
|-
! scope="row"| 7
! scope="row"| 11/26/19
|
'''Kelvin'''
* LED matrix driver should be reviewed and complete 
'''Polin'''
* Work with '''Zach''' to identify remaining hardware components and, if applicable, MP3 decoder requirements 
'''Ryan'''
* Work with '''Kelvin''' to integrate his API into the game 
* Game should be running with LED matrix display involvement 
* Advanced game logic design/implementation is near feature complete 
'''Zach'''
* PCB assembled and tested. Problems identified and solutions proposed 
|
 
* Complete 
 
* Complete 
 
* Complete 
* Complete 
* Complete 
 
* Complete 

|-
! scope="row"| 8
! scope="row"| 12/3/19
|
* Complete game testing and validation 
* Critical bugs (software AND hardware) identified and a clear path towards closure has been identified 
|
* Complete 
* Complete 

|-
! scope="row"| 9
! scope="row"| 12/10/19
|
* Continuation of previous week activities (bug fixes, etc)
* Implement any potential optimizations and/or expansions
|
* Complete 
* Complete 

|}
 

== Bill of Materials ==
{| class="wikitable"
! colspan="5" style="background:#000000;" |
 Top Level 
|-
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART NAME
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART MODEL & SOURCE
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
QUANTITY
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
COST PER UNIT (USD)
|-
| <s>'''32x64 RGB LED Matrix'''</s>
| <s>[https://www.sparkfun.com/products/14718]</s>
| <s>2</s>
| <s>$49.95</s>
|-
| <s> ''' 64x64 RGB LED Matrix'''</s>
| <s> [https://www.sparkfun.com/products/14824 Sparkfun] </s>
| <s> 1 </s>
| <s> $79.95 </s>
|-
| <s> '''NovaeLED 64x64 RGB LED Matrix (2-Pack)''' </s>
| <s> [https://www.amazon.com/gp/product/B07LFJ73GQ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Amazon] </s>
| <s> 1 </s>
| <s> $80.99 </s>
|-
| '''64x64 RGB LED Matrix'''*
| [https://www.adafruit.com/product/3649 Adafruit]
| 1
| $104.07
|-
| '''5V 4A PSU'''
| -
| 1
| FREE
|-
|}

{| class="wikitable"
! colspan="5" style="background:#000000;" |
 Breakout Board PCB** 
|-
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Item #
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART NAME
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART SOURCE
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
QUANTITY
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
COST PER UNIT (USD)
|-
! scope="row"| 1
| IC REG LINEAR LD1117S33CTR
| [https://www.digikey.com/product-detail/en/stmicroelectronics/LD1117S33CTR/497-1241-1-ND/586241 DIGIKEY]
| 5
| $0.351
|-
! scope="row"| 2
| MHS16N-ND 16POS CONN 2.54MM
| [https://www.digikey.com/product-detail/en/3m/N3408-6302RB/MHS16N-ND/1239801 DIGIKEY]
| 2
| $2.60
|-
! scope="row"| 3
| CAP CER 0.1UF 25V X7R 1206
| [https://www.digikey.com/product-detail/en/avx-corporation/12063C104JAT2A/478-11943-1-ND/8573579 DIGIKEY]
| 5
| $0.221
|-
! scope="row"| 4
| CAP CER 10UF 16V X5R 1206
| [https://www.digikey.com/product-detail/en/taiyo-yuden/EMK316BJ106MD-T/587-4881-1-ND/6563724 DIGIKEY]
| 5
| $0.202
|-
! scope="row"| 5
| RES SMD 470 OHM 1% 1/4W 1206
| [https://www.digikey.com/product-detail/en/te-connectivity-passive-product/CRG1206F470R/A106077CT-ND/3477734 DIGIKEY]
| 10
| $0.0267
|-
! scope="row"| 6
| PTC RESET FUSE 24V 500MA 1206
| [https://www.digikey.com/product-detail/en/bel-fuse-inc/0ZCJ0050AF2E/507-1803-1-ND/4156312 DIGIKEY]
| 10
| $0.1588
|-
! scope="row"| 7
| CONN SOCKET 40POS 0.1 TIN PCB
| [https://www.digikey.com/product-detail/en/samtec-inc/ESQ-120-14-T-D/SAM11108-ND/6693975 DIGIKEY]
| 2
| $5.03
|-
! scope="row"| 8
| Manufacturing x 5 boards *
| [https://jlcpcb.com/ JLCPCB]
| 1
| $29.81
|}

{| class="wikitable"
! colspan="5" style="background:#000000;" |
 Gamepad PCB** 
|-
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Item #
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART NAME
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
PART SOURCE
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
QUANTITY
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
COST PER UNIT (USD)
|-
! scope="row"| 1
| Analog 2-axis Thumb Joystick w/ select button
| [https://www.amazon.com/gp/product/B00NAY2Q6O/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Amazon]
| 1
| $7.67
|-
! scope="row"| 2
| SAM8205-ND 10POS 1.27MM
| [https://www.digikey.com/product-detail/en/samtec-inc/EHF-105-01-L-D/SAM8205-ND/1106564 DIGIKEY]
| 5
| $3.38
|-
! scope="row"| 3
| LED GREEN 1206 SMD
| [https://www.digikey.com/product-detail/en/lite-on-inc/LTST-C150GKT/160-1169-1-ND/269241 DIGIKEY]
| 5
| $0.24
|-
! scope="row"| 4
| LED RED 1206 SMD
| [https://www.digikey.com/product-detail/en/lite-on-inc/LTST-C150CKT/160-1167-1-ND/269239 DIGIKEY]
| 5
| $0.257
|-
! scope="row"| 5
| RES 1K OHM 1% 1/2W 1206 SMD
| [https://www.digikey.com/product-detail/en/stackpole-electronics-inc/RNCP1206FTD1K00/RNCP1206FTD1K00CT-ND/2240675 DIGIKEY]
| 5
| 0.0358
|-
! scope="row"| 6
| CAP CER 0.1UF 50V X7R 1206
| [https://www.digikey.com/product-detail/en/kemet/C1206C104K5RAC7800/399-C1206C104K5RAC7800CT-ND/411524 DIGIKEY]
| 5
| $0.088
|-
! scope="row"| 7
| 12x12x7.3mm Tactile Push Button w/ cap (pack of 25)
| [https://www.amazon.com/gp/product/B01NCQVGLC/ref=ppx_yo_dt_b_asin_title_o00_s01?ie=UTF8&psc=1 Amazon]
| 1
| $7.89
|-
! scope="row"| 8
| Manufacturing x 5 boards *
| [https://jlcpcb.com/ JLCPCB]
| 1
| $14.21
|}

<nowiki>*</nowiki> Shipping and tax included in value shown in the cost per unit column 
<nowiki>**</nowiki> Only parts that were purchased are displayed. 

 

== Game Design ==
=== Game Rules ===
Gameplay is split into 2 phases: 
Intermission - Player sets up tower locations 
Combat - Player watches round unfold 

During the Intermission Phase: 
#The player places towers strategically around the enemy path. 
#The number of towers is fixed per round 
#Towers can only be placed in marked areas that do not lie on a path 
#The built-in software will find a valid tower location and move the cursor there automatically according to joystick input. 
#There are 5 types of towers (increasing damages, ranges, and of different colors). Each tower type depends on the current wave. 

During the Combat Phase: 
#Enemies will enter the gameplay area at one end of the path and attempt to reach the other end 
#Towers will automatically engage enemies when they come within range 
#Towers shoot until the enemy is either dead or out of range 
#Tower proximity is 8 directions (top, bot, left, right, top-right, top-left, bot-left, bot-right) and 1 unit (not necessarily 1 pixel) away 
#Enemies that reach the end of path while being alive will result in losing the game. 
#If any spaceship reaches the end of the path, the player loses and the game ends 
#The round is over when the player loses or a set number of enemies have been defeated. 
 

[[File:combatPhase_0.JPG|300px|thumb|right|Dashboard (Combat Phase)]]

There will be a dashboard on the LED matrix that displays basic UI information: 
Intermission Phase:
#Time until combat phase 
#Current wave number 
#Number of towers left that you can still place 
Combat Phase:
#Current wave number 
#Number of enemies still remaining in the current wave 

=== Game Objectives ===
#There are 5 waves (rounds) total. 
#In each round, enemies in various amounts, groupings, and health levels (armor) pass through the path. 
#If any enemies reach the end of the path, then the user loses. 
#After each round, the user will be able to place more towers which are stronger and can shoot farther. 
#Each round will have waves of enemies that are more difficult to stop. 
#The user needs to carefully place their towers such that it will have a maximum number of opportunities to shoot at the enemies. 
#The trick is that the user will need to preserve early level towers, otherwise they will not have enough room to place the high level towers in the optimal location. 

=== How To Play ===

The gamepad controller consists of a joystick and two buttons.
*Joystick - move the cursor and decide where to place the towers.
*Black button - select and confirm the location of the towers.
*Red button - restart the game (If the player knows that he/she has made a mistake in the middle of the game and will eventually lose the game, the player can press the red button and restart the game.)

During the Intermission Phase: 
# The player places towers strategically around the enemy path by using the joystick to move the cursor and pressing the black button to select the location of the towers.
# The player needs to place all remaining towers under 45 seconds.
During the Combat Phase: 
# Cheer on your towers and watch them defend Earth from the alien invasion!

== Hardware Design - Electrical ==

=== Overview ===

At a high level hardware integration requirements fell into two categories: 

'''1.''' Reduce risk of unreliable cable connections and eliminate possibility of damage to components through unexpected disconnections, power surges, etc. 
'''2.''' Provide a more fluid physical interface for the user to interact with the game via hardware 

To accomplish these goals, two boards were designed: a breakout board and a gamepad controller. The breakout board serves as a connection hub between all system hardware components; power, the RGB matrix, the SJTWO board, etc. while the joystick provides a cleaner package to present the user with the games inputs. The diagram below shows the relationship between the main subsystems: 

[[File:tower_defense_in_space_hw_block_diagram.PNG]]

All board designs were done using [https://www.autodesk.com/products/eagle/overview EAGLE] and manufactured by [https://jlcpcb.com/ JLCPCB]. Both boards were only two layers and used passive components for the most part. 

=== Breakout Board Design ===

The breakout board design requirement was to interface all external hardware components with the embedded system (SJTWO). The hardware connections are: 

'''1.''' The 64x64 RGB Matrix 
'''2.''' Output power to the RGB Matrix 
'''3.''' User game controller (see next section) 
'''4.''' Input power supply (5V) 
'''5.''' The SJTWO embedded system 

{|
|[[File:Breakout_Rev0.2.PNG|1000px|thumb|left|Breakout Board Schematic]]
|}

{|
|[[File:breakout_board_layout_top.PNG|400px|thumb|left|Breakout Board PCB Top Layout]]
|[[File:breakout_board_layout_bottom.PNG|400px|thumb|left|Breakout Board PCB Bottom Layout]]
|}

{|
|[[File:breakout_pcb_top.jpg|400px|thumb|left|Breakout Board PCB Top Layout]]
|[[File:breakout_pcb_bottom.jpg|400px|thumb|left|Breakout Board PCB Bottom Layout]]
|}

{|
|[[File:breakout_pcb_mounted_assembled.jpg|800px|thumb|left|Populated and mounted to the SJTWO board]]
|}

==== Known Breakout PCB Issues ====

{| class="wikitable"
! colspan="5" style="background:#000000;" |
 Known Issues 
|-
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Summary
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Description
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Version
! scope="col" style="text-align: center;" style="background:#C0C0C0;" |
Status
|-
| 5V should not be routed to game controller.
| 3.3V should be routed to the game controller instead of 5V since the ADC pins are not 5V tolerant.
| 0.1
| Resolved Rev 0.2 
|-
| Wrong silkscreen/not enough room near power input.
| Power input silkscreen too small, part too big for 3.3V LED to fit
| 0.1
| Resolved Rev 0.2 
|-
| Linear regulator not needed.
| The schematic for the SJTWO board labels the input voltage pin as VIN RAW, which is different than the label on the
optional input port. They are both the same, so this input feeds directly into the on-board 3.3V regulator. Essentially
we're driving the regulator with the same voltage it outputs which just won't work well.
| 0.1, 0.2
| UNRESOLVED 
|}

=== Gamepad Hardware Design ===

The gamepad board design requirement was to provide a more packaged interface for the user to interact with the game. 

{|
|[[File:gamepad_schematic.PNG|1000px|thumb|left|Gamepad Schematic]]
|}

{|
|[[File:gamepad_layout_top.PNG|600px|thumb|left|Gamepad PCB Top]]
|[[File:gamepad_layout_bottom.PNG|600px|thumb|left|Gamepad PCB Bottom]]
|}

{|
|[[File:gamepad_pcb_assembled.jpg|800px|thumb|left|Gamepad PCB Fully Populated (no enclosure)]]
|}

== Hardware Design (Mechanical) ==

Only a few mechanical components were needed for this project. Namely simple brackets for mounting electrical hardware to the RGB matrix and displaying the matrix itself. All CAD designs were done using [https://www.onshape.com/ Onshape], a free CAD tool that can be used entirely through your web browser.

For displaying the RGB matrix, two brackets were 3D printed to prop it up. Their STL files can be found under our source repository.

{|
|[[File:matrix_bracket_1.PNG|100x|thumb|left|Mounting bracket design used to prop up the RGB matrix]]
|}

== Hardware Integration ==
=== RGB LED MATRIX ===
The LED matrix that we use is 64 pixels by 64 pixels and is controlled through a 12-pin header consisting of the following pins:

*Five Mux pins (A,B,C,D,E) for Row Selection
**In order to select a specific row of the LED matrix, we need to control the output level of each mux pin. Since the LED matrix light up two rows of LEDs at one time, we can only select 1 out of 32 rows.
*Two sets of RGB pins (R1,G1,B1,R2,G2,B2) for Color Selection
**Since we are driving two rows of LED matrix at once, we need 2 sets of RGB pins. One set is used to control the color pixels of the upper half of the display and the other set for the bottom half of the display.
*Output Enable Pin (OE)
**Output Enable (OE) pin is used to turn on or off the LEDs of the current row.
*Latch Pin (LAT)
**Latch pin is used to prevent the data being shifted into the shift registers and tells the shift register when it is time to switch to newly entered data.
*Clock Pin (CLK)
**triggers a shift on the shift registers

All these pins are required to display a specific color on a specific pixel of the LED matrix display.
{|
|[[File:Pin assignment LED Matrix.jpg|500px|thumb|middle|Pin Connections between SJtwo Board and REG LED Matrix]]
|[[File:scan116.gif|200px|thumb|right|LED Matrix - Row Scanning]]
|}

Apparently, it is impossible to driver all 4096 LEDs all at one time and thus, we can only drive two rows of LEDs at a time (one row on the upper half of the display and another row on the lower half of the display). By refreshing the LED matrix two rows at a time in a fast frequency, we can display all the game objects with animation on the LED matrix.

=== Joysticker controller ===
The joystick that we use is the product from Adafruit, the Analog 2-axis Thumb Joystick. This 2-axis Thumb Joystick provides the following pins:

# Two ADC pins
## In order to control the tower location, we need to control the Joysticker, since the direction has four: Up, Down, Left, Right, we use the Y and X-axis to implement this function.
# Three GPIO pins
## In order for selecting for the tool we need two GPIO pin for button and 1 GPIO pin for controlling the LED on the JOY STICKER controller

* Pin configuration
[[File:Selection 999(032).png]]

=== MP3 Decoder ===

The MP3 decoder that we use is Sparkfun’s vs1053 shield MP3 decoder which is the board based on the vs1053b chip.

{|
|[[File:MP3DECODER PON.png|600px|thumb|left|MP3 Decoder Module Pinout]]
|}
{|
|[[File:Selection 999(034).png|600px|thumb|left|MP3 Decoder Pin Table]]
|}
* Three SPI pin
In order to communicate with the mp3 decoder with SJtwo Board, we choose the SPI as the protocol to control the decoder. Hence, we need the one pin SCK0
(clock), one pin MOSI(Master In Slave Out) and one pin (Master Out Slave In).
* Four GPIO pin for the decoder
There are four major GPIO pin for DREQ(Data Request Pin), Reset, CS(Chip Select), XDCS(Data Chip Select), this 4 GPIO pin is how we transfer data and send
the command to activate the mp3 decoder work with SJ2 Board.

== Software Design ==
=== RGB LED Matrix ===
[[File:RGB_data.jpg|400px|thumb|right|RGB Data Element]]

All the LED Matrix data are stored in a buffer with its size equal to 32 by 64. Each element in this buffer store the color of two pixels, one pixel from the upper half of the display and one pixel from the lower half of the display.

In order to display the gaming objects in animation, we need to refresh the display by displaying the color pixels on each row one by one very fast. Below is a simple flowchart that describes the process of refreshing the display.

* Loop through each row of the LED display
# Select Row (By controlling the output level of 5 mux pins, we can select one row at a time)
# Disable the LED Display output (Turn off the LEDs of the current row of the display)
# Unlatch the Data
# Clock in Data for each column(Store the color of each pixel inside display_matrix buffer)
# Latch the Data
# Enable the LED Display output (Display the color of each pixel of the current row)
# Delay for a 100us (Increase the light intensity of the LEDs by delay a short amount of time)
# Disable the LED Display output (Turn off the LEDs of the current row of the display)

<syntaxhighlight lang="c">
void refreshDisplay(void) {
for (uint8_t row = 0; row < LEDMATRIX_HALF_HEIGHT; row++) {

select_row(row);
led_matrix__disable_output(); // gpio__set(OE);
led_matrix__unlatch_data(); // gpio__set(LAT);
led_matrix__clock_in_data(row);
led_matrix__latch_data(); // gpio__reset(LAT);
led_matrix__enable_output(); // gpio__reset(OE);
delay__us(100); // Change Brightness
led_matrix__disable_output();
}
}
</syntaxhighlight>

<syntaxhighlight lang="c">
void led_matrix__clock_in_data(uint8_t row) {
/* Clock in data for each column */
for (uint8_t col = 0; col < LEDMATRIX_WIDTH; col++) {

/* Set all the RGB pins as low*/
LPC_GPIO1->PIN &= ~(0x1 << R1.pin_number | 0x1 << G1.pin_number | 0x1 << B1.pin_number);
LPC_GPIO2->PIN &= ~(0x1 << R2.pin_number | 0x1 << G2.pin_number | 0x1 << B2.pin_number);

/* Set the RGB pins as High or Low depends on the data stored inside the buffer */
LPC_GPIO1->PIN |= ((((display_matrix[row][col] >> 0) & 0x1) << R1.pin_number) |
(((display_matrix[row][col] >> 1) & 0x1) << G1.pin_number) |
(((display_matrix[row][col] >> 2) & 0x1) << B1.pin_number));

LPC_GPIO2->PIN |= ((((display_matrix[row][col] >> 4) & 0x1) << R2.pin_number) |
(((display_matrix[row][col] >> 5) & 0x1) << G2.pin_number) |
(((display_matrix[row][col] >> 6) & 0x1) << B2.pin_number));

gpio__set(CLK);
gpio__reset(CLK);
}
}
</syntaxhighlight>

{|
|[[File:RefreshDisplaySequence.jpg|300px|Process of refreshing display]]
|}
=== MP3 Decoder ===
The MP3 deocder is executed with the mainly two task: read task and play task.
The reader task would read data from the sd card and sned queue data for the player task to play music.

{|
|[[File:MP3DECODERMODULE.png|600px|thumb|left|MP3 Decoder Module API]]
|}
* Read Task
* Loop through each row of the LED display
# Queue sned the target filename
# Queue receive the target name
# Find the mp3 file name is exit or not
# Open the file(fopen)
# Read data store to the buffer(Binary)
# Sent the data from bufder with queuesend API

{|
|[[File: READ TASK.png]]
|}

* Play Task
Receive the data of the song from the queue, and use the receiving data and sent the command to make decoder to play music.

* Read Task
* Loop through each row of the LED display
# Queue receive the data(music)
# disable the chip select
# Check the DREQ pin to know is ready or not
# exchange the data to the decoder to play the music
# Check the DREQ pin to know is ready or not
# disable the chip select
{|
|[[File: Play Task.png]]
|}

=== JOY STICKER ===
The JOY_STICKER is using the task to pool the ADC channel data to get the direction from the Joysticker.

* Loop through each time to poll the enum type data to get direction
# Receiving the data from two ADC channel(5=x, 4=y)
# Comparing which one has higher absolute data
# If (X > Y == YES) ,then we go to the loop to compare It's closer to Right or Left
# If (X > Y == YES && Right > LEFT == YES), then the status is Right
# If (X > Y == YES && Right > LEFT == NO), then the status is Left
# If (X > Y == NO) ,then we go to the loop to compare It's closer to Up or Down
# If (X > Y == NO && Up > Down == YES), then the status is Up
# If (X > Y == NO && Up > Down == NO), then the status is Down

{|
|[[File:Joystickermodule.png|1000x|thumb|left|Game controller]]
|}

{|
|[[File:JOY STICKER ADC FLOW.png|1000x|thumb|left|Game controller flow chart]]
|}

=== System Flow Charts ===
 
 Basic Software Environment: 
[[File:Flow1 TDIS.png]]

 
 Game Master (how the user sees the game flowing): 
[[File:Flow2_TDIS.png]]

 
 Intermission Phase (what happens while the user is placing towers): 
[[File:Flow3_TDIS.png]]

 
 Combat Phase (what happens when the aliens invade): 
[[File:Flow4_TDIS.png]]

== System Testing and Validation ==
{|
|[[File:StartScreenTowerDefense.gif|400px|thumb|left|Start Screen]]
|[[File:CombatPhase.gif|400px|thumb|left|Combat Phase]]
|}

{|
|[[File:EndGame.gif|400px|thumb|left|Player Loses the game]]
|[[File:VictoryScreen TowerDefense.gif|400px|thumb|left|Player Wins the game]]
|}

== Technical Challenges ==

=== Game Map (2D array) to LED matrix (2D pixels) Conversion ===
Issue:
# The game map (consisting of the path as well as all of the active enemies and towers) is managed through the use of a 2D char array.
# In order to display each object on the LED matrix, there needs to be a mechanism that converts the object along with its 2D array location to a row/column on the LED matrix.
# An algorithm to do this conversion is not as straightforward as it may appear. This is because objects stored in the array take up more/less display space than what is available on the LED matrix.
Solution:
# In order to align the array locations with the LED matrix pixel locations, some areas on the 2D array needed to be marked as "ignore". 
# If each array location is not carefully correlated to a specific pixel location, then there would be issues where objects are displayed overlapping each other on the LED matrix (or simply displayed in the wrong spot).
# There were some simple algorithms that used math to help implement this conversion. 
# However, a LUT is what was primarily used. It was not efficient in terms of code size, it took over 500 lines of code. 
# But it was an effective solution and allowed us to easily decide exactly where each pixel of each object would be displayed.

=== LED Matrix Flickering Issue ===
Issue: While we are developing the game, we notice that some color pixels are turned on when they are supposed to be off.

Investigation/Solution:
# See [[Known Breakout PCB Issues]] as a possible cause. It's possible the SJTWO board is getting inconsistent power.
# Refreshing the matrix should not be handled by an interrupt and not a task. The task should only push new display data and not have direct control of the matrix. Keeping the refresh interrupt driven would keep the refresh rate more consistent by removing the process being context switched out mid update.

=== MP3 Decoder - SJtwo Board SPI Selection ===

Issue:
# The mp3 decoder1053b's document is a kind of confusing for the mode when 1032b have several modes
# It's hard to know the configuration is successful or not.
Solution:
# Doing the survey on the GitHub is really important. For example, using the sin wave and hello binary example to test how the Initialization and HZ parameter would save a lot of time.Moreover, in the document from the vs1053b, we could use the binary file line "hello", "sine wave" function for testing.
# Besides, we also have to be careful to check the SJBoard's SPI because of the SD card reader is using for reading SDcard. Hence, I would recommend using other
SPI0, SPI1 instead of using SPI2.

== Conclusion ==
We successfully designed and implemented the video game "Tower Defense In Space". All of our team members now have a better understanding of how to use FreeRTOS to handle the synchronization of multiple tasks and to communicate with multiple hardware components in an embedded application system. After completing this project, we learned how to manage a project on a tight schedule. Starting from purchasing hardware components, developing hardware drivers and game logic and then integrating all of the drivers and APIs into the game logic. Furthermore, all of us are now better at coding and debugging code.
For a game design project like this, we learned that it's not always best to assign tasks independently between the team members. We learned that this type of project would benefit moreso from pair programming and other cooperative tasks that enable collaboration between teammates. Otherwise, project tasks may be done in such a way that they only work for 1 specific configuration, and wouldn't help progress towards the end goal of the integrated system. We also learned that not every day was going to be perfect, but as long as we never gave up and worked hard, then the final result would not be disappointing!

We would like to say thank you to Prof. Preet and all the ISAs for their precious suggestions and assistance during the development of this project!

== Advice for Future Students ==

==== Source Control ====
Unless everyone in your group is comfortable using source control, don't use it. It will likely end up costing you time in the long run.

==== Start working on your LED Matrix driver ASAP ====
The first 64x64 LED Matrix that we got from Sparkfun suffers from a serious flickering issue. After spending for a week trying to debug what causes the flickering issue, we still have no idea whether it is a hardware issue or software issue. Later, we borrow another LED matrix from a student of our class and test our code. With the other student's LED matrix (we use our own power supply and ribbon cables), there is no flickering issue at all. According to some online resources, some matrix vendors scatter the selected rows and columns differently. It is possible that your designed driver may only work on some LED matrix vendors' displays.

== Video Demonstration ==
[https://www.youtube.com/watch?v=b2isxUJta6Q Demo Video (Player Wins)]

[https://www.youtube.com/watch?v=fylwPk5g_3Q Demo Video (Player Loses)]

== Source Code ==
* [https://gitlab.com/rollin_nolan/tower-defense-in-space Tower_Defense_In_Space_Gitlab]
* [https://drive.google.com/file/d/1kggWmH2kcPciE4tFG8gYCbF9gfV2dXkk/view zip file (must have SJSU email address)]

F19: M&B (Morph & Blend)

2019-12-21T21:47:35Z

Preet: /* Grading Criteria */

== '''M&B (Morph & Blend) '''==

<center>
<table>
<tr>
<td>
[[File:giffy.gif|600px|thumb|center|'''Chameleon Run''']]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

Our game is inspired by the game "Chameleon run" in which the runner matches the color with the incoming obstacles as he moves ahead.

== Abstract ==
M&B is a unique and fast game in which the player has to blend and match with the incoming obstacles. The game demands good reflexes to jump and blend in with the approaching obstacles to keep moving forward. The player is required to control his cube-like character that moves to the right, left and forward directions to make long jumps and change color by these obstacles. Instead of the usual jumping over the barriers and pits, the player has to adapt to them by dynamically changing the character’s color before landing on the platform. SJTwo board will be used to implement the game logic, control the RGB matrix and the joysticks/switches. The
RGB matrix will be used to display the real-time game statistics such as the player name and their score. The game ends if the player lands on an obstacle of a different color.

== Objectives & Introduction ==
=== Objective ===
The objective of this project is to develop a simple, single-player 2D game using LPC 4078 microcontroller on an LED matrix display. It focuses on integrating the micro-controller peripheral drivers, led drivers, mp3 player, button controller interface and the application software in FreeRTOS.The button controller interface consists of the button controls for changing color, to control the player's movement and to reset the game. The mp3 player is used to play the game background music.

There are four components in this project:

*'''The Display''' : A 32X64 LED Display Matrix acts as the display of the game.

*'''The Controller''' : The SJ Two Board computes the random obstacle generation and handles the movement and color blend of the player from the button control interface and transfers the information to the display using the GPIO pins.

*'''The Button Control Interface''' : The push button inputs for auto-runner color and position are implemented on a PCB for game control,.The inputs given by the user are given to the SJ Two board to control the player.

=== Introduction ===

The Project consists of three main modules:

'''Button control module:''' It consists of 7 buttons for the player control; 4 for the different colours to switch, 2 for the directions and 1 for the game reset.

'''Display Module:''' It is responsible for controlling 32*64 LED Matrix interfaced to SJ Two Board.

'''Mp3 application''' This establishes communication to the display module using SPI.

==== About the game ====
* Player should match the color of the approaching obstacles to score points by "morphing and blending".
* Obstacles of random colors are generated randomly.
* Button control interface enables the user to shift the player up and down and control the color of the player to move and blend with the incoming obstacles to score points.
* The game can be reset at any time using the reset button.

=== Team Members & Responsibilities ===
* '''Ryan Will'''
** PCB design
** MP3 implementation

* '''Shreeya Mahadevaswamy'''
** LED Matrix driver
** Game Logic- Autorunner
** Game control configuration
** Scoreboard
** Testing

* '''Shanmathi Saravanan'''
** LED Matrix driver
** Game Logic- Obstacle
** Game control configuration
** Testing
** Scoreboard

== '''Schedule''' ==

{| class="wikitable"
|-
! scope="col"| Week
! scope="col"| Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
|-

! scope="row"| 1
| 10/10/2019
|
* Submission of Project Proposal
|
* Completed
|
* 10/10/2019
|-

! scope="row"| 2
| 10/15/2019
|
* Research for Required Components.
* Submit Schedule and Components List.
|
* Completed

|
* 10/20/2019

|-
! scope="row"| 3
| 10/22/2019
|
* Ordering components
* Familiarize with LED Matrix Datasheet
* understanding control pin configuration for the LED matrix display and displaying a single character
|
* Completed

|
* 11/5/2019

|-
! scope="row"| 4
| 10/5/2019
|
* Develop LED driver and a dedicated function to update display continuously
* Verifying the functioning of the update display function by creating a task that displays characters sequentially.

|
* Completed
|
* 11/15/2019
|-
! scope="row"| 5
| 11/16/2019
|
* MP3 basic code skeleton development
|
* Completed
|
* 12/18/2019

|-
! scope="row"| 6
| 11/16/2019
|
* Autorunner configuration
* Developing code for generating obstacles at particular rows statically
* Implementing obstacle shift function for shifting the obstacles towards the player
|
* Completed
|
* 11/19/2019

|-
! scope="row"| 7
| 11/19/2019
|
* Randomizing the obstacle generation code: for generating the obstacles at random rows with random colors
* Developing code for obstacle and player color mismatch and match
|
* Completed
|
*11/26/2019
|-

! scope="row"| 8
| 11/26/2019
|
* Implementing start screen and scoreboard screen configurations
* Synchronizing the obstacle generation and auto-runner generation using dedicated tasks
* Implementing button control for controlling the player position
* Implementing code for moving the auto runner position with button input
|
* Completed
|
*12/3/2019
|-

! scope="row"| 9
| 12/3/2019
|
* Implementing code for incrementing the score with each color match of player and obstacle
* Implementing button control for controlling the player color
* Implementing code for changing the auto runner color with button input

|
* Completed
|
* 12/10/2019
|-

! scope="row"| 10
| 12/10/2019
|
* Synchronizing tasks from game start to game end and scoreboard display
* Final bug fixes and troubleshooting.
|
* Completed
|
* 12/17/2019
|-

! scope="row"| 11
| 12/17/2019
|
* Complete wiki report and final demo.
|
* Completed
|
* 12/18/2019
|-

|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST (USD) 
|-
|
* '''SJTwo Boards'''
|
Purchased from Preet Kang
|
1
|
50.00

|-
|
* '''LED Matrix 32x64'''
|
Sparkfun [https://www.sparkfun.com/products/14718]
|
1
|
64.99

|-
|
* '''Switches'''
|
Amazon [https://www.amazon.com/Cylewet-Self-Locking-Latching-Button-CYT1091/dp/B075VBV4QH/ref=pd_sbs_147_1/137-7334021-3032831?_encoding=UTF8&pd_rd_i=B075VBV4QH&pd_rd_r=0ae03c79-1976-4fa3-97c5-44f6019e0e8a&pd_rd_w=kbKR6&pd_rd_wg=fu74k&pf_rd_p=52b7592c-2dc9-4ac6-84d4-4bda6360045e&pf_rd_r=VHJX4T9DNSEW6W47RJ4Q&psc=1&refRID=VHJX4T9DNSEW6W47RJ4Q]
|
7
|
7.00

|-
|
* '''DC Barrel Jack Adapter - Female'''
|
https://www.amazon.com/Chanzon-Female-Connector-Security-Adapter/dp/B079RCNNCK/ref=sr_1_4?keywords=DC+Barrel+Jack+Adapter+-+Female&qid=1574052181&sr=8-4
|
1
|
5.75

|-
|
* '''Power supply'''
|
Sparkfun [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
1
|
12.95

|}

 

== Design & Implementation ==
The game design mainly consists of the LED drivers, PCB designs, button control interface for user control, mp3 implementation to play the background music for the game.

=== Hardware Design ===
The hardware design of the 32x64 RGB LED matrix panel which is the most important part of the project, uses four data lines namely A,B,C and D which can be addressed and used to control each LED which has following technical specifications:

Parameters:
*2048 RGB LEDs
*1/16 Scan Rate
*IDC Connector for Daisy Chaining
*5V Supply Voltage

The figure and table below show the pin-out of the RGB LED matrix with description.

{| class="wikitable"
|-
! scope="col"| Label
! scope="col"| Name
! scope="col"| Function
|-
! scope="row"| 1
| R1
| High R data
|-
! scope="row"| 2
| G1
| High G data
|-
! scope="row"| 3
| B1
| High B data
|-
! scope="row"| 4
| R2
| Low R data
|-
! scope="row"| 5
| G2
| Low G data
|-
! scope="row"| 6
| B2
| Low B data
|-
! scope="row"| 7
| A
| A line selection
|-
! scope="row"| 8
| B
| B line selection
|-
! scope="row"| 9
| C
| C line selection
|-
! scope="row"| 10
| D
| D line selection
|-

! scope="row"| 11
| CLK
| CLOCK
|-
! scope="row"| 12
| LAT
| LATCH
|-
! scope="row"| 13
| OE
| Output Enable
|-
! scope="row"| 14
| GND
| GND
|}

===='''LED Matrix Control'''====
The LED panel contains 1024 RGB LEDs arranged in a matrix of 32 rows and 64 columns. Each RGB LED contains separate red, green, and blue LED chips assembled together in a single package. The display is subdivided horizontally into two parts, the top half and bottom half consists of 64 columns and 16 rows respectively.

There are different drivers for controlling display’s columns and another set of drivers for controlling rows. To illuminate an LED, the drivers for both the column and the row for that LED must be turned on. To change the color of an LED, the red, green, and blue chips in each LED package are controlled individually and have their own column drivers.

<center>
<table>
<tr>
<td>
[[File:Block4.png|600px|thumb|right|LED Matrix]]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

The panel contains six sets of column drivers; three for the top half of the display and three for the bottom. Each driver has 32 outputs. The three drivers for the top of the display drive the red, green, and blue chips in each of the 64 columns of LEDs in rows 0 to 15 of the panel. The three drivers for the bottom of the display drive the red, green, and blue chips in each of the 64 columns of LEDs in rows 16 to 31 of the panel. The red, green, and blue column drivers for the top half of the display are attached respectively to the R0, G0, and B0 data inputs. The red, green, and blue column drivers for the bottom half of the display are attached respectively to the R1, G1, and B1 data inputs. All six of the 32-bit drivers share common SCLK, LATCH, and BLANK signals.

The display is multiplexed and has a 1/16th duty cycle. This means that no more than one row out of the 16 in the top half of the display and one row out of the 16 in the bottom half of the display are ever illuminated at once. Furthermore, an LED can only be on or off. If both the row and column for an LED are turned on, the LED will be illuminated; otherwise, the LED will be off.
To display an image, the entire LED panel must be scanned fast enough so that it appears to display a continuous image without flickering. To display different colors and different brightness levels, the brightness of the red, green, and blue LED chips within each LED package must be adjusted by varying the amount of time that each LED chip is on or off within a single refresh cycle.

LED MATRIX DRIVER:

The code below is used to update all pixels of the LED display periodically using a high priority task.

for (uint8_t row = 0; row < 32; row++) {
for (uint8_t col = 0; col < 64; col++) {
if (ledmatrix_buffer[row][col] & 0x1) {
gpio__set(b1);
} else {
gpio__reset(b1);
}
if (ledmatrix_buffer[row][col] & 0x2) {
gpio__set(g1);
} else {
gpio__reset(g1);
}
if (ledmatrix_buffer[row][col] & 0x4) {
gpio__set(r1);
} else {
gpio__reset(r1);
}
if (ledmatrix_buffer[row][col] & 0x8) {
gpio__set(b2);
} else {
gpio__reset(b2);
}
if (ledmatrix_buffer[row][col] & 0x10) {
gpio__set(g2);
} else {
gpio__reset(g2);
}
if (ledmatrix_buffer[row][col] & 0x20) {
gpio__set(r2);
} else {
gpio__reset(r2);
}
gpio__set(clk);
gpio__reset(clk);
}
gpio__set(oe);
gpio__set(lat);
delay__us(250);
gpio__reset(a);
gpio__reset(b);
gpio__reset(c);
gpio__reset(d);
if (row & 0x1) {
gpio__set(a);
}
if (row & 0x2) {
gpio__set(b);
}
if (row & 0x4) {
gpio__set(c);
}
if (row & 0x8) {
gpio__set(d);
}
gpio__reset(lat);
gpio__reset(oe);
}

=== Hardware Interface ===
For the hardware, we designed a PCB board that would be used as a hub to connect the LPC4078, the LED Matrix, and the controls together. The images below show the PCB Board and the PCB schematic that were designed. The PCB features 26 pin connections that can be used to connect the pins of the LPC4078 to the LED Matrix, an MP3 decoder, a controller, or any other components. The PCB board was designed using the EAGLE PCB Design Software.

=== PCB Board Design ===
This is a screenshot of the PCB Board that was designed through EAGLE. All of the parts used for the design were plated through holes. This allowed for simple header pins to be soldered directly to the PCB rather than using surface mounted parts. This PCB was used for the button controller implementation.

<center>
<table>
<tr>
<td>
[[File:M&B_PCB_Board.jpg|600px|thumb|right|PCB Board]]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

=== PCB Schematic Design ===
This is a screenshot of the PCB Board Schematic that was designed through EAGLE and used to build design the PCB Board. The schematic features a large number of header pins that can be used to connect the LPC4078 to a variety of components, including an LED matrix, a button controller, and an MP3 Decoder. Several pins were also added to supply both a VCC and a GND to all of the components used in the design.

<center>
<table>
<tr>
<td>
[[File:M&B_PCB_Board_Schematic.jpg|600px|thumb|right|PCB Schematic]]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

=== Software Design ===

The entire software for the game including the APIs were written from scratch. A thorough understanding of the LED Display Matrix proved beneficial in writing suitable code for the display.

<center>
<table>
<tr>
<td>
[[File:SW diagram.jpg|400px|thumb|left|Flow Control of the game]]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

'''Logic'''

A '''led_matrixbuffer''' array maps onto the LED Display Matrix. A value overwritten in this two-dimensional buffer updates the corresponding Pixel value of the LED Matrix. The drawPixel function maps onto the led_matrixbuffer and updates the corresponding value.

The tasks run in parallel and are scheduled with the help of the task scheduler that updates the display regularly.

The main code logic blocks which are the random obstacle generation, obstacle motion enabling and obstacle color mismatch detection blocks are as follows:
OBSTACLE GENERATION:

bool generate_obstacle_rand(void) {
bool ret;
uint8_t randomize_color = (rand() % 4) + 1; // generating random colour
rand_row = (rand() % 17) + 9; // generating a random row for obstacle generation
while (!(((row_old - rand_row) >= obstacle_gap) || ((rand_row - row_old) >= obstacle_gap))) { // loop is used to generate a new row number in comparison with the last generated row number
rand_row = (rand() % 17) + 9;
}
while (colour_old == randomize_color || ((colour_old == yellow1) && (randomize_color == cyan1))) {
randomize_color = (rand() % 3) + 1;
}
if (randomize_color == cyan1) {
randomize_color = yellow1;
}
int8_t row = rand_row;
for (int8_t col = 63; col > 52; col--) {
drawPixel(row, col, randomize_color);
drawPixel(row + 1, col, randomize_color);
ret = 0;
}
row_old = rand_row;
colour_old = randomize_color;
ret = 1;
return (ret);
}

OBSTACLE MOTION LOGIC:

void shift_obstacle_left(void) {
int8_t temp;
for (int8_t row1 = 9; row1 < 28; row1++) {
for (int8_t col1 = 0; col1 < 63; col1++) {
ledmatrix_buffer[row1][col1] = ledmatrix_buffer[row1][col1 + 1]; // move all element to the left except first
}
ledmatrix_buffer[row1][63] = 0;
}
}

OBSTACLE BLEND COLOR MISMATCH DETECTION:

bool detect_collision(void) {
bool detect = 0;
if (((ledmatrix_buffer[autorunner_row][4] != ledmatrix_buffer[autorunner_row][5]) &&
(ledmatrix_buffer[autorunner_row][5] != 0)) ||
((ledmatrix_buffer[autorunner_row + 1][5] != ledmatrix_buffer[autorunner_row + 1][6]) &&
(ledmatrix_buffer[autorunner_row + 1][6] != 0)) ||
((ledmatrix_buffer[autorunner_row + 2][4] != ledmatrix_buffer[autorunner_row + 2][5]) &&
(ledmatrix_buffer[autorunner_row + 2][5] != 0)) ||
((ledmatrix_buffer[autorunner_row + 3][5] != ledmatrix_buffer[autorunner_row + 3][6]) &&
(ledmatrix_buffer[autorunner_row + 3][6] != 0))) {
detect = 1;
} else {
detect = 0;
}
return (detect);
}

MP3 Player Tasks:

void MP3_Play_Task(void *pvParameters)
{
BYTE decoder_buffer[512];
mp3_decoder_init();

while(1)
{
if(xQueueReceive(MP3Queue, decoder_buffer, 1000))
{
//printf("track playing");
play_mp3_track(decoder_buffer);
}
}
}

void Read_MP3_Task(void *pvParameters)
{
while(1)
{
readMP3File();
vTaskDelay(1000);
}
}

MP3 Decoder Driver:

void mp3_decoder_init()
{
ssp__init(24);
gpio_x__set_as_output(1, 28); //Set pin 1.28 as output for RESET signal
gpio_x__set_as_output(1, 20); //Set pin 1.20 as output for DCS signal
gpio_x__set_as_output(1, 31); //Set pin 1.31 as output for CS signal

//gpio_x__set(0, 25, true); //Set pin 0.25 high initially
//gpio_x__set(0, 26, true); //Set pin 0.26 high initially
//gpio_x__set(1, 30, true); //Set pin 1.30 high initially
gpio_x__set_high(1, 28);
gpio_x__set_high(1, 20);
gpio_x__set_high(1, 31);

gpio_x__set_as_input(0, 26); //Set pin 0.26 as input for DREQ

write_to_decoder(SCI_MODE, 0x0800); //Set up MODE register
//write_to_decoder(); //Set up Bass/Treble register
write_to_decoder(SCI_CLOCKF, 0x2000); //Set up Clock register
write_to_decoder(SCI_AUDATA, 0xAC45); //Set up AudioData register `
write_to_decoder(SCI_VOL, 0x2424); //Set up Volume register

uint16_t data1 = read_from_decoder(SCI_MODE);
uint16_t data2 = read_from_decoder(SCI_CLOCKF);
uint16_t data3 = read_from_decoder(SCI_AUDATA);
uint16_t data4 = read_from_decoder(SCI_VOL);
printf("SCI_MODE = %x\n", data1);
printf("SCI_CLOCKF = %x\n", data2);
printf("SCI_AUDATA = %x\n", data3);
printf("SCI_VOL = %x\n", data4);

//u0_dbg_printf("mode data = %x\n", data);

}

void play_mp3_track(uint8_t buffer[])
{
for(uint8_t byteIndex = 0; byteIndex < 16; byteIndex++)
{
while(!(gpio_x__get_level(0, 26)))
{
//vTaskDelay(1);
}

gpio_x__set(1, 20, false);
//gpio_x__set_low(0, 26);
//gpio_x__set_low(1, 30);

for(uint16_t i = 32 * byteIndex; i < (32 * byteIndex) + 32; i++)
{
ssp__exchange_byte(buffer[i]);
}

while(!(gpio_x__get_level(0, 26)))
{
//vTaskDelay(1);
}

gpio_x__set(1, 20, true);
//gpio_x__set_high(0, 26);
//gpio_x__set_high(1, 30);
}
}

=== Implementation ===

We split the code into different logic blocks for better clarity in the game design. We started to develop the LED drivers for the matrix display which took the maximum time in the project. After a lot of hit and trial, we understood how to control each pixel in the matrix. We then started on the game logic implementation where we took a lot of time to finalize on a particular idea. Implementation of the game start screen to display the name was the first step, later followed by the obstacle generation and the runner configuration. Obstacle collision and detection for every colour was time-consuming. Task synchronization helped us understand FreeRTOS and the scheduling concepts better.
The hardware module includes 32X64 LED matrix display, SJTwo board, two PCB boards- one for the LED display control port connection to the SJTwo board GPIO pins and a port for powering the board and the other for button control.

To play music from the MP3 decoder, the MP3 file needs to be pulled from an SD card and into a buffer, and the data needs to be fed to the MP3 Decoder through the SPI Bus.

HARDWARE IMPLEMENTATION:

The hardware connection between the SJTwo Board and the RGB LED matrix display control pins is as illustrated in the following block diagram:

<center>
<table>
<tr>
<td>
[[File:hw_connect.PNG|thumb|400px|center|Figure : Hardware connection]]
</td>
<td>
</td>
<td>
</td>
</tr>
</table>
</center>

The pins R1, G1, and B1 were used to control the color that lights up in the upper 16 rows of the display matrix and R2, B2 and G2were used to control the lower 16 rows. Pins A, B, C, and D are used for row selection. Based on different combinations of R, G and B pin values different colors can be generated.

== Testing & Technical Challenges ==
'''Developing a driver for the LED matrix''' 

The biggest technical challenge that we faced was interfacing with the micro-controller 32 x 64 LED matrix.

Because we used the LPC 4078 to drive the LED matrix, our choices were to either adapt a third party driver library designed for an Arduino, or develop a new driver. We chose the latter option, as the third party Arduino-focused API's were difficult to fully understand. We also felt that developing our own driver would allow us to gain a strong understanding of all aspects of micro-controller to LED matrix integration. This proved useful both for firmware development and debugging.

The first part of developing the LED matrix driver, was learning how each of the 16 input pins affected the matrix display.

The LED matrix's input socket looked as follows:

[[File:Adafruit_32x32_LED_Matrix_socket.png | 300x350px]]

'''A B C D''' 
Pins '''A''', '''B''', '''C''' and '''D''', were used as control bits for the LED matrix's row multiplexer. The 32 x 64 matrix is made up of two individual 16 x 64 LED panels. Each panel contains 16 rows and 32 columns. The binary values of the multiplexer signals, '''A''', '''B''', '''C''' and '''D''', are used to determine which row of LED's is being driven. Each panel drives the same row of LED's at a time, based on these values. For example, if '''A''', '''B''', '''C''' and '''D''' are set to 0000, then the LED's in the first row of each panel can be driven. If '''A''', '''B''', '''C''' and '''D''' are set to 0001, then the LED's in the second row of each panel can be driven. This pattern continues until '''A''', '''B''', '''C''' and '''D''' are set to 1111, which corresponds to sixteenth (bottom) row of each panel. We set our row iterating value, as '''i = (i + 1) % 16''', so that '''A''', '''B''', '''C''' and '''D''', would be set to 0000, after finishing latching data into the sixteenth row. This allowed the multiplexer to continuously loop through each row in each panel, from top to bottom. We applied a delay of 1ms after each row iteration to enable the appropriate scan rate. This scan rate was too fast for the human eye to detect, which allowed the LED matrix to display objects steadily, without annoying flickering compromising the image quality.

'''R1 B1 G1 R2 G2 B2''' 
Pins '''R1''', '''B1''', '''G1''' and '''R2''', '''B2''', '''G2''', were the 6 control signals used to drive the matrix's RGB LEDs, different combinations of red, blue and green (depending on their binary values). '''R1''', '''B1''' and '''G1''', controlled indiidual LED colors on the top panel (panel 1), while '''R2''', '''B2''' and '''G2''', controlled individual LED colors on the bottom panel (panel 2). The way these color combinations manifested on the board, were as follows:

{| class="wikitable" style="text-align: center; width: 100px; height: 100px;"
|-
| '''R''' || '''B''' || '''G''' || '''COLOR'''
|-
| 0 || 0 || 0 || '''OFF'''
|-
| 0 || 0 || 1 || '''GREEN'''
|-
| 0 || 1 || 0 || '''BLUE'''
|-
| 0 || 1 || 1 || '''CYAN'''
|-
| 1 || 0 || 0 || '''RED'''
|-
| 1 || 0 || 1 || '''YELLOW'''
|-
| 1 || 1 || 0 || '''PURPLE'''
|-
| 1 || 1 || 1 || '''WHITE'''
|}

In order to understand how these signals drive individual LEDs on the matrix, one must understand the hardware that they control. The matrix's RGB LEDs are driven by 6 column drivers, each having 32 outputs. Each panel has 3 column drivers. Each column driver can drive 32 LED's in each panel, either red, green or blue (because each of the 3 column drivers controls one of these 3 colors). As a result, the 6 column drivers can drive up to 192 individual red, green and blue LED's (each RGB LED consists of 3 individual red, green and blue LED's) at a time.

'''CLK LAT OE''' 
Each column driver is composed of serial data input, a blanking input, a shift register, and a parallel output register. Data bits are passed into the shift register on the rising edge of each clock cycle. The clock is controlled using the signal '''CLK'''. Because there are 32 RGB LEDs per row, 32 clock cycles must occur, in order to drive all LED's in a row. After 32 bits of data are passed into the shift register, the '''LATCH''' signal (which is set low before shifting in data bits to the shift register) must be asserted, in order to transfer the data bits from the shift register to the parallel output register. Output enable ('''OE''') is pulled low at this point, in order to enable the column driver. It is pulled high again when transitioning to a new row. We designed our driver to operate on 32 bit, bit strings (of type uint32_t), in order to utilize all 32 LEDs in each row of the matrix. Each 32-bit string, was stored in a 32 element array of type, uint32_t. We assigned the base memory address of the array to a pointer and used integer offset values to pass the different bit strings, stored in the array, into the matrix driver function. This method allowed us to pass 32 unique bit strings into all 32 rows of the LED matrix. The integer offsets corresponded to row numbers.

For each row, we used a for loop (which iterated from 0 to 31) in order to shift all 192 data bits into the shift registers. We latched the data bits into the parallel output register, after shifting was completed, which allowed us to illuminate different individual LED's in each row. This allowed us to use 32 bit, bit strings, to create data structures and graphics. The column driver also allowed us to give the illusion of motion, by turning the different LED's on and off in adjacent rows.

'''COLOUR MISMATCH DETECTION''' 
Since the player is cleared and redrawn continuously to keep his position in line with the user control input, the color mismatch detection between the player and the obstacle pixels was challenging initially. This issue was fixed by clearing and redrawing the player inside the high priority update display task instead of having a dedicated task for drawing and clearing the player pixels. This ensured that the autorunner pixel values are static when the medium priority mismatch detection task is checking the obstacle pixels with the autorunner pixels.

'''BUTTON INPUT''' 
The button input for the auto runner movement made the autorunner to shift position by multiple rows instead of one, since the GPIO input was high for several milliseconds and several executions with respect to the task updating the auto runner position. This bug was fixed by including an appropriate Task delay of 0.1 second for the task so that it doesn't latch high more than once for each button press. The time delay was decided based on a trial and error method resulting in the selection of a time delay that was suitable for avoiding consecutive updates as high in the GPIO for movement as well as was able to detect fast consecutive button inputs.

 '''MP3 Decoder''' 

There were problems with implementing the MP3 Decoder. When trying to decode the MP3 files, the speaker would not output any sound. The most likely cause of this problem was that there was an issue with the SPI bus, which was preventing the MP3 Decoder from getting the correct MP3 data.

'''TESTING''':

The testing screenshots for the initial screen, game screen and the final scoreboard are included below:

<center>
<table>
<tr>
<td>
[[File:image0.jpeg|500px|thumb|left|Start Screen]]
</td>
<td>
</td>
<td>
[[File:image1_2.jpeg|500px|thumb|right|Game screen]]
</td>
</tr>
</table>
</center>

<center>
<table>
<tr>
<td>
[[File:image2.jpeg|480px|thumb|center|End Screen]]
</td>
</tr>
</table>
</center>

The initial screen displays for 4 seconds before going to the game screen and the final scoreboard screen displays for 4 seconds.

== Conclusion ==
This project was a fun and strenuous application of our engineering and project management skills.

After completing the driver labs during CMPE 244, we felt confident that we could develop a driver, for the Adafruit LED matrix, without using any third party libraries. We researched the hardware operations of the LED matrix and how to drive the RGB LED's. Once we could control LED's one at a time, the project evolved from an engineering problem into more of a creative exercise.

We faced some issues in implementing the player movement along with the updated color input. To move the player back and forth with the input of a button press and to store the data of the colour stored at each location was a challenge as we were clearing and redrawing the player at every location.

Overall I think the biggest lessons that we learned is project management based. We spent a lot of time choosing between various game designs and it forced us to start our final iteration later than we would have liked. However, we banded together and worked hard during the final few days of the semester to create this game.

If we had to do this project over again, we would plan to manage our time better and probably work on increasing the complexity of the game. We would also improve our PCB and MP3 player. We went with a simple design for this project, as none of us had much prior experience with PCB design or LED matrix. However, now that we understand EAGLE better, developing a better interfacing circuit would be much easier and less time intensive.

Overall this project allowed us to apply both or engineering fundamentals, as well as our creative design skills.

== References Used ==

*https://bikerglen.com/projects/lighting/led-panel-1up/
*[http://www.socialledge.com/sjsu/index.php?title=Realtime_OS_on_Embedded_Systems FreeRTOS documentations]
*[https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/overview 32x32 LED Matrix by Adafruit]
*[https://github.com/adafruit/Adafruit-GFX-Library Adafruit Github Library]
*[https://github.com/adafruit/Adafruit-GFX-Library Adafruit Github Library]
*[http://socialledge.com/sjsu/index.php/Main_Page WikiPage by Preetpal Kang]
*[https://www.sparkfun.com/products/12660 Sparkfun MP3 Decoder]

=== Acknowledgement ===
We wish to thank Preet and the ISA team for hosting this class. This was a fun project and a great learning experience for our group. We hope to be able to take CMPE 243 in the future.

== '''Appendix''' ==

== Project Video ==
https://youtu.be/N-4_O4Ycj6k

== Project Source Code ==
* [https://github.com/ShanmathiS/CMPE244-MorphAndBlend GitHub Link]
* [[File:M&B_MP3_Decoder_Source_code.zip]]

F19: Smacman

2019-12-21T20:45:05Z

Preet: /* Grading Criteria */

== SMACMAN ==
[[File:smacman_inro.gif|600px|thumb|center|'''Smacman''']]

== Abstract ==
Our team has created a unique 2 player game involving a central screen of 64x64 LED matrix and two auxiliary controllers. The two opponents will face one another and will have a paddle on their side. A ball will travel between players which they have to deflect away. Additionally, each player will have a “monster” that will continuously move towards the ball and try to eat the ball. If a monster eats the ball, that opponent of the owner of the monster will lose. Therefore, it is beneficial for a player to try to place the ball closer to their monster and further away from the opponent’s monster in order to score. Additionally, if the ball contacts the side of the screen behind the player’s paddle, they will also lose. As the game progresses, the speed of the ball will increase and eventually, there will be variation in the movement of monster. The controllers(xBee--XB24-AWI) will be wireless and communicate with the master board which runs the game and drives the 64x64 LED matrix.The MP3 module(VS 1053) reads music files from an SD card and plays the music through a speaker interfaced with the board in the background.

== Objectives ==
The main objective of the project is to develop a 2D two player Smacman game. Other milestones to achieve are as below:
*Change the direction and speed of the monster differently at different levels, depending on the direction of the ball on LED Matrix in real time.
*The controller which does wireless transfer of accelerometer values is used to control the movement of the ball
*Play music in the background and game sounds using MP3 Decoder.
*Design PCB for Master and the Controller which will interface all the peripheral devices to the SJ-two boards.

== Introduction ==

The project is broadly divided into three nodes:

1. '''Master Node''': The master node (one SJ2 board) receives the data from the controller nodes via XBee module which is used to control the paddle movement which will eventually control the game. It repeatedly sends and receives packets with the controllers to obtain accelerometer/button information and update the score states of the controllers so that they can display the scores to the players. The Master also uses the information from the Controllers to update the paddle movements as per user's input. The master node also controls visual display on the LED Matrix and the game logic.

2. '''Controller Node''': The controller node (two SJ2 boards) consist of the XBee modules which transmits control packets to the master node using fault-tolerant broadcast wireless UART protocol. These process and send information from the onboard I2C accelerometer and pushbuttons to the Master as well as display the players' scores via an I2C 7-segment display.

3. '''Music Node''': The music node (one SJ2 board) provides background music to the game which enhances the experience of the game.

==== About the game ====
* Both Players should try to hit the ball with the paddle placed on their side.
* Press switch on the controller SJ-Two board to start the game.
* Tilt the controller left or right to move the paddle.
* Hit the ball with your paddle before the monster eats it to get a score.
* To manipulate the speed and the direction of the ball move the paddle in the same or in the opposite direction of the ball.
* Avoid the monster of opposite player to eat the ball in your side, if this happens then the game is over, else the ball continues to move between the paddles.
* The speed of the monster increases when the ball will move in opposite direction to catch the ball.
* Level 1 has the monster of opposite player moving at your side along the edges. If any player exceeds a score of 33 then me move to Level 2.
* Level 2 has the monster of opposite player moving along x-axis at your side. If any player exceeds a score of 66 then me move to Level 3.
* Level 3 has the monster of opposite player moving along x-axis and y-axis at your side. If any player reaches a score of 100 then that player wins the game.
* Both the Players can play and pause the game anytime and resume from where the game was paused.

=== Team Members & Responsibilities ===
* Nick Schiffer
** XBEE, Controller Functionality, Communication Architecture, Game Logic Development, Enclosures, PCB Designing.
* Mohit Ingale
** LED Driver, Game Logic Development, Enclosures, PCB Designing.
* Ayesha Siddiqua
** Graphic Driver, Game Logic Development.
* Shreya Patankar
** Splash Screen Graphics Driver, Game Logic Development, MP3 Decoder, Wikimedia Update.

== '''Delivery Schedule''' ==
Project Repository Link: [https://github.com/nickschiffer/Smacman/projects/1 Github Project]
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-

! scope="row"| 1
| 10/1/2019
|
* Submission of Project Proposal.
|
* Complete
|
* 10/1/2019
|-

! scope="row"| 2
| 10/15/2019
|

* Create GitLab Repository.
* Go through the projects and research about components.
* Distributing the roles among team members.
* Research Required Components.
* Submit Schedule and Components List.
|
* Complete

|
* 10/14/2019

|-
! scope="row"| 3
| 10/22/2019
|
* Familiarize with 64x64 LED Matrix Datasheet.
* Familiarize with xbee & accelerometer datasheet.
* Familiarize with Mp3 Decoder VS-1053 datasheet.
|
* Complete

|
* 11/8/2019

|-
! scope="row"| 4
| 10/29/2019
|
* Make Gitlab Repository for individual tasks for all modules
* Introduce Naming Convention
* Develop Graphics Drivers and Implementation of displaying basic monster on LED Matrix
* Calibrating Accelerometer values for 2 Players
|
* Complete
|
* 11/8/2019
|-
! scope="row"| 5
| 11/5/2019
|
* Develop code to send Accelerometer values to move the paddle for both the players
* Basic LED Display testing for boundary conditions.
* Develop game specific APIs to draw objects like monster, paddle, ball of led driver
* Project report update on the wiki.
|
* Complete
|
* 11/12/2019

|-
! scope="row"| 6
| 11/12/2019
|
* Develop Algorithm Design for Game Logic for all 3 levels of game
* Transmission of Accelerometer values for 2 players from their respective controllers to the master
* Code for the splash screen(Intro screen)
|
* Complete
|
* 11/19/2019

|-
! scope="row"| 7
| 11/19/2019
|
* Code for MP3 Decoder for the background music
* 7 segment display for players score from controller
* Code to display the score on matrix
* Code Integration for the moving of paddle on basis of accelerometer values from controllers for both the players
|
* Complete
|
*11/26/2019
|-

! scope="row"| 8
| 11/26/2019
|
* Develop Play/Pause/Stop functionality
* Debug and Test the Play/Pause/Stop functionality
|
* Complete
|
* 11/30/2019
|-

! scope="row"| 9
| 12/3/2019
|
* Design PCB for Controller & master and generate Gerber files, finalize PCB manufacture
* Integrating calibrated accelerometer, push-button functionalities and wireless transfer from controller boards
|
* Complete
|
* 12/10/2019
|-

! scope="row"| 10
| 12/10/2019
|
* Integration of subsystems
* 3-D Printing of enclosures for matrix and the player's controller
* Fixing the bugs during testing
|
* Complete
|
* 12/15/2019
|-

! scope="row"| 11
| 12/17/2019
|
* Final bug fixes and troubleshooting.
* Complete wiki report and final demo.
|
* In-Progress
|
* 12/17/2019
|-

|}

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Cost
|-
! scope="row"| 1
| SJTwo Boards
| Purchased from Preet
| 4
| $200.00
|-
! scope="row"| 2
| 64x64 RGB LED Matrix
| [https://www.sparkfun.com/products/14824 Sparkfun]
| 1
| $75.00
|-
! scope="row"| 3
| Wiring Components and Cable
| [https://www.amazon.com/XBee-USB-Adapter-Communication-Connectivity/dp/B017KGBP6Y Waveshare]
| 1
| $20.00
|-
! scope="row"| 4
| 3D printer filament spool(s)
| [https://www.hatchbox3d.com/ HATCHBOX]
| 2
| $40.00
|-
! scope="row"| 5
| XBEE Modules
| From Preet and [https://www.adafruit.com/product/128 Adafruit]
| 3
| $27.00
|-
! scope="row"| 6
| Batteries
| Local
| 2
| $4.00
|-
! scope="row"| 7
| I2C 7-seg screens
| [https://www.adafruit.com/product/879 Adafruit]
| 2
| $18.00
|-
! scope="row"| 8
| XBee Programmer Boards
| [https://www.amazon.com/XBee-USB-Adapter-Communication-Connectivity/dp/B017KGBP6Y Waveshare]
| 3
| $35.00
|}

== Design & Implementation ==

=== Hardware and PCB Design ===

=== PIN Configuration ===

{| class="wikitable"
|-
! scope="col"| PIN#
! scope="col"| Pin Desciption
! scope="col"| uC PIN
|-
! scope="row"| R1
| PIN for Red terminal of RGB LED for upper half of LED Matrix
| P2_0
|-
! scope="row"| G1
| PIN for Green terminal of RGB LED for upper half of LED Matrix
| P2_1
|-
! scope="row"| B1
| PIN for Blue terminal of RGB LED for upper half of LED Matrix
| P2_2
|-
! scope="row"| R2
| PIN for Red terminal of RGB LED for lower half of LED Matrix
| P2_4
|-
! scope="row"| G2
| PIN for Green terminal of RGB LED for lower half of LED Matrix
| P2_5
|-
! scope="row"| B2
| PIN for Blue terminal of RGB LED for lower half of LED Matrix
| P2_6
|-
! scope="row"| A
| Mux pin for row selection
| P2_7
|-
! scope="row"| B
| Mux pin for row selection
| P2_8
|-
! scope="row"| C
| Mux pin for row selection
| P2_9
|-
! scope="row"| D
| Mux pin for row selection
| P0_16
|-
! scope="row"| E
| Mux pin for row selection
| P0_15
|-
! scope="row"| OE
| Output Enable
| P1_20
|-
! scope="row"| LATCH
| Latching Data
| P1_23
|-
! scope="row"| CLK
| CLock signal to understand one bit has been detected
| P1_28
|-

! scope="row"| VCC
| VCC Supply
| VCC
|-
! scope="row"| GND
| Ground
| GND
|-
! scope="row"| TX_3
| UART Transmit for XBEE
| P4_28
|-
! scope="row"| RX_3
| UART Receive for XBEE
| P4_29
|-
! scope="row"| SCK_2
| CLOCK for SPI bus for MP3 Decoder
| P1_0
|-
! scope="row"| MOSI_2
| MOSI for SPI bus for MP3 Decoder
| P1_1
|-
! scope="row"| MISO_2
| MISO for SPI bus for MP3 Decoder
| P1_4
|-
! scope="row"| SDA_2
| I2C Data line for 7 Segment
| P0_10
|-
! scope="row"| SCL_2
| I2C Clock line for 7 Segment
| P0_11
|-
! scope="row"| Switch
| Switch GPIO
| P0_1
|-
|}

=== PCB Design ===

There are many softwares available for PCB design, among them Eagle is more popular. We chose EasyEDA for PCB design over Eagle because, it is an online free software so we din't have to worry about the license. We faced many issues while using this software but we found a good tutorial on youtube. The issues which we faced are discussed in the issue section of this wiki.
The steps involved in the PCB design process are described in the next section.
 

==== Schematic Design: ====

Our project can be divided into two main circuits, first is game display circuit and second is a console circuit. We decided to design separate PCB for both circuits as doing so can make wiring easy and improve the user experience.

===== Master Controller PCB schematic: =====
[[File:scematic_m_master.jpeg|700px|thumb|center|'''Master Controller PCB Schematic''']]
 

We have created on top PCB to mount on SJTwo board. One circuit will do the wire interfacing of SJTwo board to xbee, mp3 decoder, led matrix. This is the master board and it will recieve values from all the controllers and peripherals. This is our Main Circuit. We Also have a power jack to power all the peripheral devices so that we don't have to power SJTwo board from PC while we are playing the game.

===== Controller PCB schematic: =====
[[File:scematic_c_pin.png|700px|thumb|center|'''Controller PCB Schematic''']]
 

We have created on top PCB to mount on SJTwo board. One circuit will do the wire interfacing of SJTwo board to xbee of the two game controllers which will in turn send the values of accelerometer to the master Xbee interfaced PCB. We Also have a power jack to power all the peripheral devices so that we don't have to power SJTwo board from PC while we are playing the game.

==== PCB Layout: ====

After schematic design, the most important step is to connect the PCB layout. In EasyEDA components is not automatically associated with it's PCB footprint, so it's user's responsibility to connect right PCB footprint with the right components. In our case, we did not have the footprint of JLC connector and Rocker switch. so, we created it in a different window and saved it. The amazing feature of KiCAD is once we have done with PCB layout we can visualize PCB in 3D by pressing just one button. Below are actual screenshots of both, PCB layout & their 3D model.

===== PCB layout Designed on EasyEDA: =====
<center>
<table>
<tr>
<td>
[[File:schematic_black_m.jpeg|300px|thumb|center|'''PCB Schematic Master 3D view''']]
</td>
<td>
[[File:PCB_Controller-PCB_20191213210227.png|300px|thumb|center|'''PCB Schematic Controller 3D view''']]
</td>
<td>
</tr>
</table>
</center>

===== Printed PCB : =====

We chose JLC PCB to manufacture our PCB because, it is the cheapest and convenient option available for any prototype PCB manufacturing. It just cost us $2 for quantity of 10 PCB and $12 for shipment. We received manufactured PCB in just 3 days. Followings are actual photos of manufactured & assembled PCBs.

<center>
<table>
<tr>
<td>
[[File:copper_print_m.jpeg|250px|thumb|center|'''PCB with Copper layer for Master''']]
</td>
<td>
[[File:copper_print_c.jpeg|264px|thumb|center|'''PCB with Copper layer for Controller''']]
</td>
<td>
</tr>
</table>
</center>

=== Hardware Interface ===

<center>
<table>
<tr>
<td>
[[File:Cmpe244 F19 T1 main controller.png|570px|thumb|center|'''Main Controller Design Diagram''']]
</td>
<td>
[[File:Cmpe244 F19 T1 controllers.png|570px|thumb|center|'''Controller Design Diagram''']]
</td>
<td>
</tr>
</table>
</center>

Hardware design diagram above gives an overview of the entire system which consists of the two SJ-One controllers: one board is used as Control Module and other board is used as the Display Module.

*The Console Module uses the onboard accelerometer on SJ-One which is interfaced via I2C protocol. The calibrated accelerometer values are then used to determine the basket position on the LED Matrix.

*The Display Module SJ-One board is used to control a 32*32 RGB LED Matrix.This matrix displays the basket, eggs shot from the cannon.The movement of the basket is as per the orientation value received from the Control Module, through Wireless Module. It also consists of Peizo buzzer which is controlled via PWM pin.

=== Hardware Components Design, Description Implementation ===

==== RGB LED Matrix ====
<center>
<table>
<tr>
<td>
[[File:Intro_splash_screen.jpeg|600px|thumb|left|Intro Splash Screen]]
</td>
<td>
[[File:2048_ledmatrix_2.jpg|600px|thumb|left|LED Matrix Schematic]]
</td>
</tr>
</table>
</center>

A 64x64 RGB LED Matrix Panel is used as a display. It has 4096 full-color RGB LEDs. Each LED can be independently addressed and controlled. It requires at 13 digital GPIOs to control the LED matrix. The led matrix has 2 IDC connectors DATA_IN and DATA_OUT on the back, we can cascade multiple panels and make a huge screen together. The LED display is constructed using a decoder to decode address rows. A 64 bit Shift register should be clocked for enabling the color. When the row is low we need to select which all pixels in the column are to be configured with the required color. This is done by clocking the 64Bit shift register. There are 6 64Bit registers each for R1 R2 B1 B2 G1 G2. A single clock is interfaced to all these 6 64bit shift registers. So at once we shift and fill the required color for the column display. Once the clocking and shifting the register is completed we need to latch this data to the register. The register data is sent out to all the row lines and that Row line which is pulled low by the decoder will receive this data and corresponding pixels are turned on.

RGB LED matrix pins:
{| class="wikitable"
|-
! align="center"|S.NO
! align="center"|RGB LED pins
! align="center"|Function
|-
| scope="row" align="center"|1
| scope="row" align="center"|R1
| scope="row" align="center"|High R data
|-
| scope="row" align="center"|2
| scope="row" align="center"|G1
| scope="row" align="center"|High G data
|-
| scope="row" align="center"|3
| scope="row" align="center"|B1
| scope="row" align="center"|High B data
|-
| scope="row" align="center"|4
| scope="row" align="center"|R2
| scope="row" align="center"|Low R data
|-
| scope="row" align="center"|5
| scope="row" align="center"|G2
| scope="row" align="center"|Low G data
|-
| scope="row" align="center"|6
| scope="row" align="center"|B2
| scope="row" align="center"|Low B data
|-
| scope="row" align="center"|7
| scope="row" align="center"|A
| scope="row" align="center"|Row select A
|-
| scope="row" align="center"|8
| scope="row" align="center"|B
| scope="row" align="center"|Row select B
|-
| scope="row" align="center"|9
| scope="row" align="center"|C
| scope="row" align="center"|Row select C
|-
| scope="row" align="center"|10
| scope="row" align="center"|D
| scope="row" align="center"|Row select D
|-
|-
| scope="row" align="center"|11
| scope="row" align="center"|E
| scope="row" align="center"|Row select E
|-

| scope="row" align="center"|12
| scope="row" align="center"|CLK
| scope="row" align="center"|Clock signal.
|-
| scope="row" align="center"|13
| scope="row" align="center"|OE
| scope="row" align="center"|Output enables to cascade LED panel.
|-
| scope="row" align="center"|14
| scope="row" align="center"|LAT
| scope="row" align="center"|Latch denotes the end of data.
|-
| scope="row" align="center"|15
| scope="row" align="center"|VCC
| scope="row" align="center"|5V
|-
| scope="row" align="center"|16
| scope="row" align="center"|GND
| scope="row" align="center"|GND
|-
|}

===== Row Selection =====

The RGB matrix has a 5:32 decoder. This decoder takes 5 bits as input and decodes the corresponding row to be kept low. There are five address inputs to the display marked A, B, C, D and E. Based on the truth table, only one input is active (low) at a time. The outputs of the decoder are connected to a P-Channel MOSFET because the decoder itself can only handle low currents and cannot drive a row of LEDs directly. The P-Channel MOSFET provides the high current needed to drive a row of LEDs.
The decoder outputs are shared between every 32 outputs. Since, the 5-to-32 address decoder select rows in parallel like 1 and 33, 2 and 34, repeating that pattern until row 32 and 64.

===== Column Selection =====

The column data is stored in a 64-bit serial-in, a parallel-out shift register. The shift register is designed to work with LEDs and implements a constant-current system that ensures the LED brightness remains uniform. R1 G1 B1 is used for configuring the color for the top half of the display and R2 G2 B2 for the bottom half of the display. For 64 rows using with 32 outputs of the decoder, we must have unique data for each row pair. When Row 1 and Row 33 are selected, we must provide each row with unique data. This forces us to use two different shift registers for each row pair, an upper register, and a lower register. Because of this, the display is divided into an upper half and a lower half. The data is shifted into the top half via the R1, G1 and B1 signals on the connector. The bottom halves data is supplied by the R2, G2 and B2 signals on the connector. Then, since our display is 64 pixels wide, we use 64-bit shift registers to hold all 64 bits of pixel data for a single row. Each half of the display is controlled by 3 shift registers, one for each color. First, Row 1 and Row 33 are selected then 64 bits of data are shifted into each color’s shift register (R1, G1, B1), and then latched. At the same time, 64 bits of data are also shifted into each color’s shift register for the bottom half (R2, G2, B2), and then latched. The process repeats 31 more times, each time incrementing the rows are selected until every line has been updated.

In order to display something on the LED panels the following steps need to be performed by the driver
* Shift the pixel data for row 1 into the top column drivers and the pixel data for row 33 into the bottom column drivers using the R1, G1, B1, R2, G2, and B2 data inputs and the SCLK shift clock signal.
* Clear the blanking signal to blank the display.
* Set the address input to 1.
* Latch the contents of the column driver's shift registers to the output registers using the LATCH signal.
* Make the blanking signal high to display rows 1 and 33.
* Repeat the process for each of the pairs of rows in the display for 31 times.

===== Specifications: =====
The LED display used in our project is a 64*64 pixel panel with a pixel pitch of 3mm. More specifications are tabulated.
* Operating voltage: DC 5V
* Average power consumption: <500W/㎡
* Maxim Power Consumption: <1000w/㎡
* Pixel: 64x64=4096
* Level of viewing Angle: ≧160°
* Control mode: Synchronous control
* Drive mode: 1/16 scan rate
* Repetition frequency: ≧60Hz
* White Balance Brightness: ≧1200cd/㎡
* Refresh frequency : ≧300Hz
* MTTF: ≧5000 hours
* Service Life: 75000~100000 hours
* Pixel pitch: 3mm
* Thickness: 11mm

===== Code Snippet for updation of LED matrix: =====

void led_matrix__update_display() {
for (int i = 0; i < 32; i++) {
led_matrix__disable_display();
led_matrix__disable_latch();
led_matrix__select_row(i); // will select i and i + 32 rows at same time
for (int j = 63; j >= 0; j--) { // shift data with MSB getting shifted-in first
((frame_buffer[i][RED_PLANE] >> j) & 1) ? gpio__set(r1) : gpio__reset(r1);
((frame_buffer[i][GREEN_PLANE] >> j) & 1) ? gpio__set(g1) : gpio__reset(g1);
((frame_buffer[i][BLUE_PLANE] >> j) & 1) ? gpio__set(b1) : gpio__reset(b1);
((frame_buffer[i + 32][RED_PLANE] >> j) & 1) ? gpio__set(r2) : gpio__reset(r2);
((frame_buffer[i + 32][GREEN_PLANE] >> j) & 1) ? gpio__set(g2) : gpio__reset(g2);
((frame_buffer[i + 32][BLUE_PLANE] >> j) & 1) ? gpio__set(b2) : gpio__reset(b2);
gpio__set(clk);
gpio__reset(clk); // shift in all 3 color bits at once for top half/bottom half registers
led_matrix__enable_latch();
led_matrix__disable_latch();
}
// at this point, all 3 shift registers should be filled with corresponding row data in frame_buffer
led_matrix__enable_latch(); // push shift register contents down to output registers
led_matrix__enable_display();
delay__us(250);
}
led_matrix__disable_display();
}

==== MP3 Decoder ====

We have used the SPI bus to communicate between the MP3 Decoder and the SJ-Two Board. We faced issues while writing to the SD Card they are mentioned in the technical issues section. We are reading data of .wav file from SD Card from our board and sending it to the decoder which will in turn play the background music.

[[File:MP3_decoder.jpeg|400px|thumb|center|MP3 Decoder]]

{|The MP3 Decoder is used to play the background music in the game. It is interfaced with the SJ Two board using the SPI protocol. has an Accelerometer which is interfaced to the board using the I2C bus protocol.

The Pins used for the interfacing are:

*XDCS: Chip select for SDI pin
*XCS: chip select for SCI pin
*SCK: clock from master for SCI
*SI: Slave input and master output
*SO: Slave output and master input
*RESET: reset for the decoder
*DREQ: data request

When we recieve any data from the SJ-Two board then we send data which is read from the SD card on the decoder from the slave decoder. Thus we are able to read the file and play the music in the background.

*
''' Code snippet for reading music '''

<syntaxhighlight lang="c">

void sdcard_handle__read_song_task(void *songQueueHandle) {
xQueueHandle *xSongQueue = (xQueueHandle *)songQueueHandle;
uint8_t data_buffer[VS1053_DATABUFFERLEN];
uint32_t bytes_read = VS1053_DATABUFFERLEN;
FIL mySong;
while (1) {
FRESULT ret_code = f_open(&mySong, "pacman_death.mp3", FA_READ);
if (ret_code != FR_OK) {
SMACMAN__DEBUG_PRINTF("File Not Opened %i\n", ret_code);
fprintf(stderr, "File Not Opened %i\n", ret_code);
if (ret_code == 3) {
vTaskDelay(1000);
}
} else {
bytes_read = VS1053_DATABUFFERLEN;
SMACMAN__DEBUG_PRINTF("File opened\n");

while (!mp3__ready_for_data())
;
while (!(bytes_read < VS1053_DATABUFFERLEN)) {

FRESULT f_read_ret_code = f_read(&mySong, data_buffer, VS1053_DATABUFFERLEN, &bytes_read);
if (f_read_ret_code != FR_OK) {
SMACMAN__DEBUG_PRINTF("File not Read %i\n", f_read_ret_code);
}
// for (int i = 0; i < bytes_read; i++)
// xQueueSend(*xSongQueue, &data_buffer[i], portMAX_DELAY);
xQueueSend(*xSongQueue, data_buffer, portMAX_DELAY);
SMACMAN__DEBUG_PRINTF("Data Sent to queue\n");
}
SMACMAN__DEBUG_PRINTF("Closing File\n");

f_close(&mySong);
}
}
// return true;
}
</syntaxhighlight>

==== Controller Module ====

'''Accelerometer:'''

[[File:CmpE244_S18_Detectable_Accelerations.png|400px|thumb|center|Accelerometer Detection]]

{|The SJ two board has an Accelerometer which is interfaced to the board using the I2C bus protocol.
The MMA8452Q which is a smart low-power, three-axis, capacitive micromachined accelerometer with 12 bits of resolution is used in our project.
Accelerometers are electromechanical devices that are used to sense acceleration that can be of various forms, for instance gravity.
|In our project,we have calibrated the accelerometer based on the values of X,Y and Z co-ordinates corresponding to different orientations of the accelerometer to control the horizontal movement of the paddle in the game to hit the ball . This has also helped us decide and control the speed of the basket. As shown in the code snippet below the x movement on the right is determined based on the x co-ordinate and the console sensitivity which you wish to set.Similarly movement on the left can also be calculated for further use.
|}

''' Code snippet for Accelerometer Calibration: '''

<syntaxhighlight lang="c">
static void controller_comm__master_request_accel(controller_comm_s controller, controller_comm__role_e player_to_request) {
controller_comm__message_s request_message = {0};
request_message.recipient = player_to_request;
request_message.sender = CONTROLLER_COMM__ROLE_MASTER;
request_message.message_type = CONTROLLER_COMM__MESSAGE_TYPE_REQUEST_ACCEL_VAL;
if (player_to_request == CONTROLLER_COMM__ROLE_PLAYER_1) {
request_message.data = controller_comm__player_1_score;
}
else if (player_to_request == CONTROLLER_COMM__ROLE_PLAYER_2) {
request_message.data = controller_comm__player_2_score;
}
controller_comm__send_message(controller, request_message);
return;
}

</syntaxhighlight>

''' Wireless Module: '''
[[File:xbee_module.jpg|350px|thumb|center|'''XBee S1''']]

{|
For wireless communication we utilized the XBee S1 module. This module provides a "transparent" UART interface to the Master and Controller boards. The XBee S1 is designed by Digi Inc. and allows for relatively easy programming via the XTCU programming suite using a XBee USB programmer. This device internally uses 802.15.4 to wirelessly send UART frames between modules. Because UART is generally used as a point-to-point protocol, a custom protocol needed to be designed to allow broadcast and multi-node functionality. This can be observed in the controller_comm.h/c files in the repository.

This protocol borrows concepts from UDP and TCP protocols. A transaction begins with a defined start byte(0xDE). This allows for better synchronization between frames comprised of multiple bytes. After a device has received a Start byte, it then receives and processes a header byte. This byte is a structured bit field that encodes the Sender, Recipient, and Message Type as shown below.
<syntaxhighlight lang="c">
typedef enum {
CONTROLLER_COMM__MESSAGE_COMPONENT_START_BYTE,
CONTROLLER_COMM__MESSAGE_COMPONENT_RECIPIENT,
CONTROLLER_COMM__MESSAGE_COMPONENT_SENDER,
CONTROLLER_COMM__MESSAGE_COMPONENT_TYPE,
CONTROLLER_COMM__MESSAGE_COMPONENT_DATA_BYTE1,
CONTROLLER_COMM__MESSAGE_COMPONENT_DATA_BYTE2,
CONTROLLER_COMM__MESSAGE_COMPONENT_STOP_BYTE,
} controller_comm__message_components_e;

typedef struct {
controller_comm__role_e recipient;
controller_comm__role_e sender;
controller_comm__message_type_e message_type;
uint16_t data;
} controller_comm__message_s;

typedef union {
char byte;
struct {
char : 2;
char message_type: 2;
char sender: 2;
char recipient: 2;
} __attribute__((packed));
} controller_comm__message_header_t;
</syntaxhighlight>

When the Master requests the accelerometer positions from the controllers, it piggybacks the current scores in the same request message. This way the controllers' internal score states are always updated. If the controllers detect that the score has changed relatively to what it is aware of, it will write both the player 1 and player 2 scores to the I2C 7-seg display.
The Sender and Recipient fields allow all the controller being addressed to reply accordingly to whichever node addressed it. Additionally, the Message Type encodes what kind of message is being sent as shown below. The "button pressed" event is encoded in its own message type. This lets the Master know if the button for a specific controller has been pressed since the last time the Master communicated with it.

<syntaxhighlight lang="c">
typedef enum {
CONTROLLER_COMM__MESSAGE_TYPE_REQUEST_ACCEL_VAL,
CONTROLLER_COMM__MESSAGE_TYPE_SEND_ACCEL_VAL,
CONTROLLER_COMM__MESSAGE_TYPE_SEND_ACCEL_VAL_BTN_PRESSED,
} controller_comm__message_type_e;
</syntaxhighlight>

The goal of the controller_comm module was to provide a very abstract, easy-to-use interface that could easily be integrated into the game logic without having to understand in technicalities of the driver. As a result, the following simple APIs are exposed to the implementer.
<syntaxhighlight lang="c">
controller_comm_s controller_comm__init(controller_comm__role_e role, uart_e uart, gpio_s gpio_tx, gpio_s gpio_rx);
uint16_t controller_comm__get_player_1_accel();
uint16_t controller_comm__get_player_2_accel();
bool controller_com__get_player_1_button();
bool controller_com__get_player_2_button();
controller_comm__controller_tilt_e controller_comm__get_player_1_tilt();
controller_comm__controller_tilt_e controller_comm__get_player_2_tilt();
bool controller_comm__update_player_score(controller_comm__role_e player, uint16_t score);
void controller_comm__freertos_task(void *controller_comm_struct);
</syntaxhighlight>

Depending on the Message Type, the Data Bytes of the frame represent different information. As described above, in the CONTROLLER_COMM__MESSAGE_TYPE_REQUEST_ACCEL_VAL message type, the data bytes represent the scores for both controller. In the CONTROLLER_COMM__MESSAGE_TYPE_SEND_ACCEL_VAL and CONTROLLER_COMM__MESSAGE_TYPE_SEND_ACCEL_VAL_BTN_PRESSED message types, the data bytes represent the 12 bit accelerometer values. When being sent, the driver decomposes the uint16_t accelerometer value and recombines in upon receipt. After the data bytes are received, a Stop Byte (0xAD)is sent. This further helps with synchronization and if any of the bytes timeout or the Stop Byte is not valid, the transaction is aborted and will be retriggered. The Master polls the controllers every 25ms and as a result, there is little to no latency between controller movement, score updates, and visual screen feedback.

==== Tasks and Flow Control ====

[[File:Cmpe244 f19 state machine.png|400px|thumb|center|'''State Machine''']]

''' Software Design in Display module:'''

'''Master Task:'''
* It controls the flow of the game.
* INIT_STATE is the first state which creates all the tasks used in the game and then suspends them all till the controllers are connected.
* Once the controllers are connected then we move to state IN_PROGRESS_STATE.
* IN_PROGRESS_STATE takes care to resume the corresponding level tasks.
* The score update is checked here to automatically shift from one level to another.
* When a button provided on the controller is pressed then we move to the IN_PAUSE_STATE.
* IN_PAUSE_STATE the score is updated on the led matrix until the button on the controllers is pressed again.
* When the button on the controllers is pressed by both players to show that they are ready we move to the IN_PROGRESS_STATE again.

'''Paddle Task:'''
* Individual paddle assigned to each player.
* Testing of the paddle movement was done initially using the switches.
* Controller accelerometer values supplied to the master using UART protocol were later used to control the movement of the paddle.

'''Ball Task:'''
* Ball task is designed to take into account the velocity, direction and movement of the ball in the upper and lower half of the matrix.
* It takes care of the cumulative score update and of restarting frame after each score update.
* The logic of varying the velocity and angle of the ball upon the collision with the paddle is implemented.
* If the paddle moves in the direction of the ball then the velocity of the ball is increased and decreased for the opposite case.

'''Pacman Task:'''
* Individual pacman task written for each level.
* Pacman in first level moves along the edges and moves randomly. Whenever the ball comes in contact with the pacman then the score of the corresponding player will be updated.
* Pacman in second level moves in the center along x-axis of the side assigned to the opponent and takes into account the direction and speed of the ball. Whenever the ball comes in contact with the pacman then the score of the corresponding player will be updated.
* Pacman in third level moves in the the side assigned to the opponent in both x-axis and y-axis. It takes into account the direction and speed of the ball. Whenever the ball comes in contact with the pacman then the score of the corresponding player will be updated.

'''Controller Task:'''
* If the "role" parameter of the controller is Master, the task polls each controller for their accelerometer values while also updating their internal score states and receiving button states. It also verifies that the responses are legitimate before updating the internal states.
* If the "role" of the controller is Player 1 or Player 2, the task waits for requests from the Master node. Upon receiving this information, the task updates its internal states and writes this information to the 7-seg LED matrix. It then sends a proper response back to the master including accelerometer values and button press events.

===== Code Snippet for score the update to the controller done by the Ball task: =====

void set_players_score(uint8_t score_green, uint8_t score_blue) {
uint16_t transfer_score = 0;
green_player_score = score_green;
blue_player_score = score_blue;
transfer_score = (score_blue * 100) + score_green;
printf("Transfer Score = %i\n", transfer_score);
controller_comm__update_player_score(CONTROLLER_COMM__ROLE_PLAYER_2, transfer_score);
controller_comm__update_player_score(CONTROLLER_COMM__ROLE_PLAYER_1, transfer_score);
}

===== Code Snippet for score the detecting collision with the pacman in Ball task: =====

if (blue_collided == 1) {
blue_collided = clear_blue_collided();
score_blue += cummulative_score;
set_players_score(score_green, score_blue);
change_game_state_to = IN_SCORE_STATE;
xQueueSend(*(ball_parameters.state_queue), &change_game_state_to, 0);
cummulative_score = 1;
SMACMAN__DEBUG_PRINTF("BLUE player score: %d GREEN player score: %d\n", score_blue, score_green);
set_blue_pacman_start();
set_green_pacman_start();
ball_setup(&ball);
}
if (green_collided == 1) {
green_collided = clear_green_collided();
score_green += cummulative_score;
set_players_score(score_green, score_blue);
change_game_state_to = IN_SCORE_STATE;
xQueueSend(*(ball_parameters.state_queue), &change_game_state_to, 0);
cummulative_score = 1;
SMACMAN__DEBUG_PRINTF("BLUE player score: %d GREEN player score: %d\n", score_blue, score_green);
set_blue_pacman_start();
set_green_pacman_start();
ball_setup(&ball);
}

=='''Game Casing''' ==

Smacman is a two Player game. It is quiet inconvinient to play the game with all the wires and components lying around. So to facilitate this we 3D printed a basic enclosure for the two players controller as well as the Led matrix, which is big enough to accommodate zigbee module, MP3 Decoder and speakers, Master Board. We needed to put together all components in a single enclosure. The enclosure includes the spacing for SJTWO board with PCB mounted on top and the MP3 Decoder along with speakers.

{|
|[[File:Smacman_enclosure.jpeg|350px|thumb|left|Case Design]]
|[[File:casing.jpeg|350px|thumb|left|Casing]]
|[[File:circuit_diagram_enclosure.jpeg|350px|thumb|left|Circuit Along with all the components]]
|}
{|
|[[File:enclosure_case.jpeg|400px|thumb|center|Entire Game Casing]]
|}

== Testing & Technical Challenges ==

{|
|[[File:GIF-2019-12-18-08-45-17.gif|160px|thumb|'''Pacman Movement Testing''']]
|}

===Issues, Challenges and solutions to get past them===

'''1. RGB LED Matrix Display driver'''

a) Setting up the LED Matrix was a bit of a challenge. Started with glowing a single row and column. Getting the initial hold on the exact row and column position was a bit tricky as one can easily get confuse on the starting and ending row and column. Once we got over it we moved on to design game objects separately.

b) Flickering of led matrix was solved by doing the following:
* The frequency of refreshing the led matrix was increased to show smooth transition from one frame to another.
* Led matrix is very sensitive to the inputs provided to it. Initially the flickering was thought to be because of the data lines and row selection lines. But later with further diagnoses it was discovered that the power supply line was creating issues. Changing the adapter eliminated the flickering.

c) As the game consists of many objects that exist simultaneously on the screen clearing the trail of each object was bit of a problem.
*Initially clearing the LED matrix from time to time assigned to one task. But later each object dealt with its own clearance, which eliminated the effect of clearance of one object with the display of other objects.

d) Pacman and Ball detection of the bounadry:
* Pacman object detecting the boundary and making the decision of moving left or right was a bit tricky. Started with one boundary condition and then proceeded with the rest boundary conditions.

e) Updating the movement of each object on the LED matrix was clumsy in the beginning as individual objects where updated as soon as a movement was detected in the object.
* But when the frequency of refreshing rate was increased the update of the LED matrix was moved to one task which led to the smooth movement of the objects on the screen.

e) The varying Pacman velocity with the ball movement in the lower and the upper half of the matrix was difficult.
* Set and get functions are used to get the updated position of the ball for each movement.

{|
|[[File:game_image.jpeg|350px|thumb|left|Game Frame]]
|[[File:score.jpeg|350px|thumb|left|Score]]
|[[File:ball_testing.gif|350px|thumb|left|Ball Testing]]

|}

'''2. Challenges in the designing of the controller modules for the paddle movement and to get score from the master'''

a) SJ2 UART frames were corrupted while sending over XBEE.
* The XBEE firmware parameters had to be carefully calibrated to match the SJ2 as well as using a 38400 bps bit rate. The SJ2 UART driver had to be slightly modified match as well.
b) UART is not meant to be a broadcast protocol.
* A custom wireless broadcast/multi-node wireless protocol and driver had to be designed to be robust with dropped frames and packets being handled gracefully. (Described above)

'''3. Designing the MP3 Decoder'''

a) Earlier we used the ssp2 Driver written by Preet for SPI interfacing to write the data to MP3 Decoder. but somehow we were not able to detect the slave properly because of which we could not communicate with the decoder.
* Resolution : We wrote our own simple SPI driver which sends the data to the MP3 Decoder for playing the music in background.
b) While reading data from the SD Card sometimes we faced few issues like hardware error occured in disk i/o and physical drive cannot work.
* Resolution : The default driver was using mount later option for SD Card we changed it to mount immediately and the issue got resolved.

'''4. Dimensions of power pins for the PCB design'''

a) Accommodate the exact dimensions of the 5V Power pin on the PCB design.
* Since there is no datasheet available for the 64x64 RGB LED Matrix, hence it was a difficult task. We used a basic approximation to determine the pin dimensions that would fit inside the PCB design such that it works just fine.

'''4. Integration Issues'''
a) Controller Logic and Game Logic were developed independently.
* Careful time and consideration had to be taken to ensure that the APIs were able to be stitched together. This actually ended up going smoother than we had anticipated. The Inter-board communication driver was designed to handle almost everything regarding the controllers, providing very abstract and simple APIs. This allowed for relatively smooth integration.
b) After game and controller logic, the main SJ2 did not have enough processing power to adequately driver the music functionality.
* A standalone SJ2 board was used for the game soundtrack. This eased the load on our main board which was starting to effect our gameplay.

== Conclusion ==
At the start, the concepts that we aimed to implement were not trivial but if accomplished, would lead to an awesome project. We realized early on that each one of us had particular strengths and that it would be critical for us to leverage these effectively. We effectively parallelized our tasks and made sure to regularly synchronize to avoid accruing too much technical debt. In the end, we were able to accomplish more features than we had initially devised. This project has helped us to gain more practical exposure to building a real time embedded systems and decompose and solve new problems that don't come from a textbook. We are thankful to Preet, who motivated and guided us through out the course work. This is surely going to help us for our interview preparation and in grabbing an internship.

=== Project Video ===
[https://youtu.be/Yq6fab3F3GU Project Testing Video]

[https://youtu.be/LsbX-s07nsg Project Video Link]

=== Project Source Code ===
* [https://github.com/nickschiffer/Smacman Github Source Code Link]

=== Acknowledgement ===
We would like to thank our Professor Preetpal Kang for all his awesome lectures and explanations of the embedded system topics, they could not have been explained any better than this! Not only did we enjoy working on this project but it also gave us an overall learning experience and precious life lessons. The extra knowledge in Preet's Class is surely going to help us to prepare for our interview preparations. We would also like to thank the ISA members for always being around and ready for helping whenever required.

=== References ===

====== WIRELESS CONTROLLER ======
* [https://www.digi.com/pdf/ds_xbeemultipointmodules.pdf XBEE S1 Datasheet]
* [https://cdn-shop.adafruit.com/datasheets/ht16K33v110.pdf HT16K33 I2C 7-seg backpack datasheet]

====== MP3 DECODER ======
* [https://cdn-shop.adafruit.com/datasheets/vs1053.pdf Datasheet For MP3 Decoder VS1053]
* [https://github.com/nickschiffer/MP3_Player_RTOS/tree/master/projects/MP3_Player/L5_Application/MP3_DECODER Code Reference]

====== RGB LED Matrix Interfacing and Designing ======
* [https://cdn.sparkfun.com/assets/7/d/7/5/6/M6464-P3.pdf Datasheet and LED Matrix parameters]
* [https://learn.adafruit.com/32x16-32x32-rgb-led-matrix Power and pin connections]
* [https://bikerglen.com/projects/lighting/led-panel-1up/ Reference for setting up and testing LED Matrix]
* [http://socialledge.com/sjsu/index.php/F18:_2048 Reference for LED Matrix driver]

====== General/Miscellaneous ======
* [http://www.espruino.com/Pixl.js+Pong Pong Game Tutorial]
* [https://www.freertos.org/Documentation/RTOS_book.html FreeRTOS Documentation and Reference Manual]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Smacman

2019-10-09T03:18:02Z

Realtime OS on Embedded Systems

2019-10-09T03:17:23Z

Preet: /* Fall 2019 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2019 | Fall 2019]] ===

* [[F19: Infinity Mirror]]
* [[F19: Smacman]]

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]
* [[F18: Zero Zero UFO]]
* [[F18: Goals of Glory]]
* [[F18: Spartan Warrior]]
* [[F18: Wireless sensor network]]
* [[F18: baem geim]]
* [[F18: Hit the Balloon]]
* [[F18: 2048]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

S19: CANT Bus

2019-05-29T16:37:52Z

Preet: /* Grading Criteria */

== [C]ompile [A]nother [N]on-[T]rivial Bus ==

== Abstract ==
Design and implement an autonomous car to navigate to a destined location chosen by the user using a phone application. The user will set gps coordinates via an Android application while the current location is processed. The RC car should be able to use these coordinates to navigate itself to the destined location avoiding obstacles and providing useful data on the way. Several objectives need to be completed in order for the RC car to function properly: integrate proximity sensors, gps, compass, lcd screen, motor driver board, esp32 communication, hall sensor, and overall integration in order for the RC car to be able to determine where it is, the speed it's going, and the environment around it to successfully navigate to the final destination.

=== Introduction ===

The purpose of this project was to convert a RC car into a self driving vehicle that can navigate itself to a destination sent via an Android mobile app. To achieve this, the project was divided into 7 modules: Avoidance, Motor, Master Driver, Localize, Comms, and Android Application. The Avoidance module contains 8 IR sensors that allow the car to see the world around it. This module finds objects and measures the distance between it and the object. Motor controls a brushed motor which drives the car at various speeds and a servo to turn the car. In addition, Motor also contains a hall effect sensor that keeps track of the cars speed. Localize tells the car where it is in relation to where it needs to go. It contains a GPS and Compass to provide current coordinates and heading. Comms houses the wireless device that talks to the the mobile app as well as an LCD display to show various car data such as speed and destination. The mobile app is where the user can enter GPS coordinates as a destination point, or alter the current destination with a way-point. Lastly, the Driver receives the data from all modules and decides how the car shall react. In order to complete these modules basic knowledge of I2C, UART, SPI, and CAN bus protocols, gpio control, PWM control, phone application development, and pathing algorithms was required. While each peripheral in the modules used their own form of communication, each of the modules was connected using the CAN bus protocol.

=== Team Members & Responsibilities ===
* Kevin Chan
** IR sensors (Proximity), Compass (Localize), GPS (Localize), Distance Vector (Localize), Code Review
* Khrysta Finch
** Chassis, Driver (Driver), LCD display (Comms), Schematic, Telemetry (Comms)
* Andrew Javier
** Hall Sensor (Motor), Wireless communications via esp32(Comms), GPS (Localize), Chassis
* Aaron Lee
** GPS (Localize), Pathing Algorithm (Comms)
* Jonathan Rojas
** Motor (Motor), Servo (Motor), Motor driver board (Motor), hall sensor (Motor), Cable Management, Chassis
* Vijay Vanapalli
** GPS (Localize), Wireless communications via esp32(Comms), Mobile app (Comms)
* Nelson Wong
** Team Leader, Driver (Driver), Telemetry (Comms), PCB/Schematic, Chassis, Mobile App (Comms), Power, Code Review

==== Source Code ====
[https://gitlab.com/cant-bus/cant-bus Gitlab Project Link]
 

==== Modules ====
* Driver
** [https://gitlab.com/ntwong0 Nelson Wong]
** [https://gitlab.com/diarmadhi Khrysta Finch]

* Proximity
** [https://gitlab.com/kmchan15 Kevin Chan]

* Motor
** [https://gitlab.com/rojasjon28 Jonathan Rojas]
** [https://gitlab.com/diarkia124 Andrew Javier]

* Localize
** [https://gitlab.com/VijayVanapalli96 Vijay Vanapalli]
** [https://gitlab.com/lee_aaron Aaron Lee]
** Andrew Javier
** Kevin Chan

* Comms
** Andrew Javier
** [https://github.com/vijayvanapalli96/Final243App Vijay Vanapalli]
** Khrysta Finch

* Android Application
** Vijay Vanapalli

* Testing Team
** Kevin Chan
** Nelson Wong

 

== Schedule ==

This table can also be viewed via Google Sheets! See the link below: 
https://docs.google.com/spreadsheets/d/e/2PACX-1vRTGqwTD1WUlk0iwc0aE7aUkm7tKkvBp_5hJzrN4vy-xIHmjlPB3w5mEW0cC7l0UEJme_YXMzd_bB6A/pubhtml?gid=2009649579&single=true

{|
| || || || || Task Contributors || || || || || || || Date || ||
|-
| || || || || || || || || || || || || ||
|-
| WBS# || Task Title || Dependencies || || Jonathan || Kevin || Andrew || Khrysta || Nelson || Aaron || Vijay || Start || End || Status
|-
| 1 || Determine theory of operations || || || x || x || x || x || x || x || x || 3/19 || 4/1 ||
|-
| 1.1 || Compass || || || || || || || x || x || || 3/19 || 4/1 || Done
|-
| 1.2 || GPS || || || || || || || x || x || || 3/19 || 4/1 || Done
|-
| 1.3 || Proximity || || || || x || || || x || || || 3/19 || 4/1 || Done
|-
| 1.4 || LIDAR || || || || x || || || x || || || 3/19 || 4/1 || Done
|-
| 1.5 || Wireless || || || || || x || || x || || x || 3/19 || 4/1 || Done
|-
| 1.6 || LCD || || || || || || x || || || || 3/19 || 4/1 || Done
|-
| 1.7 || Hall Effect Sensors || || || || || x || || || || || 3/19 || 4/1 || Done
|-
| 1.8 || Motor || || || x || || || || x || || || 3/19 || 4/1 || Done
|-
| 1.9 || Steering || || || x || || || || x || || || 3/19 || 4/1 || Done
|-
| 1.10 || Battery health || || || || || || || x || || || 3/19 || 4/1 || Cancelled
|-
| 1.11 || Mobile app || || || || || || || x || x || x || 3/28 || 4/1 || Done
|-
| 1.12 || Wireless module || || || || || x || || x || || x || 3/28 || 4/1 || Done
|-
| 1.13 || Driver || || || || || || x || x || || || 3/19 || 4/6 || Done
|-
| 2 || Chassis and mounting || || || || || || x || x || || || 5/1 || 5/7 ||
|-
| 2.1 || Acrylic to chassis || || || || || || x || || || || 4/1 || 4/4 || Done
|-
| 2.2 || PCB to acrylic || 3.5 || || || || || x || x || || || 4/25 || 4/28 || Done
|-
| 2.3 || SJ One to acrylic || || || || || || x || || || || 4/25 || 5/7 || Done
|-
| 2.4 || Power modules to acrylic || 3.2 || || || || || x || x || || || 4/25 || 5/7 || Done
|-
| 2.5 || Proximity to acrylic || || || || || || x || || || || 4/25 || 5/7 || Done
|-
| 2.6 || Magnet collet to motor shaft || || || || || || x || || || || 4/18 || 4/23 || Done
|-
| 2.7 || Hall effect sensor to chassis || || || || || || x || || || || 4/18 || 4/23 || Done
|-
| 3 || PCB and assembly || || || x || x || x || x || x || x || x || 3/5 || 4/25 || Done
|-
| 3.1 || Finalize BOM || || || x || x || x || x || x || x || x || 3/5 || 4/1 || Done
|-
| 3.2 || Determine module footprints || || || || || || x || x || x || x || 3/28 || 4/1 || Done
|-
| 3.3 || Finalize schematic || || || || || || || x || || x || 4/1 || 4/9 || Done
|-
| 3.4 || Review schematic || || || || || || x || x || || x || 4/1 || 4/10 || Done
|-
| 3.5 || Finalize layout || || || || || || || x || || || 4/1 || 4/9 || Done
|-
| 3.6 || Review layout || || || || || || x || x || || x || 4/1 || 4/10 || Done
|-
| 3.7 || Order PCB || || || || || || || x || || || 4/10 || 4/24 || Done
|-
| 3.8 || PCB assembly || || || || || || || x || || || 4/23 || 4/25 || Done
|-
| 3.9 || Assembly of modules || || || x || x || x || x || x || x || || 4/23 || 4/25 || Done
|-
| 4 || ECU Logic || || || x || x || x || x || x || x || x || 3/5 || 5/23 || Done
|-
| 4.1 || MOTOR || || || x || x || x || || x || || || 3/5 || 5/23 || Done
|-
| 4.1.1 || Tachometer logic || || || || || x || || x || || || 4/3 || 4/10 || Done
|-
| 4.1.2 || Motor logic || || || x || x || || || x || || || 4/2 || 4/18 || Done
|-
| 4.1.3 || Steering logic || || || x || x || || || x || || || 4/2 || 4/18 || Done
|-
| 4.2 || COMMS || || || || || x || x || x || || x || 4/13 || 5/21 || Done
|-
| 4.2.1 || Wireless logic || || || || || x || || || || x || 4/13 || 5/21 || Done
|-
| 4.2.2 || LCD logic || || || || || || x || || || || 4/28 || 5/10 || Done
|-
| 4.3 || LOCALIZE || || || || || || || x || x || || 5/22 || 5/22 || Done
|-
| 4.3.1 || GPS logic || || || || || || || x || x || || 4/22 || 5/22 || Done
|-
| 4.3.2 || Compass logic || || || || x || || || x || x || || 4/28 || 5/22 || Done
|-
| 4.3.3 || GPS/Compass synthesis || || || || x || || || || || || 5/1 || 5/22 || Done
|-
| 4.4 || AVOIDANCE || || || || x || || || x || || || 4/3 || 5/22 || Done
|-
| 4.4.1 || LIDAR logic || || || || x || || || x || || || 4/3 || 5/22 || Done
|-
| 4.4.2 || Proximity logic || || || || x || || || x || || || 4/3 || 5/22 || Done
|-
| 4.4.3 || LIDAR/proximity synthesis || || || || x || || || x || || || 5/2 || 5/22 || Done
|-
| 4.5 || DRIVER || || || || || || x || x || || || 4/1 || 5/22 || Done
|-
| 4.5.1 || Battery health logic || || || || || || || x || || || 4/15 || 4/17 || Done
|-
| 4.5.2 || Driver logic || || || || || || x || x || || || 4/1 || 5/22 || Done
|-
| 5 || Wireless module || || || || || x || || x || || x || 4/5 || 5/23 || Done
|-
| 5.1 || Development environment || || || || || || || x || || || 4/5 || 4/7 || Done
|-
| 5.3 || Wifi connectivity || || || || || x || || || || || 4/5 || 4/7 || Done
|-
| 5.4 || Handle XHR endpoints || || || || || x || || || || || 4/5 || 5/23 || Done
|-
| 5.5 || Relay via UART || || || || || x || || || || || 4/5 || 4/29 || Done
|-
| 6 || Mobile app || || || || || || || x || x || x || 4/1 || 5/22 || Done
|-
| 6.2 || Send XHR requests || || || || || || || || || x || 4/1 || 4/29 || Done
|-
| 6.3 || Google Maps Overlay || || || || || || || || || x || 4/1 || 4/1 || Done
|-
| 6.4 || Show car icon || || || || || || || || || x || 4/15 || 5/22 || Done
|-
| 6.5 || Show waypoints || || || || || || || || || x || 5/10 || 5/19 || Done
|-
| 6.6 || Service button press as XHRs || || || || || || || || || x || 4/15 || 4/29 || Done
|-
| 7 || Documentation || || || || || || || x || || || 3/5 || 5/23 || Done
|-
| 7.1 || Summary of individual contribution || || || x || x || x || x || x || x || x || 3/5 || 5/22 || Done
|-
| 7.2 || Project wiki schedule || || || || || x || || x || || || 3/5 || 5/23 || Done
|-
| 7.3 || BOM || || || x || x || x || x || x || x || x || 3/5 || 4/5 || Done
|-
| 7.4 || CAN comms: the dbc || || || x || x || x || x || x || x || x || 3/5 || 5/22 || Done
|-
| 7.5 || MOTOR || || || || || || || x || || || 3/5 || 5/23 || Done
|-
| 7.5.1 || Theory of operation || || || x || || x || x || x || || || 3/5 || 5/23 || Done
|-
| 7.5.2 || Hardware design || || || || || x || x || x || || || 3/5 || 3/19 || Done
|-
| 7.5.3 || Software design || || || x || || || || || || || 3/5 || 5/23 || Done
|-
| 7.5.4 || Challenges || || || x || || || || || || || 5/22 || 5/23 || Done
|-
| 7.6 || COMMS || || || || || x || x || x || || x || 4/28 || 5/23 || Done
|-
| 7.6.1 || Theory of operation || || || || || x || x || x || || x || 4/28 || 5/1 || Done
|-
| 7.6.2 || Hardware design || || || || || || x || x || || || 5/1 || 5/9 || Done
|-
| 7.6.3 || Software design || || || || || x || x || || || || 5/1 || 5/23 || Done
|-
| 7.6.4 || Challenges || || || || || x || x || || || || 5/1 || 5/23 || Done
|-
| 7.7 || LOCALIZE || || || || || || || x || x || || 5/1 || 5/23 || Done
|-
| 7.7.1 || Theory of operation || || || || || || || x || x || || 5/1 || 5/14 || Done
|-
| 7.7.2 || Hardware design || || || || || || || x || x || || 5/2 || 5/14 || Done
|-
| 7.7.3 || Software design || || || || || || || x || x || || 5/2 || 5/23 || Done
|-
| 7.7.4 || Challenges || || || || || || || || x || || 5/1 || 5/23 || Done
|-
| 7.8 || AVOIDANCE || || || || x || || || x || || || 5/1 || 5/23 || Done
|-
| 7.8.1 || Theory of operation || || || || x || || || x || || || 5/1 || 5/8 || Done
|-
| 7.8.2 || Hardware design || || || || || || || x || || || 5/5 || 5/23 || Done
|-
| 7.8.3 || Software design || || || || x || || || x || || || 5/5 || 5/23 || Done
|-
| 7.8.4 || Challenges || || || || x || || || x || || || 5/1 || 5/23 || Done
|-
| 7.9 || DRIVER || || || || || || x || x || || || 5/1 || 5/23 || Done
|-
| 7.9.1 || Theory of operation || || || || || || x || x || || || 5/1 || 5/23 || Done
|-
| 7.9.2 || Hardware design || || || || || || x || x || || || 5/5 || 5/23 || Done
|-
| 7.9.3 || Software design || || || || || || x || x || || || 5/5 || 5/23 || Done
|-
| 7.9.4 || Challenges || || || || || || x || || || || 5/1 || 5/23 || Done
|-
| 7.10 || Mobile app || || || || || || || x || x || x || 4/18 || 5/23 || Done
|-
| 7.10.1 || Theory of operation || || || || || || || x || x || x || 4/18 || 5/20 || Done
|-
| 7.10.2 || Software design || || || || || || || || || x || 4/20 || 5/23 || Done
|-
| 7.10.3 || Challenges || || || || || || || || || x || 4/18 || 5/23 || Done
|-
| 7.11 || Overall PCB || || || || || || || x || x || x || 3/18 || 4/25 || Done
|-
| 7.11.1 || Hardware design || || || || || || || x || x || x || 3/18 || 4/25 || Done
|-
| 7.11.2 || Challenges || || || || || || || x || || || 4/7 || 5/23 || Done
|-
| 7.12 || Videography || || || || || x || || x || || || 5/23 || 5/23 || In Progress
|-
| 7.13 || Conclusion || || || x || x || x || x || x || x || x || 5/23 || 5/23 || Done
|-
| 8 || Supervision/Advisory || || || x || x || x || x || x || x || x || 4/1 || 5/23 || Done
|-
| 8.1 || Maintain knowledge of system architecture || || || || || || || x || || || 4/1 || 5/23 || Done
|-
| 8.2 || Assert code review || || || || || || || x || || || 4/1 || 5/23 || Done
|-
| 8.3 || Define system test approach || || || || || || || x || || || 4/1 || 5/23 || Done
|-
| 8.4 || Enforce coding style and practice || || || || || || || x || || || 4/1 || 5/23 || Done
|-
| 8.5 || Tracking project deliverables || || || x || x || x || x || x || x || x || 4/1 || 5/23 || Done
|-
| 9 || Final Demonstration || || || x || x || x || x || x || x || x || 5/22 || 5/23 || Done
|}

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Cost
|-
! scope="row"| 1
| RC Car
| Cobra [https://www.amazon.com/gp/product/B076P84HM4/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1]
| 1
| $180.00
|-
! scope="row"| 2
| CAN Transceivers SN65HVD230
| Microchip [https://www.amazon.com/SN65HVD230-CAN-Board-Communication-Development/dp/B00KM6XMXO]
| 5
| $10
|-
! scope="row"| 3
| LSM303 Compass
| Adafruit [https://www.adafruit.com/product/1120]
| 1
| $15
|-
! scope="row"| 4
| ublox Neo-6m GPS
| Ublox [https://www.amazon.com/dp/B01H5FNA4K]
| 1
| $16
|-
! scope="row"| 5
| Proximity Sensors - VL53L0X
| ST [https://www.adafruit.com/product/3317]
| 8
| $120
|-
! scope="row"| 6
| Hall Effect Sensors
| Adafruit [https://www.amazon.com/gp/product/B008AS2YBM/]
| 3
| $24
|-
! scope="row"| 7
| LiPo Batteries (3S 11.1V 5500 mAh)
| FLOUREON [https://www.amazon.com/dp/B06Y5ZGQB2]
| 2
| $34
|-
! scope="row"| 8
| Printed Circuit Board
| Bay Area Circuits
| 1
| $60
|-
! scope="row"| 9
| ESP32 Wireless Module
| Espressif [https://www.aliexpress.com/item/-/32885906652.html]
| 1
| $5
|-
! scope="row"| 10
| Power Management Integrated Circuit (PMIC)
| Amazon [https://www.amazon.com/dp/B079N9BFZC]
| 1
| $12
|-
! scope="row"| 11
| 2.2" TFT LCD display
| Adafruit [https://www.adafruit.com/product/1480]
| 1
| $25
|-
|}

== Printed Circuit Board ==
We used the online tool Upverter to create our schematic and design the final PCB board. Both schematic and board can be found on Upverter using the link below.

[https://upverter.com/eda/#designId=6fb74efa3ccbbaa4,tool=pcb PCB and Schematic]
 

== CAN Communication ==
=== CAN BUS Messages ===
The DBC file that was used to generate our CAN messages can be found [[#CAN DBC File|below]]. Each message has a priority ID assigned to it that is used by the CAN protocol to see which device to listen to first in cases of bus arbitration; the lower the ID number the higher priority it has. In our case, the message with the highest priority at 10 is KILL_MOTOR. Since we are using LiPO (Lithium Polymer) batteries, the desire to disconnect all power for the battery depleted was high on the list. Should the car be driving at that time, the KILL_MOTOR_cmd shuts off the motor immediately, allowing us to catch up to the car and swap out batteries. The KILL_MOTOR_REMOTE message follows the KILL_MOTOR message in priority. This is simply a redundancy we built in to have the message delivered to the mobile app and notifying us that the battery is low.

The priority decreases from there with HEARTBEAT from the Driver being the next highest. Since the Driver doesn't send many messages and it's there to collect data from all the other modules, it needs to let the others know it's still available. MOTOR_CMD follows as we wanted the car to move as quickly as possible, which leads to AVOIDANCE_LIDAR as the next highest. Knowing when we were in close proximity to an object is key to making sure we don't run into it. Note that while this message has "LIDAR" as part of the name, this is legacy nomenclature from when we initially had LIDAR for the car. They are now IR sensors.

GPS, Compass, and Speed were assigned the lowest priorities. While knowing where we are in relation to where we are going is important, it was less demanding that knowing if we are about to hit something or if the battery was depleted. Overall, this choice in priority has served well in providing a functional autonomous car.

<HR>
 

=== Hardware Design ===

Each of the modules are connected to a CAN transceiver via transmit and receive lines. The transceivers themselves are connected together through their CAN high and low pins (CANH/CANL) with each of those lines terminating with a 120 ohm resistor.
[[File:CANT_bus_hardware.png|thumb|400px|center|Figure 1: CAN bus architecture design]]

==== CAN DBC File ====

<syntaxhighlight lang="c">
BS_:
BU_: COMMS DRIVER LOCALIZE MOTOR AVOIDANCE

BO_ 10 KILL_MOTOR: 1 DRIVER
SG_ KILL_MOTOR_cmd : 0|8@1+ (1,0) [0|0] "" MOTOR,COMMS

BO_ 11 KILL_MOTOR_REMOTE: 1 COMMS
SG_ KILL_MOTOR_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" LOCALIZE,COMMS,AVOIDANCE,MOTOR

BO_ 101 MOTOR_CMD: 2 DRIVER
SG_ MOTOR_CMD_steer : 0|3@1+ (1,-1) [-1|1] "degrees" MOTOR
SG_ MOTOR_CMD_drive : 8|4@1+ (1,-2) [-2|5] "" MOTOR

BO_ 102 DRIVER_STATUS: 1 DRIVER
SG_ DRIVER_STATUS_enum : 0|3@1+ (1,0) [0|0] "" COMMS

BO_ 200 AVOIDANCE_LIDAR: 8 AVOIDANCE
SG_ LIDAR_f_right : 0|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_m_right : 8|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_middle : 16|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_m_l : 24|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_left : 32|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_right : 40|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_middle : 48|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_left : 56|8@1+ (1,0) [0|0] "cm" DRIVER

BO_ 201 DESIRED_VECTOR: 8 LOCALIZE
SG_ DESIRED_HEADING : 0|32@1+ (0.1,0) [0|360.0] "degrees" DRIVER,COMMS
SG_ DESIRED_DISTANCE : 32|32@1+ (0.00001,0) [0|0] "km" DRIVER,COMMS

BO_ 300 LOCALIZE_GPS: 8 LOCALIZE
SG_ GPS_STATUS : 0|8@1+ (1,0) [0|0] "" DRIVER,COMMS
SG_ GPS_TX_LATITUDE : 8|24@1+ (0.000001,37.000000) [37.000000|38.000000] "degrees" DRIVER,COMMS
SG_ GPS_TX_LONGITUDE : 32|32@1- (0.000001,-122.000000) [-122.000000|-121.000000] "degrees" DRIVER,COMMS

BO_ 301 LOCALIZE_IMU: 8 LOCALIZE
SG_ IMU_STATUS : 0|8@1+ (1,0) [0|0] "" DRIVER,COMMS
SG_ IMU_COMPASS : 8|12@1+ (0.1,0) [0|360.0] "degrees" DRIVER,COMMS

BO_ 302 SPEED: 8 LOCALIZE
SG_ SPEED_kph : 0|16@1- (0.001,0) [-5|10] "kph" COMMS,DRIVER

BO_ 303 LOCALIZE_IMU_DEBUG: 8 LOCALIZE
SG_ IMU_COMPASS_X : 0|10@1- (1,0) [-200|200] "" DBG
SG_ IMU_COMPASS_Y : 10|10@1- (1,0) [-200|200] "" DBG

BO_ 400 MOTOR_STATUS: 1 MOTOR
SG_ MOTOR_STATUS_data : 0|8@1+ (1,0) [0|0] "" COMMS,DRIVER

BO_ 500 SET_WAYPOINT: 8 COMMS
SG_ SET_WAYPOINT_LAT : 0|24@1+ (0.000001,37.331610) [37.331610|37.340132] "degrees" LOCALIZE,DRIVER
SG_ SET_WAYPOINT_LONG : 24|24@1- (0.000001,-121.886025) [-121.886025|-121.876412] "degrees" LOCALIZE,DRIVER

BO_ 501 SET_STATUS: 1 COMMS
SG_ SET_STATUS_enum : 0|2@1+ (1,0) [0|0] "" DRIVER

BO_ 700 DRIVER_DEBUG: 8 DRIVER
SG_ VEL_ARR : 0|32@1+ (1,0) [0|0] "" AVOIDANCE

BO_ 701 AVOIDANCE_DEBUG: 8 AVOIDANCE
SG_ AVOIDANCE_COUNT : 0|32@1+ (1,0) [0|0] "" DRIVER

BO_ 702 MOTOR_DEBUG: 4 MOTOR
SG_ MOTOR_SPEED_DBG : 0|32@1+ (0.0001,0) [0|0] "ms" DRIVER

BO_ 704 TACHOMETER_DEBUG: 8 LOCALIZE
SG_ TACHOMETER_DBG : 0|16@1- (0.001,0) [-5|10] "kph" COMMS,DRIVER

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ LOCALIZE "The localization controller of the car";
CM_ BU_ AVOIDANCE "The collision avoidance controller of the car";
CM_ BU_ COMMS "The wireless comms and telemetry controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BO_ 501 "0: stop, 1: ready, 2: navigate, 3: skip/next"
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_ 500 100;
BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 101 100;
BA_ "GenMsgCycleTime" BO_ 400 100;
BA_ "GenMsgCycleTime" BO_ 200 100;
BA_ "FieldType" SG_ 102 DRIVER_STATUS_enum "DRIVER_STATUS_enum";
BA_ "FieldType" SG_ 103 SET_STATUS_enum "SET_STATUS_enum";
BA_ "FieldType" SG_ 500 DBC_TEST1_enum "DBC_TEST1_enum";
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
VAL_ 102 DRIVER_STATUS_enum 7 "STOP" 6 "FWD_R" 5 "REV_R" 4 "REV_M" 3 "REV_L" 2 "FWD_L" 1 "FWD_M" 0 "IDLE" ;
VAL_ 103 SET_STATUS_enum 1 "GO" 0 "STOP" ;
VAL_ 500 DBC_TEST1_enum 2 "DBC_TEST1_enum_val_two" 1 "DBC_TEST1_enum_val_one" ;
VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;

</syntaxhighlight>

== Proximity ECU ==
The Proximity ECU was also known as the Avoidance module and can be found [https://gitlab.com/cant-bus/cant-bus/tree/avoid_prox on GitLab here]. It's sole purpose is to monitor the environment around the car and take measurements of objects that break the threshold.

=== Hardware Design ===

[[File:CANT_Proxy_Sensor.jpg|thumb|300px|center|Figure 2: VL530X]]

Avoidance contains eight VL53L0X infrared sensors for obstacle detection that utilizes the I2C interface. The sensors measure a distance in centimeters with a maximum range of 2 meters with 1 millimeter resolution. The VL53L0X sensor used in the car was purchased pre-attached to a breakout board where the voltage was stepped down from 3.3V to 2.8V. The XSHUT pin on the sensor acts as an enable where they were wired to GPIO pins on the SJOne board. For the car, there were a total of 8 sensors used: 5 in the front, 3 in the back.
The sensors come preassigned to an address of 0x52 but can be reassigned to a different address. The table for sensor address assignment and GPIO are seen below.

{| class="wikitable"
|-
! scope="col"| Sensor Position
! scope="col"| GPIO pin
! scope="col"| Slave Address
|-
! scope="row"|Front Right
|P2_2
|0x54
|-
! scope="row"|Front Middle Right
|P0_30
|0x61
|-
! scope="row"|Front Middle
|P2_1
|0x56
|-
! scope="row"|Front Middle Left
|P0_29
|0x63
|-
! scope="row"|Front Left
|P2_0
|0x58
|-
! scope="row"|Back Right
|P2_5
|0x5A
|-
! scope="row"|Back Middle
|P2_4
|0x5C
|-
! scope="row"|Back Left
|P2_3
|0x5E
|-
! scope="row"|Default
|none
|0x52
|}

Power for the sensors came from the car power supply regulated for 3.3V instead of from the SJOne board. The problem and solution of assignment of the I2C address can be seen below in the software design. The block diagram for this module can be found below. Note that for brevity, not all 8 proximity sensors are shown. Each sensor is connected in the same manner each with its own dedicated GPIO pin.

[[File:CANT bus avoidance.png|thumb|400px|center|Figure 3: Proximity IR sensors]]

=== Software Design ===
For the software design, a C++ library was ported over from Pololu along with configuration of the library to work with the SJOne Board. A C wrapper was written to allow it to be unit tested and included in our periodic_callbacks.c file. There were difficulties with having a singleton object for 8 sensors that created conflict. This was resolved by having a table of addresses, that the singleton object would select and reassign its address with to sweep through the sensor addresses. The configuration of the reassignment of addresses also took careful consideration.

To reassign the address, the modification to the VL53L0X library from the Pololu library can be seen below.

<syntaxhighlight lang="c">
void VL53L0X::setAddress(uint8_t new_addr, uint8_t i2c_write)
{
if(i2c_write)
writeReg(I2C_SLAVE_DEVICE_ADDRESS, (new_addr >> 1) & 0x7F);
address = new_addr >> 1;
_setAddress(new_addr);
}
</syntaxhighlight>

In this segment, we gave the option to change the software address instead of changing both software and hardware addresses. This gives us the ability to make a configuration change without changing the slave address register. The i2c_write signal is only enabled high on initialization and all device reads happen when i2c_write is low. This function is called before every switch to a new device. Since we adapted the VL53L0X library with the i2c read from the SJOne Board, we follow the convention of changing this software address before calling their modified method that retrieves and processes the sensor data.

The initialization function for these sensors followed the flowchart below of how to reassign the addresses of each sensor even when they all start with the same address. The process would first enable the first sensor with XSHUT using the GPIO pin, the select the device based on the default address. The function would then assign it the addressed based on the table above. After initializing was completed for one sensor, the sensor would stay enabled, but the singleton object would be reset back to 0x52 to set the next sensor.

[[File:CANT_Bus_Avoidance_Chart.png|thumb|300px|center|Figure 4: Proximity IR Init Flowchart]]

To collect and store data from each sensor, a data structure was created to be placed in a CAN message. A function was created where it would again sweep the address space of the address table, and store the data to its respective location in the data structure. The VL53L0X library outputs the sensor data in millimeters, but due to the size of the CAN message and having 8 different sensors - a conversion was required. We selected our units to be centimeters so our CAN message would contain 8 different sensors with a maximum of 255 centimeters. We preferred not to split the data into two CAN messages, because it was vital that the data being sent to DRIVER was accurate and complete across all the sensors. This occurs every 20 Hz, where a CAN message is broadcasted on the bus for DRIVER to use.

* 100Hz periodic
** proxy_get_data(); - Call all 8 IR sensors, and retrieve data into structure
** pack_avoidance_data(data); - Pack avoidance struct into CAN message for DRIVER
** CAN_tx(can1, &can_msg_dbg, 0); - Send packaged avoidance struct on CAN bus

* 1Hz periodic
** Reset CAN Bus if Bus OFF

=== Technical Challenges ===

The only issues with the proximity sensors came from using a library provided by Pololu that used a singleton object. To address this issue, a table of addresses was created where the singleton object would sweep the table of addresses to retrieve data from each sensor. The singleton object would reassign its own address from the table to access each sensor individually. The process described in the software design was also used for retrieving data from each sensor.

<HR>
 

== Motor ECU ==
[[File:Cmpe243_motor.png|thumb|400px|center|Figure 5: Architecture of Motor Controller]]
The Motor ECU also known as the Motor module was used to control the speed and direction of the RC car as well as determining the speed of the car.
=== Hardware Design ===
[[File:ServoD645.png|thumb|400px|center|Figure 6: Architecture of Motor Controller]][[File:Brushmotor.png|thumb|400px|center|Figure 7: Architecture of Motor Controller]] [[File:Hallsensor.png|thumb|400px|center|Figure 8: Architecture of Motor Controller]]
[[File:Motordriver.png|thumb|400px|center|Figure 9: Architecture of Motor Controller]]
Motor contains a MW645 HiTech servo motor, brushless motor, motor driver board, and a hall sensor switch. Servo motor used to control the steering of the RC car working at a frequency of 50Hz with dutycyles (8%-left, 6%-middle, and 4%-right) for maneuvering obstacles utilizing PWM to set the frequency. The brushless motor was used to control the speed of the RC car working at a frequency of 100Hz with dutycyles (60%backwards, 70%-stop, and 75-85%-forward), a motor driver board Adafruit 16-Channel 12-bit PWM/Servo Driver - I2C interface - PCA9685 was used to control the motor via PWM as well, but at a different frequency. Lastly a hall switch was used to detect the speed of the RC car via GPIO pins set up as interrupts.
Power for the sensors and servo came from the car power supply regulated for 5V instead of from the SJOne board. The problem and solution of assignment can be seen in the technical challenges section of this module.

=== Software Design ===
For the software design a C wrapper was written to allow the servo, motor, and hall sensor to be utilized in the periodic call backs with unit-testing capabilities. The C wrapper included PWM for the servo control, interrupt for the hall sensor, and i2c for motor control, leds and button switches for manual control and calibration. Once all the functions are written: set_speed, set_steering, i2c_writte, i2c_read, i2c_ init, switch_button, display_led, they can be used to test and control the RC car functionalities as well as determining the speed.
The initialization function for this included initializing the PWM, i2c, interrupt, and CAN bus. Once everything is initialize only two main functions were use one to receive commands from driver and one to send the status of the RC car. The overall flow the program can be seen in the following figure where the receive can message checks for specific ID in order to kill the motor, set the speed and steering values, or driver heartbeat in order to determine if the driver is active.
Once the driver sends a command the motor module will set the values and will send the speed values in m/s right after as well as check for ramp. Next the second main function, will send a status value of 1 for debugging purposes using BUS Master.
[[File:Cmpe243_motor_sw.png|thumb|400px|center|Figure 10: Architecture of Motor Controller]]
==== Motor ====
'''Periodic Init'''
* Initializes CAN, servo PWM (50Hz), motor driver board PWM (100Hz), interrupt for hall sensor, and speed calibration 
'''1Hz Task'''
* Used to check the state of CAN and reset. 
'''10Hz Task'''
* Receive CAN message for Motor Control
* Send Motor Status
* Send Motor Speed

=== Technical Challenges ===
*Motor and Servo Frequencies
*Hall Sensor Speed Determination

==== Motor and Servo Frequencies ====

*Single frequency for PWM on SJone board
Using PWM on the SJOne board only allows for one PWM frequency on all the PWM pins. For Motor, we required two different frequencies (motor (100Hz) and servo (50Hz)). We solved this by using a motor driver board using i2c to create a second PWM frequency.

*Fluctuating PWM Frequency
The PWM for MOTOR varied by a few Hz depending on the environment causing the duty cycle to control the motor to change. We set the frequency to be 100Hz, but varied between 98.7Hz. This caused the dutycycle to change from 70% to 80% to initiate the motor.

*Single frequency for PWM on SJone board
We solved this by using a motor driver board using i2c to create a second PWM frequency.

*Fluctuating PWM Frequency
In order to be able to deal with any situation and environment the RC car will be in we created a function to manually calibrate the first speed by increasing the dutycycle by 1% using push buttons and automatically incrementing the higher speeds with it.

==== Hall Sensor Speed Determination ====

*Creating a secure mount with enough magnets
Having trouble to detect more than one interrupt from the hall sensor no matter what speed, periodic callback speed (10Hz, 20Hz, 100Hz), and magnets.

*Creating a secure mount with enough magnets
Created a custom mount with a magnet ring with alternating magnets with precise spacing to give the interrupt at 10Hz task and hall sensor enough time to reset.

<HR>
 

== Localize ECU ==

The Localize ECU (also called GEO controller) can be found [https://gitlab.com/cant-bus/cant-bus/tree/kchan/localize on GitLab here]. It's sole purpose is to provide compass, GPS, and directional data to DRIVER and COMMs

[[File:Localization1.jpg|thumb|400px|center|Figure 11: Geographic Controller]]

=== Hardware Design ===

==== LSM303 ====

The LSM303 was selected as the compass for the final product. The LSM303 is a digital compass that contains an acceleration sensor and temperature sensor onboard. It uses the I2C communication protocol and can be power via a 5V or 3.3V power source. For this sensor, the SJOne board directly powered the compass. The clock rate for the slave clock was set to 100 KHz. The compass requires calibration which will be described in the both the software and technical challenges.

[[File:CANT_Localize_LSM303_BlockDiagram.png |thumb|300px|center|Figure 12: LSM303 Block Diagram]]

==== NEO-6M GPS ====

[[File:CANT Localize Neo6M image.jpg|thumb|300px|center|Figure 13: Neo-6M GPS Module]]

The Neo-6M GPS module was the device used to supply the SJOne board with positioning information. It communicates using the UART protocol and sets information at a baud rate of 9600. When powered, the module automatically sends various NMEA sentences at a rate of 1 Hz. Its only connection to the SJOne board is through the Rx pin through the Neo-6M Tx pin. The module itself has two main components: the Neo-6M module and the receiver. For optimal results, the receiver and module were mounted separately and above all other components with the white side facing up and the metallic side of the receiver facing down. While results were not perfect, it provided the most accurate and consistent results.

=== Software Design ===

==== LSM303 ====

For the LSM303, the compass required an initialization function to set all the registers. The slave address for writing to the LSM303 is 0x3D and to read from the registers is 0x3C. The data for the compass can be read from 6 8-bit registers, where X Y and Z axis are divided into high and low registers. The data is represented in two’s-complement where the conversion needed to be done after merging the two bytes together. As per the datasheet, the X axis is registers 3 and 4, where register 3 is the high byte and 4. The same goes for the Z axis which is registers 5 and 6, and Y is registers 7 and 8. After the raw coordinates are obtained, the calibration goes into effect.

{| class="wikitable"
|-
! scope="col"| LSM303 Slave Address
! scope="col"| Operation
|-
|0x3D
|Write
|-
|0x3C
|Read
|}

An example code sample for how we retrieved data can be seen below, where ret_data is a struct for the LSM303 data.
<syntaxhighlight lang="c">
ret_data.xMag = twos_complement(buffer[0], buffer[1]);
ret_data.yMag = twos_complement(buffer[4], buffer[5]);
ret_data.zMag = twos_complement(buffer[2], buffer[3]);

//CALIBRATION:
ret_data.xMag -=26;
ret_data.yMag +=244;

//Shifting
if(ret_data.yMag > 2)
ret_data.yMag -= 135;
if(ret_data.xMag < -42)
ret_data.xMag += 133;
</syntaxhighlight>

[[File:CANT_Localize_LSM303_Flowchart.png|thumb|300px|center|Figure 14: Compass Heading Calculation Flow]]

To calibrate the compass, the X and Y points were plotted while negating the Z axis. The Z axis was negated because the calibration of the compass requires that the compass be perfectly level. A sample of points were collected, and the plot can be seen below.

[[File:CANT_Localize_LSM303_plot1.png|thumb|300px|center|Figure 15: LSM303 raw data, no shifting, no calibration]]

To calibrate the compass, offsets were added such that the circle is centered at 0,0. The calibration was then added, and it looks like the plot below.

[[File:CANT_Localize_LSM303_plot2.png|thumb|300px|center|Figure 16: LSM303 X shifted down 50, Y shifted down 50]]

An additional feature that needed to be added was closing the gaps created from having the compass close to the car. Shifting was needed to close the circle when there were gaps in the calibration caused from the electronics of the car.

[[File:CANT_Localize_LSM303_plot3.png|thumb|300px|center|Figure 17: LSM303 data on car with gaps caused by electronics]]

After the points have been calibrated, an angle was formed from the point in relation to 0,0. The points go counter clockwise it goes in the order of North - 0, East - 90, South - 180, West - 270. The X and Y points were outputted to the CAN bus as a debug message and the compass direction was used for pathing.

[[File:CANT_Localize_LSM303_plot4.png|thumb|300px|center|Figure 18: Compass direction based on points]]

==== NEO-6M GPS ====

There are three main stages to collecting data from the Neo-6M GPS module. The first is to store the raw data into a string from the UART receive buffer. The second step is the verify the validity of the message and the string and store the different parts of the message into a struct if the message is valid. The final step is to verify the coordinates stored in the struct.

Message collection from the Neo-6M is handled through the UART library on the SJOne board. Two of the functions were used:
* '''is_Queue_Not_Empty()''' which returns the value of getRxQueueSize()
* '''gets()''' which stores the messages into a string and is ended through a timeout, reaching the final character of the string, or a new line character

Due to messages arriving once per second, these two functions were necessary. The '''is_Queue_Not_Empty()''' function only allows reading if a message is ready on the queue. This will prevent a message from being cut off due to timeout. Since every message is appended with a new line character, '''gets()''' will store the message into the buffer without storing parts of a new message.

For the second part of the GPS data collection, the [https://github.com/mikalhart/TinyGPSPlus/blob/master/src/TinyGPS%2B%2B.h Tiny GPS++] library was used. This provided us resources to parse and store the data from the various NMEA libraries. Furthermore, the library contains a TinyGPSCustom class which allows us to focus only on the $GPRMC messages. If a message was stored into a buffer, then this second part of GPS data collection occurred. The first step is to run the Tiny GPS++ function '''encode(char c)'''. This function passes in a char and stores it in a substring. Each substring is created after receiving a $ and is eventually checked once the * character was received. If the checksum passes, then the '''commit()''' function is called which stores all of the data in the string into a struct. The following shows an example of the $GPRMC message.

<syntaxhighlight lang="c">
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
</syntaxhighlight>

The fields of GPRMC are message time, current time in UTC, validity of GPS, latitude in degree-minute-second, north/south, longitude in degree-minute-sentence, east/west, speed over ground in knots, track angle, current date, magnetic variation, and checksum. Of these fields, the GPS validity, latitude, longitude, and checksum were used. When latitude and longitude are stored in the struct, they are converted into a decimal form from degree-minute-second.

The final part of the GPS data collection is to validate the latitude and longitude values obtained from the Tiny GPS++ library. Due to nuances with the string, it is possible to obtain values that are inconsistent with the current location. It is also possible to get a latitude and longitude of 0 if the validity of GPS field of the $GPRMC message had a V for void. The check was performed by the '''valid_coordinates(float latitude, float longitude)''' function and would only return true if the latitude was between 37 and 38 and if the longitude was between -122 and -121. Should these conditions meet, the coordinates were updated and the value is sent to the CAN bus. If they aren't meet, the old values remain the same until a validity check changes them.

[[File:CANT Localize Neo6M flowchart.png|thumb|300px|center|Figure 19: GPS Data Collection Flow]]

* 1Hz periodic
** Reset CAN Bus if Bus OFF
** getGPSData(); - Extract GPS data and place in GPS struct
** dbc_encode_DESIRED_VECTOR(); - Encode distance vector to CAN message
** dbc_encode_LOCALIZE_GPS(); - Encode GPS data to CAN message for Comms and Driver
** pack_compass_dbg(); - Pack compass data into CAN message
** CAN_tx(); - Send CAN Message

* 10Hz periodic
** call_compass(); - Extract Compass Heading and Magnetic Flux values of X and Y
** find_direction(); - Generate a heading and distance vector based on GPS and compass data

* 100 Hz periodic
** CAN_rx(); - Receive CAN message 500 if available for waypoint data

=== Technical Challenges ===
==== Compass Issues ====
* Issues with Calibration of LSM303
** The problem with the LSM303 and all digital compasses, is there is a lot of interference with magnetic fields in buildings that requires calibration for different environments. In addition, compasses do not come pre-calibrated as the strength of the North pole varies depending on location. To resolve this issue, we calibrated the compass in various locations. Our final calibration that we used and kept was the furthest away from any potential magnetic fields. Our selected location was on the top floor of the engineering building that was away from any lab rooms or elevators.

==== Unreliable GPS lock ====
* Obtaining Coordinates
** When attempting to obtain coordinates, the GPS module took several minutes in order to connect to a satellite and return coordinates. This process took more time if the GPS module was in a building or in a non-open area.
** Information from the GPS module was delivered at a rate of 1 Hz. When this information arrived, there were several possibilities such as $GPGGA, $GPGSV, and $GPRMC.
***Coordinates were only obtained when $GPRMC messages were sent and it yielded an Active (A) coordinate.
***There was no way to manipulate the GPS module to only send $GPRMC messages.

* Parsing Data
** All messages are appended with a new line "\r\n" at the end allowing it to be perfect candidates for the UART gets function. To help with consistency, the gets function was only called when there were characters in the queue to prevent the read from being timed out.
** Occasionally, some messages become cut off and merged with the next message. This skewed readings as commas were used to separate different sections of the data, including instances where $GPRMC was sent.
** To save resources, coordinates were only calculated when $GPRMC messages were sent with an (A) status message. This data is presented in a degree, minute, second format as opposed to the decimal format used by the SJOne and the mobile application. As a fail safe, converted coordinates were only saved and sent if the value yielded a latitude between 37 and 38 degrees and a longitude between -122 and -121 degrees.

<HR>
 

== Comms ECU & LCD ==
The [https://gitlab.com/cant-bus/cant-bus/tree/ajavier/commstomobile Comms module source code] includes the code for the ESP32 WiFi device and LCD display. Below is the block diagram for this module's connections.

[[File:CANT bus comms.png|thumb|400px|center|Figure 20: Comms module diagram with LCD]]

=== Hardware Design ===

==== LCD Display ====
The LCD display used is a 2.4" TFT display [https://www.adafruit.com/product/2478 made by Adafruit]. This display uses either the 8-bit or SPI protocol to transfer data. For this application, the SPI protocol was used in combination with an additional Data/Command line to distinguish between command packets (pulled low) or data packets (pulled high). The display is then connected via a controller that determines what pixels to activate and color. The controller itself uses the I2C protocol to communicate with the Comms board.

=== Software Design ===

==== ESP32 WiFi Module ====

On the side of the SJOne board, the UART library is primarily used to communicate with the ESP32. For incoming messages, the SJOne relies on two primary functions: '''getRxQueueSize()''' and '''gets()'''. The former checks to see if there are any incoming messages from the ESP32 while the latter stores the message into a string. To mitigate the possibility of a message getting truncated due to being read late, the board will only read if anything is present in queue. Once the message is read, it is parsed. There are three possible messages from the ESP32: start, stop, and coordinate data. The start is denoted by an 'A' character while the stop is denoted by a single 'Z' character. For coordinates, it is formatted like the message below

<syntaxhighlight lang="c">
37.575790|-122.049126
</syntaxhighlight>

The type of message is determined through reading the first character of the string. If the first character is a '3', then the SJOne reads it as coordinates and uses the '|' to separate latitude and longitude. Both latitude and longitudes are stored in substrings until the end when they are converted to float using '''atof()'''.

To simplify the use of web sockets, latitude, longitude, the status of a waypoint being reached, and a question mark are all sent. A sample of the message sent to the ESP is shown below.

<syntaxhighlight lang="c">
-121.881430w37.336863nO7.65?
</syntaxhighlight>

The first field is longitude and then followed by 'w' for west. The next field is latitude followed by an 'n'. The third field is an O or N. This represents if a waypoint is reached with O meaning waypoint not reached and N representing a waypoint is reached. The status is determined if the distance is below 5 meters. All of this information is retrieved from the CAN bus and is appended together using the '''sprintf()''' function.

==== LCD Display ====
The main elements we wanted to be able to see on the car were speed and destination. Destination is displayed in Lat/Long decimal degree coordinates and speed is in kilometers per hour. In addition, we also show the distance between our car and the destination and our current heading from due north. Due to the complexity of the display, each pixel requires about 7 bytes to activate, the possibility of overrunning the scheduler was high. As such, a controller was inserted to perform the actual data transfer to write pixels. The Comms module simply tells the controller what to update, via I2C, from the 1Hz periodic function. To make writing pixels a little easier, the [https://github.com/adafruit/Adafruit-GFX-Library Adafruit GFX Library] was used to create fonts, lines, and the triangles used to mimic a compass.

[[File:CANT bus display.jpg|thumb|400px|center|Figure 21: LCD display]]

There are five basic functions used to update the display, four are used to set values to a data struct and the fifth sends the data over I2C:
* '''set_display_waypoint()''' - packages the latitude and longitude destination struct values as a C-string
* '''set_display_speed()''' - packages the car's current speed struct value in a C-string.
* '''set_display_distance()''' - packages the distance remaining between the car and the destination in a C-string
* '''set_display_arrow()''' - selects which heading arrow the display should draw: N, S, E, W, NW, NE, SW, or SE
* '''updateDisplay()''' - sends the full struct that has been prepared by the above functions over I2C

=== Technical Challenges ===

==== LCD Issues ====
Originally the plan was to use a 2.2" TFT display by QVGA. This display had been used in previous projects before, however, in this project there was nothing but problems. The SPI communication from the SJOne board was not being received or sent by the display. When testing on a known board and the Adafruit library, the SPI comms would respond, but nothing would actually display on the screen. Assuming this particular display had been compromised, additional displays were purchased with the same results. After much Googling and more research, it turned out that this particular display is known for failures and inconsistencies. The Adafruit display was the original the QVGA was based on. Once that was purchased and tested, there were no further issues, both SPI communications and the display worked fine.

<HR>
 

== Driver Module ==

Driver module source code can be found on [https://gitlab.com/cant-bus/cant-bus/tree/driver/ GitLab here].

=== Hardware Design ===

With respect to hardware, the DRIVER ECU design has very little going on. Other than the CAN transceiver, the only anticipated components were level-shifting operational amplifiers that would have served the purpose of providing voltage readings. Although designed, we decided to forego implementation for a simpler solution: battery indicator buzzers that will alert us if any cell of the Lithium Polymer batteries we use approach the fatal 3.0V voltage.

=== Software Design ===

The main purpose of the DRIVER ECU is to fuse the information AVOIDANCE and LOCALIZE, in order to inform MOTOR of the necessary steering and motor commands to assert on the steering servo motor and the brushed DC electric drive motor. The following diagrams informs you on at a high level on how the information is gathered from each of those ECUs, then fed to DRIVER.

LOCALIZE: 
[[File:CANT Bus Logic - Localize.png]]

AVOID: 
[[File:CANT Bus Logic - Avoidance.png]]

DRIVER: 
[[File:CANT Bus Logic - Driver.png]]

Given the premise established in these diagrams, we wish to
1. translate the avoidance data into a set of permissible (or, in other words, admissible) velocities
2. use the heading and distance information to inform us on how to prioritize the velocities. As in, if the desired heading is straight ahead, we will prefer the forward velocity over all others.
3. assert the velocity - this is the motor_cmd value we send to MOTOR

From this premise, we describe the key routine calls within our periodic function:

* 100Hz periodic
** check_CAN_messages() - as the name suggests, this function checks the registers to see if any CAN messages were received and pulls the needed data from them.

* 10Hz periodic
** determine_admissible_velocities() - based on the proximity sensor information from AVOID, determine whether traversal is feasible. If not, nullify the velocity for this 10Hz time slice.
** determine_system_state() - determine the mode and directionality for this time slice:
*** this can be IDLE, which informs the system that there are no waypoints being serviced
*** STOP, which informs that the car is currently stopped but is servicing a waypoint,
** and the directionalities: FORWARD_MID, FORWARD_LEFT, FORWARD_RIGHT for forward directions, and
*** REVERSE_MID, REVERSE_LEFT, and REVERSE_RIGHT
** choose_velocity_by_preference_order() - based on the state determined above, we can refer to a preset list of preferences for our directionality. From this, we select the best available velocity for this timeslice.
** set_velocity() - send the selected velocity (or non-velocity) to MOTOR

* 1Hz periodic
** set_manual() - checks if manual mode has been selected, this is mostly used for testing and resetting to a known state.
** send_reset() - checks the status of CAN and if it needs to be, resets the bus
** set_heartbeat() - sends out a blank message to keep all the other modules in check

=== Technical Challenges ===

The biggest challenge we faced was the vector array algorithm as it involved a lot of math that some of us hadn't touched in many years. Eventually we were able create an algorithm what was able to take all the proximity values and plot a course of action to avoid objects while still maintaining a heading to our final destination.

In fact, we attempted several iterations of the Dynamic Window Approach[https://en.wikipedia.org/wiki/Dynamic_window_approach] popularized by Sebastian Thrun, et al[https://www.researchgate.net/publication/3344494_The_Dynamic_Window_Approach_to_Collision_Avoidance]. At each phase, we had reduced our window size, until what we were left with was one speed forward, one speed back, and one direction to either side (no fractional angles for steering commands). This left us with an unstable platform (as you can see from the left-right zigzags where you would expect smooth forward motion. Perhaps it would have been better had we
1. Started with this as a base case, and expanded from there, and
2. Ran simulations

<HR>
 

== Mobile Application and ESP32==
[https://github.com/vijayvanapalli96/Final243App FinalAppPackage]
=== Hardware Design ===
The App and the Car are connected via wifi and through the means of ESP32. The ESP32 can perform as a complete standalone system or as a slave to a host MCU, reducing communication stack overhead on the main application processor. Here, the ESP32 is being used as a host that sets up a webserver on a desired wifi connection. The wifi connection is provided by the user’s shared hotspot. The credentials of these are to be entered within the source code of the application.

Once the web server has been set up, both the ESP32 (on behalf of the SJOne board) and the App can publish messages to the web server as needed, through the means of websockets. WebSocket is a computer communications protocol providing full-duplex communication channels over a single TCP connection. The ESP32 receives a string via UART from the SJOne until a specified delimiter to differentiate between multiple messages. This string is published to the server, for the app to echo and read as necessary.

=== Software Design ===
The Mobile Application is tasked with utilizing Google Maps API, essentially acting as a UI between the user and the car. It relays the current position of the car, or allows the user to set the starting point of the car as needed - since the given point is a draggable. Similarly the destination is marked with a similar marker, which when on holding down gives the relevant descriptions of each point.

The next challenge came with being able to track the current trajectory of the car. Therefore the set objectives, was to have the set marker track the position of the car in real time, along with the refresh rate of the GPS. In this case since the GPS coordinates are being updated in the 1 Hz task, therefore a handler function is enlisted in its design that periodically checks the debug info being relayed back and forth between the Car and the App.

In order to navigate between the start and the stop point, we have to calculate the shortest possible distance between the two points. While this may be possible with just a simple distance formula, we still have to take on sample waypoints in anticipation of large obstacles or to follow a set road. This is done by creating a graph, wherein the points are labeled either according to their index or a set naming convention, and distances between these points define the cost of traversing that particular edge.

=== Technical Challenges ===
Initially, the idea was to have the ESP32 publish a webpage at a specific IP Address that the phone may access with inline buttons to further act a UI. However this was very flawed in its approach as it meant accessing web pages and not utilizing or designing UI. HTML buttons as is would open more such webpages which would become redundant and difficult to manage, especially with reusing buttons.

Websockets as a resource are limited and need to be managed efficiently so as to not lose count of the number of active websockets. As the app and the websocket server keeps running for a long time (20 minutes and over) we find a significant lag and backlog of messages being stored on the server before being published on the receivers end.
The ESP8266 and the ESP32 can only hold up to 4 websockets at a time. This is important to note since we encountered a problem where we would use up all the 4 resources simultaneously to send debug messages to the app from the car, while leaving no room for error or overflow. If overflow of resources does occur then the resources are stuck in an infinite loop and are left inaccessible. The work around to this problem is to use 2 resources only, each allocated to either device viz the host ESP32 and the client App. The resources are withheld during their use but disconnected upon reading the message so that they do not populate.

When running the dijkstra algorithm on a complete graph, the app essentially takes into consideration all the specified weights, including the distance between the start and destination point which is always a straight line and thus always the shortest path. This is an undesirable result, hence one work around to this is to populate the graph less often rather than calculating all possible distances. Eventually it was easier to set all the distances between different points as the maximum possible traversable distance and then manually add legible and realistic distances as per CalcDistance(). Once this newer doctored graph is fed through Dijkstra’s algorithm we get a reasonable traversable path for the car to follow.

<HR>
 

== Conclusion ==
Over the course of this project, we learned about the importance of planning and communication while working in a large group. The difficulties of coordinating so many people was mitigated slightly by having multiple meetings during the week. Each member was encouraged to go to as many of those meetings as possible. Some were able to make it to all while others could only make it to 2 or 3. This allowed some continuity in combining all the modules together. We learned about CAN bus protocol and how powerful of a tool it can be. The importance of unit testing was stressed as well and we learned effective ways to test each line of code as we designed the modules. This project gave us hands on experience with working with others to complete a united goal of building a RC car. Although we had some difficulties with scheduling meetings due to our different schedules - we managed to coordinate in person and on our Slack channel. Our project was to design and build an autonomous RC car that would travel to a selected GPS coordinate while passing through checkpoints and avoiding obstructions. Although our RC car did not quite reach the mark that we were expecting, much was learned from this experience that we can use in our future projects and industry jobs.

=== Project Video ===

[https://www.youtube.com/watch?v=w9LZ2Fikxn0&feature=youtu.be Link]

=== Project Source Code ===
https://gitlab.com/cant-bus/cant-bus

=== Advise for Future Students ===
* Form your team and start as EARLY as possible
* Buy spare parts, things will break when you least expect them to happen
* Don't wait to the last minute for full integration
* Buy quality parts rather than cheaper alternatives

=== Acknowledgement ===
We would like to thank Preetpal Kang for providing us the opportunity to learn about the CAN bus protocol and how to integrate it into an embedded system. We'd also like to thank our team leader, Nelson, for keeping us on task and always being there to help and provide counsel whenever it was needed.
=== References ===
[1] [https://stanford.edu/class/ee267/misc/MPU-9255-Register-Map.pdf MPU-9255 Data Sheet]

[2] [https://stanford.edu/class/ee267/misc/MPU-9255-Register-Map.pdf MPU-9255 Register Map]

[3] [https://www.akm.com/akm/en/file/datasheet/AK8963C.pdf Magnetometer Data Sheet]

[4] [https://cdn-shop.adafruit.com/datasheets/LSM303DLHC.PDF LSM303 Data Sheet]

Lab Assignments

2019-03-11T18:51:49Z

Preet:

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; left:0.25%; padding:0; margin:0;">
[[#top|Back to the Top]]
</div>

= Hello World =

=== Assignment ===
*Get the development environment from sourceforge.
: '''[https://sourceforge.net/projects/armdevpkg/files/: SourceForge SJSU Development Package]'''

*Compile a sample FreeRTOS sample project

*Load it onto the processor

*Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

= LED Switch =

=== Assignment ===

Work in groups of 2 and use existing API under '''gpio.hpp''':

* Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
* Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
* Connect the LED Board and SW Board together using "Port 2"
*: Example: P2.0 of LED board connects to P2.0 on the SW Board
*: Do not forget common ground
* LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
* On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
*: The callback should simply turn a flag (global variable) to true
*: The callback '''''MUST NOT POLL''''', and '''''MUST NOT DELAY''''', and '''''EXIT IMMEDIATELY''''' since it is an interrupt function
*: Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
* On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
*: Turn on the periodic scheduler at main.cpp
*: Deploy your code to periodic_callbacks.cpp (like 10Hz function)
* Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
*: Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
*: '''[https://www.youtube.com/watch?v=grXuVMttVuU: Binary Semaphores]'''

For the demo:
* The SW Board should detect its switch press by an external interrupt and toggle its P2.0
* The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp
Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

= Form Groups =

=== Assignment ===

Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in '''''zero points''''' for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

= Serial Communication =

=== Assignment ===

Use either UART2 or UART3 to communicate between two boards. You can work in groups of 2.

* Locate the UART pins on your board.
*: Use the schematic or Wikipedia board article.
* Interface to the UART pins on someone else's board.
*: If you use UART2, you cannot use UART2 on the 2nd board (use UART3 instead).
* Prove that both of your boards and communicate with each other.
* Bonus points for doing something creative, such as one board acting like a random sensor, and the second board outputting the sensor reading on the LED display.
* This assignment demonstrates how to communicate with another device using UART. The UART driver is based on queues, there is no need to poll for data to arrive, or for data to be sent. Size your queues appropriately and they shouldn't be too large or too small. For example, if you service the received data every 100ms, then your queues should only need to be as big as the number of characters you expect to receive within 100ms (38400bps can provide 400 chars in 100ms).

Turn in ONE SUBMISSION per group with the following:
* Only turn in the relevant source code, such as main.cpp for both boards

= Unit Testing =

Perform the "Lab 1" exercise here:
[https://gitlab.com/sibros_public/public/wikis/c/unit_tests#lab-1]

= Project Setup =

=== Assignment ===

Setup your Project Report Template:

* Go to your class webpage:
*: [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus CmpE 243 Home Page]
* There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
*: Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
*: Rename one of these bullet points to your project name (use a wise name for your project):
*: Tag your project with "F17" or similar, such as:
*: <nowiki>[[F17: Spartan and Furious | F17: Spartan and Furious]]</nowiki>
*: Click to save this page
* In a separate window, [http://socialledge.com/sjsu/index.php/Autonomous_RC_Car_Project_Report_Template browse to this page], click "Edit" and COPY the entire Wikipedia markup
*: Now click on the red link that belongs to your project
*: Paste this template for your project, and work on setting weekly goals in your schedule section.
*: Save the template
* Now go back to your project's Wiki page, click "EDIT"
*: Add information about the team members
*: Add a link to your GITLAB project and add users who can access your project:
*: My GITLAB username is simply, "'''preet'''"

= CAN Communication =

=== Assignment ===

You can work in groups of 2:

*Build and interface the CAN transceiver with another person's CAN transceiver.
*Initialize the CAN Bus (read can.h in the drivers directory).
*Use a simple periodic message (every 100ms) that is sent from BoardA to BoardB.
*: For example, if BoardA senses a switch pressed, send a 1-byte message with 0xAA, otherwise send 0x00 if button is not pressed
*For robustness, if the CAN Bus turns off, simply turn it back on at 1Hz (every 1000ms)
*On BoardB, simply light up an LED (or otherwise turn it off) based on the CAN message data

This assignment gives you an overview of practical use of the CAN Bus, and later, by utilizing the DBC file and auto-generation of code, sending and receiving data becomes very easy.

While this provides bare bones knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages' data encoding and decoding.

Although the real-time periodic scheduler was not discussed, it might be worth your time to simply turn it on (using #define) since it can help you send periodic messages fairly easily. This will also help you prepare in advance for the future lectures.

Only turn in the relevant source code, such as main.cpp for both boards.

= Wiki Schedule =

=== Assignment ===

Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

= Periodic Scheduler =

=== Assignment ===

INDIVIDUAL HOMEWORK:

Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

*Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
*Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
*Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
*: In the 10Hz callback, design a Software filter to filter the Light sensor readings
*: In the 1Hz callback, print out the filtered sensor reading.
*Do more experiments with the "Logging" capability
*: Log some data using LOG_INFO() or similar message from file_logger.h
*Use "info 5000" command to see CPU utilization for 5 seconds.
*Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

= CAN TX / RX using Auto-gen code =

=== Assignment ===

Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

*Define a DBC message that your controller sends (TX)
*Define a DBC message that your controller receives (RX)
*Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
*Send the TX message from BoardA at a fixed frequency, such as 10Hz
*Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
*Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
*Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

= Final Wiki Schedule =

= DBC File =

=== Assignment ===

Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

= CAN Communication Demo =

=== Assignment ===

Demonstrate that each ECU is able to communicate over the CAN Bus

*Code should utilize the auto-generated artifacts from the DBC file
*MIA handling should occur on the messages that are expected to be received
*: Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

= Producer / Consumer Tasks =

=== Assignment ===

*Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
*Create a queue, and have the first task send orientation values every second to the queue.
*: Print something BEFORE and AFTER sending the enumeration value to the queue.
*Create a task that is waiting on the orientation enumeration to be sent by the previous task.
*: Print something immediately after the second task receives the data from the queue.
*Use same priority for both tasks and note down the print-outs.
*Alter the priority of second task to use higher priority, and note down the print-outs
*: Note down your results, and submit it at the top of your code submission.

= Project Prototypes =

=== Assignment ===

Project prototypes are expected to demonstrate the following:

*Reliable CAN communication between different ECUs
*Basic obstacle avoidance (free-run mode)
*Reliable sensor inputs (PCAN will be used by class mentors to assess)
*Reasonable motor commands (PCAN will be used by class mentors to assess)
*Extra credit if you go above and beyond and show even more progress such as a working Android app

= Git =

=== Assignment ===

Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

= Individual Contribution =

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".

Example:

Name Letter Grade Notes
Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings.
Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

Autonomous RC Car Project Report Template

2019-03-11T18:49:39Z

Preet: Created page with "== Project Title == <Team Name> == Abstract == <2-3 sentence abstract> === Introduction === The project was divided into N modules: * Sensor ... * Motor.. * ... * Android..."

== Project Title ==
<Team Name>

== Abstract ==
<2-3 sentence abstract>

=== Introduction ===

The project was divided into N modules:

* Sensor ...
* Motor..
* ...
* Android

=== Team Members & Responsibilities ===
<Team Picture>

Gitlab Project Link - [https://gitlab.com/...]
 

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

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
| 09/15/2017
| 09/16/2017
|
* Read previous projects, gather information and discuss among the group members.
* Distribute modules to each team member.

| Completed
|-
! scope="row"| 2
| 09/17/2017
| 10/03/2017
|
|
|-
|}

== Parts List & Cost ==
{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Qty
! scope="col"| Cost
|-
! scope="row"| 1
| RC Car
| Traxxas
| 1
| $250.00
|-
! scope="row"| 2
| CAN Transceivers MCP2551-I/P
| Microchip [http://www.microchip.com/wwwproducts/en/en010405]
| 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>

<HR>
 
== Sensor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable sonor sensors ====
<Problem Summary>
<Problem Resolution>

<HR>
 
== Motor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable Servo Motors ====
<Problem Summary>
<Problem Resolution>

<HR>
 
== Geographical Controller ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Unreliable GPS lock ====
<Problem Summary>
<Problem Resolution>

<HR>
 
== Communication Bridge Controller & LCD ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Insane Bug ====
<Problem Summary>
<Problem Resolution>

<HR>
 
== Master Module ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Improper Unit Testing ====
<Problem Summary>
<Problem Resolution>

<HR>
 
== Mobile Application ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

<Bullet or Headings of a module>
==== Wifi Link Reliability ====
<Problem Summary>
<Problem Resolution>

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

Industrial Application using CAN Bus

2019-03-11T18:28:43Z

Preet:

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

Lab Assignments

2019-02-21T23:20:44Z

Preet: /* Unit Testing */

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; left:0.25%; padding:0; margin:0;">
[[#top|Back to the Top]]
</div>

= Hello World =

=== Assignment ===
*Get the development environment from sourceforge.
: '''[https://sourceforge.net/projects/armdevpkg/files/: SourceForge SJSU Development Package]'''

*Compile a sample FreeRTOS sample project

*Load it onto the processor

*Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

= LED Switch =

=== Assignment ===

Work in groups of 2 and use existing API under '''gpio.hpp''':

* Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
* Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
* Connect the LED Board and SW Board together using "Port 2"
*: Example: P2.0 of LED board connects to P2.0 on the SW Board
*: Do not forget common ground
* LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
* On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
*: The callback should simply turn a flag (global variable) to true
*: The callback '''''MUST NOT POLL''''', and '''''MUST NOT DELAY''''', and '''''EXIT IMMEDIATELY''''' since it is an interrupt function
*: Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
* On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
*: Turn on the periodic scheduler at main.cpp
*: Deploy your code to periodic_callbacks.cpp (like 10Hz function)
* Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
*: Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
*: '''[https://www.youtube.com/watch?v=grXuVMttVuU: Binary Semaphores]'''

For the demo:
* The SW Board should detect its switch press by an external interrupt and toggle its P2.0
* The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp
Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

= Form Groups =

=== Assignment ===

Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in '''''zero points''''' for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

= Serial Communication =

=== Assignment ===

Use either UART2 or UART3 to communicate between two boards. You can work in groups of 2.

* Locate the UART pins on your board.
*: Use the schematic or Wikipedia board article.
* Interface to the UART pins on someone else's board.
*: If you use UART2, you cannot use UART2 on the 2nd board (use UART3 instead).
* Prove that both of your boards and communicate with each other.
* Bonus points for doing something creative, such as one board acting like a random sensor, and the second board outputting the sensor reading on the LED display.
* This assignment demonstrates how to communicate with another device using UART. The UART driver is based on queues, there is no need to poll for data to arrive, or for data to be sent. Size your queues appropriately and they shouldn't be too large or too small. For example, if you service the received data every 100ms, then your queues should only need to be as big as the number of characters you expect to receive within 100ms (38400bps can provide 400 chars in 100ms).

Turn in ONE SUBMISSION per group with the following:
* Only turn in the relevant source code, such as main.cpp for both boards

= Unit Testing =

Perform the "Lab 1" exercise here:
[https://gitlab.com/sibros_public/public/wikis/c/unit_tests#lab-1]

= Project Setup =

=== Assignment ===

Setup your Project Report Template:

* Go to your class webpage:
*: [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus CmpE 243 Home Page]
* There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
*: Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
*: Rename one of these bullet points to your project name (use a wise name for your project):
*: Tag your project with "F17" or similar, such as:
*: <nowiki>[[F17: Spartan and Furious | F17: Spartan and Furious]]</nowiki>
*: Click to save this page
* In a separate window, [http://www.socialledge.com/sjsu/index.php?title=Sample_Project_Report browse to this page], click "Edit" and COPY the entire Wikipedia markup
*: Now click on the red link that belongs to your project
*: Paste this template for your project, and work on setting weekly goals in your schedule section.
*: Save the template
* Now go back to your project's Wiki page, click "EDIT"
*: Add information about the team members
*: Add a link to your GITLAB project and add users who can access your project:
*: My GITLAB username is simply, "'''preet'''"

= CAN Communication =

=== Assignment ===

You can work in groups of 2:

*Build and interface the CAN transceiver with another person's CAN transceiver.
*Initialize the CAN Bus (read can.h in the drivers directory).
*Use a simple periodic message (every 100ms) that is sent from BoardA to BoardB.
*: For example, if BoardA senses a switch pressed, send a 1-byte message with 0xAA, otherwise send 0x00 if button is not pressed
*For robustness, if the CAN Bus turns off, simply turn it back on at 1Hz (every 1000ms)
*On BoardB, simply light up an LED (or otherwise turn it off) based on the CAN message data

This assignment gives you an overview of practical use of the CAN Bus, and later, by utilizing the DBC file and auto-generation of code, sending and receiving data becomes very easy.

While this provides bare bones knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages' data encoding and decoding.

Although the real-time periodic scheduler was not discussed, it might be worth your time to simply turn it on (using #define) since it can help you send periodic messages fairly easily. This will also help you prepare in advance for the future lectures.

Only turn in the relevant source code, such as main.cpp for both boards.

= Wiki Schedule =

=== Assignment ===

Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

= Periodic Scheduler =

=== Assignment ===

INDIVIDUAL HOMEWORK:

Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

*Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
*Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
*Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
*: In the 10Hz callback, design a Software filter to filter the Light sensor readings
*: In the 1Hz callback, print out the filtered sensor reading.
*Do more experiments with the "Logging" capability
*: Log some data using LOG_INFO() or similar message from file_logger.h
*Use "info 5000" command to see CPU utilization for 5 seconds.
*Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

= CAN TX / RX using Auto-gen code =

=== Assignment ===

Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

*Define a DBC message that your controller sends (TX)
*Define a DBC message that your controller receives (RX)
*Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
*Send the TX message from BoardA at a fixed frequency, such as 10Hz
*Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
*Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
*Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

= Final Wiki Schedule =

= DBC File =

=== Assignment ===

Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

= CAN Communication Demo =

=== Assignment ===

Demonstrate that each ECU is able to communicate over the CAN Bus

*Code should utilize the auto-generated artifacts from the DBC file
*MIA handling should occur on the messages that are expected to be received
*: Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

= Producer / Consumer Tasks =

=== Assignment ===

*Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
*Create a queue, and have the first task send orientation values every second to the queue.
*: Print something BEFORE and AFTER sending the enumeration value to the queue.
*Create a task that is waiting on the orientation enumeration to be sent by the previous task.
*: Print something immediately after the second task receives the data from the queue.
*Use same priority for both tasks and note down the print-outs.
*Alter the priority of second task to use higher priority, and note down the print-outs
*: Note down your results, and submit it at the top of your code submission.

= Project Prototypes =

=== Assignment ===

Project prototypes are expected to demonstrate the following:

*Reliable CAN communication between different ECUs
*Basic obstacle avoidance (free-run mode)
*Reliable sensor inputs (PCAN will be used by class mentors to assess)
*Reasonable motor commands (PCAN will be used by class mentors to assess)
*Extra credit if you go above and beyond and show even more progress such as a working Android app

= Git =

=== Assignment ===

Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

= Individual Contribution =

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".

Example:

Name Letter Grade Notes
Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings.
Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

Industrial Application using CAN Bus

2019-02-20T04:39:27Z

Preet: /* Class Project Reports */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

== Class Project Reports ==

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: Tech Savy | F19: Tech Savy]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

F18: Flappy Bird

2018-10-10T02:37:28Z

Preet: /* Schedule */

F18: Flappy Bird

2018-10-10T02:35:25Z

Realtime OS on Embedded Systems

2018-10-10T02:33:37Z

Preet: /* Fall 2018 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]
* [[F18: Catch me if you can]]

 

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Realtime OS on Embedded Systems

2018-10-10T02:33:08Z

Preet:

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial Tasks | Lesson 0: Multiple Tasks]]
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==== Class Project ====
* [[MP3 Player]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===

=== [[Fall 2018 | Fall 2018]] ===

* [[F18: Flappy Bird]]

=== [[Spring 2018 | Spring 2018]] ===

* [[S18: Team Nemesis(SJSU Cam)]]
* [[S18: Death Race]]
* [[S18: Hand gesture controlled multiplayer game]]
* [[S18: Smart Rock Paper Scissors]]
* [[S18: Spybot]]
* [[S18: Audio Spectrum Analyzer with Graphics Display]]
* [[S18: XY-Plotter]]
* [[S18: RGB LED Sound Behavior on a Skateboard]]
* [[S18: Spark - MP3 Music Player with Audio Spectrum]]
* [[S18: Traffic Menace Video Game]]
* [[S18: M.E.O.W]]
* [[S18: Rahee]]

=== [[Spring 2017 | Spring 2017]] ===

* [[S17: Wake up Barista]]
* [[S17: Propeller Clock]]
* [[S17: Sky Knight]]
* [[S17: MyAutoHealth]]
* [[S17: Logan]]
* [[S17: ElectricBoard]]
* [[S17: CamBot]]
* [[S17: Sphero Droid]]
* [[S17: Smart Planter]]
* [[S17: Boom-Z Equalizer]]
* [[S17: Interactive Snake and ladder ]]
* [[S17: Smart Health Gear]]
* [[S17: Halo]]
* [[S17: Squad]]
* [[S17: Smart security system]]
 

=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

VM Development Package

2018-08-30T04:28:29Z

Preet:

=== Download ===
* [https://sourceforge.net/projects/armdevpkg/files/virtualbox_experimental Download this virtual hard disk] file from Sourceforge
* Unzip the virtual hard disk to somewhere safe and permanent, such as '''C:/Documents/sjsu_vm/'''

=== Setup VM on VirtualBox ===
* Download and install '''VirtualBox''' for your operating system (Windows, MacOS etc.)
* Install and run '''VirtualBox'''
* Click on '''NEW'''
* Give your VM (virtual machine) a name
* Select the '''Type''' as '''Linux'''
* Select '''Version''' as '''Ubuntu (64-bit)''' and click '''Continue'''
* Choose 2560 or more MB of RAM and click '''Continue'''
* Choose '''Use an existing virtual hard disk file''' and browse to the VM disk you downloaded, and then click '''Create'''

=== Configure VM ===
* Click on the VM you created in VirtualBox, then click '''Settings'''
* Go to '''Advanced''' and under '''Shared Clipboard''', select '''Bidirectional'''
* Click on '''System''' and ensure 2560 Mbytes (2.5 GBytes) or greater RAM (assuming your laptop has at least 8 Gbytes or so
* If your system allows, use 2 CPUs under '''Processor'''
* Under '''Display''' use '''128Mbytes''' of RAM
* Under '''Audio''', de-select to disable Audio

=== Setup COM port on VM ===
* Start your Ubuntu OS
* Plugin your USB cable to the board and ensure your board has power
* After the system boots, go to '''Devices''' on VirtualBox menu, then '''USB''' and select the USB board to virtually plug into the VM

=== Use Development Environment ===
* Open the '''SJSU_dev''' folder when the Ubuntu VM boots
* Double click on '''run_eclipse''' to start Eclipse IDE
* Develop your code and hit '''Ctrl + B''' to compile in Eclipse
** Ensure the program has compiled successfully
* Right click anywhere (but not on a file) in '''SJSU_dev''' folder and then click on '''Open terminal'''
* Type '''sudo ./run_flash''' to program the compiled HEX file to the board
** Note that this assumes you have a file built at '''projects/lpc1758_freertos/_build/lpc1758_freertos.hex'''
** Note that this assumes your serial port is at '''/dev/ttyUSB0'''
** If the assumptions above are not true, you can edit the '''run_flash''' file

=== Be an Engineer ===
* Figure out how to use '''Minicom''' on your own
** This will let you open up the serial port and interact with your board and see the Board's output data from printf()

VM Development Package

2018-08-30T04:27:13Z

Preet:

VM Development Package

2018-08-30T04:26:12Z

Preet:

=== Download ===
* [https://sourceforge.net/projects/armdevpkg/files/virtualbox_experimental Download this virtual hard disk] file from Sourceforge
* Unzip the virtual hard disk to somewhere safe and permanent, such as '''C:/Documents/sjsu_vm/'''

=== Setup VM on VirtualBox ===
* Download and install '''VirtualBox''' for your operating system (Windows, MacOS etc.)
* Install and run '''VirtualBox'''
* Click on '''NEW'''
* Give your VM (virtual machine) a name
* Select the '''Type''' as '''Linux'''
* Select '''Version''' as '''Ubuntu (64-bit)''' and click '''Continue'''
* Choose 2560 or more MB of RAM and click '''Continue'''
* Choose '''Use an existing virtual hard disk file''' and browse to the VM disk you downloaded, and then click '''Create'''

=== Configure VM ===
* Click on the VM you created in VirtualBox, then click '''Settings'''
* Go to '''Advanced''' and under '''Shared Clipboard''', select '''Bidirectional'''
* Click on '''System''' and ensure 2560 Mbytes (2.5 GBytes) or greater RAM (assuming your laptop has at least 8 Gbytes or so
* If your system allows, use 2 CPUs under '''Processor'''
* Under '''Display''' use '''128Mbytes''' of RAM
* Under '''Audio''', de-select to disable Audio

=== Setup COM port on VM ===
* Start your Ubuntu OS
* Plugin your USB cable to the board and ensure your board has power
* After the system boots, go to '''Devices''' on VirtualBox menu, then '''USB" and select the USB board to virtually plug into the VM

=== Use Development Environment ===
* Open the '''SJSU_dev''' folder when the Ubuntu VM boots
* Double click on '''run_eclipse''' to start Eclipse IDE
* Develop your code and hit '''Ctrl + B''' to compile in Eclipse
** Ensure the program has compiled successfully
* Right click anywhere (but not on a file) in '''SJSU_dev''' folder and then click on '''Open terminal'''
* Type '''sudo ./run_flash''' to program the compiled HEX file to the board
** Note that this assumes you have a file built at '''projects/lpc1758_freertos/_build/lpc1758_freertos.hex'''
** Note that this assumes your serial port is at '''/dev/ttyUSB0'''
** If the assumptions above are not true, you can edit the '''run_flash''' file