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.