P18075: Smart Device - Integrated Baby Jumper
/public/

Customer Handoff & Final Project Documentation

Table of Contents

Team Vision for Final Demo and Handoff

Plans for Final Phase

Team Accomplishments

Current State of Jumper

The jumper now has increased the number of switches available for the baby to interact with from one to five. Each switch initiates a unique light pattern in the main base and toys. These ten LEDs are an increase from the original three. The main platform on the jumper now offers 4 levels of volume control over the song playing, ability to switch between two modes (continuous play and interactive), and next track selection. It also includes provisions to allow for pause/play control on the app.

A video of the jumper functioning using the controls on the main module can be downloaded here.

Below are pictures showing the electrical components that are now contained within the main module of the jumper:

public/Customer Handoff and Final Documentation/module_open1.jpg public/Customer Handoff and Final Documentation/module_open2.jpg

Below is a screenshot of the app user interface:

public/Customer Handoff and Final Documentation/app_screen.jpg

A video of the jumper functioning using the controls on the app can be downloaded here. In the video, it can be seen that changing the top slider affects the volume at which the song is playing on the jumper. Next, the video demonstrates that the second slider can control the brightness of the LEDs when buttons are depressed. Lastly, the pause/play button is pressed and you can hear the song stop the resume when the app button is pressed again. The "Next Track" button was experiencing bugs so that is not reflected in the video but it is functioning at the completion of the design review.

A video of the accelerometer data being live displayed on the app can be found here.

New Method for App-Jumper Interfacing

Due to difficulties developing an android app by directly communicating with the microcontroller via Bluetooth Low Energy, an alternate solution was implemented that utilizes a Raspberry Pi. This Raspberry Pi has become known as the Internet of Things (IOT) Hub. Essentially the "IOT Hub” connects to the microcontroller, then reads and writes from and to it based on what it sees in a variables file. The variables file’s data is posted and accessible by a web page URL hosted on the Raspberry Pi. Also provided are methods for editing the variables file from the webpage. This webpage is parsed and controlled using the android application. In this way it acts like a wifi router for internet of things devices that are set up to work with it, collecting, controlling and representing that data in an easy to work with form.

public/Customer Handoff and Final Documentation/mcu_communication.PNG

How Do We Market This Device?

Why did we make the improvements that we did?

Initially, the team decided on the list of improvements to be made to the jumper from the parent survey conducted during MSDI. These features included volume control, song selection, and audio/video monitoring. Additionally, after researching developmental milestones common for babies using jumpers, the team decided on adding additional stimuli for the baby. The new light patterns and switches address babies' affinity for novel light patterns and the formation of cause-and-effect recognition in this age range. This is the main marketing potential the team has been working towards and has successfully demonstrated in our prototype (all except audio video monitoring).

With the addition of this new "IOT Hub," a door is opened to an additional opportunity. The Raspberry Pi hub is capable of connecting to multiple devices in addition to our jumper. So this central Hub could be a start to developing a whole new "Baby Product Internet of Things." (Refer to our app name Pacif-I.O.T.) IF additional development is done on the system, a team could create a whole line of baby products that connect to a single smart phone app via the IOT Hub and allow parents of caregivers of multiple children to track their child's toy usage and customize the baby's experience with each toy. This would require far more software and computer engineering expertise than our team can provide but is a long term goal that our team has done an initial proof of concept for.

Elevator Speech

Our senior design project is a baby jumper with smart device integration and improved user experience. The jumper is able to connect to a smart phone app via Bluetooth and allow for control of the jumper/stimuli through the app by the parent. Improvements being implemented are based off a customer survey for parents who have used similar devices and look to improve upon them. App features include volume control, song selection, mode selection, LED brightness control, accelerometer data display, and pause/play control over the song. The jumper itself contains controls on its main module and additional stimuli to promote cognitive development. It utilizes a Raspberry Pi that acts as an "internet of things router" that multiple devices can connect to. The goal is to be able to develop this technology to be applicable across a whole line of smart-device baby products for caretakers or parents looking to track toy usage for multiple children.

Test Results Summary

Test Plan Summary

public/Customer Handoff and Final Documentation/test_list_summary.PNG

Engineering Requirement Summary

public/Customer Handoff and Final Documentation/ER_summary.PNG

As seen above, the only test plan that did not pass was the one testing for our power consumption requirement. The reason this test result did not perform to desired/expected specifications is due to the team's choice to switch audio modules. Originally, a low-power solution was anticipated but this solution would have required a lot more development work that the team did not have time to complete. Instead, a different sound module solution was chosen to save on development time in order for the team to have a working prototype in time for the end of the course. This solution is not nearly as efficient with power consumption and would need to be replaced with a lower-power component in the future in order to meet this engineering requirement.

The entire document containing customer requirements, engineering requirements, a test plan list, and test plan results can be found here.

Risk and Problem Tracking

Only two risks remain at the conclusion of this project. Risk 15 was not able to be addressed due to time constraints. The team only developed an app for Android devices but future work could be done to create an equivalent app for Apple products. Risk 16 could be addressed in the future as well by conducting a user survey to see if parents/caretakers approve of the app and its functionality. All other risks have been eliminated or mitigated.

public/Customer Handoff and Final Documentation/remaining_risks.PNG

The full risk assessment document can be found here.

Final Budget Use

Below is a diagram of the team's expenses and how they were distributed across purchase categories. There will be some minor updates made after the conduction of this review to reflect changes made to the original schematics during fabrication.

public/Customer Handoff and Final Documentation/SankeyBOM.png

The full BOM document can be found here.

Final Project Documentation

Project Management Design Tools Design Documentation Implementation Validation Presentation & Dissemination

PRP

Requirements

House of Quality

Schedule

Risk Assessment

Problem Management

Communication & Minutes

Use Case Scenarios

Benchmarking

Functional Decomposition

Morphological Chart

Pugh Concept Selection

BOM

Mechanical Drawings

Electrical Schematics

Software Diagrams

Test Plans

Test Results

Technical Paper

Poster

Functional Demo Materials

The pre-read document for this review with notes and action items can be found here.

Plans for Wrap-up

Plans for Wrapping up the Course

Individual 3 Week Plans

The team was asked to complete individual 3 week plans to describe what they plan to do to wrap up the course and what additional activities they would do if the course were continuing. These plans can be found * 3 week plans for final phase can be found here.

PRP for Possible Project Continuation

The team was asked to create a document that explains any shortfalls the team had during this journey and suggestions for overcoming these shortfalls as if the project were to continue onto later semesters. This "PRP" for a follow-on team can be found here.


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation