WOCCS: WIRELESS COMPONENTS HOUSING PACKAGE

8
Multi-Disciplinary Engineering Design Conference Kate Gleason College of Engineering Rochester Institute of Technology Rochester, New York 14623 Copyright © 2010 Rochester Institute of Technology Project Number: P11204 WOCCS: WIRELESS COMPONENTS HOUSING PACKAGE Amy Powell / Interface Manager, Dustin Falkner / Interface Manager RIT: Rochester Institute of Technology ABSTRACT The mechanical engineering department at RIT has been developing a robotic platform to help engineering freshmen learn different engineering concepts. The robotics project has been in existence for a couple years and each year the project is given to senior engineering students to create a robust, working robot. This is a continuation of the LV-1 Wireless Command and control System project. The mission of this project is to manage all interfaces and system level design components in order for proper integration of the RF modules, Power Supply, Housing, and Test Bench into a wireless open-source/open-architecture command and control system. Throughout this project proper testing was conducted and compared to the interface specification document as well as the mission profile to validate the success and completion of the overall design. This paper will outline the design and manufacture of the new system, along with a complete bill of material, test results, and user manual for proper use of the application. INTRODUCTION The WOCCS family of projects is a continuation of the LV-1 Wireless Command and Control System project (P10205). The LV-1 team designed and assembled a set of transceiver units that were implemented into the LV-1 Land Vehicle Project. Together, the transceivers are capable of sending user input commands to the LV-1 robot, and receiving sensor data information from the robot. The WOCCS team was tasked with designing and assembling a base and a remote unit to take the main functions of these transceivers, and separate them into discrete functions: a RF module and a Digital Baseband module. The purpose of this separation is to create modularity in the RF section. Three RF Teams, Mid-Range 1, Mid-Range 2, and Long-Range were created demonstrate a variation of ranges and capabilities of the system. A power supply team was also created to provide power and harness energy to allow for transportability of the system. A common housing team was then created to protect components from the environment, provide adequate cooling, and accommodate all power I/O. Lastly, a Test Bench team developed both software and hardware to test a variety of capabilities of the system. In order to properly integrate all subsystems together, the Interface Team was created. The Interface Team controlled all engineering specifications that applied to the system level functionality, as well as defined critical interface definitions that supported interchangeability of components and modular design. They also managed project planning, system level integration, and a complete budget for the system. NOMENCLATURE LV-1: Land Vehicle 1kg UAV: Unmanned Air Vehicle WOCCS: Wireless open-source/open-architecture command and control system RF: Radio Frequency LED: Light Emitting Diode DAQ: Data Acquisition FCC: Federal Communication Commission TX/RX: Transmit/Receive USB: Universal Serial Bus OVERVIEW Customer Needs At the initial phase in the design, the customer needs had to be identified. After reviewing the MSD Project Description and conducting meetings with Dr. Hensel, Mechanical Engineering Department Head, and Jim McCusker, Harris Engineer, two primary applications for the unit were identified. The first consisted of future Senior Design Competitions. As a continuation of the LV-1, the WOCCS System would add another dimension to the design that would allow multiple robots to be controlled at once under various environmental conditions. The interchangeability of the boards would also give RIT an edge over competing units by allowing transfers over multiple ranges. The other main application that drove the design of the system was the military background of Harris. Harris was known for designing highly reliable, that can withstand extreme heat or cold, vibrations up to 10G‟s, and threats of radiation in case of nuclear warfare. These specifications were too extreme for the WOCCS system, but the ultimate goal of collecting sensory data and transmitting it back to a remote station in a variety of environmental conditions was of high priority during design. Based on feedback from initial research, the following customer needs were defined: 1) System must transmit command data from base to remote unit. 2) System must communicate status and sensor data between base and remote units. 3) System must be powered by portable high power density energy system. 4) System can be easily programmed to allow debugging and development testing. 5) System will be portable (both base station and remote platform) must have modular design. 6) System must be reliable. 7) System must have operator friendly design.

Transcript of WOCCS: WIRELESS COMPONENTS HOUSING PACKAGE

Multi-Disciplinary Engineering Design Conference

Kate Gleason College of Engineering Rochester Institute of Technology

Rochester, New York 14623

Copyright © 2010 Rochester Institute of Technology

Project Number: P11204

WOCCS: WIRELESS COMPONENTS HOUSING PACKAGE

Amy Powell / Interface Manager, Dustin Falkner / Interface Manager

RIT: Rochester Institute of Technology ABSTRACT

The mechanical engineering department at RIT has been developing a robotic platform to help engineering freshmen learn different engineering concepts. The robotics project has been in existence for a couple years and each year the project is given to senior engineering students to create a robust, working robot. This is a continuation of the LV-1 Wireless Command and control System project. The mission of this project is to manage all interfaces and system level design components in order for proper integration of the RF modules, Power Supply, Housing, and Test Bench into a wireless open-source/open-architecture command and control system. Throughout this project proper testing was conducted and compared to the interface specification document as well as the mission profile to validate the success and completion of the overall design. This paper will outline the design and manufacture of the new system, along with a complete bill of material, test results, and user manual for proper use of the application. INTRODUCTION

The WOCCS family of projects is a continuation of the LV-1 Wireless Command and Control System project (P10205). The LV-1 team designed and assembled a set of transceiver units that were implemented into the LV-1 Land Vehicle Project. Together, the transceivers are capable of sending user input commands to the LV-1 robot, and receiving sensor data information from the robot. The WOCCS team was tasked with designing and assembling a base and a remote unit to take the main functions of these transceivers, and separate them into discrete functions: a RF module and a Digital Baseband module. The purpose of this separation is to create modularity in the RF section. Three RF Teams, Mid-Range 1, Mid-Range 2, and Long-Range were created demonstrate a variation of ranges and capabilities of the system. A power supply team was also created to provide power and harness energy to allow for transportability of the system. A common housing team was then created to protect components from the environment, provide adequate cooling, and accommodate all power I/O. Lastly, a Test Bench team developed both software and hardware to test a variety of capabilities of the system. In order to properly integrate all subsystems together, the Interface Team was created. The Interface Team controlled all engineering specifications that applied to the system level functionality, as well as defined critical interface definitions that supported interchangeability of components and modular design. They also managed project planning, system level integration, and a complete budget for the system.

NOMENCLATURE

LV-1: Land Vehicle 1kg UAV: Unmanned Air Vehicle WOCCS: Wireless open-source/open-architecture command and control system RF: Radio Frequency LED: Light Emitting Diode DAQ: Data Acquisition FCC: Federal Communication Commission TX/RX: Transmit/Receive USB: Universal Serial Bus OVERVIEW

Customer Needs At the initial phase in the design, the customer needs

had to be identified. After reviewing the MSD Project Description and conducting meetings with Dr. Hensel, Mechanical Engineering Department Head, and Jim McCusker, Harris Engineer, two primary applications for the unit were identified.

The first consisted of future Senior Design Competitions. As a continuation of the LV-1, the WOCCS System would add another dimension to the design that would allow multiple robots to be controlled at once under various environmental conditions. The interchangeability of the boards would also give RIT an edge over competing units by allowing transfers over multiple ranges.

The other main application that drove the design of the system was the military background of Harris. Harris was known for designing highly reliable, that can withstand extreme heat or cold, vibrations up to 10G‟s, and threats of radiation in case of nuclear warfare. These specifications were too extreme for the WOCCS system, but the ultimate goal of collecting sensory data and transmitting it back to a remote station in a variety of environmental conditions was of high priority during design.

Based on feedback from initial research, the following customer needs were defined: 1) System must transmit command data from base to

remote unit. 2) System must communicate status and sensor data

between base and remote units. 3) System must be powered by portable high power

density energy system. 4) System can be easily programmed to allow debugging

and development testing. 5) System will be portable (both base station and remote

platform) must have modular design. 6) System must be reliable. 7) System must have operator friendly design.

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 2

Project P11204

Mission Profile

A mission profile is an explanation in graphical or written form of what a typical application of the system would look like. In order to design for a specific mission, the Interface Managers from each team met to describe what they envisioned their subsystem to be capable of. To capture all of the needed information, the Mission Profile document contained the expectations of the unit and quantifiable measures that must be met.

The WOCCS Mission Profile described a typical mission as a Senior Design Competition in the Gordon Field house. A single use would consist of a fully charged Li-Ion battery being used to power the unit for a marginal time of 10 minutes, and a maximum mission of 2 hours. The WOCCS would be attached to the LV-1 robot, and given the task moving a distance of 100m (Mid-Range) or 500m (Long Range) while completing a TX/RX of sensory data every 10 seconds. Sensory data may consist of messages, temperature, relative humidity, or current location. After transmitting up to 200 bytes of data using a bandwidth of 56 kbps, the unit would return back the remote station and remain in the idle state. Overall, the system would account for up to 20, 10-minute missions where units would be idle 80% of time and in TX/RX mode 20% of the time. The mission profile also graphically defines what the current, voltage, and bandwidth look like throughout the mission. This application helped verify the adequacy of the engineering specifications in order to carry out a successful mission.

Typical Mission

Engineering Specifications

After the customer needs were identified, they were then translated into the engineering specifications so the design could be properly tested. Weekly Interface meetings with the RF Teams, Test Bench Team, and the Power Team were held to identify how the defined customer needs would drive the specifications that would be later tested once system assembly was complete. As the System Team, it was important to define specifications that pertained to the performance and functionality of the entire system rather than each subsystem. The specifications were divided into four main categories:

1. Test Bench – To demonstrate the proper RF communications were functioning appropriately; specifications to that measure range, bandwidth, data rate, error loss, and latency were given.

2. Demonstration & Performance – To verify that WOCCS was able to carryout the mission profile, specifications for operation environmental conditions as well as mechanical properties were defined.

3. Functionality & Durability – To prove reliability in the design, specifications involving accurate voltage, current, and power consumption were created. Mechanical specifications such as vibe susceptibility were also defined.

4. User-Friendliness & Customer Expectations – Due to the variety of applications of the system, Yes/No specifications were created to determine if the design were modular, adaptable, easy to use, and functional.

Architecture

To aid in the concept design phase two documents were created: a System Architecture and a Functional Architecture. The System Architecture captured each individual teams responsibilities, while the Functional Architecture described the main purpose of the entire unit.

The System Architecture was broken down to show the individual components of the base unit and the remote unit. The housing, RF teams and the power team was directly responsible for the two units, while the test bench team needed to verify the functionality of the system. Under each team, a few obligations needed to be met. For the housing team, they needed to be able to provide adequate cooling, be able to protect the internal components and accommodate input/output interfaces. The RF teams simply needed to transmit and receive analog data between the two units. Lastly, the power team was required to deliver power and also be able to harvest/store the necessary energy.

The Functional Architecture can be viewed as the set of basic information processing capabilities available to an information handling system. The document is to display the main function of the entire system, while also branching off and describing smaller sub-functions. The main function of the WOCCS family was to provide wireless command and control data between the base and the platform. Branching off from that, the team must allow for functionality testing by testing input/output, bandwidth, error rate, and power consumption, be able to transmit and receive data wirelessly, transmit data to the PC through USB and provide power to supply the system by harvesting and storing energy.

Concepts

Risk Assessment For the WOCCS base and transceiver unit to function

properly with as little risks of failing as possible a risk assessment was conducted. The assessment was directed by inputs from all the teams and a document that captured each team‟s significant risks was created. After determining the likelihood and severity of each risk an importance factor was calculated. Based on the importance factor, the team could understand what specific risks were driving the project and would determine if it would pass or fail. The important risks were continuously addressed and significantly aided the design stage. QFD

To assist in capturing all risks associated with the WOCCS system a Quality Function Deployment (QFD)

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 3

Copyright © 2010 Rochester Institute of Technology

document was created. A QFD, also known as „House of Quality‟ translates the voice of the customer into technical requirements for each stage of development. This document helped check and improve the team's shared understanding about the requirements, and measure and key issues. By assigning rankings to each customer need and then scoring each specification‟s importance, a matrix was created defining a hierarchy of system needs. After ranking each of the specifications, the WOCCS System determine it needed to place a heavier emphasis on the ability to TX/RX correct data, transmit over the appropriate ranges, and have an operating time of 2 hours. FMEA

Failure modes and effects analysis (FMEA) is an established reliability engineering activity that supports fault tolerant design, testability, safety, and related functions. The purpose for an FMEA was to analyze the design characteristics relative to the planned design/assembly process to ensure that the resultant product met customer needs and expectations. When potential failure modes were identified, a corrective action was taken to eliminate and continually reduce the potential for occurrence.

The Functional FMEA was created first to identify elements of the system and subsystems that could fail. There are also end effects, causes and mitigations associated with each failure. This document provided the team with critical failures that could potentially cause significant impacts on the overall design.

The Design FMEA was created after the final design was completed, which differed from the functional FMEA. Here the focus was on the actual parts of the system, in which emphasis was on how each part could potentially fail, rather than the overall system. After determining a sensible level of detail for the parts in the individual systems, the team was able to complete the document. By focusing on each individual part, the team could look at the manufacturing/assembly stage to see what areas needed serious attention.

Some key results of both the Function and Design FMEA in WOCCS System were that it identified potential board assembly failures. To mitigate this risk, the RF teams would consult various professors to check board designs. The time allotted for delivery of parts was also of major concern as long-lead time parts needed to be ordered before break. The last major risk identified was the potential for the interfaces not fitting together. Additional time was spent reviewing tolerances of the interface document to ensure interfaces could fit in their allotted space.

Detailed Level Design Interface Analysis

By identifying a common understanding of the mechanical structures (size, weight, shape), electrical capability (maximum current, voltage, power), and RF Protocol (bandwidth, data rate, ranges), decisions were made as to how the unit would be integrated together. The Interface Specification document was created to capture key connections between each subsystem. These connector points needed to be defined both mechanically and electrically in order for each subsystem to function together properly. The Interface Document provides each team with necessary connection locations, connector types, electrical values, and visual diagrams for each interface. Additional

comments section also provides special insight for components requiring additional integration information.

The first interface that is of major concern is the battery to the power electronics. The power electronics interfaces include the on/off switch, charging dock, test bench and the RF module. Next, the RF modules need to interface with the power electronics, the USB port, LED lights, and the antenna. The housing needed to interface with the mounting card, top of the extrusion, and all slide plate holes. Finally, the entire unit needs to attach to the top of the LV-1.

Figure 1: Battery and Power Electronics board

Shown above is the battery, on/off switch, power electronics and the charging dock.

Figure 2: RF Module board

Shown above is the RF board, which is labeled with the USB, LED bank and the antenna.

Figure 3: Front view without front plate.

The picture above is how the front of the unit looks with the front plate removed to understand how the boards line up in their respected slots, the spacing of all components and the top extrusion inserted.

Battery Power Electronics

On/Off Switch

Charging Dock

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 4

Project P11204

Figure 4: Isometric view of entire unit

Shown above is the isometric view, which shows how the individual components line up with the front plate and how they extrude from the unit.

Figure 5: Assemble unit with Charging Capabilities Here is a picture of the assembled unit with the wall plug

in cord inserted into the power board through the housing, proving that the interface is fully functional.

Figure 6: Back view without back plate.

Shown above is the back view with the back plate removed to show how everything is aligned and to demonstrate the adequate spacing between the RF board and the Power Board. Bill of Materials and Budget for WOCCS Family

A budget is essential in determining and managing a project’s cost. It categorizes where money on a particular project is being spent. A Bill of Materials on the other hand

identifies the individual pieces of a product that must be purchased or manufactured. Basically consisting of a list of parts, a BOM is an essential part of the design and manufacture of any product. BOMs are important, since without a basic knowledge of how many parts a product needs; there is no way of knowing how many units of that part you need to buy. A purchase requisition is the paperwork required to initiate the purchase.

The WOCCS family of projects was given a budget of $5000 and it was our goal to stay under budget in case of mistakes or damaged parts. Having such a complex design, it was necessary to allow each team to build eight units while keeping the overall cost in concern. This would allow two units to go to the test bench team as well as a pair to each of the RF teams for proper testing.

Through good budgeting and updating the Bill of Materials regularly, the WOCCS Family was able to complete the project under budget with a remaining balance of $376. There were a few unanticipated costs that arose due to complications in board design and a few broken connectors.

Figure 7: Budget Summary The figure above shows the overall summary of costs

spent by each team. The teams highlighted in red all went over the original budget; however it should be noted that these costs were due to shipping that was not originally accounted for in the budget.

Figure 8: Budget Summary

Shown above in Figure 8 is a graphical summary of allocation of costs, according to team. All three RF Teams purchased their board‟s together accounting for the majority of their cost so their totals consolidated.

The figure below represents how shipping costs

accumulated throughout the project and were a significant part of our total cost. Total shipping costs were $430, while total material/component costs were $4,194.

Team Original Budget

Current Spent

Current Spent WITH SHIP

Ship Cost

Final Total Spent

P11204 - House

$500 $293 $320 $27 $320

P11207 - RF 1

$800

$2,323 $2,460 $137 $2,460 P11208 - RF

2 $800

P11209 - Long

$800

P11210 - Test $500 $480 $592 $112 $592

P11401 - Battery

$1,200 $1,096 $1,250 $154 $1,250

Grand Total $4,600 $4,194 $4,624 $430 $4,624

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 5

Copyright © 2010 Rochester Institute of Technology

Figure 9: Shipping Breakdown

User Manual

For this project a user manual is essential due to the necessity of correct assembly. A user guide also commonly known as a manual, is a technical communication document intended to give assistance to people using a particular system. Knowing that the WOCCS system is complex, this document needed to be constructed to present the information necessary and to employ a system that obtains desired results.

The document provides an introduction, which includes the overview of the WOCCS system, the user architecture, the system level architecture as well as the functional architecture. Within this section the user gains an understanding of the background associated with the design and function.

In order for the user to fully understand how to assemble the system an assembly guide was constructed. Within the assembly guide, there are parts diagrams and assembly instructions for the housing, the power supply and the RF boards. Detailed instructions were associated to each system to ensure that the user does not damage or undergo improper assembly during the construction. If the user fails to follow the instructions the entire system could fail and could potentially harm the unit, the user and/or others.

On the electrical side of assembly there contains a GUI implementation section within the manual. This section explains how to configure the device to a PC as well as how to operate the device. System Test Plan

A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be. A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements.

Using other team‟s inputs, a test plan document was created to show all necessary testing procedures as well as descriptions of each test attached. The document is broken down into four categories, which are test bench testing, demonstration and performance testing, analysis testing, and observed functional testing. Within each category is a description of the test, the testing procedure, equipment needed, resources required and recorded results where the user fills in the test results.

Results

After carrying out the System Level Test Plan, the base and remote units proved to be an overall successful

operating system. All basic demonstration/performance tests passed both marginal and ideal level specifications. The functionality and durability tests passed all operating times and mechanical requirements; however, the drop test failed due to unsecure power board-battery connection, as well as the protrusion of the on/off switch when dropped at a distance of 1 meter. The usability/user-friendliness tests were also successful as survey results positive feedback and binary specifications met all necessary criteria. Lastly, the Test Bench was able to demonstrate basic power, voltage, and current met all requirements throughout a typical mission. With the exception of Mid-Range 2 failing to meet range specifications due to board assembly complications, all boards passed error loss, data rate, bandwidth, and latency tests against engineering specifications.

The first test conducted was the verification of size and weight specifications. Both remote and base units measured 7.8 x 7.35 x 9.5 cm giving them a total volume of 544 cm2 which was well within the marginal size requirement of 780cm2. The units were then weighed without their corresponding antennas and yielded results of 470.8g (Mid-Range 1), 452.7g (Mid-Range 2), and 535.2g (Long-Range). These weight requirements were well within the 1587g specification that was estimated for as the carrying capacity of the LV-1 Robot. These demonstrate the system can be used in a Senior Design Application as well as a potential military application as its compact, light-weight design allows easy transportability of the unit.

The next test performed was to demonstrate the usability of the system. Total assembly time took an average of 133 seconds with a low standard deviation of only 4 seconds. Board changeover time averaged 182 seconds with a standard deviation of 39.6 seconds. Lastly, battery changeover time and standard deviation was 154 and 21 seconds respectively. All tests passed specification of 10 minute assembly and 5 minute changeovers. The tests showed that the majority of the time was spent securing the 4 screws as well as struggles inserting the power board due to the grounding clip‟s tendency to get caught on the housing slot.

Operating times for the unit were also recorded in ideal conditions. The units were placed in the Gordon Fieldhouse,

on the track, with an external temperature of 69⁰F and relative humidity of 35%. Both Mid-Range 1 and Mid-Range 2 were able to transmit and receive 60 bytes worth of data every 10 seconds for operating times of a marginal mission of 10 minutes as well as an ideal use of 2 hours. The charge on the battery went from 100% to 18% during the 2 hour operational test, proving that a typical mission would be able to be carried out without needing to change the battery during the course of use.

To conclude the basic operational tests, the power supply team conducted battery re-charge time tests using both the wind-turbine method as well as a standard AC adapter plugged into an outlet in RIT‟s CFD lab. Using an input voltage of 3.6, the wind turbine was able to pass the recharge test with a time of 2 hours for 0-100% utilization. Using an AC adaptor, the re-charge time was 1.2 hours. Both tests passed marginal and ideal specifications. It should also be noted that in a typical mission, complete charge of the battery would not be needed in order to have operation of the unit. During a typical 10-minute mission, li-ion battery lost only 9% of its charge. Using this assumption, the unit should be able to complete an estimated 10 missions before the battery needs to be replaced or recharged.

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 6

Project P11204

After conducting ideal, cold, and hot temperature environmental tests on the appropriate boards for ranges of 100m (Mid Range) and 500m (Long Range), results showed 2 of 3 boards met engineering specifications. Mid-Range 1 was able to transmit and receive 60 kbps worth of data every 10 seconds for the entire 10 minute mission for both ideal temperatures and hot temperatures. As shown below in Figure 8, three internal temperatures were recorded with a laser-point temperature gauge. As anticipated, under ideal

conditions of 70⁰F and 37% relative humidity, the internal

temperature raised slightly, from 70 to 74.1⁰F with a steady decline in the slope of the temperature increase. Under hot

conditions, an initial internal temperature of 98⁰F and 35% relative humidity yields an increase in internal temperature

of 70⁰F to 80.1⁰F. It can be concluded that eventually the system and external temperature would reach equilibrium of

99⁰F and the unit would remain operable. Mid-Range 2 Team was unable to perform basic transmit

and receive tests due to their dependency on the CC-Debugger and only 1 functioning board. They were able to transmit and receive at a range of 17 inches; however, this resulted in a failed range test. Internal temperatures were not able to be taken as the unit could not properly shut while being connect to the Debugger. Hot Temperature tests were also not able to be conducted due to the range constraint.

Long-Range boards showed passing test results for ideal, cold, and hot temperatures. They were able to successfully transmit and receive 60 kb worth of data for 10 minutes under all three environmental conditions. The Long-Range board was tested first, which may have skewed the internal temperature graph resulting in a lower slope since the battery was still in its warm-up phase. Nevertheless, internal temperature readings throughout the mission showed a similar increase in temperature due to the heating of the battery. Under cold temperatures of 29°F and 57% relative humidity, there was a similar change only in a decreasing fashion from about 70°F to 62.5°F. During the hot temperature test, the Long-Range also showed a slightly lesser increase in temperature compared to the Mid-Range 1, going from 70°F to 78°F. Overall, the housing unit shielded the components from reach extreme increases or decreases in temperature. Both the Long Range and Mid-Range 1 passed all tests demonstrating the systems versatility.

Figure 10: Basic TX/RX Test Ideal Temperatures

Figure 11: Basic TX/RX Test Cold Temperatures

Figure 12: Basic TX/RX Test Hot Temperatures

The next test performed was to demonstrate the durability of the system through a drop test. The test was conducted in the Gordon Field house, where a typical mission was to be completed. The WOCCS unit was dropped from a height of one meter onto the track. After each drop was completed, the team inspected the unit, noted any external damages and opened the housing to see if components had shifted, broken or had become dislodged from their respected areas. After 20 trials of dropping the unit onto four different sides (five times a side) the main damage came within; in which the battery actually popped out of the battery holder and the battery holder often detached itself from the power board. There were other minor damages to the outside of the housing on the two flanges, but due to the application these tests were conducted: simply dropping the unit by itself, they did not simulate a typical mission. This is due to the fact that the unit will be attached to a remote unit (UAV, person or robot) by a specific mount, where these flanges will not be exposed to damages. In conclusion, the only significant failure came in terms of the power board, in which the battery weight could be accounted to the failure. Located below is a picture of the drop test that was conducted.

Figure 13: Drop Test Damage to Battery and Holder

Proceedings of the KGCOE Multi-Disciplinary Engineering Design Conference Page 7

Copyright © 2010 Rochester Institute of Technology

Through careful inspection of the mission statement and collaboration with the power team, it was determined that the most heat will be generated inside of the housing during charging of the internal battery, so a thermal test was conducted. The reason for the test in this situation was to see that the housing meets the thermal specification given. The temperatures of the power board, battery, internal air, and external ambient air were measured from the beginning of the charge cycle up until the charge was complete and an equilibrium between the internal and external air were reached. The graph below shows that this takes approximately 3 hours to complete the thermal cycle. The temperature of every internal component jumps up 1.5°C in the first 10 minutes. The battery and internal air remain at that elevated temperature until charging is complete just before 1:30 hours, while the power board‟s temperature continues to rise until 28.5°C where it levels off just before the battery is fully charged. After charging is complete, all of the internal temperatures begin to drop until the external and internal air temperatures are equalized. The test shows that charging in a regular inside thermal environment the battery experiences a maximum temperature of 26°C and the power board experiences a temperature of 28.5°C, which falls well within the operating internal temperature metric defined in the engineering specifications. Located below is the graph representation of the charging temperature over time.

Figure 14: Charging Temperature vs. Time

A Vibration test was performed for a variety of reasons:

to determine if the WOCCS unit can withstand the rigors of its intended use environment, to ensure the final design could be suitable for shipment, or in order to weed out product defects in the design. The vibration test was conducted using DAQ software, accelerometers, and a B&K 4801 Shaker Table. The accelerometer measures the frequencies associated with the device being run and can determine the natural frequency. The test was conducted in the Vibrations Lab of the Engineering building at RIT. In order to perform the test, the team used one housing unit with mounting holes that allowed mounting screws to be attached to the table, one power board and substituted the three RF Modules. The housing cover was then inserted back into its respected location and screwed shut.

A PCB accelerometer was attached to the outside of the housing using wax, and was plugged into the DAQ device at the computer terminal in the lab. The testing started at a high frequency of 425 Hz and slowly decreased until the unit was actually seen to be vibrating dramatically. The shaker was run at an amplitude of 3 volts peak-to-peak with a sinusoidal frequency of 28 Hz. Upon visual observation, it was

determined that the most vigorous and violent vibrations occurred at this frequency. As a means of checking this data, the results were compared to the engineering specs written for vibration integrity. Upon converting the 28 Hertz output from the shaker table to G forces, it was determined that the housing unit was able to withstand approximately 3.2 G‟s without failure. The results from the vibe test proved to be a success and were well within the engineering specs that were specified. A graphical representation of the long-range vibe test is shown below in Figure 14. The resonant frequency is determined by the largest amplitude or “spike” in the graph and is shown to be around 28Hz. Both mid-range groups displayed similar results.

Figure 15: Long Range Vibe Test

To prove that the WOCCS system met the customer

needs and specifications, functionality tests were conducted. So to initialize these tests, the group gathered three observers; Boris Sango, Fran Branco and Michael Garrity who had little knowledge of the project. With their help, the tests were conducted and passed for all three subjects. The main reason for all tests passing was aided by the user-friendly design. Through interface meetings and deliberation, the overall design was able to capture some of the most crucial expectations of the customer such as the use of a lithium-ion battery, being able to be configured to a PC, LED lights to display different statuses, as well as following FCC Regulations.

In design, Usability is the study of the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal. Usability, similar to user friendliness was considered multiple times throughout this project simply due to the fact that the user was the sole implementer to complete full interaction. The four main categories of the tests being piloted were categorized under the user manual, the overall design of the system, the ease of assembly or assigned to the overall appearance.

During testing for the overall size and weight requirements as well as the assembly and operating times there were a few problems discovered. The users continued to disassemble the front (input/output) panel, which is not made for disassembly and should at all times remain in its one position. In hindsight, we could have eliminated this problem by possibly gluing the front panel to extrusion, which would have not allowed the user to detach this plate from the housing. Also, due to the power team soldering the stabilizing clip to the side of their power board, it extruded off of the board and made it difficult to slide the board in its respected location. Another issue was brought up when it came to the antenna, in that there are two different types with respect to the mid-range and long-range. The matter

Proceedings of the Multi-Disciplinary Engineering Design Conference Page 8

Project P11204

CategoryAverage Score

(out of 4)Comments

Ease of

Assembly3.27

Stabilizing clip on Power

Board made it difficult to slide

in slot & Antennas are not

labeled

Overall

Appearance3.56

No labels for I/O panel & No

Harris Logo

User

Manual3.45

User continuously tried to

disassemble the I/O panel

Design of

System3.40

User continuously tried to

disassemble the I/O panel

with the antenna was due to a labeling error, in that they were not and the user was attaching the wrong antenna with the wrong RF board. To eliminate this confusion, the team should have implemented a label on the different antennas, which could distinguish the specific application. Also, another design flaw occurred early in the design stage when the team tried to slide the RF and power board into the housing and didn‟t know the precise slot to slide it in. In order to implement a quick fix, the team color-coded the correct slots and added the color scheme into the user manual. This provides the user with a more user-friendly design and ultimately lessened the assembly time.

To gain feedback on the user friendliness, the survey above was provided to 20 users, unfamiliar with the project and the results are shown below in the table. A user friendly summary table is represented below with some comments associated to each category pointing out the flaws in the design.

Figure 16: User-Friendly Summary Table

To assist in further user-friendliness, a WOCCS GUI was created to allow the user to interface with the system. Figure 16 shows a basic demonstration of how the user to send and receive sensory data across the units. Further GUI Instructions can be found in the Test Bench User Manual.

Figure 17: WOCCS GUI

To conclude System Level Testing, the Test Bench was able to design test system capabilities of range, bandwidth, latency, and error loss. Through the development of appropriate Testing Equipment and software, all units passed

electrical tests with the exception of Mid-Range 2 failing to meet range requirements. Range testing at 25m apart showed a mid-range 1 bandwidth of 16.5 kbps, with a data loss of 0% and latency of 195.3ms. Data loss testing showed a loss of 0% for all systems, and 10% for a modified data set, thus verifying the system was accurately depicting the 0% data loss for the system. Latency testing passed with recordable values of 182ms, 204ms, and 200ms for a 118 byte file. Latency values for a 202 byte file were 178ms, 188ms, and 188ms. Finally, bandwidth for a 222 byte file was 64.6 kbps which passed specification of 56 kbps. Further analysis and procedural details can be found in the Test Bench Test Results section on EDGE. Conclusions

The WOCCS system was tasked with creating a modular set of units with wireless communications capabilities. After project completion, the design of the system definitely met all customer expectations. The assembly of 8 housing packages, 8 power boards, 8 Mid-Range 1 boards, 2 Mid-Range 2 boards, and 6 Long-Range Boards, as well as test equipment capable to measuring useful electrical capabilities demonstrates the team’s dedication to the project. The Interface Managers were able to successfully manage system level design specifications, interface documentation, assembly, testing, and troubleshooting. The Customer demonstration received positive feedback from both Harris and Dr. Hensel.

After reflecting on both MSD I and II, the System’s Team was able to understand why it was so important to communicate effectively among all teams. The hardest challenge came during planning phases as teams struggled to get a clear understanding of how the system would operate and what was expected. The completion of the Mission Profile helped clarify these expectations and in the future should be one of the first deliverables completed. We also valued the FMEA - which pointed out key areas of failure such as correct spacing for boards, I/O holes, and hardware compatibility. The actual integration went very smoothly with minimal adjustments needed for boards. The slight addition of a copper plating caused modifications on the housing to be made. This is a perfect example of how the FMEA captured the risk of this happening, and knowing that the housing slots would be widened if needed.

The design of the WOCCS system was extremely user-friendly. Our final recommendations for improvement of the system would be to include a stronger battery clip in order to strengthen the battery-housing interface. The Battery Clip placement would also need to be slightly adjusted for easier assembly. Lastly, more labels on the outside I/O would allow users to clearly see which interface performed what action. The I/O plate could also be permanently sealed shut to prevent users to incorrectly disassembling the unit. Overall, the WOCCS Senior Design Project was extremely rewarding, as all six teams got an opportunity to work together, learn about their strengths and weakness’, and understand the design process. Acknowledgements

The team would like to thank Harris, our customer for the financial contributions to our project. In addition we would like to thank our guide (Phil Bryan) and our teaching assistants (Leo Farnand and Vince Burolla).