led-lux design reportengr.calvinblogs.org/17-18/srdesign06/.../2018/05/team06_designre… ·...
TRANSCRIPT
LED-Lux
Design Report
Team 06
Anna Little, Melanie Fox, Evan Hill, and Reuben Lewis
ENGR 340 Senior Design Project
Calvin College
May 10, 2018
© 2018, Team 06 and Calvin College
Abstract This document describes the LED-Lux project by Team 06. The project was designed to create a healthier
environment in hospital rooms by providing a spectrum of light that adjusts throughout the day according
to a patient’s circadian clock. This system would allow patients to get the most and best sleep possible and
allow nurses and doctors to stay attentive longer by adjusting the light spectrum to fit their respective needs.
The lights in this system are a part of a node-mesh network where each light is a node. The network is
controlled via machine vision, which will be able to “see” the users in the room. The system differentiates
humans from other objects and turns the light on and off automatically when they enter and leave the room.
Other features were added to the improve the machine vision as the project continued, such as location
tracking and detecting key objects that are being interacted with.
Table of Contents
Introduction 1
Project Management 2
Team Organization 2
Schedule 2
Budget 3
Method of Approach 3
Requirements 4
Spectrum and Light Requirements 4
Node-Mesh Network Requirements 4
Machine Vision Requirements 5
Task Specifications and Schedule 6
System Architecture 7
System Communication 7
Machine Vision Architecture 9
LED Driver Architecture 12
Design Criteria 13
Openness and Communication 13
Caring 14
Delightful Harmony 14
Justice 14
Design Alternatives 14
Fixture Design: 14
LED Design and Implications: 15
ZigBee Communication and Module: 15
Machine Vision and Webapp Control 15
Design Decisions 16
Project 16
ZigBee 16
Machine Vision 16
Fixture Design 17
Integration, Test, Debug 17
ZigBee Network 17
Web Application 17
Machine Vision 17
Fixture 18
Business Plan 18
Marketability 18
Competition 18
Market Survey 19
Cost Estimate 19
Development 19
Production 20
Conclusion 20
Acknowledgements 21
References 22
Appendix A 23
Appendix B 24
Appendix C 25
Appendix D 27
Table of Figures
Figure 1: Organizational chart for Team 06 …………………………………………………………… 02
Figure 2: Task Specification Graph ………………………………….………………………………… 06
Figure 3: Individual Task Diagram ………………………………… ……………………………….... 07
Figure 4: Block diagram of the system communication of LED-Lux …………………………………. 08
Figure 5: Diagram of the lighting demo..………………..……………………………………………… 09
Figure 6: Discerning different figures via machine vision……………………………………………… 10
Figure 7: Image classification process…………………..……………………………………………... .11
Figure 8: Image processing flowchart….………………..…………………………………………….. 12
Figure 9: LED driver software architecture……………..……………………………………………... 13
1
1. Introduction Calvin College is a Christian liberal arts college located in Grand Rapids, Michigan where students
are encouraged to “think deeply, act justly, [and] live wholeheartedly as Christ’s agents of renewal
in the world.” Engineering students, as future designers, optimizers, and managers, are especially
taught to take this motto to heart. This, in addition to all the other skills gained during the
engineering program, is showcased in the student’s senior design projects. For the projects, students
form small groups that will each work on a subject of personal interest and address that subject in
a culturally appropriate, just, transparent, and caring way. This year, Senior Design Team 06
decided to address the shortcomings of indoor lighting within hospitals, calling their project LED-
Lux.
Though typical indoor lighting is sufficient for illuminating dark spaces, it does not properly
stimulate the human circadian clock. The human circadian clock aligns with changes in sunlight
throughout the day, among other things, and helps regulate hormone production, body temperature,
heart rate, immune responses, sleep schedules, and more [1]. Within a hospital, both night-shift
workers and bedridden patients may not have access to sunlight or special supplementary lighting
to help maintain their inner clocks. This conceivably results in reduced productivity, lower morale,
and longer healing periods.
To combat these issues, LED-Lux created a scalable, smart lighting system that works with the
human circadian clock to improve user mood, health, and productivity. The system is made up of
a ZigBee node-mesh network and uses machine vision to monitor user activity and control the
lighting system.
The LED-Lux team is made up of three computer and electrical engineering students and one
mechanical engineering student. Each student brings unique skills to the team. Evan Hill studies
Electrical/Computer Engineering, works as a Resident Assistant at Calvin College, and has interests
in LED implementations and lighting spectral systems. Anna Little is a Electrical/Computer
Engineering major with a minor in mathematics who specializes in the mechanics of ZigBee
communication and the software programming of ZigBee modules and Arduino. Reuben Lewis
studies Electrical/Computer Engineering at Calvin College with minors in German and Computer
Science. One of his interests is capabilities and applications of machine learning and vision. And
finally, Melanie Fox, the Mechanical Engineering major, has a biotechnology minor and is
interested in the effects sleep and circadian clocks have on the human body.
2
2. Project Management
2.1. Team Organization
As mentioned above, the team consists of four members: Anna Little, Reuben Lewis, Evan
Hill, and Melanie Fox. Anna filled the role of the communication liaison by handling
emails and setting up meetings with consultants and mentors. Reuben ran team meetings
and kept the team on track during discussions. Evan took minutes during meetings and
handled the follow-up emails to make sure everyone was on the same page. Melanie
managed schedules to plan meeting times and helped assign tasks to the people with the
best ability to complete them in the allotted time. Figure 1 gives a visual representation of
how the team is organized.
Figure 1. Organizational chart for Team 06
The team met weekly to discuss the next steps in the project, the timetable of current and
future tasks, and any new problems or questions that arose. The team used its resources to
solve issues as they came. This included their advisor Mark Michmerhuizen and industrial
consultant Eric Walstra. The minutes and various documents are kept in Google Drive for
ease of access.
2.2. Schedule
The team schedule was managed using a calendar in Google Drive and Taiga software. The
calendar was used to keep track of due dates and specific benchmarks required by the
Senior Design class, while the Taiga Kanban was used for task management.
The team struggled with scheduling when some due dates for the Senior Design class were
changed close to the expected due date but these were few and far between. These
challenges improved the flexibility of the team and showed how adaptable the members
are.
3
The overall projected hours per week per person (hrs/wk/person) was 5 for the first
semester and about 10 hrs/wk/person for second semester. These numbers are an average
and are not a good measure for the amount of time one person spent on the project in a
given week. The schedule that was used is in Appendix A, and shows the deadlines that
were set to frame the progress of the project over time.
2.3. Budget
The budget was put together by estimating the cost for the different components of the
project prototype and other parts needed for development. The team kept track of expenses
and allocated each expense to the appropriate categories. As the project progressed, the
amount allotted to different categories changed, though the total budget was kept constant.
This was due to changing expenses and focuses in the project, as well as the realization of
the actual cost of some components. DornerWorks has also contributed $500 for the
integration of machine vision into the project, of which we used approximately $340. The
final budget sheets are shown in Appendix B.
2.4. Method of Approach
Once the project was defined, the next step was exploring how to design the system.
Because of the scope of the project, it was not feasible to put the entire burden of a single
overarching task on a single member. Instead, each member was the leader of an
overarching task. Each leader focused on the design of their area, and, when prototyping,
organized the work on their area. For example, Melanie was in charge of the fixture
enclosure and headed up designing the parts. She kept things on schedule by checking in
with the rest of the team for electrical component dimensions and having Evan help with
some construction. It is up to the area leader to ensure that the work on their part is done
in a timely and efficient fashion, as well as to research in their area. Some resources used
were the library, online databases including Google Scholar, professionals in the specific
fields being researched, and online resources such as Stack Overflow. Communication was
done via Facebook Messenger and weekly meetings in the first semester and at least twice
weekly in the second. Documentation and version control are done using Google Drive for
documents and GitHub for software files.
One of the pieces of scripture that guided the team was Ephesians 4:2: “Be always humble,
gentle, and patient. Show your love by being tolerant with one another.” As the project
goes on, the team will have to have patience with each other as other commitments and
homework are added onto the workload and people may not be able to focus on the project
for as much time as is expected. This verse reminded the team that they need not only have
patience but be humble as well, which is important as an engineer. Using this verse as a
guide, the team worked together well throughout the project.
4
3. Requirements The main goal of the project was to create a better indoor environment by not only adjusting the
color and type of lighting to ensure the best type of lighting for humans, but integrating the system
seamlessly into the indoor environment. In order to refine the scope of the project and ensure a
correct area of focus, the following requirements were developed. The first set of requirements
outline the system in general. The system shall be designed so that the lights change color
temperature and spectrum as the time passes to give the optimal type of light for humans at that
specific time of day. The system shall be a node-mesh network of light fixtures, with each light
fixture being a single node in the system. Finally, the system shall be controlled via machine vision.
This system shall differentiate between humans and other things such as animals, controlling the
lights depending on what it sees. The goal of the machine vision is to reduce the number of
purposeful interactions the user has with the system, creating a more seamless lighting
environment. These requirements will be broken down further in the following sections.
3.1. Spectrum and Light Requirements
In order to properly create the right lighting environment for the user, the lighting system
must meet the following requirements. First, the lighting system shall adjust the spectrum
in real time based on an internet connected clock and the user’s approximate location. To
keep general anonymity, the user’s zip code will be used to calibrate the system
accordingly. When the lights change, they shall change slowly and unobtrusively, allowing
users eyes to adjust easily and without shock. The lights shall also be manually
configurable by the user, so that any standard temperature of light can be set at any time,
as well as the intensity of the lights. They shall be responsive, changing soon after the input
was validated. The lights shall also be turned on and off or dimmed when a person enters
or leaves the room, as sensed via machine vision. The lights shall also produce enough
light that their designated area is adequately lit by using LEDs. The lights shall be designed
for maximum efficiency, aiming for the maximum life of the LEDs. This means optimal
current control, heat dissipation, and voltage control.
There are a set of other options that could be added to improve the system. Being a node-
mesh network, the nodes could be grouped together and controlled as one set. A manual
scheduler may also be added to allow users to set their own unique schedule and light
alarms. The light may also be adjusted via a light sensor, reading in the intensity of the
light outside and then dimming the lights to preserve energy. Finally, the system may
include a fail-safe system to detect if and when lights may be failing, and help identify the
problem in that node.
3.2. Node-Mesh Network Requirements
In order to change the lights effectively, the nodes in the node-mesh network shall
communicate data properly and securely, ensuring that only the right nodes get the data
and commands they need. They shall also communicate in a timely manner, ensuring that
system adjustments and changes begin within 5 seconds. The commands to change each
5
node shall come from the gateway, which shall be connected to the machine vision system.
Each node shall have the hardware capable to run the lights effectively, including a power
supply to power the LEDs, the ability to adjust the intensity of each LED, and hardware
for the node-mesh network. The hardware shall be designed to consumer electronics
specifications, and shall be for indoor use only. This is just a base requirement, and as the
project progresses, will be revisited and updated based on the specifications needed in a
hospital environment. Should a node need to be replaced, the network shall easily integrate
and categorize the new node. The gateway shall be a small but powerful computer with the
ability to tap into the node network and run the machine vision software need for
recognizing the users and potentially their actions. The gateway shall be connected via
Ethernet for a reliable connection to the internet to ensure the accuracy of the time.
The network could also be improved by giving it the ability to self-organize. This means
that once the lights are installed, they will know where in the building they are, as well as
where they are with respect to other nodes. They may also be able to self-heal any issues
that might arise. For example, if when the meshes are being brought up two networks are
formed, they should automatically merge into one network.
3.3. Machine Vision Requirements
The machine vision shall use a camera to recognize objects entering and leaving the room.
The objects shall be classified, with actions only occurring when a human is recognized.
The threshold for human recognition will be set to a high percentage based on the model
used, with reading less than that discarded. The machine vision shall control the systems
actions by turning the system on when it detects a human in the room, and turn or dim the
lights after a set time once the human leaves. Data, if needed for training or improving the
model, shall be stored in a secure, encrypted manner, restricting access to only the machine
vision software. Any data not needed will be discarded after the time of recognition. The
IP camera shall connect securely to the processing gateway, sending data in an encrypted
format. The camera shall have enough resolution to ensure a correct recognition can occur.
The machine vision system can be extended in many different directions and offer many
improvements. It may be trained to detect what activities people are doing in the room. For
example, the system may notice that the user is opening a book, and adjust the lights to
help the user read, or see that the user is sitting down to watch a movie and dim lights for
a more entraining feel. It may be trained to recognize users and adjust lighting preferences
based on who is in the room. It may be able to track users throughout the house, dimming
lights in one part of the room while turning sets of lights up. It may also recognize key
gestures, giving the user the ability to use manual turn off, dimming, or brightening
commands. These actions and ideas can be extended and developed based on the
development time available.
6
4. Task Specifications and Schedule
Figure 2: Task Specification Graph
7
Figure 3: Individual Task Diagram
5. System Architecture
5.1. System Communication The basic design of the system begins with the communication between the machine vision
gateway and the ZigBee light network. First, assuming the camera has infrared capabilities,
the camera will use its infrared sensors to get a basic black and white image of the room.
The camera will continually grab images of the room, using a pre-trained model to classify
any objects of relevance found. If the classification returns an object classification of a
human that is above an appropriate recognition level based on the model used, the system
will send out commands to turn the lights on or off. The system can also react to when
humans interact with key objects. For example, if someone goes and sits in front of the TV,
the vision system automatically sends out commands to dim the lights. Similarly, when a
book is opened, the lights receive commands to increase their warmth and decrease their
cool LEDs, creating a more pleasant reading environment.
The ZigBee gateway will then distribute the instruction to the correct nodes via a serial
command structure that was created. Each command gets sent to the ZigBees via a serial
signal, and the light controller reads in and parses that serial code. Each node and its
location will be stored on the gateway so that it will be able to selectively send data to
8
whichever node is specified. The nodes will be in the same connection group, sending the
encrypted data between nodes with each node having a key. Since only the nodes in the
connection group have valid keys, this will prevent the sniffing of data. If the gateway is
not connected directly to one of the nodes, the data will be passed from node to node until
it reaches the proper node. The nodes will then use the received data to change the light as
specified. A block diagram showing this system can be seen in Figure 4.
Figure 4. Block diagram of the system communication of LED-Lux
To model this system, the team created a small demo utilizing the same architecture. The
gateway acted as the classifier for the vision system, pulling in an image and classifying it.
It would then send out a character code for the lights to parse. For the demo, a three
character code was used. The first character designates which node is being addressed, with
0 being all the nodes and 1, 2, or 3 being assigned to the other three nodes in the system.
The second character would designate what the command to be run is. For example, “b” is
for adjusting the brightness, “w” for adjusting the warmth of the lights, and “c” for
adjusting the coolness. Because the commands are sent via serial, the system is cross
platform, allowing for the python program running on the gateway to communicate with
the C program on the lights. Figure 5 shows a diagram of this system.
9
Figure 5: Diagram of the lighting demo
5.2. Machine Vision Architecture
A machine vision system will allow the system to automatically turn on and off depending
on if a person is in the room. The general system is that there will be a infrared camera
placed in a part of the room that allows a complete view of the entire room. The camera
would capture data at around three to six frames per second. The data will be sent
encrypted over an internal network, separated on its own VLAN. Then, using a pre-trained
model, the images will be classified on the edge, allowing for a quicker response. Once
classified, the images will then be pushed through a set of algorithms to track the subject
as they move through the frame, as well as find any interactions with key objects occuring.
In most cases, the images captured will simply be parsed and deleted after processing,
unless the system needs more training. In the case that the system fails to recognize a
human, the frames in which it occurs will be sent to the training server to retrain and
improve the system, all the while being securely stored. The processing would occur on
the gateway, which would issue the commands to dim the lights or toggle them. The system
would search for human figures, ignoring other movement or objects in the room, as seen
in Figure 6.
10
Figure 6. Discerning different figures via machine vision
There are a couple of key nuances when designing this system, the first of which is model
accuracy. While it would be nice to give a sure percentage cut off of what constitutes a
found object for the machine vision, it is impossible to make a sure cut off without knowing
the model. For example, models designed for maximizing accuracy would have a much
higher tolerance than ones designed for speed. This is because in machine vision, models
have a trade off between speed and accuracy. The faster the model, the lower the accuracy.
Because this system would most likely do the classifications on the edge of a system, the
model used would most likely be a model designed for speed. This means that the cut off
percentage would be lower, around 50%. This doesn’t mean that this model is bad,
however. Some interpolation can also be used to improve the accuracy. For example, when
the system often gets a mediocre reading, it’s often because the object is in the frame, but
the system is not sure enough to give it a high percentage. This can be used to help
interpolate if an object is still in a frame after it is detected. For example, if a banana is
detected in frame one with 59% accuracy, but in frame two the accuracy drops to 36%
because the banana was turned, the system can assume the banana is still the frame but
perhaps turned or partially hidden. The system can then keep assuming the banana is in
frame if the accuracy is above a smaller threshold, say 25%, for a short amount of frames
or until it gets a reading of above 50% again. This ensures a smooth transition between
frames and reduces dropped detections significantly.
The other consideration is that when trained with proper data, the system will be quite
accurate. Proper data includes pictures taken by the camera the system is using and keeping
the data accurate and relevant. For example, if using an IP camera with infrared, the system
should be trained with a plethora of images taken in both the full light and infrared light.
The data also needs to be relevant, as bad data could hurt the accuracy. The system also
11
needs diverse data. For example, if training to detect humans, the data used for training
should include tall people, short people, people of all races and ethnicities, long haired
males and short haired girls; as much diversity as possible. This diversity leads to accuracy,
as models detect what they are trained to detect. Adding diversity ensures that all people
are detected, creating a robust system.
To demo the machine vision system, a real-time classification program was created using
Tensorflow, Google’s Object Detection API, and OpenCV. The model used was a pre-
trained model from Google based on the COCO dataset and based on Google’s Mobilenet
architecture. It was designed for running in a mobile environment, making it perfect for
being run on the gateway, an NVidia TK1 development board. The system has two steps.
First, it classifies the images using the Object Detection API. This API was chosen since
Tensorflow is currently one of the more powerful machine learning environments, and the
API makes it easier to take advantage of the models. It also opens up many useful options,
such as specific classes, bounding boxes, scores, and keypoints. To speed up the
classification, the system utilized Python’s Multiprocessing library. This library allows for
multiple classification instances to be running, increasing the number of frames that can be
classified at once. This allows the system to work more efficiently and quickly, increasing
our frame rate. A diagram of this process is shown in Figure 7.
Figure 7: Image classification process
After the image is classified, the system goes through some algorithms to track the location
of all the subjects in the frame. By adding a midpoint to the bounding boxes and analyzing
the movement of the boxes and the midpoint, algorithms were developed to following
people as they move through the frame. This allowed for certain lights to be toggled when
the detected human moved from one region to the next. Smoothing was also added to the
12
movement to ensure accuracy. This is because the bounding boxes given fluctuate from
frame to frame, sometime unpredictably. For example, a person might be moving back in
the frame. In the first and third frame, the bounding box would follow the pattern seen in
the algorithm, but in the second frame, it would show that the person was actually moving
forward. By adding an averaging over a couple frames, these inconsistencies could be
smoothed out, and the true direction found. This process is shown in Figure 8.
Figure 8: Image processing flowchart
5.3. LED Driver Architecture
As part of the demo, the team created a LED driver stack to drive the lights we created for
the demo. In a hospital system, each of these lights would be bigger, providing enough
light to illuminate the entire room. The driver consists of three parts. First, the LED driver.
This the is the power regulator ensuring that the LEDs get the amount of voltage and current
needed. The driver used in the demo is the Infineon XMC 1200, a version of which could
be used in the lighting system. This driver is has a few key features, the biggest of which
is the brightness control unit. This chip is designed to regulate and deliver precise voltages,
which ensures that the color temperature of the LED is stable. This is key, as the system is
designed around providing accurate color temperatures. The driver is then controlled via
I2C from a microcontroller. For the demo system, an Arduino UNO R3 was used; however,
in the lighting system, a similar ATMega chip could be used. This microcontroller is used
to parse the commands from the ZigBee as well as issue commands to the LED driver. This
generic system can be extended to a larger system, allowing for the lights to scale. The
driver architecture diagram is shown in Figure 9.
13
Figure 9: LED driver software architecture
6. Design Criteria As a part of the Calvin engineering curriculum, students are made aware of how their Christian
faith sets criteria for their work. There are seven basic Christian design criteria. Cultural
appropriateness deals with ensuring that the design does not insult the traditions of its intended
users. Openness and communication ensures that all important information relating to the project
is easily available. This norm fits with trust which details design dependability. Stewardship deals
with protecting the environment and effectively using resources. Smoothly integrating into people’s
lives is described by the delightful harmony norm. Justice involves improving equal opportunities
and quality of life between groups of people. Caring ensures that the design helps those in need.
Though each norm applies to every project, openness and communication, caring, delightful
harmony, and justice are specifically addressed by LED-Lux.
6.1. Openness and Communication
Transparency is important for LED-Lux because the system gathers and processes data
using a camera, and potentially holds onto that data for retraining. The intentions and
means of these features were made clear to ensure those who are concerned of this
potentially intrusive technology. One of the ways this was be done is through thorough
documentation and using GitHub so that public has access to the source code of the project.
Though the team was upfront with the details of their project, it is foreseeable that some
information may become the property of DornerWorks, the team’s sponsor.
14
6.2. Caring
Caring for other people is at the heart of LED-Lux. Built to improve the indoor lighting in
hospitals, care for patients and medical professionals was at the forefront of our design. In
discussing the project with friends and loved ones, each team member received comments
that time spent in hospitals would be improved immensely by better lighting. However, the
team was only able to provide what is predicted to be better lighting. Objective studies
must be done on the whole LED-Lux system before any claims can be made. This is a part
of openness and communication, ensuring that the effects are not overstated.
6.3. Delightful Harmony
Delightful harmony is integral to LED-Lux. The overall goal of the system was to
seamlessly fit into its users’ lives. LED-Lux simplifies spaces by combining supplementary
lights, such as night-lights and therapy lighting, into overhead lighting that requires
minimal user input by adjusting automatically with the help of the machine vision. The
ideal system would adjust itself automatically, creating the perfect indoor lighting
environment intuitively and naturally. Unfortunately, delightful harmony competed with
both time and cost restraints. Within the given time period, the team built a demonstration
of the proposed system that showcased lighting features while stylishly and seamlessly
blending into any given space.
6.4. Justice
LED-Lux was designed to give all people access to the light they need to stay healthy.
Though light does not discriminate, the models used in the machine vision have the
potential to. The machine vision feature of LED-Lux allows the lights to adjust to users’
actions. The team used a model pre-trained by Google based on the COCO dataset. While
the dataset is large, containing 330,000 images, the demographics of the images used to
classify the humans are not known. This could cause issues when the system uses the model
to classify humans, specifically when it comes to characteristics such as skin color, hair,
and other features. For example, some models have issues detecting people with very dark
skin. An ideal version of LED-Lux would be trained using an intentionally diverse group
of people, including amputees, handicapped persons, and people of all races, so that the
benefits of smart lighting controlled by machine vision can be enjoyed bywall.
7. Design Alternatives
7.1. Fixture Design:
When choosing a fixture, it was vital to consider not only the look of the frame that holds
the lighting but the type of material that encases it. The shape and size of the fixture was
also crucial to creating the optimal lighting experience. The material of the fixture was
15
important because it directly affects the weight, durability, and reflection of light.
Additionally, the materials used impact on the environment and were selected in reference
to the stewardship design norm. Anxieties and other traumas can be exacerbated by
exposure to harsh lighting, and so, the shape of a lighting fixture, which controls light
exposure, can have positive or negative effects on human functions. To fit with the major
design norm of caring, the team focused on ensuring the design helps, not hinders,
especially in a hospital setting. Not only that, but the brightness must be able to fill a whole
room with light so that there are no unnecessary light fixtures, ensuring the delightful
harmony of the room. All of these factors have a direct influence on the cost and
optimization quality of the lighting system.
7.2. LED Design and Implications:
The LED market is vast with many types and brands with many different hues and colors
of lights. The goal of the project is to be able to design a full solar lighting spectrum that
emulates a more natural light. Since there are only a limited number of LEDs one can put
in each node before it becomes over budget, the team hopes to make the most they can get
out of each LED. LEDs may come in multivariable white lighting (cool vs. warm);
however, they also come in the RGB scale which adds the ability to create a full solar
spectrum via tuning the intensities of each LED. In short, there are many design alternatives
with the combination of LED colors, being affected by not only the spectrums of the LEDs,
but the industry standards as well.
7.3. ZigBee Communication and Module:
ZigBee is a type of communication protocol between devices. Although ZigBee will offer
all around flexibility by creating easy connections between the controlling gateway and the
lighting nodes, there are other options of node-mesh communication protocols that could
be used. Wireless connection range, types of modules, and compatibility with other systems
are also variables to be aware with when deciding which node-mesh communication
protocol to use. Alternatives to using the ZigBee included the use of a WiFi Direct, but
difficult security and discussions of connection issues eliminated that option. The new
Bluetooth 5.0 was an alternative as well. However, being a new technology, it does not has
a much support and development behind it as the ZigBee protocol. Because of the resources
and help behind ZigBee are much greater, it allows for more ease of development. ZigBee
is also the de-facto standard for wireless control in the lighting sector, being used in many
lighting products such as LimeLight and Philips Hue lighting systems.
7.4. Machine Vision and Webapp Control
Part of the decision when imagining what the system would look like included whether the
focus would be on the machine vision component or the web app. By focusing on
controlling the lights via the web app, the team would be able to make a more user-friendly
16
interface with many different modes of operation. On the other hand, if the team focused
on controlling the system with machine visioning, then there would be time to do precise
sensing techniques within the design, as well as exploring an up and coming field. With
both of these alternatives, the openness and communication design norm is key. In both
cases, data will be collected and used to analyze the user’s patterns and activities in order
to optimize the system. Being open about what data the team collects and analyzes is key
to this project.
8. Design Decisions
8.1. Project
During the summer of 2016, Reuben did research on high-power LEDs with Professor
Yoon Kim at Calvin College. This inspired Reuben to work with LEDs for his senior design
project. He was interested in finding an implementation for the range of colors and
temperatures low-power LEDs can produce. The team brainstormed options and came up
with a service-oriented use and design to integrate and improve a hospital’s lighting, an
idea that excited each member of the team. This was cemented when Anna visited her
grandpa in the hospital and the thing he complained about most was the harsh lighting.
8.2. ZigBee
A ZigBee network was chosen to control the lights in the proof of concept. ZigBee is a
low-cost, low-power, scalable wireless network that fits the team goal of delightful
harmony. There are many resources available that will make the implementation and
integration of ZigBee simpler than other wireless networks. ZigBee can also be configured
in a mesh network that is self-healing and has a greater range than point-to-point options
like Bluetooth (BLE).
8.3. Machine Vision
The team decided to incorporate machine vision because of their connection with
DornerWorks. DornerWorks agreed to invest in the project if the team provided innovation
in the machine learning realm and implemented it in their design. Because of this addition,
the user interface had fewer features, being used for more debugging than user control. The
system acts more “automatic” by sensing when someone enters and leaves a room and
keeping track of occupancy (for the minimum viable product). This increased the delightful
harmony element of LED-Lux. Key object recognition was implemented, but recognizing
if the object is in use versus just present is not yet functional. Ideally, this would recognize
if someone is watching TV, reading, or sleeping. The system would then communicate
through the ZigBee network and adjust the lighting accordingly.
17
8.4. Fixture Design
A light box design was used for the final proof of concept. Models of this design are shown
in Appendix C. The light box design was chosen above a 3D printed fixture because it
would be simpler to modify, easier to build, and would allow superior materials to be used.
The light box was primarily made from Baltic birch plywood and frosted microprism panel.
Baltic plywood is a high-quality plywood used in the cabinet industry. It was selected by
LED-Lux for its durability and aesthetics. Frosted microprism panel was a natural choice
for the light box because it is designed to blend and blend the light of LEDs.
The overall box was designed to be aesthetically pleasing while still offering access to the
boards it housed. This was done by having a thin, dark plywood frame which would make
the unit appear light and offer contrast against the glowing LEDs. All components were
accessible from the back of the box. A slot was cut into the back panel so that the box
would not need to be disassembled for the boards to be flashed.
9. Integration, Test, Debug LED-Lux has many components, each of which need to be tested exhaustively. The ZigBee
nodes, web app, and machine vision are the main components.
9.1. ZigBee Network
There are multiple tests that the ZigBee network must pass. The nodes must connect and
be assigned addresses automatically. The hardware must be tested for range both with and
without line of sight (through-wall). After connection is tested and debugged, the output
must be tested by forcing inputs and seeing the change in light. The final ZigBee
requirement is communication with the both web app and machine vision running
simultaneously, ensuring the protocol and command structure works with both systems
running at the same time.
9.2. Web Application
The web application is used for system integration and gives the user a low level of control
over the system. The communication between the web app and the ZigBees will be tested
with simple output from the app that prompts a simple change in the LEDs. The tests for
this app were based around basic functionality and sending conflicting signals with the
machine vision input.
9.3. Machine Vision
The machine vision component of the project was supported by DornerWorks. The system
was able to identify objects in multiple environments. The tests it must pass are storing
data correctly if storing, using the data to impact the behavior of the nodes, detecting the
18
correct number of people in a room, and dimming the lights correctly according to the
input. Testing methods include using a test room to see how the system interacts with a
space, entering the room in the camera’s line of vision and monitoring the input, and
making sure the output of the machine vision controls the ZigBee network in the correct
way. Other tests include flooding the room with people to see if it can handle all the
detections, testing the system for a long period to ensure that it doesn’t overload the system,
and testing fringe detection cases.
9.4. Fixture
The fixture environment was tested in relation to the heat dissipation it allowed for. The
light was turned on at full brightness and intensity for two hours and the temperature was
recorded. A graphical summary is shown in Appendix D. The temperature of the room was
25 degrees C to begin with, and the peak temperature that was recorded was 29.5 deg C.
This is an acceptable amount of heat given the conditions. When the room itself began to
cool, the inside of the box did as well. This confirmed our calculations and SOLIDWORKS
models involving the heatsink.
10. Business Plan
10.1. Marketability
10.1.1. Competition
Currently, there are only a few lighting companies providing a variable
temperature lighting solution. Of those companies, many tend to be one time
projects, such as the Seattle Mariners clubhouse [2]. Other current solutions
include lighting systems such as Philips Hue. These systems target consumers and
home markets, whereas LED-Lux is targeting more industrial and business
customers. The biggest competition in these markets are normal LED systems,
since the customers being targeted would be those looking to make the switch from
fluorescent lights to LEDs. In order to win customers over, marketing would have
to focus on not only the energy savings from switching to LEDs but the
productivity and worker satisfaction improvements seen in recent studies [3]. This,
combined with the futurism and cool factor of the machine vision and extra energy
savings from a smarter lighting system would convince the customers needed to
purchase a system. Another focus is the different types of lighting people want for
different areas of the hospitals. For example, waiting rooms should be designed to
help anxious patients relax. While most other companies have multiple lights for
each situation, the highly configurable nature of LED-Lux could make it suitable
for many different environments, giving it a leg up on the competition. Overall,
LED-Lux outshines the competition, being unique and highly configurable.
19
10.1.2. Market Survey
Lighting is incredibly important in hospitals. Needed for patient care, giving proper
diagnosis, and for creating a welcoming and caring environment, light plays a huge
role in a hospital setting. As many older hospitals begin to update their facilities
and new hospitals are being built to accommodate the rising demand of healthcare
in the United States, the market is wide open for LED based projects to be
implemented. The key is to create a system that is irresistible to hospitals, covering
all their bases for lighting needs as well as creating a better, more restful
environment for their patients. By anticipating and meeting both the needs and
wants of a hospital, LED-Lux can take over the market, improving lighting and
patient care throughout the country.
There are other markets LED-Lux could break into as well. As office’s look to
reduce costs, more efficient LED lighting is being installed, and LED-Lux can
meet the needs and more of these office systems. Adding lights similar to LED-
Lux have shown to increase focus and productivity, as well as office moral [3].
In a similar way, LED-Lux could be used in schools to help students learn. On
Senior Design Night, three different educators and an architect talked with the team
about how this lighting system could make an impact in schools. This is a growing
market as well, as many new schools are being built with the focus of create a
perfect learning environment for kids. By entering into this market with firm
research behind the beneficial properties of these lights, there could be a huge
market in the education sector. In the end, there is a lot of potential room for LED-
Lux to grow, and with proper marketing and outreach, LED-Lux could be the go-
to lighting system for many different markets.
10.2. Cost Estimate
10.2.1. Development
When developing this system, there are three main teams needed. First, a hardware
design team is needed to develop the lighting system and LED driver board. Many
of the components used the design could be synthesized together, creating a
smaller and more unified board. This board would have three main components,
starting with the main microcontroller. For the demo, an ATMega was used, but
that contained more power than was needed. Switching to a smaller, power sipping
microchip such as an ATtiny would make the system run more efficiently, without
losing too much in terms of power. The second part is LED driver portion, which
will be communicated to via I2C from the ATtiny and be driven by the Infineon
XMC 1200 microchip. This will control the two different channels of light, as well
as the voltage and current control circuits. The system will take power from a
standard power outlet, so the LED driver will work to regulate that power
distribution to the LEDs. Finally, the ZigBee radio will be integrated into the
20
board, with the antenna be routed out to allow for a strong signal to be received.
Overall, this should not be too difficult of a task for experienced engineers, with
an estimated work time of around 192 hours total split between three engineers.
Another 288 hours would also have to be used to create a camera system that
process the images quickly and efficiently. In order for this project to be effective,
the images must be processed and classified on the edge, ensuring a speedy
response to the lights on detection. This would require a strong processor, such as
NXPs i.MX8 chip or another microchip based on the ARM’s A57 processor
architecture, as well as some sort of classification acceleration, potentially using
Intel’s Modulus chipset. By creating a custom SoM and integrating it into the
camera, the classification can be done quickly and cheaply. This will take more
time however, as it is a more difficult task, and so the 288 hours would be split
between a larger team of five engineers.
The second team would be focused on ensuring that the software works well,
encompassing everything from the control panel to the machine vision. While the
control panel might not be that big of a task with and estimated 96 hours for three
developers, the machine vision will need a lot of work to make it ready for
production. A basic system could be brought online quickly, but a more robust
system will a well trained model and the AI features to make this a viable product
will take more time. With a larger team of five engineers, the total amount of hours
needed should be around 600. However, the vision system could also be done in
an Agile manner. This would allow for the system to be deployed while the
developers were finishing up and fine tuning the extra and more robust features of
the system, potentially cutting the development time to get the product to market
by a third.
10.2.2. Production
Bringing this system to production would not be too expensive. As it is using
standard parts and microchips, production of the lights would be inexpensive.
However, installation would be the biggest cost of this system. Integrating it into
a current hospital’s infrastructure, both physically and with their IT department,
would be a big expense. Creating guidelines, steps, strict deadlines, and processes
would help drive these costs down by creating structure to how the lights get
implemented. Having a strong and proven process would allow for everything to
be integrated as smoothly as possible, reducing the cost and frustrations of such a
project, as well as ensuring that everything is done properly and securely.
11. Conclusion A prototype for a smart, scalable lighting system that meets all the criteria was made and tested.
Additionally, the system was used as means for exploratory research in machine vision, looking
into the areas of figure recognition and location tracking. With the help of DornerWorks, the team’s
21
advisors and other industry contacts, the team believes that this project was not only viable but
innovative, changing the way lighting design will be done into the future.
12. Acknowledgements We have worked very hard on this project; however, it would not have been possible without the
assistance of multiple people. We would like to thank our advisor Mark Michmerhuizen for the
guidance he has provided to us throughout this project. The people at DornerWorks and the
University of Michigan have aided us in the research and design phase of our project, helping us
move forward quickly and efficiently. We would also like to express our gratitude towards the staff
at Calvin College for assisting us in design through information on vendors.
We know we would not be at Calvin College or able to take on a project like this without the support
of our families and friends. The support we have received has been instrumental in our success.
22
13. References [1] “NHBL Workshop: “Circadian Clock at the Interface of Lung Health and Disease” 28-29 April
2014 Executive Summary”. National Heart, Lung, and Blood Institute. September 2014.
[2] “Seattle Mariners Pilot Project.” Human Centric Lighting, Human Centric Lighting Coalition
, humancentriclighting.org/seattle-mariners-pilot-project/.
[3]Walerczyk, Stan. “Human Centric Lighting.” July 2012, humancentriclighting.com/wp-
content/uploads/2012/07/Stan-Article-SSL1.pdf.
23
Appendix A Team 06 project schedule
Each date marked shows what should be completed by that time
24
Appendix B Team 06 final budget
Calvin Budget:
DornerWorks Budget:
Hardware and Fixture Budget:
Commented [1]: Update the budget.
Commented [2]: Is this a confusing format?
25
Appendix C Fixture Design
SOLIDWORKS Model of Light Fixture
Commented [3]: This appendix needs a number, and should be referanced in the report
26
SOLIDWORKS Model of Fixture with Side Panel and Diffuser Removed
27
Appendix D Temperature test
SOLIDWORKS Study of Heatsink with 295 K Ambient Temperature and 2.48 W Load
28
Graphical summary of temperature test data.