Final Demo :: ECE 445 - Senior Design Laboratory

Final Demo

Description

The Final Demo is the single most important measure (and assignment) for the success of your project. The evaluation is holistic, focused on whether your project is completed, well-designed, reliable, and usable. You will demo your project to your professor, at least one TA, and a few peer reviewers. Other guests (e.g. alumni, high school students, sponsors, or other department affiliates) may also be present.

Requirements and Grading

Students must be able to demonstrate the full functionality of their project by proving that all the requirements in their Requirements and Verification (RV) table are met. Students must bring a printed out version of their block diagram, high level requirements, and RV table. Credit will not be given for feature which cannot be demonstrated.

For tests that are lengthy or require equipment not available at the time of demo, students should have their lab notebooks or printouts ready to show testing data. For any portion of the project which does not function as specified, students should have hypotehses (and supporting evidence) of what is causing the problem. If your demo needs to happen somewhere that is not the Senior Design Lab, you must communicate this with your TA!

The design team should be ready to justify design decisions and discuss any technical aspect of the project or its performance (not just one's own responsibilities). Quantitative results are expected wherever applicable. The demo grade depends on the following general areas: See the Demo Grading Rubric for specific details, but in general, show the following:

  1. Completion: The project has been entirely completed.
  2. Integration: The project is well-integrated, looking more like a final product than a prototype.
  3. Performance: Performance is completely verified, and operation is reliable.
  4. Understanding: Everyone on the project team must must be able to demonstrate understanding of his/her technical work and show that all members have contributed significantly.
  5. Polish & Attention to Detail: The project is well-polished with the user in mind. Good attention to detail is afforded to useability, presentation, and packaging.

 

Submission and Deadlines

Signing-up for a demo time is handled through the PACE system. Again, remember to sign up for a peer review as well.

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.