P18075: Smart Device - Integrated Baby Jumper

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

Team Goals for Phase 4

Team Accomplishments in Phase 4

Progress Report

The team created a progress report to send to our customer and guide before leaving for Thanksgiving break. The document can be found here.

Schematics, Flow Charts, Simulations

Electrical Schematics

MCU Schematic is shown below:

public/Detailed Design Documents/circuit_schematic_1a.PNG

Power Supply Schematic is shown below:

public/Detailed Design Documents/circuit_schematic_2a.PNG

LED Interface Schematic is shown below:

public/Detailed Design Documents/circuit_schematic_3a.PNG

Audio Interface Schematic is shown below:

public/Detailed Design Documents/circuit_schematic_4a.PNG

IO Extender/Button Inputs Schematic is shown below:

public/Detailed Design Documents/circuit_schematic_5a.PNG

Schematics document can be found here.

Micro-Controller Embedded Software Diagram

public/Detailed Design Documents/EmbeddedSoftwareFunctions.PNG

Flowchart document can be found here.

Detailed Function Descriptions can be found here.


public/Detailed Design Documents/Application Structure.PNG

Larger Size can be found here.

The application has been designed in a typical manner befitting hardware control. The application is also designed in a loose manner, and will be documented as changes and helper classes are added to the predicted classes.

To simplify development as much as possible, the following software design patterns were used in the design: - Factory - Flyweight - Facade - Observer - Chain of Responsibility - Command - Strategy

Other design patterns may be used as well as development continues.

The Application functions (loosely) as follows:

The single representation of the micro controller state is held by a SQLite database within the application. SQLite was chosen for its light weight and widespread use in Android application programming. The User interacts with the View representation held by the apps MainActivity. The MainActivity then edits the database based on the changes requested by the user/state changes that are going to be logged. The Main Activity, when it edits the changes, also creates a "Command Object" which holds a representation of the command to be carried out by a micro controller. This Command object is parsed into the appropriate communication protocol by MicrocontrollerCommunication(to be dictated by Electrical Hardware design) Once the command has been sent by the Communication program over serial, then it is stored in a contained within a linked list of objects inside a separate thread (instantiated at start). This thread (Named ObserverOfCheckTable) will Observe a hash table (hashed by time command created) contained by a State Data Handler. This thread will iterate over its contained list objects, checking the state data handlers incoming data that concerns a state change for the micro controller and verifying that any change was successful. If any change is unsuccessful, it logs this failure, and sends a signal to the MainActivitiy to recreate the command.

Incoming data from the microcontroller will be deserialized by MicrocontrollerCommunication and then sent to the first in a linked list of handler objects (described by the "Chain of Responsibility" Design Pattern). These will allow incoming data to be quickly handled in an appropriate manner flexibly, and also allow priority of data to be considered. The most important data will be any incoming audio data from the monitor, so it will handle it first. This data is identified and then sent to a separate thread "AudioStream" which will implement with the standard android persistent audio playback interlaces. If the data is not audio data it passes it to the next handler, which handles urgent notifications. The next handler is then to handle data to be synced from the micro controller to the database. The final handler will then be handling state data and any unhanded data, and allow a previously mentioned thread to verify commands have been completed.

This is the flow of information as currently understood. As development continues, this could alter in some way. That being said, the high level functionality of each of the portions of this description should remain true throughout development, with any unanticipated changes being in helper classes and android interfaces that are as of yet unknown.

The applications user interface was also drafted: public/Detailed Design Documents/Application User Interface.PNG

Drawings and 3D Models

CAD models of jumper components can be found on the Mechanical Drawings page.

Bill of Material (BOM)

Bill of Material document can be found here.

Test Plans

List of Tests to be Conducted

public/Detailed Design Documents/test_plan_list.PNG

Test Procedures and Information

A description of the tests listed above that are not described by ASTM standards can be found here.

Federal Regulations and Testing Standards

Our product falls within ASTM F2012 - 16: Standard Consumer Safety Performance Specification for Stationary Activity Centers. The document describing theses specifications can be found here.

Risk Assessment

public/Detailed Design Documents/risk_assesment.PNG

Updated Risk Assessment document can be found here.

After doing some research, Risk Assessment ID# 15: "Tying Our self to a Single Platform" has reduced. The following data compares Android vs Apple users, which shows Android Users represent majority of the market.

public/Detailed Design Documents/Android.PNG

Design Review Materials

Meeting agenda and notes/action items from the review can be found here.

Plans for next phase

Gantt Chart for Phase 4

public/Detailed Design Documents/plansnextphase.PNG

Individual 3 Week Plans

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