Final Presentation

Description

Presentations of the projects are given a few days after the Final Demo to an audience of fellow student reviewers, the lab instructors, and occasionally faculty or even students from outside the class who are following up a project of personal interest to them. The style is formal and professional, and students should dress accordingly (Generally business professional, or what you would wear to a career fair).

Requirements and Grading

Each project team has 25 minutes for a Powerpoint presentation and questions. Every group member must present their own work contributing to the project and be ready to answer questions. Presentations are judged on the basis of presentation technique and of technical organization and content.

Presentation technique includes dress, use of display materials (slides), clarity of speech, absence of filler words/fidgeting, proper eye contact with audience and smooth transitions between speakers. Content is judged on use of a proper introduction, orderly and connected development of ideas, absence of unnecessary details, proper pacing to stay within the allotted time, and an adequate summary at the close of the talk. Quantitative results are expected whenever applicable. Here is a general outline to follow:

  1. Introduction to your team and your project.
  2. Objective. What problem are you solving?
  3. Brief review of original design, statement on areas of design that changed, and overview of each functional block's requirements.
  4. Description of project build and functional test results. You can choose to include a short (30s) video of your project here.
  5. Discussion of successes and challenges, as well as explanations of any failed verifications demonstrating and understanding of the engineering reason behind the failure
  6. Conclusions from the project: what did you learn, what would you do differently if you redesigned your project, etc.
  7. Recommendations for further work.

Any significant, relevant ethical issues should be briefly addressed, preferably in a single slide.

Presentations will be graded using the presentation grading rubric. Your slides should follow ECE or College of Engineering presentation theming.

Submission and Deadlines

Slides for your final presentation must be uploaded to your project page on PACE prior to your presentation time. Deadlines for signing up may be found on the Calendar. Sign-up for the final presentation is done through PACE. Remember to sign up for a peer review of another group.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.