Description
Product Overview
This semester teams are asked to develop some type of “smart” device for enhancing an outdoor recreational
activity of some sort. The choice of which outdoor recreational activity it is intended for, how it enhances
that activity, and who it is intended for is up to the product development team. Our collaborative teams
have worked on similar products in the past, but in these instances the product was specified for them.
• 2011: Teams were told that approximately 3,500 children die in swimming pool accidents each year.
They were asked to develop a product that would help reduce this problem.
• 2017: Teams were asked to develop a GPS-based device for helping hikers know the position of others
in their group when they were outside cell phone coverage.
Other examples of possible products could be:
• A “smart” bicycle helmet that warns riders that a car is approaching from behind.
• An emergency alert device for skiers/snowboarders/hikers to notify rescuers if the need help.
• A range finder (GPS?, laser?, . . . ) for use by golfers to find out how far they need to hit their next
shot.
• A weatherproof and/or film industry grade device that mates to various professional and consumer
cameras and tripods head mounts to provide setup, alignment, and control of time-lapse camera shooting and tracking of objects and accurately predict and frame the shot to where the moon, sun, or other
object will rise over the horizon.
All of the product described above already exist in some form and they all satisfy some need, want or
desire. EE/MKT/ITP teams are expected to push beyond what is currently available and develop a product
that is innovative in as many ways as possible. It should include one or more features that are new to the
market and cannot be found on competitive products.
This collaboration is not about building a phone app. For many recreational activities using a relatively
expensive phone for the type of purposes describe above may not be what the consumer wants. The goal
here is to design an effective standalone product that will perform its tasks when not connected to Wi-Fi or
cellular service. It should work reliably but be cheap enough that the owner will view it as being expendable
in case it gets damaged through normal use in the activity. If a team wishes to include a connection to a
phone app as part of their design that can be done but doing so will have no effect on the how the project
is evaluated.
Product Guidelines
Regardless of what function your product is designed to do, some basic guidelines should be followed.
• It should be a product whose primary purpose is to improve the enjoyment, safety, or quality of the
activity at the time of the activity, as opposed to something that gathers data during the activity for
later analysis or evaluation.
• This product must be for an outdoor activity. It should not be for an activity that is normally done
indoors but is sometime played outdoor. For example, a device to automatically keep track of scores
in a basketball game would not qualify.
Rev. 1/9/19 1
• Ergonomics. Design decisions should take into account the environment in which the device will be
used. For example, using a touch screen may not be a wise choice for a device that will be used by
someone wearing cold-weather gloves.
• Ease-of-use. You are developing a product that will probably be used by non-technical people. It
should be easy to set up and use and not require the user to call in an expert every time they want to
make a small change in the configuration.
• Expandable. Depending on the activity, the product may have the ability to be expanded to handle
more devices. In this case the user should be able to expand their system in the future without
having to reinstall or reconfigure the entire system. If your company plans on introducing additional
components for the system in the future, it should do so in a way that does not require their past
consumers to scrap their existing system in order to incorporate them.
• Reliability. The product should be designed with the idea that once it is put to use by the consumer
it may operate for many years without the owner making changes to it. What can be done during
the design stage to produce a product that has a longer useful life than many consumer electronics
devices?
The product development teams are free to design the product in any way they choose that achieves
the goal of producing a system that meets the project requirements. The product teams are encouraged to
explore any designs that they can dream up. Keep in mind the overall goal is to develop a commercially
viable product which may or may not look like anything ever seen before on the market.
Product Requirements
The requirements for your product are heavily dependent on what type of project your team chooses to
design so the requirements listed below are meant as rough guidelines. Once you have settled on a product,
the more specific requirements will be discussed with the instructors at weekly meetings early in the semester.
Regardless of what is eventually required for your product, teams are strongly encouraged to go beyond these
requirements in terms of both additional features and the quantity of each feature.
It is not required that every single feature that is claimed for the product be implemented in the prototype.
Teams should plan to implement in their prototype about 80% of the features they claim for their product
but should not make claims for product features that cannot be implemented due to limitations on the
available technology, size, etc. Teams are not required to implement every product feature to the same
extent or quantity as would be required in the final product. For example, if your product claims to be able
to communicate with 20 devices of some type, it is not required that the prototype be able to communicate
with all 20. Showing that it can communicate with two or three, and is expandable to more, is sufficient.
The cost analysis of the final product should reflect any claims made for it, not just what was implemented
in the prototype
In the description below of the project, the terms “inputs” and “outputs” refer to whatever devices the
product includes that senses conditions (the inputs) or does something to cause some action to happen (the
outputs).
• The product must be based around one or more pieces of dedicated hardware using embedded microcontrollers. It is not a phone app. You may choose to use a phone app as one possible way to
communicate with the system, but the end user must also be able to operate the system using controls
attached to the device.
• If the device consists of multiple units (a main controller unit and one or more remote units) it is up to
the product development team to determine what type of connection to use (wired or wireless) between
the various devices. In the actual product the connection between the controller and the remote units
can be some type of wireless link, however experience in past semesters has shown the the wireless
links can be difficult and expensive for the teams to work with so teams may be allowed to simulate a
wireless link by using a wired connection. This will be discussed in more detail in class meetings.
Rev. 1/9/19 2
• The system must include at least three inputs of different types (temperature, moisture, noise, motion,
buttons, light, etc.) If your product consists of multiple units (a main unit and one or more remote
devices) at least one of the inputs must be incorporated into one of the remote devices and communicate
information to the main unit. Other can be part of the main controller if that is the optimum place
for it.
• The system must include at least three outputs of different types that do something as a result of the
information provided by the inputs devices. These can be alarms, servo motors that move something,
electrical outlets that are turned on or off, etc. If your product consists of multiple units (a main
unit and one or more remote devices) at least one of the outputs must be incorporated into one of the
remote devices and receive information from the main unit. Other outputs can be part of the main
controller if that is the optimum place for it.
• At least one of the input or output components of the system must be new to the market in that it
cannot be found in competing products that are currently on the market.
• For products with multiple devices, the main controller must be able to detect and notify the user
when it can no longer communicate with a remote input or output device. This might be due to a
broken communications link, a dead battery, or the remote unit itself may have become defective. A
user should not think that all is well with their system when in fact an input or output unit is no
longer working.
• If the product is designed to include wireless links between the controller and the remote units, the
design must address the issue of how to prevent inadvertent interference with or from a neighbor’s
similar unit. The product should only communicate with wireless devices that it is supposed to be
associated with.
• The controller must be immune to power outages in that the user should not have to take any action
to put the product back into service after a power outage. For example, if the controller has a internal
time-of-day clock, then the clock must be able to continue to function during power outages so that it
will know the correct time when the power is restored. All configuration data for the various inputs
and outputs should also be retained through power outages. It is not required that the various outputs
continue to operate if the controller loses power, however once power is restored everything should
resume normal operation without operator intervention.
All teams are encouraged to go beyond these minimum requirements in order to make their product
more attractive to consumers. Whenever possible, additional features selected for inclusion in the product
should be included in the prototypes sufficiently to show that they can be implemented and would work as
planned. Teams should always be aware of how additional features will affect the cost of their product and
be prepared to justify the added cost. For example, a team may decide to add a module to their product to
give it a wireless connection to the Internet, and then plan to use this to send messages to the user about
various conditions. The cost of this module must then be factored into the cost of the product. Saying that
you have added a $80 module to a project that is supposed to sell for $60 is not a good idea if you plan to
make a profit.
Rev. 1/9/19 3