Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P13036NTID NOTIFICATION ALERT PHASE III

Thomas Adcock William JohnsonMechanical Engineering Mechanical Engineering

Patrick Ganson Stephen MoskalComputer Engineering Computer Engineering

Umer Usman Elizabeth PhillipsElectrical Engineering Electrical Engineering

ABSTRACT

The purpose of this project is to design and create a mobile, inexpensive notification alarm system for the deaf and hard-of-hearing community. The device combines an alarm clock functionality with a notification system using a Bluetooth device. This device has dual features; to wake a user but to also notify them of messages or calls from their own cellular device. Users will program their device using a mobile application designed for the Android cellular platform. This system was designed with the goal of preparing future teams with the ability to extend the cellular capabilities to Apple mobile devices.

NOMENCLATURE

NAS – Notification Alert SystemARM – RISC family of computer processorsRPi – Raspberry PI ARM GNU/Linux single board computerNAS – Notification Alert System Bed Shaker – Device with counterweighted motor used to vibrate the bedLED – Light emitting diodeBlueGiga WT12 – Bluetooth module with antennaPCB – Printed circuit boardUART – Universal Asynchronous Receiver/TransmitterGNU – UNIX-like computer Operating SystemPython 3.3 – General Purpose, high-level Programming LanguageXML – Extensible Markup Language

INTRODUCTION

This project originated when the need for an inexpensive, mobile alarm clock and notification system for the deaf and hard-of-hearing community. The design brought together the aspects of an alarm clock; a bed shaker, a LCD display and high intensity LEDs and a mobile notification system; a Bluetooth device and a mobile application. The key to the project was to make sure both subsystems could work individually (i.e. the alarm and notification systems) but could also be used together using the proper hardware and software techniques.

This project is the third iteration of the NTID Notification Alert System. From the previous team designs, this phase of the device focused on the Bluetooth notification system in order to prepare a new team on the design’s further development. Aspects from the previous teams were used to assist with the design of the project including their design strengths and weaknesses. For this device, a Raspberry Pi board was implemented to enable future teams to develop a board with an individual microcontroller. This phase also implemented using a BlueGiga WT12 Bluetooth module rather than the Panasonic PAN1315 of a previous team due to its ability to integrate with both Android and Apple devices and ease of programming.

Due to the changes of certain components from previous teams, certain customer specifications were not met; mainly the size and weight of the device. The use of the RPi board increased the size of the battery needed and thus, the entire design. However, the project stayed true to the need of the customers. The scope of this design can be summarized in the following bullet points:

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 2

Provide a mobile alarm and notification device for the deaf and hard-of-hearing community. Implement Bluetooth technology to provide the ability to interface the device with the Android cellular

platform and cellular network. Provide a functional prototype that can be used for future teams. Provide the necessary documentation to assist a customer using this product.

CONCEPT SELECTION PROCESS

From previous phases of the project, a set of customer needs and specifications were needed to be abided by. The critical customer specifications are shown in the bullet points below.

Device must function as an alarm system with high-intensity LEDs and a bed shaker. Device must be user friendly Device must abide by FCC regulations. Device must be powered by a rechargeable battery and be able to be recharged using an AC adapter

when the battery when low. Device must have a GUI screen to display notifications and time/date. Device must use Bluetooth to communicate with Android devices. Device must have a ‘snooze’ functionality Device must be designed for easy implementation for future teams to use and develop further.

From early on in the project development, decisions were made to tradeoff the size and weight of the device to develop ARM and Bluetooth module implementation. The use of the RPi board gave space to design more functionalities including using an LCD screen to display notifications. The RPi also helped with saving time on board development since it was already pre-designed. This time saving decision also opened the way for designing a battery charging circuit that can be applied to 1-4 cell Li-ion batteries, a low battery notification circuit, and a reliable case design. The team was able to design a fully functional prototype with the flexibility to be used by new teams to further improve the functionality.

Bluetooth ModuleThe Bluetooth module was the key to the entire design being created. This phase of the project family

implemented a BlueGiga WT12 Bluetooth module. This module provided the stability and wireless range needed to meet the customer specifications and the ability to work with both Android and Apple devices. The Bluetooth module was able to communicate with the RPi microcontroller using UART. This provides the ability to bridge the alarm system and the notification system together.

Alarm SystemThe alarm system is composed of a bed shaker, high intensity LEDs and the mobile application. Each

component is controlled using the RPi GPIO’s connections. The bed shaker and high intensity LEDs were proven from the previous team because of their successful design to meet the customer needs. In this phase, the LCD screen was a new requirement that needed to display the current date/time as well as notifications from the mobile device. The LCD screen full functionalities will be discussed later in the Notification System section where it is used.

Both the shaker and high intensity LEDs are controlled by using a IRL3410 NMOS switching circuit and the RPi. The devices would always have voltage applied to their positive terminals however, until the gate of the MOSFET was turned on using the RPi, the devices would be off. Using control signals from the RPi GPIO pins, the high intensity LEDs and the shaker could be controlled on and off but also at variable frequencies and vibrating intensities for different users.

The alarm system is controlled from the user’s mobile application in order to enable and disable an alarm. Once the alarm condition was set, the control signal would connect through the Bluetooth device to the RPi in which the necessary components would be enabled. To be more like an actual alarm clock, an ‘alarm off’ button was added. If pressed, the button would send a 5V rising edge pulse to the RPI which then is used to disable the alarm.

Battery Indication SystemThe indication system was designed to alert customers of when their battery’s voltage was getting low. The

device contains one red LED that is displayed at the top of the case to alert customers of this event. The circuitry for this system was very minimal with only two chips; a LM339 quad comparator and a NAND gate, as well the red LED and necessary resistors. The indication system would compare the input voltages of the battery and the static 5V from the regulator. When the battery voltage hit the desired threshold designed to alert customers, the red LED would turn on. This threshold voltage was designed to give the user approximately 30 minutes of battery life before

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 3

the entire system would turn off. As long as the red LED was off and the LCD screen is powered on, the system is in correct working order.

User Notification SystemThe notification system combines the use of a cellular device to the device to send messages and alarms using a

Bluetooth module. When an email, text message, call, etc. comes from the cellular network to the customer’s phone, the mobile application will forward the message over Bluetooth to the device. Depending on the message received, for example a text message, the LCD display would print the name or phone number of the sender and then display the start of the text message for the user. During this, the high-intensity LEDs would also blink in order to notify the user if the phone’s alert system and the LCD display are not noticed. In the case of the user not noticing any, the LCD display would continue to show the message until a new message was received or the message was read on the mobile device.

Raspberry Pi Software DesignThe software written for the RPi is a multi-threaded, object-oriented design implemented in Python 3.3. The

program consists of a single main class to spawn all of the threads; 3 classes to handle the display, alarm, and Bluetooth which are all threaded, and two non-threaded classes to handle communication between the Bluetooth chip and the display. The multi-threaded design was the main focus and was the main incentive to use both the RPi and Python. Multi-threading allows for a less complicated design and modularity in the system.

To start, the Raspberry Pi uses the operating system Arch Linux. Arch Linux is a stripped out Linux distribution that contains no functionality other than a basic command line. It is up to the user to add whatever features that are desired. This keeps the boot time under ten seconds and uses very low resources to run. This was the main driving factor to use Arch Linux in this design. The OS handles basic functionality like the clock and the rest is for this software.

Python was chosen due to its high scalability, portability, and integration already implemented in Arch Linux. The RPi allows for a plethora of programming languages from C and C++ to Java and Perl; however Python has already been precompiled for the ARM11 and was easily accessible. The five Python files written for this design are as follows: NAS.py is the main class that starts the threads, DisplayHandler.py takes in messages and displays them on the screen, LCDDriver.py handles the actual hardware interfacing with the screen, AlarmSystem.py handles setting off the shaker and LED’s when the alarm goes off, and BluetoothHandler.py handles all messages from the Bluetooth chip. Two packages were imported that added functionality to the design: RPi.GPIO.py is a package from the GNU Free Software where it handles all communication with the GPIO pins on the RPi. PySerial.py is a package also from GNU, however it was not compatible with Python 3.3, thus it had to be rewritten to work in this situation. PySerial.py handles basic UART communication, which is used to communicate serially with the Bluetooth chip.

The main class, NAS.py, is the simplest of the classes. This class simply spawns each of the threads of AlarmSystem, DisplayHandler, and BluetoothHandler. Once all threads have been started, it then continues and simply monitors the threads to make sure nothing goes wrong. In the event that something goes wrong, the class will then terminate each thread and restart the program automatically. This is used as sort of a failsafe in case something truly unexpected happens in the system.

DisplayHandler.py and LCDDriver.py are both closely coupled because DisplayHandler is the only class to communicate with LCDDriver. DisplayHandler is a threaded class that is constantly checking the state of three Boolean variables. These Boolean variables are set by another program by a public method. These variables govern whether if an alarm or a notification has been received or if the time should be changed. If one of these variables are set to true, they perform their function until they are false again. If all of them are false, then the system will just refresh the time that is seen on the clock. If the alarm is seen, the system will turn on both the shaker and LED’s and will not deactivate until the snooze/alarm off button is pressed. If the notification button is pressed, then the system will display the message on the screen, flash the LED’s, and then turn off in 5-6 seconds. Lastly, if the control signal is received the program will simply take in the message and change the system time. LCDDriver is the program that actually sends off the messages to the screen by the use of the GPIO pins. This is done simply by sending off 4 bit representations of each of the characters, very similar to UART.

Lastly, the BluetoothHander.py is actually a very simple program even though it governs the entire functionality of the program. For simplicity, the BluetoothHandler program opens up the UART socket using the pySerial package written and then allows the BlueGiga WT12 to handle all of the pairing and data transfer. This design is using the serial communication profile to communicate between the RPi and the phone. This allows for a very simple parsing of strings to decode the data from the phone. In this design, an opcode is used to tell the BluetoothHandler what to do with the data. The code allows for 5 different commands: ALR %H:%M (ex ALR

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 4

22:55), MSG <text>, DEL <Time>, CON %F %H:%M (ex 1991-04-24 03:55), and SPD <float>. ALR is the opcode to set an alarm and the text after it is the time, MSG is a message that allows for a shake speed and the actual message, DEL deletes an alarm, CON is the control signal which is the entire date, and SPD is the period of the LEDs and shaker. The BluetoothDriver simply looks for these opcodes in the beginning of a new line (all lines must be new-line terminated) and then passes it off to the AlarmSystem or the DisplayHandler.

Mobile Application

Figure 1a + 1b + 1c: NAS Mobile Application Screenshots

The mobile app was designed and built for the Android operating system. Apps on Android are written in Java and the GUI is powered by XML. The NAS app was designed with three major features: setting alarms, intercepting text messages, and sending Bluetooth alarms, current time, and messages.

Setting the alarm for the NAS can be either from the Android system or in the app. If there already is a list of alarms that the user has, then the next alarm to go off will be sent to the device. If there isn’t an alarm in the native app, then the user can select “Sync Alarm” to fetch the system alarm. Once it fetches the alarm, it will send it to the device. There can be many alarms in the app’s alarm list. When the user returns to the main screen from the alarms screen, there is an algorithm that determines which alarm in the list is the “next” one from the current time, and sends it to the device.

Intercepting text messages is fairly straight forward. When the option to enable text messages is checked on the settings page, text messages will be sent to the device. Only the first 13 characters of the body of the text messages get sent to the device’s LCD display along with the sender’s name. Once the text message is received on the device, the message is displayed and the LEDs blink at the frequency set in the app’s settings. This setting also controls the frequency of the vibration and LEDs of the alarms. The settings screen is very simple. There are only three settings, one to keep Bluetooth always on, one to control the vibration frequency, then another to enable text messages getting sent to the device. The text message setting is dependent on the Bluetooth persistence setting. That is, if the Bluetooth setting is off, then the text message setting can’t be turned on.

There are several classes in the app’s programming structure. There is a class controller for each screen in the app, MainActivity.java, AlarmsActivity.java, AlarmActivity.java, and SettingsActivity.java. There are several object classes and helper classes. Alarm.java is the object class that represents an alarm. BluetoothHandler.java is the helper class that contains the necessary functions that control the Bluetooth interactivity with the device. SMSReceiver.java is the helper class that handles intercepting text messages on the phone. AlarmStorage.java is the helper class that saves and loads the list of alarms that is stored on the phone. AlarmAdapter.java is the adapter class that places the alarms ArrayList on the AlarmsActivty.java list screen.

Using the device is fairly straight forward. Upon initial use of the app, the app asks for you to turn on Bluetooth, if it is disabled. Once it is on, the app checks for any alarms stored on the device. If there are no alarms the current time will be shown on the app. If the phone is paired to the device, the name of the device will appear on the home screen. Then the current time, default vibration frequency and next alarm (if any) will be sent to the device. Adding alarms can be set either with the alarm button on the action bar on the top of the screen, or going to the menu and selecting Alarms. Once on the alarms screen, to add an alarm, the alarm clock plus button needs to be pressed and a new screen will be shown to select an alarm time. Once a time is chosen, “Add Alarm” needs to be pressed to add the alarm to the alarms list screen. Many alarms can be added, but when the user navigates to the home screen, then only the next alarm will be shown and sent to the device. To go to the settings screen to choose preferences for the device, the “Settings” button needs to be pressed in the menu on any screen. Those settings only

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 5

go into effect when the user navigates back the home screen. If there is a problem with sending any Bluetooth message to the device, when either the device doesn’t display “Alarm set” or there is a notification on the app that says Bluetooth message not sent, simply hit “Sync Device” button on the home screen to resend the current time, vibration frequency and next alarm.

BatteryIn order for the device to be mobile and reusable, a rechargeable Li-ion battery was used. The batteries main

function was to keep the microntroller board alive since the entire device ran from the RPi. Due to the high current pull of the Raspberry Pi board, a high capacity battery was needed. Testing was performed on two different voltage/current capacity batteries; the first being a 11.1V, 4800 mAh, 3-cell battery and the chosen battery for this project, a 8.4V, 5200mAh, 2-cell battery. The goal for the battery life was set to be eight to twelve hours. The batteries were simulated with a 500 mA current pull and recorded until the batteries were no longer functional. Both batteries meet the required lifetime goal and the 2-cell battery was chosen over the 3-cell. Despite the 3-cell battery lasting longer, the 2-cell battery was smaller and added less weight to the overall design.

Power RegulationThe power regulator system needed to keep the entire system powered on. The system is composed of two main

sections; the battery charging circuitry and the 5V regulator circuit. Since the RPi runs on 5V, the entire system was designed around this voltage level. In addition to just powering the system, FCC regulations were needed to be abided by so an ON/OFF switch was implemented into the design. When switched to off, the RPI, indication system, and the LCD screen would turn off.

The battery charging circuit implemented a MAXIM MAX1758 Li-ion battery charging switch. This IC was very versatile and provided the ability for developers to configure the input and charging currents, support up to a 4-cell Li-Ion battery, and provide fast charging for less time plugged into the wall. When connected to the AC adapter, charging of the battery will begin. While charging, the rest of the components are powered by the 12V wall wart. This allows for maximum charging to the battery. As soon as the connection to the wall is removed, the entire system will seamlessly change over to battery powered.

The output of the battery charging circuit is a step-down/buck converter to take either the battery voltage or the wall wart DC voltage and convert it to 5V; the voltage required by the RPi. The TPS5420 is a high efficiency buck converter and works well into this design where the less loss of power into heat, the better. Once the voltage is converted down to 5V, the RPi can be powered.

PCB LayoutA single two layered PCB was designed to accommodate all the EE circuits. The dimensions of the board were

driven by the need to match the final case design. A block level methodology was adopted in connecting the various schematics. The board houses the charge control, voltage regulation and comparison, LED and motor control switches and the Bluetooth circuits all on the top surface. Accommodating all the components was made possible through use of surface mount parts. Through hole components were only used as connectors to input and output peripheral devices. These connectors were placed on the edges of the board to assist the mechanical mounting of the input switches and output connectors on the device. The power input traces are isolated from the digital components so as to not cause any interference. A ground plane is used to provide a common signal ground to all the digital components. The signal ground is connected to the analog ground via a 0 ohm resistor, where the analog ground is shorted to the negative terminal of the battery. The motor connectors have built in back emf control to protect the other electronic components on the board. The board also has built in fuse protection, to prevent any damage to the components in case of excess current. The WT12 chip itself is mounted on the bottom of the board. This was primarily done to provide some shielding to the chip and keep the antenna away from the other electronic components used on the board.

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 6

Figure 2: Final PCB LayoutHousing

The biggest design constraint during the design of the housing was to keep our housing as small as possible while also advancing the functionality from the previous phase. With the addition of an LCD screen and a larger processor (RPi), this phase of the project required the use of a larger, more powerful battery. By designing the case with the battery being in a separate compartment, optimizing the internal locations of the PCB and RPi was achieved. Once placing the PCB and the RPi, the focus was then deciding how the alert LEDs and the LCD screen would be placed to be visible to the user. With this in mind, the decision to place the housing facing the user can observe both the LEDs and the LCD at the same time. With this orientation in mind, the alarm off buttons were placed on the top of the case to make the product more like a real alarm clock. The bed shaker, power input, and on/off switch were then added to the sides to complete the design. While trying to advance the project in a new direction rather than a focus on the manufacturing side of the previous project, the housing was printed using a 3D printer. This allowed the focus on the concept selection rather than an easier rapid prototyping design. Concerns with the manufacturing the housing this way was whether it would be strong enough to withstand the stress it was required to withstand as well as the amount of heat generated by the system and whether or not the housing material would be able to withstand that heat generation.

Figure 3: CAD Renderings of Complete Device

Structural Analysis:The initial structural requirement for the case was to be able to withstand a 20G impact. This approach had

several shortcomings. The model did not accurately model the damaging dynamic forces and the most damaging corner impacts were still difficult to model. Possible approached include 2D or 3D static analysis and 2D or 3D dynamic analysis. The 2D and 3D static analyses are possible to implement, yet would fail to capture the damaging dynamic aspects of stress. The 2 and 3 dimensional dynamic models would require skills beyond those taught at RIT. The 2D approach would also not capture the damaging stresses at the corners of the enclosure. The risks associated with this approach were mainly due to the prototyping technology. While Fused Layer Deposition rapid prototypes do not have the brittleness associated with Stereo Lithography prototypes, they are weaker than a finished part in the direction perpendicular to the layers, this may cause premature breakage, leading to over designing the case, increasing weight.

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 7

Thermal Analysis:The problem being modeled in this case is the heat transfer through a case of an electronic device. The

transfer through the case is modeled as conductive and the amount of power dissipated is known. To aid analysis the conditions surrounding the device are assumed to have a convective effect to dissipate heat. Due to the relatively low temperatures involved, radiation effects can be ignored. The solution will be modeled using the conductive heat equation and several simplifications will be made to aid in solving this partial differential equation. This partial differential equation is a model for calculating heat flow through solids. (Weisstein)

α ∇2u=∂u∂t

Equation 1. Heat diffusion equation (Weisstein)

The main mathematical problems will be solving the equation for the volume of the case thickness and applying the conditions at the boundaries. The problem will be simplified to a one dimensional ordinary differential equation and solved analytically.

Figure 4. Problem Schematic

h Q l A k u∞Convective heat transfer coefficient on the surface

of the casing

Heat leaving the casing

Thickness of the casing

Interior area of the casing

Thermal conductivity of the

casing material

Ambient temperature surrounding the casing

Table 1: Parameter Descriptions

For an analytic solution for one dimensional steady state model, the governing equation for the heat transfer problem is the heat conduction equation. Combined with flux and convective boundary conditions, this allows for a one-dimensional model of the steady state heat transfer to be made.

α ∇2u=∂u∂t

Equation 2. Heat diffusion equation (Weisstein)

@x=0 , qx=q=Q̇ /AEquation 3. Inner surface boundary condition

@x= l , qx=−h(u−u∞)Equation 4. Outer surface boundary condition (eFundamentals)

u=q0

h+q0lk

+u∞−q0

kx

Equation 5. Solution for model

k = 0.17Wm∗k

l = 0.005m A = 0.0388 m2 Q̇ = 1W to 2 Wq0=

Q̇A

=25.8 Wm2 ¿51.5 W

m2

h=5W

m2∗k to 25

Wm2∗k

Table 2: Assumed Values for Key ParametersQuantitative outcome of model:

Worst Case:

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 8

u=q0

h+q0lk

+u∞−q0

kx=

51.5 Wm2

5 Wm2∗k

+51.5 W

m2∗.003m

.17 Wm∗k

+40℃=51.2℃

Best Case:

u=q0

h+q0lk

+u∞−q0

kx=

25.8 Wm2

25 Wm2∗k

+25.8 W

m2∗.003m

.17 Wm∗k

+40℃=41.48℃

Equation 6 + 7: Temperature at inner surface

RESULTS AND DISCUSSIONEach subsystem of the product was tested individually before bringing together for the final design. PCB testing

uncovered multiple errors. Issues were related to wrong footprint sizes for parts, schematic errors and manufacturing errors resulted in corrections to the PCB board. As more and more components of the overall design were attached to the PCB, more troubleshooting was required in order to make functionality work. One such example was the need to solder a pull-down resistor for certain GPIO pins and ground two pins of the Bluetooth device that were not originally in the schematics.

From the Thermal analysis, even in the worst case scenario, the temperature inside the case is only 11C above ambient. For more lenient conditions, the difference drops to 1.5C. Overall, given normal usage, it does not appear that there will be cooling issues with the device. Testing was performed in terms of functionality, the device operated properly without overheating, indicating that the estimates of the thermal scenario were reasonable. Structural testing was not completed due to the requirement being dropped.

Testing both the software and mobile application required an iterative approach to find and debug issues. Majority of development on the RPi and the mobile application was done prior to full system integration. As a result, most coding errors were fixed when testing could be done with the entire system. Errors that existed between the Bluetooth and mobile application also were fixed with a testing and debugging method.

CONCLUSIONS AND RECOMMENDATIONS This phase of the Notification Alert System was able to achieve many, if not most of the required customer

needs and specifications. Based upon feedback given by others, the next phase of the project could focus on size and weight reduction, brighter LEDs, a larger LCD notification screen and the integration with Apple ® devices.

As noted previously, the size and weight of the final product were needed to be outside of the customer needs and specifications in order to implement the use of the Raspberry Pi and thus a larger battery. The RPi was able to fit all the needs of the product such as controlling the LEDs and shaker. However, for the next phase of this product, the use of a pre-designed microcontroller board is not ideal. The software code was designed to be implemented seamlessly into a different microcontroller for the next phase. With the current code as a guideline for the next team, it should be possible to program a microcontroller of their choosing and as a result, a smaller battery can be used.

From feedback given by others during this project, it was noted that the need for more/brighter high intensity LEDs and a larger LCD notification screen would be ideal. This phase of the product was only able to implement six high intensity LEDs. Even though the LEDs were bright, concerns were raised about would they be bright enough to wake up a person. For future teams, it is vital to add more LEDs or choose LEDs that have more luminosity. Similar to the LEDs, the chosen LCD screen brought concerns about being able to see the text on the screen during wake up. Even though the screen seems bright enough during the day and easily readable, for a user using corrective lenses could have a difficult problem with this screen. It would be best for the next team to find a better LCD screen to display the notification messages.

Finally, the implementation of Apple ® devices was pushed to the next phase of the project in order to focus on building a sturdy foundation with Android ® devices. From what was researched about using Apple ® devices, an authentication co-processor chip will be needed to be placed on the designed PCB and used to communicate in-between the Bluetooth and the Apple ® mobile devices. The Bluetooth module that was used, the BlueGiga ® WT12 is a module that the next phase could use since it supports both Apple ® and Android ® devices.

Copyright © 2013 Rochester Institute of Technology

Proceedings of the Multi-Disciplinary Senior Design Conference Page 9

ACKNOWLEDGMENTS Dr. Gary Behm (Customer) Professor George Slack (Faculty Guide; technical assistance) Dr. Adriana Becker-Gomez ImagineRIT ARM Day Competition

Copyright © 2013 Rochester Institute of Technology